Artykuły, tutoriale, wsparcie dla programistów
March 18, 2014, 1:53 pm

Jak napisać pierwszą grę komputerową. Czyli najtrudniejszy pierwszy krok

Prawdopodobnie każdy gracz ma w głowie co najmniej jeden pomysł na rewelacyjną grę. Niektórzy idą dalej i zakładają zeszyty w kratkę, których strony zapełniają pomysłami i szkicami. Niestety w tym szczególnym przypadku sam pomysł to zbyt mało i – bez konkretnych kroków – jest niewiele wart.

Autor: Konstanty Kalicki
Źródło: Software Developer’s Journal 02/2010 (182) http://sdjournal.org

Trudno jest zainteresować poważną firmę inwestycją w grę , przysyłając im zeszyt z pomysłem. Na papierze każda gra – choćby była oryginalna i rewolucyjna – wygląda podobnie i, niestety, zazwyczaj nieciekawie. Dzisiaj produkcja gry komputerowej to duży budżet i wiele zaangażowanych osób. Mówimy tu o co najmniej dziesiątkach tysięcy złotych w przypadku małych gier, a milionach dolarów w przypadku produkcji większych, nie ma więc co się dziwić, że mało kto wyłoży pieniądze na realizację pomysłu jakiegoś gościa z zeszytem. Zwłaszcza pamiętając, że gry to kapryśne produkty i czasem nawet bardzo dobra produkcja może przepaść na rynku w wyniku niesprzyjających okoliczności lub pecha (przykładowo Vampire: The Masquerade – Bloodlines czy choćby Psychonauts).

Skoro widoki na to, że dyrektor znanej firmy podsłucha nasz pomysł w autobusie i od ręki nas zatrudni, są marne, trzeba przejść do planu B.

Na potrzeby niniejszego artykułu założymy, że nasz pomysł na grę to gra platformowa, której bohaterem jest wściekła małpa. Małpa zbiegła z miejskiego ZOO i teraz ściga po mieście biznesmanów w garniturach, aby zatłuc ich wielkim bananem. Grę roboczo nazywamy Monkey Business.

Plan B, czyli „Wystarczy chcieć”
Plan B sprowadza się do tego, że musimy grę wykonać sami. Pierwszym krokiem powinna być ocena naszych umiejętności i możliwości. Jeśli jesteśmy akurat John’em Carmack’iem lub mamy szafę pełną pieniędzy, to sprawa jest dosyć prosta. W innym przypadku musimy usiąść i zastanowić się, co właściwie potrafimy.

Spisujemy wszystkie nasze umiejętności takie jak rysowanie, modelowanie grafiki trójwymiarowej, projektowanie baz danych, interfejsów baz danych, projektowanie stron WWW, programowanie (w czymkolwiek) lub dowolną inną umiejętność powiązaną z szeroko pojętą informatyką. Nawet jeśli lista jest bardzo krótka, nadal jest nadzieja, nie poddajemy się. Kolejny krok to próba dopasowania naszych umiejętności do konkretnego projektu.

Jeśli planujemy grę handlową lub nawet MMORPG (Massive Multiplayer Online Role Playing Game), a potrafimy tylko tworzyć bazy danych, to możemy przyciąć nasz projekt tak, by dało się go zrealizować na bazie danych lub tylko formularzu. Przykładem bardzo wciągającej gry wykonanej naprawdę prostą metodą jest Drug Wars lub jej polski odpowiednik MaXDila 2000. Kilka pól tekstowych i zabawa murowana na wiele godzin.

Co możemy zrobić, gdy nie mamy żadnego doświadczenia w tworzeniu graficznych interfejsów użytkownika i jedyne, co potrafimy, to wyświetlanie znaków ASCII? Możemy zrobić grę oczywiście. Jest cały gatunek gier Roguelike, czyli tak zwanych rogalików. Są to gry naśladujące kultową grę Rogue (stąd ich nazwa). Cała grafika reprezentowana jest tu za pomocą znaków ASCII. Prostota reprezentacji wizualnej może być myląca – gry te są często przerażająco złożone. Przykładem może być ADOM lub Dwarf Fortress. Stworzenie gry w tak ubogiej oprawie graficznej może przy okazji ujawnić słabe punkty scenariusza lub mechaniki. Gdy nie ma nic, co by nas rozpraszało, to właśnie fabuła i gameplay trzymają nas przy klawiaturze (lub kontrolerze).

W takim razie co robić, jeśli umiemy tylko rysować lub tworzyć modele trójwymiarowe? Paradoksalnie możemy się odprężyć, jesteśmy w dosyć komfortowej sytuacji. Sieć jest pełna zdesperowanych programistów szukających grafików, którzy pomogliby skończyć ich projekt. Pozostaje tylko przekonać ich, że to właśnie nasz projekt jest ciekawszy.

Oczywiście może się też zdarzyć, że kartka pozostaje pusta, ponieważ nie posiadamy żadnych umiejętności, które pomogłyby nam w stworzeniu gry. W takiej sytuacji nadal nie wszystko jest stracone – wystarczy bliżej zainteresować się narzędziami do tworzenia gier. Nie zawsze oferują swobodę, jakiej oczekujemy. Nie zawsze są wydajne. Mają jednak jedną ogromną zaletę, a mianowicie są proste w obsłudze i często darmowe lub bardzo tanie. Dzięki temu skupiają wokół siebie spore społeczności. To z kolei oznacza, że dostępne jest bardzo dużo gotowych przykładów i poradników, jak stworzyć własne gry, bazując na danym narzędziu. Przykładem takiego narzędzia może być Game Maker.

Gdy umiemy trochę programować, powinniśmy rozważyć wykorzystanie istniejącego silnika lub framework’a. Zawsze pamiętajcie, że gra to olbrzymie przedsięwzięcie i trzeba ułatwiać sobie życie jak się tylko da. Częstym błędem jest zabieranie się do pisania własnego silnika, żeby potem na nim stworzyć grę. Przypomina to trochę wyważanie drzwi otwartych na oścież – jest wiele darmowych rozwiązań, które zaoszczędzą nam miesięcy żmudnej dłubaniny. No chyba że właśnie ta dłubanina wciąga was najbardziej – wtedy twórzcie silniki i dzielcie się nimi z innymi. Kto wie, może zostaniecie zauważeni.

W naszym przypadku lista jest krótka – trochę doświadczenia z C++ i PHP. Potrafimy coś narysować w Gimp’ie, ale na tym nasze zdolności artystyczne się, niestety, kończą.

Na tym etapie trzeba zdecydować, czy piszemy grę dwuwymiarową, czy trójwymiarową. Większość z nas w pierwszym odruchu powie, że oczywiście trójwymiarową. W tym przypadku jednak więcej nie zawsze znaczy lepiej. Jak powiedział Antoine de Saint-Exupéry „wiesz, że osiągnąłeś perfekcję w projekcie, nie, gdy nie masz już nic do dodania, lecz gdy nie możesz już nic uprościć”. Zastanówmy się , czy ten trzeci wymiar jest rzeczywiście konieczny. Czy bez niego gra nie będzie ciekawa? Czy mechanika nie może działać w dwóch wymiarach? Jeśli zdecydujemy się na realizowanie gry w trzech wymiarach, musimy liczyć się ze znaczącym wzrostem nakładu pracy i złożoności zadania. W przypadku gry dwuwymiarowej do stworzenia grafiki wystarczy usiąść do przysłowiowego „painta” na kilka minut i naszkicować sprite’a. Może być nawet paskudnie brzydki – programmers art’y też mają swój urok i przede wszystkim pozwalają zaprezentować projekt innym osobom. Oczywiście możemy także skorzystać z ogromnej ilości grafik dostępnych za darmo w sieci. Przykładem może być Reiner`s Tilesets – zbiór dostępnych za darmo obiektów i tile’i do gier w rzucie izometrycznym. Pewnym  problemem jest tworzenie przyzwoicie wyglądającychanimacji dwuwymiarowych. Konieczneest ręczne rysowanie kolejnych klatek,co jest dosyć uciążliwe.

Pewnym ułatwieniem może być tworzenie grafiki wektorowej – rozwiązuje to problem niewprawnej drżącej ręki, pozwala wypełniać kształty gradientami i ułatwia animowanie. Co prawda powstaje grafika flaszowa, ale lepszy rydz niż nic.

Taka grafika nie musi być grafiką docelową – może służyć tylko do przygotowania prototypu gry, który będziemy chcieli – celem zachęcenia do współpracy – pokazać wydawcy lub kolegom potrafiącym rysować.

Jednak w przypadku trzech wymiarów sprawa się komplikuje. Żeby nasza gra zaczęła dobrze wyglądać, musimy stworzyć model w jakimś programie do modelowania, takim jak darmowy Blender. Jednak sam model to nie wszystko – raczej dopiero początek. Jeśli będzie to obiekt animowany, musimy przygotować animację. Ten krok jest łatwiejszy niż animowanie rastrowych obiektów dwuwymiarowych ze względu na wektorowy charakter modeli trójwymiarowych (zakładając, że nie porywamy się na nic niestandardowego jak voxele).

Kolejna sprawa to pokrycie naszego obiektu barwą, czyli stworzenie tekstury. Musimy namalować obraz dwuwymiarowy, który zostanie zmapowany na powierzchnię obiektu trójwymiarowego. Można więc powiedzieć, że i tak musimy wykonać pracę, której wymagałaby nasza gra, gdybyśmy zdecydowali się na grafikę dwuwymiarową. W zależności od tego, na jak złożone efekty specjalne i oświetlenie się decydujemy na tym etapie, możemy skończyć prace nad modelem lub jeszcze wygenerować mapy normalnych, mapy nierówności, mapy odbić i co tylko nam przyjdzie do głowy.

Oczywiście możemy znaleźć darmowe modele trójwymiarowe w sieci. Jednak doświadczenie uczy, że dużo trudniej jest znaleźć odpowiadający nam model trójwymiarowy niż bitmapę dwuwymiarową. Nawet gdy znajdziemy odpowiedni obiekt, może okazać się, że nie posiada on wszystkich map, których potrzebujemy lub jest wykonany w sposób uniemożliwiający wykorzystanie z naszymi metodami wyświetlania.

W naszym konkretnym przykładzie najrozsądniejszym rozwiązaniem wydaje się być grafika dwuwymiarowa. Gry platformowe jako gatunek kojarzone są z dwuwymiarowymi planszami. Dzięki uproszczeniu świata gry będziemy mogli szybciej zaimplementować zasady rozgrywki i skupić się na dodawaniu ekstra funkcjonalności takiej, jak rzucanie bananem w odległych przeciwników.

Podstawowymi elementami, znajdującymi się w większości gier, są:
• silnik graficzny odpowiedzialny za wyświetlanie gry;
• biblioteki odpowiedzialne za odgrywanie efektów dźwiękowych oraz muzyki;
• silnik symulacji fizycznej;
• skrypty;

Jeśli planujemy stworzenie gry dwuwymiarowej, warto zainteresować się PopCap Games Framework. Framework ten jest bardzo kiepsko udokumentowany (garść dokumentów opisujących ogólne zasady działania), jednak jego prostota rekompensuje wszelkie wady. Nawet niewprawny programista po przejrzeniu przykładów dostarczonych wraz z kodem źródłowym może napisać prototyp gry  platformowej (lub dowolnej innej) w dosłownie kilka godzin. Framework zapewnia wszystko, czego potrzeba do stworzenia gry dwuwymiarowej. Znajdziemy tu parser XML’a, obsługę rejestru, dźwięku oraz animacji. Tworzenie interfejsu użytkownika jest stosunkowo proste i już na starcie dysponujemy praktycznie wszystkimi potrzebnymi kontrolkami. Nic, tylko siadać i pisać. Oczywiście im głębiej w las, tym więcej drzew – framework nie jest pozbawiony wad. Nie powinny one jednak przeszkadzać w tworzeniu pierwszej gry. Nie musimy ograniczać się do PopCap’a – jest wiele innych bardzo dobrych bibliotek i framework’ów wspomagających tworzenie gier dwuwymiarowych – chociażby SDL, Allegro czy Blitz2D.

W przypadku gdy decydujemy się realizować nasz projekt w trzech wymiarach, wybór jest jeszcze większy. Możemy zdecydować się na silniki graficzne takie jak Irrlicht lub Ogre. Jako że są to silniki graficzne same w sobie nie oferują żadnej funkcjonalności poza wyświetlaniem sceny. Tu z pomocą przychodzą społeczności powstałe wokół tych projektów. Z łatwością znajdziemy dodatkowe narzędzia ułatwiające budowanie silnika gry.

Ponieważ zdecydowaliśmy się na realizację naszej gry w dwóch wymiarach, wybieramy framework PopCap. Pozwoli to nam bardzo szybko stworzyć pierwszą wersję gry.

Do obsługi dźwięku możemy wykorzystać gotowe biblioteki, takie jak FMOD lub OpenAL (Open Audio Library). Pierwsza  nich jest biblioteką komercyjną. Jeśli będziemy chcieli sprzedawać naszą grę, musimy liczyć się z kupnem kosztownej licencji – nawet do kilku tysięcy dolarów. Jeśli jednak nasza gra ma być produktem darmowym, możemy korzystać z FMOD bezpłatnie.

Tym, którzy od komercyjnych bibliotek dostają wysypki, na pewno przypadnie do gustu OpenAL. Jest to biblioteka w pełni open source, rozwijana przez społeczność na wzór OpenGL (choć nie w tak koordynowany sposób). Dzięki temu nazewnictwo i konwencje nazw przypominają OpenGL.

Wybrany przez nas framework PopCap posiada moduły odgrywające dźwięk, jednak  decydujemy się na zaimplementowanie własnego modułu wykorzystującego bibliotekę OpenAL. Jest darmowa i  oferuje dźwięk przestrzenny, co jest dla nas bardzo ważne. Przecież chcemy, żeby odgłos banana uderzającego w biznesmana dobiegał dokładnie z miejsca, w którym znajduje się małpa i brzmiał inaczej w  zależności od otoczenia.

Kolejnym ważnym elementem naszej gry mogą, lecz nie muszą, być skrypty. Zaimplementowanie silnika skryptowego może nam pozwolić na przeniesienie części logiki poza kod. W szczególności pozwoli to na modyfikowanie parametrów i zachowań obiektów w świecie gry bez konieczności rekompilacji silnika. Nie każda gra wymaga implementowania skryptów – na pewno nie będą potrzebne w prostej platformówce czy grze logicznej. Generalnie wszędzie tam, gdzie mechanika gry jest powtarzalna i nie występują nieprzewidziane zdarzenia, skrypty są zbędne. Będą za to niezastąpione w grach  role-playing lub przygodówkach.

Dwa języki, które można polecić, to z pewnością Lua oraz Python. Prawdopodobnie lepszym rozwiązaniem (przynajmniej na początek) będzie wykorzystanie Lua. Jest to język skryptowy projektowany z myślą o integracji z C lub C++. Jest bardzo lekka, szybka i prosta do opanowania. Te cechy sprawiają , że jest bardzo popularna wśród twórców gier.

Nasz projekt nie wymaga silnika skryptowego. Co prawda rozważaliśmy dodanie niestandardowych zachowań planszy takich jak walące się budynki czy załamujące się pod małpą kładki dla pieszych. Jednak po dokładnej analizie doszliśmy do wniosku, że takich zdarzeń będzie niewiele i szybciej będzie zaprogramować je na twardo niż implementować skrypty. Nie ma sensu wytaczać artylerii na muchę.

Ostatnim wartym rozważenia elementem jest wykorzystanie biblioteki symulacji fizycznej. Nie powinniśmy dać się ponieść modzie na symulowanie wszystkiego. Musimy się zastanowić , czy nasza gra potrzebuje symulacji fizycznej. Jeśli to przygodówka, to pewnie nie. Gry, w których często dochodzi do interakcji z otoczeniem w trudny do przewidzenia sposób, takie jak różnego rodzaju strzelanki
lub symulatory wyścigów, prawdopodobnie skorzystają na zaimplementowaniu symulacji fizycznej. Do wyboru jest bardzo dużo zarówno komercyjnych, jak i darmowych rozwiązań. Popularniejsze biblioteki open source to Open Dynamics Engine (ODE), Bullet, Tokamak. Spośród pozostałych rozwiązań warto wymienić Havok, PhysX oraz Newton Game Dynamics. Praktycznie wszystkie te silniki pozwolą nam zaimplementować realistycznie zachowujące się bryły sztywne, efekty cząsteczkowe oraz efekt rag-doll (wykorzystywany do symulowania realistycznie padających bezwładnych ciał).

W naszej grze zdecydowaliśmy się wykorzystać silnik ODE. Użyjemy go, by zasymulować realistyczne upadki postaci trafionych bananem oraz różne przedmioty, które małpa może przewrócić. Takie smaczki nie będą miały wpływu na rozgrywkę, jednak będą dawały graczowi dużo satysfakcji z pokonania wroga i sprawią, że plansza będzie bardziej interaktywna. Możemy także zdecydować się na kompleksowe rozwiązanie i wykorzystać gotowy silnik gry. Tu wybór jest bardzo duży. Większość  silników dostarczana jest wraz z narzędziami i edytorami pozwalającymi w wygodny sposób projektować gry. Minusem zastosowania gotowego silnika będzie oczywiście utrata elastyczności , jaką daje nam napisanie własnego silnika dopasowanego do naszych potrzeb. Może się jednak okazać, że znajdziemy silnik doskonale pasujący do wizji naszej gry. Warte uwagi pozycje to Torque Game Engine, Blitz3D, Unity i id Tech od 1 do 3 (silniki , na których powstał Doom, Quake 2 oraz 3), Virtools czy Blender Game Engine. Niektóre z wymienionych silników pozwalają na tworzenie gier praktycznie bez pisania kodu – w VirTools możemy dosłownie składać grę z klocków metodą drag and drop.

Prototyp
Bez względu na to, jaki silnik zdecydujemy się wykorzystać, pierwszą rzeczą, którą stworzymy, powinien być prototyp naszej gry. Prototyp jest to bardzo prosta wersja gry pozwalająca zapoznać się z mechaniką rozgrywki i ją przetestować. Najczęściej opiera się na bardzo prostych elementach graficznych i powinien pozwalać graczowi na zagranie w grę i jej wygranie (lub przegranie). Jeśli piszemy grę  przygodową, prototyp powinien być jedynym zadaniem, które postać musi wykonać – na przykład wydostać się z celi, wykorzystując znaleziony pod pryczą widelec. Jeśli nasza gra będzie strzelanką, w prototypie powinniśmy móc strzelać i niszczyć wrogów. Celem może być dotarcie żywym do określonych drzwi.

Generalnie prototyp powinien powstać w kilka dni, a w idealnej sytuacji godzin. Jeśli w ciągu tygodnia nie jesteśmy w stanie ukończyć prototypu ,może być to ważna wskazówka, że nasz projekt jest zbyt obszerny jak na nasze możliwości i trzeba zrewidować plany. Może na początek warto  stworzyć prostszą grę, którą będziemy potem rozszerzać o nową funkcjonalność? Tak czy inaczej bardzo ważne jest , abyśmy jak najszybciej mogli zobaczyć efekty swojej pracy w postaci działającej gry. Da nam to siłę i motywację do dalszej pracy!

Dzięki prototypowi stosunkowo wcześnie możemy stwierdzić , czy nasza gra jest interesująca i czy nasze pomysły faktycznie sprawdzają się. Jeśli nie – oszczędziliśmy właśnie sporo czasu. Jeśli tak – możemy od razu sprawdzić, czy wymyślone sterowanie sprawdza się, czy interfejs jest czytelny i tak dalej. Możemy też pokazywać prototyp ewentualnemu inwestorowi lub współpracownikom (na przykład grafikowi, który zachwycony wciągającą rozgrywką przygotuje nam profesjonalną oprawę wizualną). Taki prototyp możemy pokazać w sieci i próbować ewentualnie zwerbować pomoc do naszego projektu. Jeśli nie możemy pochwalić się działającą wersją gry, zostaniemy potraktowani w najlepszym razie jak marzyciele i zachęceni do dalszych prac. Takimi miejscami w sieci, gdzie możemy podzielić się naszymi doświadczeniami lub skorzystać z wiedzy i doświadczenia innych przy pisaniu gier, jest na przykład GameDev.net lub nasz rodzimy Warsztat (www.gamedev.pl).

W naszym idealnym przypadku wokół naszego projektu powstaje prężna społeczność  zdolnych ludzi nienawidzących biznesmenów w garniturach, ale lubiących rzucać bananami. Szybko powstaje fantastyczna komiksowa oprawa graficzna i gra podbija serca graczy. A druga część także portfele.

Pozostaje życzyć powodzenia w zmaganiach z pierwszą grą!

KONSTANTY KALICKI
Opiekun specjalizacji Programowanie Gier Komputerowych na PJWSTK
epg@pjwstk.edu.pl

Zostaw odpowiedź

Musisz być zalogowany aby publikować komentarz.



Software Press Sp. z o.o. Sp. Komandytowa 02-682 Warszawa, ul. Bokserska 1, NIP 9512279582, REGON 141804060, KRS: 0000327578