Tworzenie gry komputerowej

Z Wikipedii

Tworzenie gry komputerowej zaczyna się od zaprojektowania jej, stworzenia dokumentu projektu. Określa on najpierw podstawowe dane o grze (gatunek, docelowa grupa odbiorców, świat gry), następnie powstaje design doc (z ang. dokument projektu), w którym zawarte są praktycznie wszystkie informacje o grze. Sam proces tworzenia gry jest zależny od przyjętej strategii twórców, stosowanej przez nich metodologii projektowej.

Spis treści 1 Prototyp 2 Projekt gry 3 API oraz biblioteki 3.1 Graficzne API 3.2 Inne API 4 Pętla gry 4.1 Warstwowa budowa 5 Produkcja 6 Milestone'y 7 Blisko ukończenia

[edytuj] Prototyp

Prototyp ma za zadanie ukazać najważniejsze założenia z design doca. Zazwyczaj testy prototypowe powodują wiele zmian w samym projekcie gry. W prototypie znajduje się np. tylko jeden scenariusz z kampanii całej gry, bez żadnych menu, itp. - tylko sama gra, "pokazowa". Służy on głównie jako miejsce na szybkie sprawdzanie nowych pomysłów w akcji, przez wprowadzenie takich zmian w jego kodzie.

Prototyp nie musi być wykonany w języku, w którym powstanie gra. Musi jedynie ukazywać koncepcje projektu gry, dać możliwość ich przetestowania, sprawdzenia "w praniu". W ostatecznym rozrachunku i tak wszystko zostanie napisane ponownie.

Z racji zadania prototypu, od jego wykonawcy oczekuje się dużej szybkości tworzenia, potrzebnej zresztą później - aby móc szybko przetestować nowe pomysły. Stąd prototyp jest często tworzony z pomocą środowiska RAD lub innych tego typu narzędzi zwiększających prędkość tworzenia oprogramowania.

[edytuj] Projekt gry

Projekt gry, design doc jest sercem projektu. Znajdują się w nim wytyczne dla wszystkich członków zespołu, łączy on prace grafików, programistów czy marketingowców. Stąd jakość projektu gry jest bardzo ważnym elementem w procesie tworzenia gry. Często design doc powstaje z udziałem całego zespołu - projektanci konsultują się z programistami czy grafikami.

Design doc najczęściej zawiera: ogólny opis gry, wszystkie dane, wzory i obliczenia mechaniki, koncept arty, opisy technologii programistycznych, strategie marketingowe, strategie finansowe projektu, wytyczne nadzorowania dla kierowników działów.

[edytuj] API oraz biblioteki

Kluczową decyzją w procesie programowania gry jest wybór API i/lub bibliotek, których będzie się używać. Chodzi tutaj w głównej mierze o silnik graficzny, lecz pozostaje także wybór biblioteki obsługującej dźwięk czy wejście (myszka, klawiatura).

Przy czym, należy pamiętać, że API (z ang. interfejs programistyczny) to bardziej "niskopoziomowe" polecenia. API jest na przykład DirectX. Natomiast biblioteka to najczęściej opakowanie dla API, często z poprawkami i dodatkową funkcjonalnością - do bibliotek wliczają się właśnie silniki graficzne.

Wybierając API twórcy kierują się dostępnością jego na platformy - tak aby API było dostępne na docelowe dla projektu platformy. Oprócz tego oczywiście sprawą ważną jest język, dla którego API jest dostępne.

[edytuj] Graficzne API

Obecnie najpopularniejszą platformą PC jest Microsoft Windows. Tutaj liczą się głównie dwa API graficzne - DirectX i OpenGL. Od czasów, gdy te API powstały, toczą się dyskusje, które kiedy się lepiej sprawdza. Do dziś te dyskusje trwają i nie zanosi się na to, aby się zakończyły.

DirectX, w skrócie nie jest tylko API graficznym, ale jest zestawem interfejsów programistycznych przydatnych w grach. W DirectX znajduje się Direct3D (moduł graficzny), DirectInput (wejście), DirectSound (dźwięk), DirectPlay (multiplayer) - acz dziś nie poleca się używania DirectPlay. Pakiet DirectX nie jest portowalny (jedynie na inne produkty Microsoftu - Xbox oraz na PocketPC, na którym zainstalowany jest system Windows). Najnowszą wersją DirectX jest DirectX 10.

OpenGL głównie jest portowalny. Kod napisany z użyciem OpenGL możemy skompilować z Windowsa do Apple Macintosha lub Linuxa. W OpenGL powstały produkty id Software jak seria Quake czy Doom.

[edytuj] Inne API

Dla twórców na platfrmę Microsoft Windows pakiet DirectX oferuje cały zestaw innych bibliotek potrzebnych w grze. Twórcy programujący w OpenGL najczęściej korzystają z API pakietu DirectX. Spotyka się też wykorzystywanie SDL do obsługi wejścia oraz dźwięku, natomiast do wyświetlania OpenGL (w SDL OpenGL jest dostępny z poziomu API).

[edytuj] Pętla gry

Właściwie cała gra działa na podstawie jednej pętli - pętli gry. W niej są wywoływane kolejno warstwy wejścia, logiki, grafiki oraz dźwięku.

Najczęstsza kolejność poleceń w pętli:

pętla( użytkownik nie wyłączył gry )
  sprawdzenie wejścia gry
  wykonanie warstwy logicznej
  sprawdzenie kolizji
  narysowanie grafiki
  odegranie dźwięków
koniec pętli

[edytuj] Warstwowa budowa

Gra zazwyczaj jest zbudowana z warstw: grafiki, logiki, wejścia, dźwięku. Każda z warstw przechowuje ważne tylko dla siebie dane - przykładowo warstwa wejścia stan wciśniętego klawisza myszki - oraz odpowiednio na nie reaguje. W grze zazwyczaj występuje szeroko pojęta komunikacja między wszystkimi warstwami. Idąc dalej tym samym przykładem warstwa wejścia otrzymała komunikat, że gracz przycisnął lewą strzałkę na klawiaturze. W związku z tym, warstwa wejścia wywołuje warstwę logiczną, aby ta odpowiedziała - i warstwa logiki przesuwa pozycję gracza o n pikseli w lewo. Natomiast procedura rysująca z warstwy graficznej, chce narysować gracza, więc odwołuje się do warstwy logiki, aby ta zwróciła pozycję gracza - aby móc narysować go na ekranie według jego pozycji. Każda z warstw ma swoją funkcję, w której jest jej pętla, czyli na przykład rysowanie grafiki w warstwie graficznej. W pętli gry wszystkie pętle warstw są wywoływane według wyżej podanej kolejności.

[edytuj] Produkcja

Podczas produkcji, programiści piszą kod źródłowy, który będzie odzwierciedleniem gry opisanej w design documencie.

Nad zespołem programistów czuwa główny programista, którego zadaniem jest nadzorowanie pracy. Wydziela on dla każdego z programistów obowiązki, a także stara się dotrzymywać terminów spisanych w design documencie. Tutaj dużą rolę odgrywa przyjęta przez firmę metodologia - niektóre wdrażają listy zadań czy automatyczne testy, natomiast inne wręcz nie pozwalają na takie zmiany.

Programista jednak tworzy tylko kod używający zasobów gry, natomiast zasoby tworzą graficy, muzycy i inni. Dlatego też bardzo ważne jest zgranie i integracja zespołu programistów z resztą pracowników. Pracownicy lubią, gdy efekty są widoczne od razu - występuje wtedy motywacja, sprzężenie zwrotne. W czasie produkcji tworzone są także dane fizyczne (czyli np. scenariusze, misje, dane o państwach) przy pomocy narzędzi utworzonych przez programistów.

[edytuj] Milestone'y

Najczęściej postęp tworzenia gry jest oznaczany przez milestone'y - kamienie milowe. Kamień milowy, jak sama nazwa wskazuje, jest czasem, gdy zostanie skończony kolejny ważny element gry - np. utworzenie edytora danych fizycznych gry. Przy tworzeniu gier przez zdalnie połączonych twórców milestone oznacza kolejne spotkanie się wszystkich członków.

Liczba wykonanych kamieni milowych (np. 2/5) stanowi ważną informację dla wydawcy gry, który często płaci za każdy skończony milestone.

[edytuj] Blisko ukończenia

W tym okresie też zaczynają się beta testy. Oznacza to, że cele opisane w design documencie zostały wykonane, lecz gra zawiera jeszcze wiele błędów. Rozpoczyna się praca dla zespołu testerów, którzy wyłapują błędy, zgłaszają je do głównego programisty, a ten rozdziela usuwanie ich między swój zespół.

Często zdarza się, że ostateczny termin wydania gry wyznaczony przez wydawcę (nieprzekraczalny) wypada np. tydzień po tym gdy skończono wersję gotową do beta testów. Wtedy w połowie procesu testowania i usuwania błędów gra zostaje wydana - przez co po produkcji pojawiają patche zawierające poprawki usuwające błędy.

Gdy gra jest już wolna od błędów, oznaczana jest jako wersja "złota".