0. Wstęp
A więc chcesz napisać własną grę komputerową? Zastanawiasz się jednak od czego zacząć? Chciałbyś potrenować programowanie lub stworzyć grę, która być może stanie się hitem? Niezależnie od tego w jakim celu chcesz ją stworzyć, ten artykuł ma za zadanie podsunąć ci parę podstawowych idei, o których należy pamiętać w trakcie jej tworzenia. Wiele amatorskich gier nie zostaje ukończonych właśnie z powodu braku zachowania podstawowych reguł tworzenia wszelkich projektów programistycznych, nie tylko gier.
1. Pomysł
Pierwszą i podstawową zasadą jest mieć pomysł. Skąd się biorą pomysły? Oczywiście z wyobraźni. Twój mózg przy odrobinie kreatywności jest w stanie wytworzyć nawet ogromne światy, które mogą służyć jako podstawa do stworzenia gry. Jeśli nie spełnisz tego warunku, nawet nie masz co marzyć o napisaniu czegoś sensownego.
Co jednak jeśli żaden pomysł nie przychodzi ci do głowy? W takim wypadku zabierz kumpla na kilka filmów w kinie, idźcie do gralni lub po prostu wypożyczcie kilka filmów na video. Filmy i gry to dobre źródło pomysłów, jeśli masz pustkę w głowie. Nie chodzi jednak o to aby po prostu skopiować daną grę lub film. Chodzi tu o pewien punkt zaczepienia, o pewną ideę. Równie dobrym źródłem pomysłów są sny. Wiele gier powstało właśnie z sennych marzeń ich twórców. Jednym słowem, im bardziej skrzywiona twoja psychika, tym lepiej. ;)
Załóżmy, że nagle przyszedł ci do głowy pomysł na grę, która w twoim mniemaniu z pewnością zaszokuje graczy i powali ich na kolana. I co teraz? Rzucasz się do komputera z wywalonym jęzorem i jak szalony zaczynasz klepać w klawiaturę kod C++ lub innego Delphi? Otóż nie. Jest to największy błąd jaki może popełnić projektant gry. Co w takim razie należy zrobić?
Najpierw zastanów się dobrze nad tym pomysłem. Nie zastanawiaj się w jaki sposób to wykonasz. Chodzi tylko o sam pomysł, o historię, o świat, o stosunki w nim panujące. Zastanów się nad tym o co w tym wszystkim będzie chodziło, kim lub czym będzie gracz, jaki jest jego cel, relacje w stosunku do otoczenia, itd. Zastanów się nad historią i warunkami samego świata, pomijając aspekty związane z graczem. Nie wdawaj się jednak w szczegóły, lecz rób przemyślenia na płaszczyźnie bardziej ogólnej.
Najważniejsze myśli i spostrzeżenia wynotuj na kartce. Najlepiej jednak, abyś kupił sobie dobry segregator oraz plik kartek do niego i wszelkie rzeczy dotyczące gry w nim zachowywał. Pozwoli ci to mieć wgląd w swoje wsześniejsze przemyślenia, założenia gry i wiele innych przydatnych rzeczy, o czym napiszę później. Nie mówiąc już o tym, że dzięki temu będziesz pracował jak prawdziwy profesjonalista. Ogólnie rzecz biorąc jest to bardzo dobry pomysł, bo pozwoli ci uporządkować wiele spraw, a także w przypadku jeśli dołączą w przyszłości do twojej ekipy inni ludzie, będą mogli się szybko zorientować w założeniach gry.
Po wynotowaniu wszelkich ciekawych i dość ogólnych spostrzeżeń, zostaw projekt. Pozwól przez kilka dni dojrzeć twojemu pomysłowi. Jeśli wymyślisz jakieś ciekawe aspekty swojej gry, dopisuj je w segregatorze. Czemu masz czekać? Otóż chodzi o to, żebyś miał czas na dokładniejsze przemyślenie całej sprawy. Dzięki temu będziesz mógł znacznie lepiej przeanalizować wszystkie niuanse świata gry. Będziesz mógł zastanowić się nad psychiką bohatera, nad światem, nad sytuacją polityczną/ekonomiczną w grze, itd. W zależności od tego jaka będzie twoja gra, czy będzie ona rozbudowaną, wielowątkową RPG, czy też prostą, nie wymagającą głębszego zastanowienia strzelanką, będziesz mógł przemyśleć poszczególne jej aspekty. Po co te wszystkie analizy? Po pierwsze uchroni cię to od wielu błędów w kolejnych fazach tworzenia gry. Po drugie będziesz miał lepszą możliwość zrozumienia co ci będzie potrzebne do stworzenia takiej gry. Jest jeszcze kilka innych mniej ważnych czynników dla których te przemyślenia są tak potrzebne. Jeśli jesteś osobą inteligentną to sam dojdziesz do tego jakie one są. Ponadto jest jeszcze jeden plus. Jeśli przez ten tydzień nie stracisz zapału do stworzenia gry, to masz duże szanse na to, że twoja gra zostanie ukończona.
2. Scenariusz i założenia gry
Załóżmy, że poczyniłeś już stosowne przemyślenia. Pora zabrać się do bardziej szczegółowego określenia założeń twojej gry. Jest to równie ważny krok w tworzeniu gry, co zdobycie pomysłu. Wielu projektantów gier zapomina o tym jakże ważnym czynniku jakim jest fabuła gry oraz jej scenariusz. Obowiązuje tutaj kilka zasad, które mogą cię uchronić przed zaplątaniem się we własne przemyślenia, a co za tym idzie mogą one przyczynić się do zaoszczędzenia ci czasu i nerwów.
Bardzo pomocne w tym momencie będą twoje zapiski poczynione w segregatorze. Po pierwsze określ jaki będzie rodzaj gry. Czy będzie to gra trójwymiarowa czy dwuwymiarowa? Czy będzie to gra FPP, TPP, a może platformówka albo RPG czy też przygodówka? Jest to bardzo ważne ponieważ będzie miało znaczący wpływ na scenariusz i założenia gry. Określ sposób wyświetlania lokacji, podstawowe założenia interfejsu użytkownika i interakcji ze światem gry. Wszystkie te rzeczy notuj w segregatorze pod odpowiednimi działami, tzn. chodzi o to abyś podzielił segregator na kilka działów, np. ogólne założenia gry, interfejs użytkownika, sposób wizualizacji, interakcja z otoczeniem. Wszystkie swoje spostrzeżenia notuj skrupulatnie w danych działach.
Jeśli już poczynisz techniczne spostrzeżenia odnośnie założeń gry, możesz przystąpić do określenia reguł rządzących światem gry. Tak jak w poprzednim przypadku podziel w zależności od potrzeb część segregatora na działy, np. historia, scenariusz, fabuła, wątki poboczne, cel gry, sytuacja polityczna świata gry, relacje bohatera ze światem, relacje świata z samym sobą, klimat gry, itd
To tutaj definiujesz zachowania i psychikę bohaterów, ich relacje ze światem gry. To tutaj opisujesz wszelkie rozmowy jakie mogą wystąpić w grze. To tutaj opisujesz wszelkie lokacje. To tutaj definiujesz cele jakie gra ma stawiać przed graczem. Jest to stosunkowo żmudna faza tworzenia gry, jednak niezwykle ważna, gdyż takie potraktowanie sprawy pozwoli na znaczne skrócenie czasu w dalszych fazach tworzenia gry, nie wspominając o tym jak może to podnieść atrakcyjność gry. Dobrze zaplanowany świat i scenariusz to połowa sukcesu! Oczywiście jest to faza w której rozwijasz swoje przemyślenia z fazy pierwszej. Nikt nie mówi, że ten krok jest łatwy, ale czy ktokolwiek powiedział, że tworzenie dobrych gier jest łatwe? Oczywiście jeśli lubisz pisać, możesz się popisać swoją fantazją i umiejętnościami. Im bardziej zagmatwana i rozległa fabuła tym lepiej. Uważaj tylko na to, aby samemu nie pogubić się we własnym pisaniu. Nie ma nic gorszego niż skopana fabuła gry.
Niestety wielu projektantów traktuje ten krok po macoszemu. Tworzą scenariusz i fabułę na siłę albo wogóle, wymyślając ją w trakcie gry. Jest to ogromny błąd, który powoduje, że 90% takich gier NIGDY nie ujrzy światła dziennego. Naprawdę warto napisać trochę dłuższą i ciekawą fabułę. Wiadomo, że nie każdy ma talent i nie każdy jest Mickiewiczem, ale zawsze można pokazać założenia zapisane w segregatorze swojej dziewczynie lub kumplowi i zdać się na jej/jego wyobraźnię, pod koniec wprowadzając ewentualne poprawki.
3. Absorbowanie gracza
Musimy pamiętać o tym, że nie piszemy gier dla siebie (choć nierzadko dla zdobycia większej wiedzy programistycznej). Gra musi zachwycać, szokować, prowokować, ciekawić. Ludzie grają w gry ponieważ mają wpływ na losy bohaterów, mogą poczuć się swoistego rodzaju bogami, którzy mają kontrolę nad wirtualnym światem. Gra ma dostarczać rozrywki. Niektórzy preferują (bez obrazy) tępą strzelankę, a niektórzy wysublimowaną rozrywkę intelektualną w grze przygodowej. W zależności od preferencji gracza musimy znaleźć środki, jakimi będziemy się posługiwać do dostarczania graczowi podniety. Nawet jeśli stworzymy grę, która będzie miała hiperrealistyczną grafikę, a nie stworzymy ciekawej fabuły, to nasza gra będzie niewiele wartym "cukiereczkiem", który można obejrzeć raz lub dwa. Gracz chce mieć poczucie, że uczestniczy w życiu wirtualnego świata, że ma jakiś wpływ na jego kształtowanie. Należy o tym pamiętać, bo jest to bardzo ważne.
W zależności od rodzaju gry i jej klimatu musimy postarać się o to aby możliwie jak najwięcej zmysłów gracza było zaabsorbowanych naszą grą. Jeśli tworzymy np. grę przygodową w stylu Larry 7, chcemy aby gracz grał w naszą grę z uśmiechem na ustach, raz po raz tarzając się na podłodze ze śmiechu. Jeśli tworzymy psychotyczny horror, chcemy aby gracz się bał i przy pierwszej lepszej okazji omal nie dostał zawału serca. ;) Nie możemy jednak przesadzać, bo jeśli graczowi wyda się, że gra jest zbyt straszna, to zrezygnuje on z gry i nie będzie chciał do niej powrócić. Dlatego należy znaleźć złoty środek.
Co więc powoduje, że gracz grając w naszą grę chce krzyczeć, bać się, zanosić się śmiechem? Otóż powoduje to oddziaływanie na zmysły. Im więcej zmysłów gracza uda nam się podporządkować tym lepiej. Z pewnością kluczowe znaczenie mają dwa zmysły: wzroku i słuchu. Trochę rzadziej zmysł dotyku. Ten ostatni może być absorbowany tylko przez specjalne urządzenia jak joysticki, pady lub myszki z ForceFeedback'iem lub inną podobną technologią.
Zajmijmy się w takim razie zmysłem wzroku. Jest to główny element, poza grywalnością, który wpływa na przyciągnięcie gracza do monitora. Piękna, fotorealistyczna grafika może zachwycić gracza. Im więcej szczegółów tym bardziej gracz jest oczarowany. Spójrzcie np. na taką grę jak Unreal2. Na sam widok tej gry człowiek chce krzyczeć! Nie zawsze jednak taki typ grafiki może być odpowiedni do naszych celów. Jeśli chcemy na przykład stworzyć baśniowe RPG lub przygodówkę typu Wacki, to taka grafika byłaby nieodpowiednia. Jak więc określić grafikę, która zachwyci gracza? Wszystko zależy właśnie od typu i klimatu naszej gry. Jeśli chcemy aby grafika przypominała kreskówki, to musimy zastosować taką konwencję grafiki, która będzie kolorowa i tryskająca humorem. Nie musi być bardzo szczegółowa. Natomiast, jeśli chcemy stworzyć horror, grafika musi być utrzymana w ciemnych, ziemistych barwach, z mnóstwem ciemności. Wszystko zależy od poczucia estetyki gracza. Grafika musi być estetyczna i utrzymana w jednej konwencji. Np. jeśli stworzymy grę z fotorealistyczną grafiką, a jako potworki damy rysowane ręcznie postacie to poczucie estetyki gracza będzie mocno zachwiane, a tym samym gracz może być mocno zdegustowany. Tak samo jeśli stworzymy już naszą nieśmiertelną przygodówkę z kreskówkową grafiką i wstawimy w pewnej lokacji zdjęcie samochodu to gracz także poczuje się zdegustowany. Oczywiście, czasami można uciec się do wykorzystania takiego triku, ale jeśli nie tworzysz gry z bohaterami Monty Pythona, zastosowanie takiej konwencji graficznej nie ma większego sensu.
Warto w tej fazie zaprojektować concept-art'y (czyli grafiki poglądowe) lokacji, broni, potworków, postaci, pojazdów, itd. Jeśli nie umiemy rysować to można zlecić to naszemu grafikowi, zdając się kompletnie na jego wyobraźnię lub też podać mu wytyczne. Concept-art'y powinny być jak najbardziej zgodne z klimatem gry. Zwykle concept-art'y powinny być rysowane na gładkim papierze. Technika jest w zasadzie dowolna, aczkolwiek najczęściej stosowana technika czarno-białych concept-art'ów to ołówek lub tusz. Najbardziej popularne techniki kolorowych concept-art'ów to farby olejne lub gwasze, tudzież kredki świecowe. Jest to naprawdę ważny krok, ponieważ koordynator projektu może już na etapie projektowania grafiki mieć wgląd w to co należy jeszcze poprawić, a co jest ok. Jeśli sami malujemy concept'y możemy je potem przedstawić grafikowi, aby wiedział jak dana grafika ma mniej więcej wyglądać po ukończeniu.
Jednak sam zmysł wzroku to nie wszystko. Równie ważny jest zmysł słuchu, który dobrze wykorzystany może w połączeniu ze zmysłem wzroku wywoływać różne emocje u gracza. Jak ważna jest muzyka i dźwięk przekonajcie się sami grając w grę taką jak np. System Shock 2 lub Thief z dźwiękiem i bez niego. Muzyka wpływa na stany emocjonalne gracza. Może budzić rozbawienie, litość, żal, strach, niepokój, napięcie. Umiejętnie dobrana ścieżka dźwiękowa wpływa doskonale na odczucia gracza podczas gry. Zobaczcie jak wielką rolę odgrywa muzyka w filmach. Najlepiej gdy muzyka zmienia się wraz z sytuacją w grze. Wpływa ona wtedy na jeszcze większe emocje wyzwalane u gracza. Podobnie jest z dźwiękiem. Jeśli np. tworzymy horror, to nagły ryk bestii w połączeniu z rzuceniem się jej na postać gracza spowoduje, że niespodziewający się niczego gracz, podskoczy na stołku i zacznie na oślep strzelać. Również ryki bestii czających się gdzieś w ciemnościach cmentarza lub złowrogie odgłosy podmuchu wiatru budują atmosferę grozy. Dlatego nie należy lekceważyć potęgi dźwięku. W szczególności jeśli wykorzystujemy go umiejętnie w połączeniu z grafiką.
Wszystko to jednak miałoby niezbyt wielkie znaczenie jeśli nie jeszcze jeden czynnik. Tym czynnikiem jest element zaskoczenia. Czy opisany wyżej przypadek bestii rzucającej się na gracza, wywarłby tak ogromną reakcję, gdyby gracz wiedział, że bestia skrada się w jego kierunku? Z pewnością nie. Element zaskoczenia musi być stosowany umiejętnie, bo w przeciwnym wypadku gracz może przyzwyczaić się do tego, że np. zza każdego winkla wyskakuje w jego kierunku bestia. Należy podsunąć grającemu złudne poczucie bezpieczeństwa, a w momencie w którym najmniej się tego spodziewa, zaskoczyć go. Oczywiście to przykład horroru i to raczej w wydaniu FPP, ale nic nie stoi na przeszkodzie, aby podobną konwencję zastosować w grze przygodowej czy jakiejkolwiek innej. Chodzi tu tylko o pewną ideę.
Element zaskoczenia może, a nawet czasami musi opierać się na fabule gry. Np. w momencie gdy gracz prowadząc swoją armię do zwycięstwa, jest już w 100% pewny, że wygrał, jest zaskakiwany np. przez zasadzkę w przełęczy górskiej, co prowadzi do rozbicia jego armii i objęcia prowadzenia przez przeciwnika komputerowego. Albo np. grający w grę przygodową uważa, że już jest blisko rozwiązania zagadki, lecz w tym momencie wychodzi na światło dzienne nowy wątek i gracz jest odsuwany od osiągnięcia celu. Należy to jednak robić niezwykle umiejętnie, ponieważ nie można zniechęcić gracza. W momencie odsunięcia go od celu, należy podsycić jeszcze jego ciekawość, aby chciał grać dalej. W tym momencie możecie zobaczyć jak ważna jest dobrze zaprojektowana fabuła i przemyślany scenariusz. Nieoczekiwane zwroty akcji są niezwykle pożądane, lecz muszą być naprawdę umiejętnie wykorzystane.
Jest jeszcze jedna sprawa, która zadecyduje o tym czy gracz będzie grał w naszą grę, czy też nie. Chodzi mianowicie o to, aby każdy etap gry prowokował i nagradzał, aby w jakiś sposób przybliżał gracza do celu. Podczas gry należy motywować gracza do dalszej zabawy. Nie można stworzyć np. RPG w którym przez 9/10 gry nic nie będzie się działo, co przybliżyło by gracza do celu, za to w ostatniej części gry, gracz otrzymałby "kawę na ławę". Owszem można nie mówić graczowi wszystkiego i większość enigmatycznych spraw wyjaśnić na końcu, jednak w taki sposób, aby gracz przez prawie całą grę myślał, że to czego dowiaduje się podczas rozgrywki jest tylko właściwym dla rozwiązania zagadki. Dzięki temu zakończenie w pełni usatysfakcjonuje gracza.
4. Algorytmy
Projektowanie gry to nie tylko fabuła i scenariusz oraz grafika. To także algorytmy. Naprawdę warto abyśmy je zaplanowali przed przystąpieniem do dalszych faz tworzenia naszej gry. Warto zaplanować algorytmy poruszania się postaci, głównego bohatera, pojazdów, itd. Szczególnie ważne są algorytmy sztucznej inteligencji. Np. jeśli tworzymy RTS to musimy opracować algorytmy poruszania się jednostek, wyszukiwania przez nie najlepszej możliwej trasy, a także algorytmy, które odpowiadają za obronę naszej bazy przez nasze jednostki. Musimy opracować algorytmy, którymi będzie kierował się komputer. W jaki sposób będzie się rozwijał, kiedy atakował, jak się bronił, jakie cele będzie sobie stawiał.
Warto rozważyć ten problem ponieważ gdybyśmy wymyślali algorytmy podczas pisania gry to moglibyśmy natrafić na trudności, które zmuszałyby nas do ogromnych zmian w kodzie gry albo prowadziłyby do całkowitego upadku projektu. Algorytmy są prawie najważniejszym elementem każdej gry. Bez nich żadna nie mogłaby istnieć.
Opracowanie algorytmów na kartce, czasem może przysporzyć sporo kłopotów, dlatego warto podczas ich planowania spróbować napisać małe programiki testowe, które będą je wykorzystywały. Nie chodzi tu bynajmniej o to aby zaraz pisać połowę gry. O nie. Chodzi natomiast o napisanie bardzo schematycznych programów, które wykorzystywałyby nasz opracowany algorytm. Dzięki temu wynikają z tego dwie korzyści. Możemy wypróbować algorytm czy działa i nie zawiera błędów oraz możemy udoskonalić algorytm jeszcze przed przystąpieniem do kodowania gry. Możemy także wypracować najlepszą technikę wprowadzenia algorytmu do naszej gry.
5. Sprawy techniczne
Po określeniu większości założeń gry, możemy przystąpić do czysto technicznego etapu projektowania. Wykorzystując ogólne założenia gry, które zapisaliśmy w naszym segregatorze, w poprzednich krokach, możemy zastanowić się nad technicznymi aspektami gry.
Podstawowymi zagadnieniami tego etapu projektowania jest wybór platformy sprzętowej, języka programowania, oraz API w jakim będziemy pisać. Wybór tego pierwszego decyduje o wyborze języka, a ten z kolei o wyborze API. Na platformę sprzętową składa się nie tyle jaki komputer wybierzemy, ale pod jakim systemem operacyjnym chcemy pisać. Praktycznie dwa liczące się systemy do rozwoju gier to Windows i Linux. Jeśli wybierzemy ten drugi, mamy praktycznie bardzo wiele możliwości wyboru języka, począwszy od nieśmiertelnego C przez C++, Kylix, Tcl/Tk, Bison, Python i na Perlu oraz PHP kończąc. Większość z tych języków obsługuje API OpenGL oraz SDL. Muszę tu powiedzieć, że to pierwsze API nie obsługuje nic poza grafiką, głównie trójwymiarową.
W przypadku wyboru systemu z piekła rodem, znaczy się z Redmond, możemy spotkać się z równie szeroką paletą języków. Mamy do wyboru C, C++, Delphi, Visual Basic, DarkBasic, Python i Perl. Te dwa ostatnie jednak ze względu na swoją interpretowaną budowę, nie są zbyt dobrym wyborem. Ponadto nie obsługują innego API niż OpenGL. API jakie mamy do wyboru to niezwykle popularny DirectX, OpenGL oraz SDL. Te dwa ostatnie, w przypadku wyboru któregoś z języków pochodzących z *NIX'a, dają nam możliwość łatwego przenoszenia kodu między Windozem, a *NIX'em.
Gdy już wybraliśmy środowisko programowania, należy zastanowić się nad innymi aspektami technicznymi gry. W skład tej fazy wchodzi zaprojektowanie lub wybór gotowego silnika gry. Każda gra posiada jakiś silnik, niezależnie od tego czy jest to najlepsza FPP/TPP pod słońcem czy prosty tetris. Każda gra posiada swój silnik.
Co robi taki silnik? Otóż jest on kluczowym elementem danej gry odpowiedzialnym z grubsza za wyświetlanie grafiki, odgrywanie muzyki i dźwięku, symulację fizyki gry, zachowania sztucznej inteligencji, obsługę interfejsu użytkownika, interakcję z otoczeniem, zapisywanie i odczytywanie stanu gry, słowem wszystko co wiąże się z grą. Projektowanie silnika gry to temat rzeka, ja jednak przybliżę wam pokrótce jak należy się do tego zabrać.
Niestety projektowanie silnika jest bardzo niewdzięczną fazą tworzenia gry. Musimy przewidywać naprzód, aby zaoszczędzić sobie mnóstwa kłopotów w trakcie pisania silnika. Musimy dokładnie rozważyć co chcemy osiągnąć i jakie rzeczy ma nasz silnik wykonywać. Nie przewidzenie jakiejś rzeczy, może mieć fatalne skutki w fazie pisania gry, gdyż niejednokrotnie musimy przerabiać cały silnik lub pisać go od nowa. Najlepiej jest podzielić nasz silnik na zasadzie budowy modułowej, wykonywanej poprzez klasy. Np. jedna klasa odpowiadająca za wyświetlanie poziomów, druga odpowiedzialna za interfejs, trzecia za zachowanie sztucznej inteligencji, czwarta za parsing języka skryptowego, piąta za wczytywanie plansz... Warto także rozważyć czy nasz silnik będzie mógł być rozwijany przez dodawanie dodatkowych funkcji np. przez biblioteki .DLL.
Projektując silnik warto wcześniej zaplanować jaki będzie format wyświetlanych przez niego poziomów. Weźmy za przykład przygodówkę typu Wacki, jednak z tylko jednym bohaterem dla uproszczenia. Do wyświetlenia poziomu potrzebny jest mniej więcej format pliku zawierający pola:
ID
Nazwa planszy
Tło
Dźwięk tła
Nazwa skryptu sprite'ów
Nazwa skryptu oddziałującego na planszę
Nazwa skryptu interakcji z użytkownikiem.
ID może być umowne i wykorzystane przez skrypt fabuły. Nazwa planszy może być nazwą lokalizacji widoczną dla użytkownika. Tło może wskazywać na lokalizację bitmapy. Dźwięk tła wskazuje np. na plik z dźwiękiem szumu morza lub wiatru. Nazwa skryptu oddziałującego na planszę stanowi jakby odwołanie do zewnętrznego skryptu, który może definiować np. obszar poruszania się bohatera po planszy, zdarzenia losowe (np. przelot samolotu na niebie), miejsce startowe bohatera, itp. Nazwa skryptu interakcji z użytkownikiem może zawierać np. działanie silnika jeśli użytkownik kliknie w dany obszar planszy.
Skrypt rozmieszczający sprite'y na planszy musi być wydzielony, ponieważ niektóre sprite'y mogą zniknąć/pojawić się w razie interakcji z użytkownikiem lub jeśli rozwój akcji gry tego wymaga. Przykładowy skrypt dla sprite'ów wyglądał by następująco:
Ilość sprite'ów (i_s)
i_s * Sprite {
id
nazwa
warunek istnienia {
pozycja x
pozycja y
pozycja z // do skalowania
flaga "czy interaktywny z interfejsem użytkownika?" {
flaga "czy możliwe podniesienie przez użytkownika?"
nazwa skryptu interakcji z użytkownikiem
}
nazwa skryptu zachowania sztucznej inteligencji
}
}
W ten sposób konstruujemy modułową budowę skryptów odpowiadających za całą grę. Zadaniem silnika jest tylko w odpowiedni sposób je przetworzyć. Dzięki odpowiedniemu zaplanowaniu silnika możemy go wykorzystywać w wielu innych naszych produkcjach przy zmianie tylko skryptów. Podany wyżej model formatu poziomów jest tak dobrze zaplanowany, że nic nie stoi na przeszkodzie by dodać dwóch, trzech, a nawet więcej bohaterów, którymi kierowałby gracz. Jedynym ograniczeniem byłyby ograniczenia możliwości języka skryptowego. Wiele gier opiera się o własne języki skryptowe. Naprawdę warto je stosować.
Parser języka skryptowego jest podstawą silnika gry. Oczywiście możemy nie pisać parsera i wszystko "na żywca" zakodować w grę, lecz takie rozwiązanie jest po pierwsze nieekonomiczne, po drugie powoduje, że ludzie nie mogą pisać ewentualnych modów do naszej gry, po trzecie nasz silnik staje się tylko jednorazowy i nie można go bez kłopotów wykorzystać do innych produkcji. Język skryptowy nie musi być wcale jakiś wyszukany i może być bardzo prosty w swojej budowie, ważne natomiast żeby spełniał swoje zadanie.
Podczas projektowania silnika gry należy oprócz opracowania formatu poziomów zdecydować jakie formaty graficzne, muzyczne, dźwiękowe i animacyjne będą stosowane. W przypadku gier 3D należy określić jaki będzie wykorzystywany format modeli, plansz, dźwięku przestrzennego, tekstur, itd. W zależności od rodzaju gry jaką chcemy stworzyć możemy wykorzystać standardowe formaty danych lub stworzyć własne. W tym drugim przypadku musimy dokładnie przemyśleć struktury danych jakie będą nam potrzebne w danym formacie.
Jeśli zdecydujemy się na własne formaty danych, które w zależności od potrzeb mogą nam dać nieporównywalnie większe możliwości, będziemy musieli zaprojektować narzędzia edycyjne dla tych formatów. Niejednokrotnie znacznie lepiej jest opracować własny edytor jednego formatu danych niż np. korzystać z 3 różnych formatów danych dla osiągnięcia tego samego celu. Należy jednak pamiętać, aby uwzględnić w nagłówku pliku ID formatu, wersję i zawrzeć inne potrzebne tam dane. Polecam także zostawić od kilku do kilkuset bajtów w przypadku jeśli chcielibyśmy zachować kompatybilność ze starym formatem w nowszych wersjach, ale jeszcze nie wiemy do czego to kilka bajtów może nam się przydać. Naprawdę polecam taką praktykę, gdyż wiele razy sam na własnej skórze odczułem jak przewidywanie popłaca.
Edytory i struktury własnych formatów danych powinny być zaprojektowane zanim przystąpimy do projektowania bardziej szczegółowych funkcji silnika. Przede wszystkim musimy określić co tak naprawdę nam będzie potrzebne i co chcemy osiągnąć poprzez wykorzystanie takiego, a nie innego formatu danych. Wszystkie nasze projekty odnośnie silnika, formatów danych i edytorów oczywiście zapisujemy szczegółowo w naszym segregatorze, ale chyba nie muszę więcej mówić po co.
6. Tworzenie gry
Mając opracowane projekty gry, możemy przystąpić do jej tworzenia. Zanim jednak z właściwym nam zapałem rzucimy się do ulubionego kompilatora powinniśmy jeszcze chwilkę się powstrzymać. Najpierw musimy sporządzić sobie listę programów i edytorów, które wykorzystamy do tworzenia naszego dzieła. Warto to zrobić, bo w pewnym momencie możemy obudzić się z ręką w nocniku. Musimy pamiętać o edytorach: graficznym, dźwiękowym, muzycznym, animacyjnym, modeli 3D i świata gry. Jeśli już stworzymy taką listę, musimy upewnić się czy posiadamy wszystkie te edytory. Gdy już je posiadamy, jak i nasz ulubiony kompilator, warto sprawdzić czy mamy biblioteki API w którym zamierzamy pisać naszą grę.
Gdy stwierdzimy, że posiadamy wszystko co jest nam potrzebne, możemy przystąpić do pracy. Jeśli pracujemy w zespole, to według wytycznych z naszego segregatora rozdzielamy robotę pomiędzy grafików, muzyków, inżynierów dźwięku, programistów, projektantów poziomów i innych ludzi zajmujących się poszczególnymi aspektami gry. Jeśli jesteśmy sami to musimy pamiętać o kolejności wykonywanych prac. Zaczynamy oczywiście od grafiki, następnie tworzymy silnik, potem projektujemy poziomy i świat gry. Na samym końcu tworzymy dźwięk i muzykę. Należy pamiętać o tym, że podczas tworzenia silnika gry niejednokrotnie będziemy musieli tworzyć testowe etapy, aby wypróbować funkcjonalność naszego dzieła i likwidować ewentualne błędy.
Gdy wszystkie poprzednie rzeczy są już gotowe, piszemy właściwą grę w oparciu o nasz silnik.
Tutaj, jak i przy pisaniu silnika warto pamiętać o kilku sprawach. Pierwszą jest tworzenie kopii zapasowych naszego programu. Bardzo często zdarza się tak, że człowiek przez pomyłkę zniszczy sobię swoją kilkudniową pracę. Warto także zapisywać naszą pracę możliwie często. Nikt przecież nie wie, kiedy spece z elektrowni w alkoholowym amoku zaczną bawić się wyłącznikami prądu. Jeśli ukończymy pewien etap developingu gry, czyli osiągniemy cele postawione do osiągnięcia kolejnego numerka wersji, zróbmy kopię CAŁEJ GRY i wrzućmy ją do katalogu w którym będziemy przechowywać wszystkie starsze wersje naszego projektu. Warto, naprawdę warto. Wielokrotnie zdarzało mi się, że chciałem wrócić do starej, działającej wersji i nie było jak, bo nie zrobiłem kopii zapasowej. A zdarza się to niezwykle często. I jeszcze jedna bardzo ważna rzecz. Naprawdę warto komentować. Jeśli nie jesteś zrośnięty ze swoim komputerem i nie tworzysz z nim jednolitej całości, pamiętaj o komentarzach! Inaczej gdy po kilku miesiącach zechcesz zrobić coś z tym kodem, będziesz musiał żmudnie analizować wszystko od początku do końca.
Jeśli gra jest już gotowa, należy zabrać się za alfatesty. Są to testy wewnętrzne przeprowadzane w środowisku twórców gry. Po poprawieniu wszelkich błędów, możemy rozpocząć betatesty, czyli testy otwarte. Wybrana grupa osób z zewnątrz otrzymuje naszą grę i testuje ją, wyszukując ewentualne błędy w grze. Po okresie betatestów i zlikwidowaniu wszelkich błędów, nasza gra jest gotowa do użytku.
Wydaje się, że wszystko tutaj jest ładnie-pięknie, lecz w praktyce jest to jeden z najgorszych możliwych etapów. 90% czasu programistów zajmuje nie tyle napisanie gry, co wyśledzenie błędów. Dlatego warto tutaj zastosować kilka zasad. Podczas pisania naszej gry uwzględnijmy funkcję, która pozwoli na logowanie ewentualnych błędów i wartości zmiennych. Funkcja ta może zapisywać dane do pliku np. "debug.txt". Dzięki temu, szczególnie w fazie betatestów, będziemy mogli łatwo wywnioskować gdzie i czemu powstał błąd, który np. nie występuje u nas.
Warto także napisać prosty programik, który może w razie sypnięcia się naszej gry, będzie automatycznie raportować nam błędy poprzez wysyłanie nam np. emaila. Nie jest to zbyt trudne nawet dla początkującego. Przy pisaniu takiego narzędzia raportującego należy pamiętać o kilku rzeczach. Po pierwsze takie narzędzie musi nam przesyłać plik "debug.txt" z naszej gry. Po drugie narzędzie musi wysłać nam jak najwięcej informacji o systemie testera, tzn. system operacyjny, jego wersję, wersję używanych API, rodzaj karty graficznej, muzycznej, sieciowej oraz numery wersji ich sterowników. Warto także przesłać dane o innych częściach komputera, tzn. płycie głównej, procesorze, pamięci, dysku twardym, cdromie, itd. Nigdy nie wiadomo czy któreś z tych urządzeń nie powoduje błędnego działania naszej gry. Oczywiście musimy uwzględnić to, że użytkowik może nie zechcieć podzielić się z nami informacją o crashu.
7. Zakończenie
Mam nadzieję, że ten artykuł przybliżył wam wizję jak powinno się poprawnie tworzyć gry komputerowe. Naprawdę warto stosować się do tych zaleceń, gdyż wiele zagadnień przedstawionych w tym artykule jest po prostu lekceważona przez wielu projektantów gier. Są jednak one na tyle ważne, że w dużym stopniu pozwalają na ukończenie projektu. Oczywiście drugą ważną rzeczą jest zapał. Jednak jeśli projekt zostanie dobrze zaplanowany to znacznie rzadziej traci się zapał do jego tworzenia.
I pamiętajcie te kilka wskazówek na przyszłość:
* Zawsze opłaca się coś DOKŁADNIE zaplanować zanim się to wykona.
* Nigdy nie porywajcie się na coś, czego nie jesteście w stanie zrobić, bo wasz projekt nigdy nie zostanie dokończony.
* Starajcie się przewidzieć co wam będzie lub może być potrzebne.
* Twórzcie kopie zapasowe tak często jak się da i na ilu nośnikach tylko możesz.
Jeśli ten dość obszerny tutorial spodobał się wam (bądź nie) piszcie na mój adres email (
wolverine@mitsoft.pl). Jeśli macie jakieś pytania, uważacie, że coś należy tutaj poprawić lub zmienić to także dajcie znać. Wreszcie jeśli sądzicie, że lektura tego tutoriala była dla was pożyteczna i chcielibyście poczytać więcej moich tutoriali, na różne tematy związane z projektowaniem i tworzeniem gier komputerowych to KONIECZNIE PISZCIE DO MNIE.
źródło :
http://www.gamedev.pl/articles.php?x=view&id=97&comments=1
