Reminiscencje Twórcy Systemów cz. 9: Druga gra, pierwsza praca i przełom

W poprzedniej części zarysowałem koncepcję liniowego postrzegania rzeczywistości i jej nieliniowej natury. Czas na przykład z życia.

Po zakopaniu się w pierwszej grze łagodzę cel: zamiast gry bitewnej w czasie rzeczywistym zrobię strategię turową. Symulator konfliktów zbrojnych na przestrzeni dziejów pod tytułem Historical Wars. Kopiuję część bibliotek narzędziowych, sporo dopisuję, projektuję od nowa główną pętlę gry. Kod jest bardziej przejrzysty, obiektowy, znacznie więcej klas i wyraźniejsza hierarchia.

Wiosną 2004 zaczynam pierwszą pracę w małym polskim studiu Aidem Media tworzącym gry dla dzieci (dziś giełdowa spółka Boombit). Myślałem, że wykażę się swoją znajomością C++, tymczasem potrzebny jestem do obsługi wewnętrznego game makera, na który składa się engine, prosty język skryptowy z IDE i program do składania animacji. System ma wiele ograniczeń, ale dwie zasadnicze zalety: tworzy się w nim prawie bezbłędnie gry, a skrypty są tak proste, że jakieś łatwiejsze fragmenty typu menu, cut-scenki są w stanie pisać nie-programiści.

Na początku wydaje mi się, że niewiele się nauczę, ponieważ moje postrzeganie ograniczone jest przez pryzmat wtajemniczenia w złożoność języka programowania. Tymczasem największa wartość game makera kryła się w prostocie jego koncepcji. W mojej grze było kilka faz odświeżania grafiki: heksy, elementy terenu, drogi, budynki, jednostki wojskowe, interfejs itd. W game makerze nie było żadnych faz, obiekty graficzne i animacje były przesłaniane na podstawie przypisanego w skrypcie priorytetu. To programista gry decydował o hierarchii wyświetlania. Engine napisany w C++ ze wstawkami asemblerowymi był odizolowany od logiki gier.

Wtedy zrozumiałem, że muszę napisać Historical Wars od nowa w podobny sposób. Stworzyć uniwersalny engine, który wystawia wysokopoziomowe API i ukrywa wszystkie niuanse związane z obsługą multimediów, i dopiero na nim stworzyć swoją wymarzoną strategię. Ponieważ zbliżał się już piąty rok studiów, postanowiłem upiec dwie pieczenie na jednym ogniu: gra stała się bazą dla magisterki. Engine był uniwersalny, mogłem zatem stworzyć na nim edytor map i scenariuszy. Wreszcie po 5 latach zrealizowałem marzenie: napisałem grę od A do Z. Najazd Asyrii na Babilon, obrona Grecji przed Persami, inwazja Hannibala na Rzym, AI które pokonuje nowicjuszy :) W tamtej firmie też poprowadziłem kilka projektów i sprawiały frajdę, jednak najwięcej spełnienia dała mi ta przestarzała strategia turowa na hexach.

Pomyślicie, że nie powiedziałem nic nowego - ot prosta historia o gościu, który sobie programował chałupniczo gierkę, poszedł do pracy, zobaczył jak to się robi i zrobił gierkę od nowa. A jednak świadomość o tym jak ważne są przełomy, game changery, jest rzadka i zanika z czasem. Ludzie przyzwyczajają się do tego co znają i nie są w stanie porzucić nawyków. Ponadto nie każda zmiana jest potrzebna - opisałem temat w części 5 reminiscencji w podrozdziale “zaciemnienie”.

Nie istnieje prosty przepis na skuteczny rozwój. Obecnie, po 15 latach od tamtych wydarzeń, niemal codziennie poszukuję nowych koncepcji i narzędzi w domenie, w której operuję. Ale żeby dotrzeć do tego etapu musiałem osiągnąć mistrzostwo w prostych elementach. Dopiero to pozwoliło mi dostrzegać podobieństwa i różnice w narzędziach, by na tej podstawie ocenić, czy potrzebuję zmiany. Nauczyłem się dostrzegać czego nie wiem i tworzyć mapę do osiągnięcia zrozumienia.