Transcript Wzorce projektowe

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