„Zastosowanie wzorców w programowaniu gier komputerowych”

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

3. 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

4. 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.

5. 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);

6. 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.

7. „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.

8. 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’sAge); • 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 :)

9. 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 AmberuRogera Żelaznego

10. 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.

11. 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;

12. „Wzorzec Gra”

13. 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.

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

15. 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.

16. 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ę”.

17. 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.

18. 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.

19. 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.

20. 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 !

21. 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;

22. 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 #defineGo_Left, Go_Rightif(…) zmieniamy animacje, to userinput 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ę.

23. 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 RogueSquadron – 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);

24. 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;

25. 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.

26. 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.

27. Wizytator • Opis: odseparowanie algorytmuod struktury obiektowejna 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.

28. 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.

29. „Dziękuję za uwagę”