„Zastosowanie wzorców w programowaniu gier komputerowych” Szymon „Veldrin” Jabłoński

Agenda Skąd pomysł na prezentację? Myśl przewodnia „Dobry” kod źródłowy Definicje O czym ten wykład nie będzie Wzorzec „Gra” Wzorzec „Gatunek” Wzorce projektowe

Skąd pomysł na prezentacje? Potrzeba regularnego powrotu do oczywistych oczywistości; Przypadki produktów grywalnych/użytecznych tragicznie napisanych (projekty OSlib, Java MapEditor); Mało materiałów na portalach np. GameDev; Mało dyskusji na forach – temat wydaje się pomijany, błąd; Częste sytuacje szukania „dziwnego” rozwiązania wzorcowego problemu Próba przemyślenia i przedyskutowania tematu.

Czemu tak się dzieje? Gry tworzone są przez graczy – hobbystów; Ludzie uczą się programować od podstaw tworząc gry; Grywalny, „dobry” produkt nie musi być wcale dobrze napisany(pułapka); Brak wspólnego języka w zespołach; Zespoły mające dobre pomysły nie sięgają po programy middleware; Nadmierne skupianie się na grafice – programowanie gier skupia się na programowaniu grafiki; Wzorce są traktowane narzędzie do budowy systemów informatycznych, nie gier; Zapomina się, że gra komputerowa to aplikacja, rządzi się takimi samymi prawami( + dużo więcej oczywiście);

Myśl przewodnia prezentacji „Programista powinien skupić się na programowaniem gier, nie ich tworzeniem” Zasoby zostawmy grafikom i animatorom; Zasady i gameplay niech wymyślają designerzy; Nie starajmy się tworzyć pięknych arcydzieł, tylko twórzmy jak najwięcej różnych gier, na różnych platformy w różnych językach. Indywidualnie/w grupach; Ładne GUI, grafikę może zrobić gimnazjalista – my proponujmy lepsze pomysły rozwiązania programu.

„Dobry” kod źródłowy Kod się kompiluje; Działa według założeń, rozwiązuje nasz problem; Krótko mówiąc – działa. W tym momencie często przestaje nas interesować reszta aspektów; „Dobre nawyki, zgodność ze sztuką programistyczną” Trzymanie się przyjętej notacji; Spójność logiczna kodu; Udokumentowany; Spójność stosowanego języka: jak angielski to angielski; Zoptymalizowany ( ale nie na siłę!); Pozbawiony Anty-wzorców(wykład w zeszłym semestrze); Pokryty testami ( temat na prelekcję); Przenośny, uniwersalny, prosty, łatwy w konserwacji i rozwijaniu, zgodny ze standardem i dobrymi nawykami języka; Korzystający z wzorców projektowych ! I wiele, wiele innych.

Pytanie po co? Skoro mamy grywalny, fajny produkt bez „tracenia czasu na spełnienie tych wszystkich warunków – to po co to robić? Faktycznie grywalny i fajny, albo i nie? Zbliżamy się krawędzi możliwości sprzętu. Proste algorytmy na potężnych sprzętach; Różnice choćby w grach komercyjnych(przykład ME2/Dragon’s Age); Chcemy robić kasę na sprzedawaniu pół-produktów, czy sprzedawać coś dobrego(gry na konsole, a łatki na PC kilka lat temu), czy nowe gry na starcie wymagające po gb łatek; Jeśli ktoś wybiera pierwszą opcję – może już iść do domu :)

Wzorzec Wzorzec - to słowo, które może oznaczać wzór jednostki miary, wzór rzeczy, wyrobu albo zalecany wygląd lub zachowanie się osoby (wzór do naśladowania) lub zwierzęcia. Wzorzec to zwykle coś pozytywnego, godnego naśladowania a także cel do którego należy dążyć. metrologii: wzorzec jednostki miary, inaczej: etalon wzorzec inkrementalny w zoologii: wzorzec rasy wzorzec rasy psa w technikach projektowych: wzorzec projektowy- inaczej: wzorzec konstrukcyjny lub operacyjny w literaturze: Wzorzec - źródło mocy w Kronikach Amberu Rogera Żelaznego

Wzorzec projektowy Wzorzec projektowy (ang. design pattern) – w inżynierii oprogramowania , uniwersalne, sprawdzone w praktyce rozwiązanie często pojawiających się, powtarzalnych problemów projektowych.

O czym ten wykład nie będzie Nie będzie o wzorcach projektowych – bezpośrednio. Zakładam, że osoby zajmujące się programowaniem spotkały się już takim terminem; Za mało czasu na dokładne przedstawienie choćby kilku; Jedynie krótkie informacje o co chodzi w danych wzorcu; Zmuszenie do samodzielnej nauki – źródła będą dostępne;

„Wzorzec Gra”

Gra Gra – czynność o ustalonych zasadach, w której udział bierze zwykle kilka osób (rzadziej jedna). Od innych rozrywek grę oddziela istnienie ścisłego zbioru zasad gry, od innych skodyfikowanych czynności jej rozrywkowy charakter.

Gra komputerowa Gra komputerowa - program komputerowy służący do celów edukacyjnych lub rozrywkowych.

Wzorzec „Gra” Co nam z tego wynika? Gra to aplikacja – szczególny rodzaj aplikacji; Gra posiada zasady; Grę realizuje zespół ludzi o odmiennym wykształceniu - konieczność przyjęcia wspólnego języka. Do kogo skierowany wzorzec: projektanci , etap projektowania aplikacji.

Wzorzec „Gra” Czym się charakteryzuje? Specyficzne terminy, algorytmy ( teksturowanie, shadery, rendering, pętla czasu rzeczywistego); Dokładnie mówiąc: charakterystyczny język, który musi być wspólny dla wszystkich; Co możemy z tego wyciągnąć? Jakie gotowe, dobre rozwiązania. Co nam daje struktura pętli gry(potrzeba istnienia modułów renderowania, timerów, zarządzanie zasobami. Operujemy pojęciami niezależnymi od platformy/języka – abstrakcyjny szkielet aplikacji. Ustalenie podstawowych informacji o grze: jakie zasoby, ile wymiarów, jaka przestrzeń, dla kogo itp. Decyzje od razu sugerują nam potrzebne klasy, nie rzadko ich powiązania. Ileż daje sam fakt, że zaczynamy pisać „grę”.

Wzorzec „Gatunek” Do kogo skierowany wzorzec: projektanci , designerzy, etap projektowania aplikacji. Gatunek charakteryzuje nam grę. Czy tylko? Co możemy wyciągnąć z faktu, pisania danego gatunku? Przykładowo: RTS, jaka mapa (tile/hex), jednostki, budynki, hierarchie jednostek. FPS: czy w takim przypadku specyfikujemy ceny i zasoby dla budynków. Raczej nie. RPG: dialogi, zadania itp. Musimy uwzględnić też mieszanie gatunków, jeżeli na to się decydujemy. Krótko mówiąc: wybieramy gatunek/listę gatunków. Spisujemy rzeczowniki znajdujące się w opisie gatunku – otrzymujemy kolejne klasy/moduły/metody do implementacji. Określamy co potrzebujemy, a czego nie potrzebujemy.

Wzorzec „Gatunek” Do kogo skierowany wzorzec: projektanci , designerzy, etap projektowania aplikacji. Gatunek charakteryzuje nam grę. Czy tylko? Co możemy wyciągnąć z faktu, pisania danego gatunku? Przykładowo: RTS, jaka mapa (tile/hex), jednostki, budynki, hierarchie jednostek. FPS: czy w takim przypadku specyfikujemy ceny i zasoby dla budynków. Raczej nie. RPG: dialogi, zadania itp. Musimy uwzględnić też mieszanie gatunków, jeżeli na to się decydujemy. Krótko mówiąc: wybieramy gatunek/listę gatunków. Spisujemy rzeczowniki znajdujące się w opisie gatunku – otrzymujemy kolejne klasy/moduły/metody do implementacji. Określamy co potrzebujemy, a czego nie potrzebujemy.

Wzorce projektowe Do kogo skierowany wzorzec: projektanci , programiści etap implementacji aplikacji. Jak było wspominane: sprawdzone rozwiązania, częstych problemów. Generalnie: niezbyt skomplikowane. Uniwersalne, łatwość dopasowania do problemu. Istnieją trzy kategorie podstawowe: kreacyjne, strukturalne, czynnościowe. I wiele innych wymyślanych przez duże firmy tworzące frameworki itp.. Kilka uwag wstępnych: Warto używać. Nie stosować na siłę! To, że pasuje nie oznacza, że nie ma lepszego rozwiązania – ciągła nauka. W procesie nauki – warto korzystać jak najwięcej. Nauka po jednym. Przeczytać -> zaimplementować -> korzystać. Jak można wykorzystać w grach – przykłady, to czego brakuje wszędzie.

Singleton Popularny wzorzec(książki o programowaniu gier), masa tutoriali, dobrze pokazuje idee wzorców; Ogranicza możliwość tworzenia obiektów do jednej instancji; Zapewnia globalny dostęp – alternatywa dla zmiennych globalnych; Przykład zastosowania: teoretycznie wiele modułów „będzie miało” tylko jedną instancję; Ale też po co? Klasa Configuration, połączenie z fabryką obiektów. Ważne, żeby zastosowanie było logiczne !

Stan Ulubiony wzorzec projektowy; Pojawia się pojęcie automatu stanów – przydatne narzędzie; Obowiązkowy dla gier, dla każdej można znaleźć zastosowanie, czy to Saper, czy FPS; Przykład zastosowania: stan gry, stan obiektu, zastąpienie #define, enum (w Javie korzystanie z enum), podział pętli gry na stany gry (Play, Pause itp.); Np. Stan Mario, poruszanie się, wielkość itp.. Elegancja ! Połączenie z wzorcem Obserwatora, Strategii;

Strategia Enkapsulacja algorytmów i możliwość ich wymiany w trakcie działania. Przykład zastosowania to np. poziom trudności gry, poziom AI przeciwników itp. Ciekawe połączenie z wzorcem Stanu – w zależności od stany/zmian stanu zmiana obiektu strategii danego obiektu np. zamiast #define Go_Left, Go_Right if(…) zmieniamy animacje, to user input zmienia stan, który zmienia strategię, a kod aktualizacji postaci pozostaje update(dt), performStrategy(dt) np. Co nam daje takie połączenie? Pewną elegancję rozwiązania, możliwość łatwego rozwoju no i również optymalizację. Nie sprawdzamy w jakim stanie jest postać, przy możliwych 1000 stanów mamy wiele ifów na sekundę.

Fabryka obiektów Istnieje kilka rodzajów fabryk, prosta fabryka, skalowalna, prototypów, abstrakcyjna. Różne metody ten sam cel. Przykład zastosowania: tworzenie obiektów. Na podstawie pliku wczytywanie zasobów, budowanie poziomów gry, sklepy w grach itp. Fabryka zwykła/skalowalna: wczytywanie zasobów w zależności od rodzaju(tekstura, dźwięk), budowanie sceny. Fabryka prototypów: tworzenie co jakiś czas wielu jednostek do gry np. Star Wars Rogue Squadron – myśliwce imperium; Fabryka abstrakcyjna: każda postać otrzymuje inne obiekty. Przechowuje wskaźniki na abstrakcyjne klasy bazowe, rejestrujemy docelowe obiekty -> unikamy kolizji. Np. krasnolud dostanie swój topór/młot, a nie łuk przeznaczony dla elfa. Często łączy się z singletonem(fabryka skalowana);

Fasada Opis: dostęp do zaawansowanego systemu poprzez dobrze udokumentowane publiczne API. Przykład zastosowania: API bibliotek, silników itp. Ograniczenie dostępu tylko do wymaganych modułów, enkapsulacja systemu;

Adapter Opis: opakowanie interfejsu klasy w nowy, połączenie dwóch klas o niekompatybilnych interfejsach; Przykład zastosowania: opakowanie w klasy API, strukturalnych bibliotek graficznych, typów. Praca z cudzym brzydkim kodem -> opakowujemy w swój zgodny dla całego projektu interfejs.

Kompozyt Opis: kompozycja, jak przykładowy system plików. Przykład zastosowania: drzewo sceny. Obiekty mogą też być kontenerami innych obiektów np. mapa z domkami, w domkach szafy, w szafach ubrania itp. Inny przykład to kombinacje, makra. Połączenie z wzorcem Komenda.

Wizytator Opis: odseparowanie algorytmu od struktury obiektowej na której operuje Przykład zastosowania: Obsługa eventów, kolizji. Obsługa zdarzeń na podstawie tego co się wydarzyło. Elegancja! Brak setek ifów.

Wnioski Projektujmy. Programujmy. Mniej grania, więcej programowania :) Wzorce nie oferują remedium na każdy problem, są jedynie propozycją; Tak naprawdę stosujemy, często nie zdając sobie z tego sprawy: wzorzec Obserwatora czy Iteratora.

„Dziękuję za uwagę”