Wzorce projektowe
Download
Report
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.