Na początku był JavaRush

Mój pierwszy okres próbny zakończył się 3 lata temu, ale dopiero teraz mam czas na napisanie artykułu. Na uniwersytecie spędziłem 1 rok na różnych wydziałach: pierwszy semestr studiowałem, aby zostać menadżerem, w drugim semestrze przeniosłem się na inżynierię oprogramowania. Miałem nadzieję, że nauczą mnie programować, ale się myliłem, więc wziąłem dokumenty i postanowiłem wszystkiego nauczyć się sam. Jedyną rzeczą, za którą jestem wdzięczny nauczycielowi, jest to, że poradził mi zacząć od książki Stephena Prata „Język programowania C”. Naprawdę dobra książka z wieloma praktycznymi problemami. Książka trwała jakieś 2 miesiące, po czym natknąłem się na JR w grupach znajomych i jedziemy dalej. Na początku planowałem zostać programistą Androida, ale w trakcie nauki backend wydał mi się bardziej interesujący. Nawiasem mówiąc, szkolenie trwało 3 miesiące, podczas których osiągnąłem poziom 20, po czym postanowiłem spróbować znaleźć pracę. Po pierwsze przeprowadziłam się do innego miasta, bo... W moim nie było wakatów dla młodszego programisty Java. Znalazłem firmę, odpowiedziałem, otrzymałem zadanie testowe, na wykonanie którego dano tydzień. Konieczne było napisanie prostej aplikacji internetowej z wykorzystaniem Hibernate, Servlet\JSP i MySQL. Ze wszystkich tych słów wiedziałem tylko, że MySQL jest bazą danych. Na początku byłem bardzo zdenerwowany, postanowiłem nawet na razie poszukać pracy w jakimś KFC, ale potem w końcu zdecydowałem się spróbować spełnić wymagania techniczne - zawsze zdążę znaleźć pracę w KFC. Robiłem test non-stop przez cały tydzień i udało mi się. Wysłałem rozwiązanie, ale było „paskudne”, więc przerobiłem je jeszcze 4 razy. Ostatnia decyzja okazała się słuszna, okazało się jednak, że rekrutacja deweloperów została już przeprowadzona, a kolejny nabór odbędzie się za 3 miesiące. Sztosz, ok. Przez kolejne 3 miesiące uczyłem się html, css, js, sql i php. Co tu robi PHP? Potrzebowałem języka po stronie serwera, który odpowiadałby na żądania i tak dalej – serwlety i jsp wydawały mi się wówczas zbyt skomplikowane. W rezultacie powstała pełnoprawna aplikacja internetowa z okropnym interfejsem, której kod umieściłem na githubie dla mojego portfolio. Właśnie minęły 3 miesiące i napisali do mnie z tej samej firmy, zaprosili mnie na rozmowę i dali mi kolejne proste zadanie testowe ze znajomości SQL, które wykonałem w kilka godzin. Osoba, z którą rozmawiałem w sprawie pracy, zasugerowała, że ​​będzie pytać o algorytmy i struktury danych – jeszcze nie opanowałem tego tematu, ale do rozmowy zostało 15 dni, do cholery my, kierowcy. Pomogła mi książka Roberta Laforeta „Struktury danych i algorytmy w Javie”. Nie miałem czasu przeczytać i zrozumieć wszystkiego w dwa tygodnie, ale i tak nauczyłem się wielu nowych rzeczy. I wtedy nadszedł dzień rozmowy kwalifikacyjnej, przybyłem na umówioną godzinę, spotkało mnie 2 mężczyzn i rozpoczęła się rozmowa. Powiedzieć, że się martwiłem, to mało powiedziane, nawet głos mi się trząsł. Pytali o wszystko z wyjątkiem algorytmów i struktur danych. Pytali o Spring, DI, IoC, Hibernate, jak działa JVM, jak działa GC - nie odpowiedziałem na żadne z tych pytań. Radziłem sobie tylko z pytaniami dotyczącymi Java Core (kolekcje, wyjątki, OOP itp.). Już na rozmowie kwalifikacyjnej zdałem sobie sprawę, że mi się nie udało, ale nadal byłem rozczarowany brakiem informacji zwrotnej. Ale zidentyfikowałem luki w wiedzy i zacząłem je pilnie uzupełniać. Pracę znalazłem miesiąc po nieudanej rozmowie kwalifikacyjnej. Przy okazji natknąłem się na wakat w dyskusjach JavaRush. Najpierw odbyła się rozmowa Skype z rekruterem (trwała około 2 godzin). Pytali o Java Core, GC (teraz już wiedziałem jak to działa), bazy danych, struktury danych. Następnie ankieter poprosił mnie o udostępnienie ekranu i napisanie kalkulatora. Prawie krzyknęłam ze szczęścia, bo kalkulator pisałam dosłownie tydzień wcześniej. Pewny siebie rozpocząłem zadanie, ale albo z podniecenia, albo z innego powodu zapomniałem części algorytmu. Ekran jest udostępniony - strach wejść do Google. Na szczęście miałem telefon komórkowy, który uratował mi tyłek. Następnego dnia zaprosili mnie na rozmowę kwalifikacyjną, a po kilku dniach otrzymałem ofertę. Praca nie miała charakteru oficjalnego, pełniłem funkcję praktykanta u indywidualnego przedsiębiorcy. Napisaliśmy usługę tworzenia wydarzeń, sprzedaży biletów i tak dalej. Pamiętam swój pierwszy dzień w pracy – indywidualny przedsiębiorca spędził 15 minut na wyjaśnianiu, co należy zrobić. - Cóż, czy wszystko jest jasne? - zapytał IP - Mmm, nie bardzo, możemy to zrobić jeszcze raz? – zapytałem szalenie zaniepokojony. IP wyjaśnił wszystko ponownie. - Teraz jest już jasne? - Teraz tak. Tak naprawdę NIC nie zrozumiałem. Ale bałam się znowu poprosić o wyjaśnienia - myślę, że każdy, kto dostanie pracę, mnie zrozumie. Istotą zadania było przepisanie z thymeleaf na AngularJS. Na szczęście znalazłem część gotowego kodu, poszedłem za przykładem i zrobiłem to samo. Nie rozumiałem wtedy, jak to działa, ale poradziłem sobie z zadaniem. Następnie przyszły zadania związane bezpośrednio z częścią backendową. Dopiero po praktycznym doświadczeniu ze Springiem zacząłem rozumieć, co napisano w książce „Wiosna dla profesjonalistów”. Pracowałem tam 8 miesięcy, po czym przeprowadziłem się do innego miasta, gdzie szybko znalazłem oficjalną pracę, przepracowałem 2 lata, jednocześnie zmieniając stanowisko z „Junior” na „Średni”. Teraz stoję przed faktem, że praca stała się rutyną i nie przynosi ani odrobiny przyjemności. Dlatego w tej chwili zrobiłem sobie przerwę i aby zapobiec zanikowi palców podczas przerwy, postanowiłem spróbować innej dziedziny - tworzenia gier. Mianowicie tworzenie gier mobilnych, na początek na Androida, bo... Znam Javę. Opowiem Ci teraz o tym szczegółowo. O nas W krótkim czasie powstał mały 4-osobowy zespół (w tym ja): 2 programistów, 1 projektant gry, 1 inżynier dźwięku. Ponieważ Nikt w zespole nie miał żadnego doświadczenia w dziedzinie tworzenia gier, a mój czas wolny był ograniczony, postanowiliśmy wdrożyć prosty projekt, który na pewno doprowadzimy do końca. Zrobili to! Początkowo termin upłynął 15 listopada, ale jak wiadomo ukończenie projektu w pierwotnym terminie to grzech. Skończyliśmy więc dwa tygodnie później. Według nich Stos to: Java 8 i libGDX.

O rozwoju

Za początek rozwoju można uznać 17 października. W sumie spędziliśmy 45 dni, podczas których:

1. nauczyłem się pracować z libGDX;
2. napisał kod;
3. narysował grafikę;
4. tworzył muzykę;

Ci, którzy już widzieli grę, mogą mieć pytanie - dlaczego to tak długo trwa, gra jest prosta? Tak, to prawda i jeśli chodzi o ścisłość, samo opracowanie (pisanie kodu) zajęło około półtora tygodnia. Resztę czasu można podzielić pomiędzy:

1. opanowanie silnika;
2. rysowanie obrazów, a następnie ich przerysowywanie;
3. pisanie muzyki;
4. wyszukiwanie dźwięków na https://freesound.org ;
5. czytając kilka artykułów o tym, jak promować gry

Poza tym zdarzały się momenty „przestoju” z różnych powodów – ktoś miał egzamin, ktoś miał poprawkę itp. Możesz bezpiecznie spędzić półtora tygodnia, a nawet więcej, na „przestoju”. Pozostałą część czasu poświęcono na „debaty”: niemal codziennie pojawiały się pomysły, co dodać do gry, więc pojawiały się spory, „to byłoby zbędne”, „to by nie pasowało” itp. Dlatego porzuciliśmy wiele pomysłów, na przykład dodając biegające karaluchy, które można zmiażdżyć i zyskać za to ekstra. punkty: Ogólnie rzecz biorąc, moim zdaniem jedną z najtrudniejszych rzeczy jest podjęcie decyzji z wyprzedzeniem, co będzie w grze i trzymanie się tego planu, bez prób dodawania „kolejnej” funkcji. W ten sposób zgromadziliśmy te 45 dni. Prototyp gry był gotowy po półtora tygodnia. W tym okresie nie mieliśmy jeszcze tak naprawdę grafik, więc część rzeczy wzięliśmy z domeny publicznej (na przykład pożyczyliśmy kartkę tła z Doodle Jump), a część stworzyliśmy sami w paintcie. Gra jest bardzo prosta technicznie - nie musieliśmy nawet używać box2d (silnika fizyki), sami mogliśmy obsługiwać kolizje i obliczać przeciwprostokątną. Z najciekawszych punktów podkreślę następujące.

1. Początkowo wszystkie elementy gry były generowane losowo. Te. mamy dostawców czarnych dziur, nożyczek, shurikenów, prętów, serc - układamy ich w tablicę, a następnie bierzemy losowego dostawcę i otrzymujemy element o losowych współrzędnych. Dość szybko stało się jasne, że takie podejście jest „niezbyt dobre”, to samo powiedzieli nam nasi znajomi, którzy brali udział w testach, i poradzili, abyśmy skorzystali z szablonów. Z pewnością dla osób zajmujących się tworzeniem gier jest to oczywiste rozwiązanie, ale… Jesteśmy nowi w tej okolicy i była to dla nas bardzo dobra rada.

   W ten sposób wyłoniło się kilka wzorców: dolina nożyczek; ukośne pręty - całkiem fajnie jest je składać z dużą prędkością (swist-sch-swist palcem); i jeszcze jeden szablon, nie wiem jak to nazwać - nazwę go tak, jak nazywa się klasa w kodzie: StraightForwardPattern.

   Z szablonami stało się przyjemniej, ale było to zbyt przewidywalne czy coś. Dlatego ten sam losowy stał się kolejnym szablonem. Te. Teraz mamy szablony „statyczne” i jeden losowy. (tutaj mem o idealnej równowadze).

2. Głównym problemem, jaki napotkaliśmy, był następujący. LibGDX wywołuje metodę render(float delta) w nieskończonej pętli, w której faktycznie następuje całe renderowanie elementów. Rysujemy linię ołówkiem w następujący sposób: bierzemy współrzędne palca i umieszczamy tam teksturę. Tak więc, jeśli bardzo szybko przesunęliśmy palec po ekranie, powstały „dziury”, ponieważ znaleźliśmy się w tych milisekundach, gdy metoda render(delta) już zadziałała i nie została jeszcze wywołana ponownie. Problem został rozwiązany w prosty sposób - pamiętamy ostatnią współrzędną, w której narysowana była tekstura, otrzymujemy kolejną i jeśli odległość między nimi jest większa niż X i palec nie został puszczony, wypełniamy tę lukę. Na początku myśleliśmy, że ta opcja może nie zadziałać – linie będą kanciaste, ale nasze obawy okazały się płonne – wszystko działa tak, jak powinno.

   A właściwie o grze

   Rozgrywka nie udaje, że jest wyjątkowa, ale jest całkiem niezła i potrafi uzależnić. Sterujesz ołówkiem, dosłownie rysujesz na papierze, unikając przeszkód - nożyczek, shurikenów, czarnych dziur. W takim przypadku rdzeń ołówka kończy się i musisz podnieść małe ołówki. Jeśli pręt dobiegnie końca, a ołówków nadal nie będzie, możesz podnieść fragment lustra. Będzie działać przez kilka sekund - zamiast marnować pręt, zostanie przywrócony, ale jednocześnie kontrola zostanie odzwierciedlona - przesuwasz się w lewo, a ołówek rysuje w prawo. Możesz także podnieść serce, które pozwoli ci raz napotkać przeszkodę i pozostać przy życiu. Im dłużej przytrzymasz, nie odrywając palca od ekranu, tym wyższa będzie kombinacja, co zwiększa prędkość zdobywania punktów. Dodatkowo prędkość gry stopniowo rośnie. Chyba, że ​​nie możesz okraść Korovanów. Początkowo planowaliśmy nazwać grę Karan Dash (ołówek, ahaha, rozumiesz, prawda?), ale później zmieniliśmy zdanie i zdecydowaliśmy się na Pencil Dash. Motywacją było to, że ta elegancka (mówię) gra słów będzie zrozumiała tylko dla rosyjskojęzycznej publiczności. Wydaliśmy grę kilka dni temu i teraz ją promujemy. W tym też nikt w zespole nie ma doświadczenia, całą wiedzę o promocji zaczerpnęliśmy z różnych artykułów. Informacje o grze publikowaliśmy bezpłatnie na różnych stronach/forach. Jeśli chodzi o kanały płatne, zamówiliśmy reklamę na 4PD, od jednego blogera, kilka postów na publicznych stronach VK i AdMob. Swoją drogą ten post też jest częścią promocji, więc za zgodą administracji zostawiam tutaj link do gry. Strona gry w Google Play: kliknij Zostawię też link do naszej grupy VK, gdzie możesz zostawić recenzje/sugestie i nie przegapić żadnej aktualizacji. kliknij Będę wdzięczny, jeśli ją zainstalujesz (a jeśli Ci się spodoba?), a za recenzję z oceną obiecuję zapalić świeczkę dla Twojego zdrowia! Zadawaj pytania, jeśli masz, odpowiem.