Teraz może coś o naszym małym zespole, o którym raczej też należy wspomnieć. Głównym pomysłodawcą i programistą gry jestem ja, Denis. Pomysł na DevTycoon miałem już na początku 2017 roku, lecz brakowało mi umiejętności kodowania oraz modelowania. Jednym z pierwszych pomagierów został mój najlepszy internetowy przyjaciel, Jakub, który odpowiedzialny jest za całe otoczenie w świecie gry oraz trochę za działanie gry. Jako że to on najwięcej czasu poświęcił w granie gry na jego youtubowym kanale, został on moim prywatnym doradcą w sprawie responsywności interfejsu oraz ogólnie całego gameplay’u. Z tego miejsca mogę też wspomnieć o dwóch innych osobach, mianowicie o Staśku oraz o Wiktorze . Stasiek bardzo dużo pomaga przy zaawansowanych modelach , to dzięki niemu Auta mają wnętrze, a komputery to nie klocki, niczym z Minecraft’a. Wiktor przygotował dla Was stronę , którą będzie z czasem rozbudowywał pod Betę oraz Alphę. I teraz najważniejsza grupa, czyli Testerzy przedpremierowi. Bardzo chciałbym podziękować Root’owi oraz iLiquid’owi za udział w testach, które pomogły nam wyłapać głupie, aczkolwiek ciężko wykrywalne błędy. Ogólnie, gdyby nie te wszystkie osoby, gra by najprawdopodobniej nie powstała, bo by mnie to autentycznie przerosło.

Teraz chyba odpowiedź na pytanie, na którą wszyscy czekają. Czym DevTycoon będzie różniło się od innych tego typu gierek? W sumie, to niczym, oprócz tego, że chcemy zapożyczyć wszystkie udane pomysły, dodać do nich troszkę oryginalności i wszystkie włożyć pod jedną maskę. Np. w Simsach da się wchodzić w zaawansowaną interakcję z simem, u nas będzie podobnie, lecz trochę mniej zaawansowanie i bardziej pod temat programowania. Teraz zostają wszystkie inne gierki: Mad Games Tycoon, Game Dev Tycoon, StartUp Company oraz Software Inc. Każda z tych gier jest poświęcona innemu tematowi w dziedzinie programowania. W jednych możesz programować gry, w drugich antywirusy, a w jeszcze innych możesz robić nawet strony internetowe. Co by się stało, gdyby to wszystko połączyć w jedną całość? Podjęliśmy się zadania, aby to sprawdzić.

Co dalej z grą? Nie wiemy. Jeśli Demo Technologiczne wyjdzie znakomicie , a opinie będą w miarę dobre, to będziemy starać się rozwijać grę jak najlepiej, a w przyszłości wydać ją nawet na steamie. O fundingu na razie nie myślimy. Być może założymy Patronite, aby najbardziej zainteresowane osoby mogły nas wspierać finansowo, ale bardzo staramy się robić wszystko samemu .

// Krótki gameplay z gry zostanie dodany, kiedy będzie on gotowy.

Link do pobrania znajduje się na stronie: https://devtycoon.com/

Podsumowując: Wszelkie pomysły i uwagi na temat gry prosimy kierować na nasz adres Email: [email protected] , na wszystkie postaramy się odpowiedzieć.

Trochę screenów:

Ta historia nie jest dość długa, ale mam nadzieję, że kogoś to zainteresuje. Najpierw zacznijmy od mojego życia, od moich początków z programowaniem, bo to ma bardzo duże znaczenie dla LockMe.

Trochę o mnie oraz o pomyśle na LockMe

A więc nazywam się Denis i mam 14 lat. Programowaniem zainteresowałem się gdy miałem 10 lat wtedy dostałem od kolegi jego „program” napisany w Batchu. Chwalił on się tym że można zmieniać kolor tekstu i przechodzić pomiędzy menu. Ja jestem takim typem człowieka, że jak ktoś mi się chwali to zazwyczaj muszę to zrobić lepiej, więc od razu szukałem na YouTube frazy „Jak zrobić program w notatniku” .

Po dwóch dniach napisałem swój pierwszy pseudo-program, który potrafił to co program mojego kolegi. W tym samym okresie wyprowadziłem się Niemiec, a konkretnie do Bayernu. Początki w Niemczech były bardzo trudne, więc trochę odstawiłem na parę miesięcy Batcha na rzecz uczenia się języka niemieckiego, lecz już po paru miesiącach wszystko się ułożyło i miałem chwilkę na programowanie.

Stwierdziłem, że Batch jest troszkę nudny, a wtedy nie posiadałem innego edytora niż systemowy Notatnik, więc postanowiłem poszukać nowego języka, a był nim Visual Basic. Pisałem w nim przez wiele miesięcy, ucząc się przy tym czym tak naprawdę jest programowanie oraz Syntax. Nauczyłem się bardzo wiele przez ten paro-miesięczny proces, aż do momentu kiedy wyjechałem do Polski na wakacje i tam z moim kolegą wpadliśmy na pomysł nowej aplikacji. Było to tak, że byłem u niego i zobaczyłem tabelkę w Excelu, która pokazuje mu ile wydał oraz ile zarobił. Odrazu wpadłem na pomysł stworzenia aplikacji o nazwie „Liczydło”. Postanowiłem to zrobić w Visual Basic , ale moje zdolności oraz Technologia na to nie pozwalały. Porzuciłem projekt do momentu, aż poznałem mojego nowego kolegę, który doradził mi abym przeszedł na C# . Jak postanowiłem tak zrobiłem. Za pomocą C# miałem możliwość zrobienia pierwszej wersji Liczydła , która była bardzo okrojona, patrząc na to dziś:

Potem tak się potoczyło że Liczydło nazwane zostało LockMe i doszło do stanu tego który teraz widzicie.

Lecz co tak naprawdę się zmieniło?

W pierwszej wersji LockMe wszystko było zapisywane w pamięci podręcznej. Czyli jak się wyłączyło LockMe to automatycznie cały save przepadł. Dlatego przestawiłem się na zapis do pliku . Nie był on skomplikowany ani zabezpieczony. Po prostu był, działał i pełnił on swoją funkcje, aż do momentu kiedy ktoś mi napisał, abym stworzył aplikację na telefony . Postanowiłem, że tak zrobię, lecz był jeden problem. Chciałem zrobić tak, aby była synchronizacja między LockMe na PC oraz LockMe na Androida. Na taki system nie pozwalała mi technologia zapisu do pliku tekstowego dlatego porzuciłem ten pomysł. Przez kolejne 2 miesiące powstały LockMe 1.2 – 1.5.2 oraz LockMe Biznes, który nie miał swojej premiery. LockMe 1.5.2 to aktualnie najnowsza dostępnie publiczna wersja LockMe, lecz nie polecam jej pobierać bo za nie długo wyjdzie LockMe 2.0.

A więc czemu LockMe 2.0 to taki skok do przodu i jakie mam plany?

LockMe 2.0 posiada obecnie całkowicie nowy system zapisu do bazy danych . Pozwoli mi to na synchronizacje między telefonem i komputerem , ale też pozwoli odpalić LockMe na innych komputerach. Pierwsze wersje LockMe 2.0 miały na cel posiadać tylko nowy wygląd, lecz postanowiłem się nauczyć MySQL i zaimplementować to do LockMe.

Aktualnie pracuję nad LockMe na komputery, a pierwsza wersja będzie miała premierę 14 października, natomiast na LockMe na telefony będziecie musieli poczekać jeszcze parę tygodni.

LockMe początkowo miało być asystentem, który posiada wszystko. Na szczęście grupa Nastoletni Programiści wybiła mi ten pomysł z głowy i LockMe to będzie aplikacja o funduszach.

I jestem z tego bardzo zadowolony.

Dziękuje, pozdrawiam.

Przytoczę pewne bardzo obrazowe porównanie. Wyobraź sobie, że jesteś w restauracji. Podnosisz menu, wybierasz potrawę i czekasz na kelnera. Widzisz, że tymczasowo obsługuje innego klienta. Mija kilka, kilkanaście minut, a kelner wciąż stoi przy stoliku innego klienta, obsługuje tylko jego. Dopiero, gdy klient płaci i wychodzi z restauracji, kelner podchodzi do Ciebie i zaczyna cię obsługiwać. W tym czasie przychodzi inny klient, ale kelner jest zajęty tylko tobą. Mniej więcej tak działa aplikacja jednowątkowa (nasz kelner). W oczywisty sposób jest to nieefektywne.

Wtedy niczym superbohater, przybywa wielowątkowość.

Super! A więc zyskujemy trochę wydajności. Jednak rozważmy ten kod w języku C# i przeanalizujmy go.

Co tu się dzieje? Program sprawdza czy plik examplefile.txt istnieje, jeżeli nie, tworzy go. Teraz przejdźmy do tego, dlaczego kod ten nie jest bezpieczny. Jako, że dziś mamy do czynienia z wieloma procesorami (rdzeniami), to w tle mogą działać równocześnie różne programy. Nie ma więc żadnej gwarancji, że jeden z nich nie utworzy pliku o nazwie examplefile.txt właśnie w tym katalogu. Rozchodzi się więc o moment pomiędzy otrzymaniem informacji, że plik nie istnieje, a utworzeniem go. Klasa tego błędu to tzw. Race Condition . Aby uniknąć takich sytuacji, wymagana jest synchronizacja.

Najprostszym używanym niskopoziomowym mechanizmem do synchronizacji są tzw. Spinlocki (w luźnym tłumaczeniu – kręcące się blokady). Jest on w zasadzie aktywną pętlą, która czeka, aż dany obiekt (blokada) zostanie zwolniony. Dziś w zasadzie się z nich nie korzysta, gdyż nowoczesne języki takie jak C# mają wbudowane mechanizmy synchronizujące, takie jak lock . Lock działa w ten sposób:

i jest równoważny temu:

gdyż lock jest w zasadzie aliasem tego drugiego. Teraz, zanim przejdę do spinlocków, wytłumaczę z pomocą Wikipedii czym jest owa sekcja krytyczna.

Sekcja krytyczna – fragment kodu programu, w którym korzysta się z zasobu dzielonego, a co za tym idzie w danej chwili może być wykorzystywany przez co najwyżej jeden wątek.

Myślę, że ta definicja spokojnie wystarczy. Przejdźmy teraz do Spinlocków.

W C++ można podejść do tego na prawdę prosto, jest to zwyczajnie (jak już pisałem) aktywna pętla. Wygląda to mniej więcej tak (korzystając z biblioteki <atomic> służącej właśnie do synchronizacji, i jak sama nazwa mówi do operacji atomowych):

Dzięki Spinlockom możemy także zsynchronizować uruchomienie wątków, aby wystartowały w mniej więcej tym samym czasie, co można zaimplementować bardzo prosto:

Wówczas nasza blokada może blokować(?) wykonanie wątku tak długo, jak programista sobie zażyczy. Słówka volatile użyłem, gdyż nie chce, by kompilator potraktował tę pętle tak:
if (slock != THREAD_COUNT) while(1); a tego oczywiście nie chcemy.

C# również udostępnia nam mechanizm spinlocków, ba, w zasadzie całą strukturę! Napisałem tu krótki program implementujący Spinlock:

Przeanalizujmy, co się w nim dzieje.

To by było na tyle, jeżeli czegoś wystarczająco nie rozwinąłem, albo macie jakieś pytania, zachęcam do komentowania!

Źródła

• https://msdn.microsoft.com/en-us/library/windows/desktop/ms683614(v=vs.85).aspx
• http://en.cppreference.com/w/cpp/atomic/atomic_flag
• http://www.c-sharpcorner.com/UploadFile/1d42da/spinlock-class-in-threading-C-Sharp/
• https://camedcomputing.wordpress.com/2016/03/31/wielowatkowosc-w-c-threading-locki-spinlocki /

Początek.

Sam projekt zaczął się prawie rok temu. Dokładnie wtedy gdy wystartował konkurs „Daj się poznać!” Zgodnie z zamysłem, ważne były trzy rzeczy : vive, fun i low poly. Miała to być zwykła gra typu „kill them all” z wsparciem dla Vive. Akcja miała się toczyć na małej, latającej wyspie w stylu Low poly. Poly. Jak się już domyślacie, była chooolernie brzydka, główny powód? Ja i grafika? Dobry żart. Jednakże, już wtedy działało wsparcie dla Vive. Krótki czas później wprowadziłem pierwszą arenę z już działającym AI stworzonym dzięki temu projektowi . Wyglądało to już wtedy troszkę lepiej, jednakże, to ciągle nie było to.

Wyglądało to wtedy tak:

Beabest

Zmieniamy tą cholerną mapę!

Niedługo potem postanowiłem pierwszy raz przebudować gruntownie projekt. Zmieniłem mapę, poprawiłem kod, pobawiłem się ustawieniami światła. Wyglądało to już o niebo lepiej, lecz ciągle nie było to tym, co chciałem. To nie było nadal TO. To nie był wygląd z moich marzeń i snów (Tak, duża część pomysłów, po prostu pojawiła się w moich snach.). Na całe szczęście mam jeden film i kilka screenów z tego okresu

View post on imgur.com

Gdy tak patrzę na te screeny, to nadal się dziwię jak długą drogę przeszła grafika tej gry, podczas gdy kod doczekał się kilku zmian logicznych by był po prostu szybszy. Ale wracając. W tym momencie, działała mi większość rzeczy, które chciałem umieścić w grze. Jednakże, później ich część została usunięta ze względu na głupi kod lub po prostu bugi. Zostało to, co działało idealnie. Po tym zabiegu postanowiłem się skupić bardziej na grafice. Tak o to dochodzimy do aktualnego stanu, a raczej jego bliskiej wersji!

To już ostatnia zmiana! Przysięgam… Kogo ja oszukuję?

Nietrudno się domyślić, że i tą mapę czekał smutny los, została posłana w otchłań. Na jej miejsce weszła nowa, wydawać by się mogło, że już właściwa wersja głównej mapy. Niestety, albo i „stety” tak nie było. Po zmianie, mapa główna wyglądała, a przynajmniej pod względem kolorów, jak ta ze snów. Była duża, bajkowa, cieszyła oko przez co aż chciało się zakładać Dreamz i testować. A właśnie, Dreamz. Zapomniałem o nich wspomnieć. Cóż, zrobię to na końcu artykułu gdyż z nimi jest inna, ciekawa historia! Wracając. Wtedy to kumpel podsunął mi pomysł, że po cholerę mi portale i areny, skoro wszystko może się dziać „jak w minecraft’cie”. Miał przez to na myśli, że główni wrogowie będą się non stop pojawiać na głównej mapie, a gracz będzie musiał przetrwać. Podsunął mi także pomysł na to by w nocy byli silniejsi i by wypadał z nich wtedy lepszy loot. Cóż, niedługo potem mapa była już gotowa i miałem się brać za pisanie algorytmu dla spawnowania ich. Jednak, przyszła do mnie „babcia niepewność” i zdałem sobie sprawę, że to nie wypali. Wyspy są za małe, znacznie za małe. Do tego, gracz miałby budować zabezpieczenie (mury, wieżyczki itp), które miały by pomagać w walce z hordami monstrów. To był już gwóźdź do trumny. Kolejny, tym razem ostateczny raz zacząłem zmieniać mapę.

I jesteśmy w aktualnym stanie.

Mój pomysł na aktualną mapę to kilka dużych wysp z portalami, oraz kilka jeszcze większych wysp z wrogami, ustawione dookoła wyspy-matki czyli wyspy gdzie leży miasto, w którym gracz rozpoczyna swoją przygodę. Nie mam za dużo z tego zrobione. Na ten czas, staram się by miasto wyglądało jak najlepiej, podchodzę do tego powoli bo poprzednie mapy mnie nauczyły, że tak będzie lepiej. Do zrobienia jest jeszcze dużo rzeczy, jednakże, o tych już będziecie się dowiadywać z moich devlogów!

View post on imgur.com

Bonus

Jeśli ktoś chce zobaczyć, jak gra sprawowała się na żywo w każdej iteracji mapy, to tutaj mam specjalną playlistę, niestety nie jest uporządkowana chronologicznie:

Dobra, dobra, a co z Dreamz?

Pewnie część z was już wie lub się domyśla czym są Dreamz. Cóż, są to gogle typu Google Cardboard, jednakże o niebo lepsze. Wersja 1.0 dorównywała optyką do Oculus Rift DK2 /1. Wersja 2.0 jest porównywalna z HTC Vive pod względem zastosowanych soczewek. Spytacie, jakim cudem testuję grę na vive, mając tylko gogle do telefonu? Otóż, istnieje program Riftcat, który sprawia, że nasz telefon jest rozpoznawany jako gogle HTC Vive przez steamVR. Dzięki czemu, jestem zdolny testować czy wszystko działa jak należy. Wspominałem coś o ciekawej historii z nimi związanej? A tak! Otóż, spytałem kiedyś  na grupie VR Poland o to jakie „ficzersy” lubią oni w grach VR, oraz co lepiej unikać gdy tworzy się grę VR. Jako zapaleni gracze VR, dali mi dużą ilość rad co robić i czego nie robić nie wywołać efektu nausea czy nie wybić gracza z immersji.

Zauważył mnie tam Piotr Krukowski i spytał o projekt, oraz to czemu robię go bez gogli. Po wyjaśnieniu wszelkich spraw, postanowił mnie wspomóc jedną sztuką gogli Dreamz. Czy mi to pomogło? I to jeszcze jak! To dzięki temu odkryłem całą masę głupich błędów, których bez gogli po prostu nie miałem jak sprawdzić. To dzięki temu skierowałem projekt na właściwe tory. Jestem za to dozgonnie wdzięczny!

Whoa, ale się rozpisałem. To by było na tyle w dzisiejszym devlogu. Powiedzcie co sądzicie o tych zmianach jak i o samym projekcie!