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:

Najlepszym rozwiązaniem jest oczywiście poprosić kogoś, aby wam zrobił wizualną część gry, lecz nie zawsze jest taka możliwość. Zwłaszcza gdy nie wiemy czy gra w ogóle coś zarobi. Ale szukajcie . Mi się udało znaleźć tylko gościa od muzyki w tle. Ale jeśli jednak nie ma to co? Może jakieś stronki z darmowymi grafikami/dźwiękami? Nie najgorsze rozwiązanie, ale często są to takie bardzo oklepane, typowe materiały wykorzystywane w wielu grach. Zresztą każdy woli być oryginalny i nie kopiować. W takim razie czemu by nie spróbować swoich sił w stworzeniu zarówno efektów dźwiękowych jak i grafik? Opowiem to na przykładzie mojej gry o nazwie kodowej Cyber Attack.

A więc polecam zaczynać od mądrego konceptu. Rozplanujcie sobie wszystko! Od mechaniki, fizyki aż do grafikę i dźwięki. Policz ile plansz chcesz stworzyć, czy aby na pewno tworzenie ich nie zajmie dużo czasu (zwłaszcza gdy są to gry logiczne, gdy często generator plansz nie wystarcza, potrzebne są mądrze skonstruowane przez człowieka plansze). Jako jeden programista musisz to wszystko ogarnąć, więc postaraj się żeby nie było tego za dużo . Ile to się spotyka ciekawych projektów, które giną przez to że po prostu nudzimy się tworzeniem ich, mamy już tego projektu dosyć! To zły nawyk !

Ja chciałem stworzyć grę o tematyce survivalu. Czy to oryginalne ? Wiadomo, temat survivalu jest bardzo oklepany, jednak bardzo wciągający i jest dużo możliwości, żeby był w miarę możliwości oryginalny. Nie chcę tutaj rozdrabniać na szczegóły, jak moja gra będzie wyglądać potem, bo to byłoby nie na temat. Moim (nie)skromnym zdaniem nie będzie to kolejna nudna gra survivalowa z craftingiem i po prostu przechodzeniem plansz z domieszką zombie.

Plan rozpisany, więc zaczynamy! Zacząłem od stworzenia algorytmu wyznaczania trasy. Zaimplementowałem algorytm A*, który wydaje się być łatwym i wydajnym dla mojej gry. Stworzyłem także prostą fizykę, która odpycha zombie jeśli są obok siebie, oraz wylicza kolizję obiektów ze ścianami.

Działa. Następnym elementem jaki zrobiłem to specjalną fizykę przeznaczoną dla pocisków, ponieważ są szybkie i w czasie jednej klatki mogą przeniknąć przez całą ścianę:

Działa! Wydaje się że wygląda to koszmarnie, ale szkielet przecież mamy zrobiony! Teraz najgorsza część dla programisty czyli upakowanie grafiki i dźwięków na tym szkielecie.

Grafika. Coś czego nienawidzę i nie mogę tego ogarnąć. Pamiętajcie – nie dawajcie sobie zbyt dużych celów. Gry z gorszą ale zrobioną z serca grafiką także zdobywają szacunek wśród graczy. Polecam pixelart lub coś w stylu flat design! Proste ale jak chociaż trochę popracujecie to wyniki będą zadowalające. Do tworzenia grafiki polecam Inkscape, lub jeśli macie pieniądze (lub klient Torrent) Adobe Illustrator. Inkscape zdecydowanie wystarczy, poszukajcie paru poradników, w których nauczycie się wielu operacji na ścieżkach, co znacznie przyspieszy pracę.

Plansza. Jako pierwsze chciałem zrobić planszę. Postanowiłem, że będzie ona… sześciokątem. Od tak – pierwsza plansza, więc powinna być prosta i dla gracza i dla mnie, aby ją dobrze zaprojektować. Oto etapy tworzenia planszy:

Jak widzicie zaczęło się od malutkiego sześciokąta, potem dodałem ich więcej aby dodać głębi planszy, a na sam koniec dodałem trójkąty, wpasowujące się w stylistykę gry oraz stanowiące miejsca „rodzenia się” przeciwników.

Główny bohater. Niełatwo czasem wymyślić fajnego bohatera. Czasem warto zapytać znajomych. Zwłaszcza tych co zazwyczaj mają „głupie” pomysły. Ja zapytałem i zaproponował mi zrobić klauna na wózku inwalidzkim który będzie uciekał przed policją . Na początku pomyślałem „Boże, co za debil”, ale to nie jest przecież zły pomysł. Zawsze lepiej być oryginalnym niż tworzyć kolejną zwykłą, typową, oklepaną setki razy postać.

Gorzej z rysowaniem owej postaci. Nie jestem w tym dobry . Na szczęście kamera w grze ma być dość oddalona, także gracz nie będzie się wpatrywać w tą beznadzieję, którą zrobiłem. Przynajmniej wózek w miarę ładnie wyszedł.

Bronie. Chyba jeden z prostszych elementów. Polecam znaleźć obrazek w Google i po prostu go przerobić. Efekt jest dobry:

Przeciwnicy. Planuję na każdą mapę dać innych przeciwników. To dużo roboty, jednak gracze doceniają takie rzeczy. Przeciwników oczywiście też zrobiłem w flat design, aby wszystko komponowało się w jedną całość. Pierwsza plansza ma przedstawiać współczesne + trochę fikcyjne elementy, do których flat design bardzo pasuje:

Bonusy. W tym stylu bardzo łatwo narysować różnorodne bonusy:

Edytor plansz. Grę piszę w frameworku LibGDX. Nie ma w nim żadnego edytora plansz czy coś na jego wzór, dlatego musiałem sobie stworzyć swój prosty edytor plansz. Napisałem go w Javie wykorzystując standardową bibliotekę GUI Swing. Nie wygląda on jakoś świetnie, ale sprawdza się w roli pomocy do tworzenia plansz. Wygląda on mniej więcej tak:

O edytorze nie będę za dużo mówić, bo to trochę nie na temat. Powiem tylko że jest bardzo pomocny, szczególnie gdy zamierzacie robić kilka map do gry – nie wyobrażam sobie umiejscawiać każdego obiektu bezpośrednio w kodzie, zwłaszcza jak mamy dużą mapę. Edytor pełni u mnie tylko funkcję pomocy, do umiejscawiania obiektów, cała reszta (skrypty itp.) dzieje się już w kodzie. Zerknijmy jeszcze na to, z czego składa się edytor:

• Points – punkty, używane do tworzenia ścian, węzłów nawigacji,
• Navigation Nodes – węzły nawigacji, potrzebne do algorytmu A* (wyznaczanie trasy przez przeciwników). Składają się z kilku punktów, tworzą wielokąt (koniecznie wypukły),
• Walls – ściany. Po prostu ściany w grze – każdy taki obiekt składa się z dwóch punktów,
• BackgroundTex / Tex – tekstury. Tex wyświetlają się nad graczem, BackgroundTex pod graczem,
• Spawners – oznaczają punkt w którym mogą pojawić się przeciwnicy.

Całą resztę mam zrealizowaną w kodzie. Wszystkie elementy interakcji, Easter Eggi teraz można łatwo wyłapać, po prostu pobierając punkt z pliku edytora i na przykład sprawdzając jego odległość od gracza.

Okej, mamy już planszę. Nie wygląda najgorzej, co nie?

Ale brakuje dźwięków – i to bardzo. Przecież nie będę ogarniać FL Studio – zajęłoby mi to parę tygodni, zresztą i tak nie mam słuchu muzycznego. Ale Audacity chyba każdy zna. Mikrofon też wiele osób ma. Ja użyłem bezprzewodowych mikrofonów Singstar do nagrania efektów dźwiękowych (siostra je używała do gry na PS3, teraz się kurzą, więc czemu by im nie nadać drugiego życia?).

Brzmi mało profesjonalnie, co nie? Pamiętajcie, gracze to nie audiofile, nie potrzebują wszędzie formatu *.flac ani idealnej jakości dźwięku. W takim razie możemy przystąpić do nagrań!

1. Wybuch
   Oryginalne nagranie (po prostu dmuchanie w mikrofon):
   
   Po drobnej edycji (m. in Paulstretch, zmiana tonu):
   
2. Strzał z shotguna
   Oryginał (zrobione ustami + przeładowanie):
   
   Po drobnej edycji:
   
3. Śmierć bohatera:Oryginał/po drobnej edycji:
   
4. Uderzenie w jednego z robotów ( pistolet na kulki + strzelanie w garnek )
   

Jak widać efekty dźwiękowe można samemu zrobić w domu. Wystarczy chcieć !

Muzyka. Muzykę w tle ogarnęli moi koledzy. Pozdrawiam Marcina Marszałka i Huberta Rzeszótko ;-). Jednak jeśli nie macie kogoś, kto by wam zrobił utwór muzyczny, to możecie skorzystać z opengameart.org . Tylko szukajcie dosyć „głęboko”, aby utwór nie powtarzał się często w innych grach. Efekt końcowy wygląda tak:

Czy to już koniec? Nie.

W planach mam dużo bardziej skomplikowane plansze, których stworzenie będzie teraz już dużo szybsze dzięki edytorze oraz dobrze napisanym kodzie programu, w którym łatwo dodawać i oskryptowywać plansze. Zamierzam dodać fabułę, zmienić styl na jeszcze bardziej arcade i stworzyć masę Easter Eggów i pobocznych misji . Oczywiście multiplayer (lokalny + sieciowy) też by się przydał.

Podsumowanie

Samemu da się stworzyć przyzwoitą grę. Jeżeli nie masz ekipy to nie jesteś od razu skazany na porażkę. Wyliczcie dobrze swoje umiejętności, nie twórzcie dużych projektów, które od razu są skazane na porażkę, gdyż znudzicie się podczas ich tworzenia. Lepiej jest robić coś mniejszego , ale równie dobrego – zawsze są to też jakieś projekty które na pewno przydadzą się wam w waszym portfolio. Często spotyka się ambitnych młodych programistów, którzy nie mają tak naprawdę żadnego projektu skończonego . Czasami trzeba się wziąć w garść i dokończyć jakiś projekt mimo, iż wam się nie chce. Jak to mówił św. Benedykt z Nursji: Ora et labora (łac. módl się i pracuj). Przecież w pracy też nie będziecie mogli sobie wymyślać. Dzięki małym projektom nauczycie się wiele, dopełnicie portfolio oraz zyskacie szansę na zarobek (bo czemu niby takiej gry nie wrzucić do serwisu Google Play lub Steam?).

Hack Heroes to hackathon z okazji Code Weeka, czyli długiego tygodnia od 15. do 23. października. Więcej możecie o nim poczytać tutaj: http://apki.org/news/hack-heroes-wez-udzial-w-codeweekowym-hackathonie .

Pierwsza doba

23:53

Już od początku doby, tj. od północy do jakiejś czwartej zabrałem się za rozpoczynanie projektu. Odpalenie phpStorma, załadowanie wszystkich zależności na composerze i npm-ie. Rozrysowanie na kartce czegoś, na czym będę mógł się opierać podczas pisania i kodowania frontendu i backendu. Obmyślałem podstawowe funkcjonalności aplikacji i zabrałem się za pisanie najprostszego szkieletu backendu, żeby móc się skupić na frontendzie. Dlaczego tak? Lubię widzieć do czego piszę backend, a taki gotowy frontend motywowałby mnie do dalszego pisania. Z racji czasu na backend wybrałem Slim-a , a na frontend nic, prócz frameworka Materialize.css (który swoją drogą jest dużo słabszy niż wygląda, przez jedną dobę zdążył mi już sprawić nie jedną bolączkę).

Sama aplikacja nazywa się Wakadog . Inspirowane lekko Wakatime. Czytane łakadog , wymową podobnie do walk a dog . Do tego właśnie służyć będzie moja aplikacja, do wyprowadzania psów. Mamy na mapie obszar z markerami, które oznaczają psy, których właściciele nie mają czasu lub nie mogą z nimi wyjść i potrzebują z tym pomocy. Porównałbym to do bazy ogłoszeń, jak OLX, z ogłoszeniami psów do wzięcia na spacer. Odpłatnie czy nie, to już kwestia leżąca poza odpowiedzialnością aplikacji. Potencjalny wyprowadzacz dostaje całkiem kompletny zbiór informacji o psie oraz numer telefonu do kontaktu. Po spacerze wyprowadzacz może wystawić psu ocenę, do pięciu gwiazdek. Na dzień dzisiejszy wygląda to tak:

Mój cel na nadchodzącą noc to dokończyć podstawowe widoki we froncie, żeby móc się skupić na backendzie.

Druga doba

01:53

Formularz dodawania psiaka ukończony, jednak nie jestem specjalnie zadowolony z jego aspektów wizualnych. Cóż, jak będzie czas to się coś wymyśli.

Naciśnięcie na mapę w dowolnym miejscu tworzy marker i wpisuje kordynaty do pola poniżej. UX tego rozwiązania jest zdecydowanie do poprawy. Nie podoba mi się rozkład poszczególnych pól. Te dwie sekcje można by jakoś sensownie pod względem wizualnym zgrupować.

Narazie zostawiam frontend i zaczynam klepać pehapa. Jakieś podstawowe encje i repozytoria, jednak najpierw, biorę kartkę i długopis i rozpiszę sobie bazę danych co by później nie mieć z zaprojektowaniem relacji problemów, w końcu jest coraz późniejsza godzina w nocy.

Czwarta doba

20:02

Oj ciężko w dni szkolne; zdecydowanie mniej czasu na to przeznaczam, co widać na WakaTime (screen obok).

Wczoraj siedziałem nad Wakadog tylko jakieś półtorej godziny. Trochę czasu zajęło mi za to przygotowywanie obrazu wirtualnej maszyny z linuksem skonfigurowanym do moich potrzeb, aby jutro móc w szkole kontynuować moją pracę. Nic prócz drobnej optymalizacji, dodaniu kontrolera od landing page oraz napisaniu dwóch widoków, formularza logowania i rejestracji nie zrobiłem. Obmyślałem za to sposób, w jaki będe w Wakadog uwierzytelniał i autoryzował użytkownika. Wszystko rozpisałem na kartce, trochę pogumkowałem, popoprawiałem i ostatecznie wyszło mi to, co widać na zdjęciu w tym issue na GitLabie .

Dzisiaj natomiast wcielam w kod (hmm, ciekawy zwrot) to, co rozpisałem na kartce. Planuję skontaktować się z jednym z mentorów w celu porozmawiania na temat bezpieczeństwa pewnego rozwiązania nad którym się zastanawiam. Tyle na teraz, lecę dalej pisać.

Szósta doba

21:39

Minął dzień odkąd pisałem. Postaram się opisać co przez te dni robiłem.

Przedwczoraj udało mi się wcielić moje rozpiski w kod, z którego jestem na moment obecny zadowolony, a może i nawet dumny. Po hackathonie dopracuję go pod względem elastyczności, napiszę testy i opublikuję w oddzielnym repozytorium, żeby móc w przyszłości z niego korzystać.

Wczoraj z rana, w szkole, przez dwie lekcje implementowałem funkcjonalności formularza do logowania się. Swoją drogą pierwszy raz używałem linuksa jako systemu gościa do faktycznego developmentu i pracowało mi się całkiem przyjemnie. Postawiłem 64bitowego Debiana na Cinnamonie, jeżeli ktoś byłby ciekaw. Na iMacu 2015 27″ z przydzielonymi 4GB RAM działał bardzo dobrze.

Wieczorem zabrałem się za obackendowywanie formularza rejestracji, razem z tym doszedł też wybór walidatora. Wybór padł na symfony/validator jak niektórzy mogli się domyśleć. To, co popełniłem tamtego wieczoru było syfem i nie chcę o tym pamiętać. Cóż, teraz nie jest wspaniale, ale to za chwilę. Skończyłem wczoraj dosyć wcześnie, bo koło 22:00.

Przechodząc do dnia dzisiejszego, poprawiłem wczorajszy kod rejestracji na coś bardziej znośnego. Winę zwaliłem na slim/flash , który rozszerzyłem i zmodyfikowałem tak, aby akceptował coś innego niż tylko stringi. Możesz dowiedzieć się o co mi chodzi przeglądając commity z tego dnia. Dowiedziałem się telefonicznie, że termin oddawania prac został przesunięty o jedną dobę, a więc oddać projekt trzeba przed poniedziałkową północą.

Na ten moment udało mi się dodać dodawanie, usuwanie i moderację ocen. Lekko zmieniłem wygląd mapy, który będzie punktem wyjściowym nawigacji po stronie. Przede mną stoi obackendowanie dodawania psa. Gdy to zrobię, będę już na prostej do finiszu głównych funkcjonalności aplikacji i będę mógł się zabrać za drobne refaktoryzacje, optymalizacje czy poprawki wizualne.

Ósma doba

12:17

Dzisiaj już nie wieczorem tylko z rana.

Wczoraj dodałem edycję oraz usuwanie psiaków. Walidacja tego wszystkiego to jest jeden wielki syf , na który nie mam pomysłu jak go ogarnąć. Jednak działa dobrze. Poprawiłem też pole date w psiakach, które nie ma teraz jakiejś dziwnej wartości, gdy wyborem jest Kiedykolwiek , a wynosi po prostu null . Dodałem ustawienia konta, w których można zmienić pola konta (aktualnie tylko widoczna nazwa), zmienić hasło lub bezpowrotnie usunąć konto.

Na mojej liście todo pozostał widok psów, których jesteśmy właścicielami oraz strona landing. Biorę się za pracę. A, i swoją drogą, podrzucam tydzień z WakaTime, ponieważ mam darmowe konto i statystyki mi zaczną już znikać.

Po wysłaniu projektu

01.11.2016 00:19

Projekt ukończyłem na przeddzień terminu, nie jestem specjalnie dumny z kodu w poszczególnych kontrolerach, mówiąc ściślej chodzi mi o ten, związany z walidacją. To jest porażka. Jednak cała aplikacja działa. Ma sporo dziur bardzo banalnych do odkrycia, o których pomyślałem już po terminie oddawania projektów. Na GitLabie pozostało parę issues otwartych i nieukończonych. Jednak jestem zadowolony z tego, że skończyłem ten projekt w terminie. Gdyby przysiąść do tego już na spokojnie, można by poprawić wszystkie niedociągnięcia i stworzyć całkiem udany produkt.

Na planowanie, programowanie oraz przeglądanie dokumentacji przeznaczyłem w 10 dni około 50 godzin, czyli średnio 5h dziennie, co jest przy takim okresie czasu moim osobistym rekordem. Na WakaTime załapałem się nawet do top100. Dzięki temu projektowi dowiedziałem się co to znaczy pracować z deadlinem .

Pojutrze (tj. 03.11.2016) rozpoczyna się głosowanie internetowe na najlepszy projekt. Na moment obecny pozostaje mi czekać na otwarcie głosowania oraz na oficjalne wyniki. Małe statystyki odnośnie hackathonu: udział wzięły 62 drużyny reprezentowane przez 193 zawodników, projekty końcowe złożyło finalnie 38 drużyn, czyli 61% drużyn złożyło ukończone projekty.

Na dole posta zdjęcie, które zrobiłem sobie podczas pisania. Bardzo mi się podoba.

Podsumowanie

Cały kod znajduje się na GitLabie pod tym linkiem . Wersja online będzie pod tym linkiem (jeżeli prowadzi do 404, już ją zdjąłem, jednak dodałem parę stron na https://archive.org/ ).

Wręczenie nagród

Cały hackathon został oficjalnie zakończony wręczeniem nagród w budynku Taurus w Warszawie na Mokotowie. Filmik (niestety ze słabym audio) możecie obejrzeć:

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.

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!

Przeglądając ciekawe itemy z chin natrafiłem na dość tanią adresowaną taśmę led. Jak to już bywa czasem najpierw się kupuje, a potem myśli. Początkowo miało to służyć jako ambilight, lecz ostatecznie przykleiłem pod półką, która wisi nad biurkiem. Przewiduje 4 opcje sterowania: sterowanie głosowe, panel www, klaśnięcie, przyciski/switche. Całość będzie oparta o Raspberry Pi Zero. Przedstawiane tutaj kody mają jedynie pokazać drogę do stworzenia aplikacji, lecz nie podawać tego na tacy, więc nie nastawiajcie się na kopiuj-wklej

Sterowanie głosowe

Od początku całość miała służyć jako pole manewrowe przy nabywaniu nowych umiejętności, z tego powodu też postanowiłem sam wszystko napisać. Poza programowaniem potrzebna będzie też podstawowa znajomość praw fizyki przy budowie układu elektronicznego (dotyczyć tego będzie osobna część tego devloga).

Aplikacja na telefon

Jako iż posiadam telefon z Androidem, tylko pod ten system powstanie aplikacja. Jako IDE wybrałem IntelliJ Idea z powodu przyzwyczajenia oraz tego, że Android Studio jest jak dla mnie za bardzo przepełnione dodatkami. Do rozpoznawania mowy wykorzystana została odpowiednia klasa z API systemu . Nie przypadła mi do gustu wizja wyskakującego okienka, dlatego przeszukałem Internet w poszukiwaniu rozwiązania aby tego uniknąć. Pomijam tutaj kwestię stworzenia projektu z wygenerowanym Activity.

Aby skorzystać z opcji rozpoznawania mowy potrzebujemy zezwolenia systemu do nagrywania audio. W tym celu dodajemy do pliku AndroidManifest.xml w środku elementu manifest linijkę: <uses-permission android:name="android.permission.RECORD_AUDIO"/> .

Kolejnym krokiem jest przygotowanie wyglądu naszej aplikacji (w zależności od potrzeb jest to layout activity albo fragment). Ja postanowiłem nie dawać użytkownikowi możliwości wyłączenia nagrywania tylko ustawiłem sztywno ilość czasu na podanie polecenia, dlatego użyłem zwykłego przycisku (w przeciwnym przypadku można pokusić się o 2 przyciski ON/OFF albo ToggleButton).

Gdy już nasza aplikacja jako tako wygląda, należy jakoś tchnąć w nią życie. W metodzie onCreate należy stworzyć nową instancję wyżej wymienionego SpeechRecognizer’a:

Tworzymy klasę RecognitationListener implementującą metody z androidowego interfejsu RecognitionListener . Teoretycznie potrzebna nam jest tylko metoda onResult (fajnie by było zaimplementować też obsługę błędów, lecz to już zależy od waszych preferencji). Teraz w metodzie onCreateView musimy dopisać tuż przed return view; kod dodający listener do przycisku:

voice_activation_button to ID naszego przycisku przypisane w pliku xml wyglądu. W klasie należy stworzyć także metodę która jest wywoływana wewnątrz tego listenera, czyli onVoiceActivation :

Uruchamia to proces wykrywania mowy, a z opóźnieniem 5000 milisekund zatrzymuje go.

W klasie listenera rozpoznawania mowy, w metodzie onResults wszystkie uzyskane wyniki pobieramy np. tak: ArrayList<String> matches = results.getStringArrayList(SpeechRecognizer.RESULTS_RECOGNITION); .

Wpadłem później także na pomysł aby zamiast przycisku dać ImageButton a za nim wstawić okrągły progressbar pokazujący ile czasu minęło. Do tego celu wykorzystałem bibliotekę CircleProgress .

Screen aplikacji na tym stadium rozwoju:

To by było na dziś tyle. W kolejnej części devloga przedstawie jakiś sposób na przypisywanie otrzymanych wyników do danego szablonu i wykonywanie w związku z nim jakiejś akcji.