Odpowiedz
Teraz mniej nonszalancka odpowiedź z kilkoma sugestiami. Nie traktuj ich jako zaleceń dotyczących implementacji, a raczej jako przykładów możliwych zastosowań.
- Konstruktor: konfiguruj encję opartą na komponentach po jednym komponencie na raz, na podstawie danych.
- Metoda fabryczna: utwórz NPC lub widżety GUI na podstawie ciągu odczytanego z pliku
- Prototyp: zapisz jeden ogólny znak „Elf” z właściwościami początkowymi i utwórz instancje Elfa, klonując go.
- Singleton: to miejsce celowo pozostawiono puste.
- Adapter: dołącz opcjonalną bibliotekę innej firmy, opakowując ją warstwa, która wygląda jak istniejący kod. Bardzo przydatna w przypadku bibliotek DLL.
- Złożony: utwórz wykres sceny obiektów renderowalnych lub utwórz GUI z drzewa widżetów.
- Fasada: uprościć złożone biblioteki stron trzecich, zapewniając prostszy interfejs, aby ułatwić sobie później życie.
- Waga: przechowuj wspólne aspekty NPC (np. modele, tekstury, animacje) oddzielnie od poszczególnych aspektów (np. stanowisko, stan zdrowia) w a przeważnie przejrzysty sposób
- Proxy: Twórz małe klasy na kliencie, które reprezentują większe, bardziej złożone klasy na serwerze i przesyłaj żądania przez sieć.
- Łańcuch odpowiedzialności: obsługuj dane wejściowe tak, jak łańcuch handlerów, np. klawisze globalne (np. do zrzutów ekranu), następnie GUI (np. w przypadku, gdy zaznaczone jest pole tekstowe lub menu jest otwarte), a następnie gra (np. do przesuwania postaci)
- Polecenie: hermetyzuje funkcjonalność gry w postaci poleceń, które można wpisywać na konsoli, przechowywać i odtwarzać, a nawet skryptować, aby pomóc w testowaniu gry.
- Mediator: implementuj jednostki gry jako małą klasę mediatora, która działa na różnych komponentach (np. odczyt z komponentu kondycji w celu przekazania danych do komponentu AI)
- Obserwator: ma renderowaną reprezentację postaci nasłuchuje zdarzeń z reprezentacji logicznej, aby w razie potrzeby zmienić prezentację wizualną bez logika gry wymaga jakiejkolwiek wiedzy o renderowaniu kodu
- Stan: zapisz AI NPC jako jeden z kilku stanów, np. Atakowanie, wędrowanie, ucieczka. Każdy może mieć własną metodę update () i wszelkie inne dane, których potrzebuje (np. Przechowywanie postaci, którą atakuje lub z którego ucieka, obszar, po którym wędruje itp.)
- Strategia: przełączanie między różne heurystyki dla twojego wyszukiwania A *, w zależności od rodzaju terenu, na którym się znajdujesz, lub może nawet użyć tego samego frameworka A * do znalezienia ścieżki i bardziej ogólnego planowania
- Metoda szablonowa: skonfiguruj ogólna procedura „walki” z różnymi funkcjami haka do obsługi każdego kroku, np. zmniejszanie ilości amunicji, obliczanie szansy na trafienie, rozstrzyganie trafienia lub chybienia, obliczanie obrażeń, a każdy rodzaj umiejętności ataku zaimplementuje te metody na swój własny, specyficzny sposób
Niektóre wzorce pominięto z powodu braku inspiracji.
Komentarze
Odpowiedź
Napisałem książka na dokładnie ten temat: Wzorce programowania gier . Rozdziały, które tam są, mogą być dla Ciebie pomocne.
Komentarze
Odpowiedź
Jedna rzecz, którą Brandon Eich miał na tyle rozsądku, aby poruszyć w Koderach at Work polega na tym, że wzorce to hacki i obejścia: [Patterns] pokazują pewien rodzaj defektu w języku. Te wzory nie są darmowe. Nie ma darmowego lunchu. Powinniśmy więc szukać ewolucji w języku, który dodaje właściwe bity.
Jako programiści gier, a nie projektanci kompilatorów, rzadko mamy możliwość ewolucji języków których używamy, ale możemy nauczyć się rozwijać nasz własny styl, aby lepiej pasował do naszego języka i wymagań. Wzorce to tylko część tego, ale niestosowanie wzorców to kolejna część, zwłaszcza że, jak mówi Brandon, wzorce rzadko bez znaczącej wydajności, pamięci lub zwinności kodu. MVC po prostu nie jest dobrym wzorcem dla wielu rzeczy w grach. Singleton jest obejściem dla kiepskich statycznych reguł inicjalizacji C ++ i prawdopodobnie i tak nie powinieneś ich robić. Factory upraszcza tworzenie skomplikowanych obiektów – być może obiekty powinny być prostsze na początku. Popularne wzorce to narzędzia, z których można się uciekać kiedy ich potrzebujemy do zarządzania czymś złożonym, a nie narzędzia, których powinniśmy pragnąć użyć do zbudowania czegoś złożonego na początku.
Dobry kod (gry) może wykorzystywać wzorce lub nie. Jeśli używa wzorców, dobrze – są one świetnym narzędziem komunikacyjnym do wyjaśniania struktury kodu innym programistom na wysokim, niezależnym od języka poziomie. Jeśli uważasz, że kod jest lepszy bez użycia wzorca, nie pobijaj się to – prawdopodobnie tak jest.
Komentarze
Odpowiedź
Oczywiście, jak powiedzieli inni wszystkie wzorce są przydatne w odpowiednich okolicznościach, a częścią nauki, jak ich używać, jest nauczenie się, kiedy ich używać. Jednak doskonała książka Podstawowe techniki i algorytmy w programowaniu gier autorstwa Daniela Sancheza-Crespo Dalmau zawiera sześć wzorców programowania i sześć wzorców użyteczności jako szczególnie przydatne w programowaniu gier.
Programowanie:
- Singleton: Nie nienawidzę tego, jak wielu ludzi; może być używany do takich rzeczy jak pojedynczy gracz lub czytnik klawiatury.
- Fabryka: pozwala efektywnie tworzyć i niszczyć obiekty.
- Strategia: pozwala elegancko zmieniać strategie AI.
- Spatial Index : Pomaga w wykonywaniu zapytań dotyczących zbiorów danych przestrzennych.
- Złożony: ustawia użyteczną heirarchię obiektów.
- Waga: uwalnia pamięć, generując takie rzeczy, jak identyczni wrogowie.
Użyteczność:
- Tarcza: chroni przed przypadkową aktywacją dramatycznych działań.
- Stan: wizualne wskazówki dotyczące stanu świata / interfejsu użytkownika.
- Automatyczne anulowanie trybu: sprawia, że gra działa bardziej intuicyjnie.
- Magnes ism: automatyczne celowanie i łatwy wybór jednostek.
- Skupienie: wyeliminowanie rozpraszających elementów interfejsu użytkownika.
- Postęp: uniwersalnie przydatne.
Książka oczywiście , omawia bardziej szczegółowo każdy z nich.
Komentarze
Odpowiedź
Systemy encji to fajny rodzaj wzorca. Nie jest to dokładnie wzorzec projektowy, ponieważ nie jest to ostry OOP. Możesz jednak mieszać to z OOP.
Kilka dobrych linków (zacznij od góry na wprowadzenie):
Komentarze
Odpowiedź
Wszystkie z nich. Z wyjątkiem Singletona. [/ flippancy]
Komentarze
Odpowiedź
Nie chodzi o wzorce, ale o podstawowe zasady, które się za nimi kryją. W „Wzorce projektowe: elementy oprogramowania obiektowego wielokrotnego użytku” (1995) grupa czterech osób (Gamma, Erich; Richard Helm, Ralph Johnson i John Vlissides) zaleca tylko dwie zasady projektowania zorientowanego obiektowo: (1) program do interfejsu, a nie do implementacji oraz (2) przedkładaj kompozycję obiektów nad dziedziczenie klas.
Te 2 zasady są bardzo pomocne w wielu zadaniach w grze rozwój. Na przykład wielu programistów gier używa głębokiej hierarchii klas do reprezentowania jednostek gier. Istnieje inne podejście oparte na kompozycji – obiektach gier opartych na komponentach. Artykuł na temat tego podejścia. Jeszcze więcej linków . Jest to przykład dekoratora .
Komentarze
Odpowiedź
ciekawie powtarzający się wzorzec szablonu może być naprawdę przydatny do unikania metod wirtualnych i obniżenia wydajności, które mogą wynikać z wywołań funkcji wirtualnych.
To może być odpowiednim wzorcem, gdy w rzeczywistości nie potrzebujesz kontenera typu klasy bazowej, który miałby interfejs, którego szukasz, ale chciałbyś mieć podobnie nazwane zachowania i interfejsy.
Na przykład możesz tego użyć podczas kompilowania klas dla wielu platform lub silników (dx vs. opengl), gdzie wariancja typu jest znana w czasie kompilacji.
Komentarze
Odpowiedź
Wzorzec projektowy, który rozwijałem przez wiele lat i który okazał się dla mnie spektakularnie przydatny, to coś, co nazywam „zestawami definicji obsługiwanymi przez brokera”; jak podsumować to w kategoriach GOF wydaje się być kontrowersyjne, ale to pytanie, które napisałem na ten temat w StackOverflow , zawiera więcej szczegółów.
Podstawową koncepcją jest to, że pewna właściwość modelu, na przykład gatunek stworzenia, jest skonfigurowana w taki sposób, że każda możliwa wartość właściwości ma odpowiadający jej obiekt definicji – jeden wspólny obiekt na wartość – który określa jej zachowanie , a dostęp do nich uzyskuje się za pośrednictwem centralnego brokera (którym według GOF może być Rejestr, Fabryka lub jedno i drugie). W moim przypadku „są one również ogólnie dostępne za pośrednictwem kluczy skalarnych, aby ułatwić słabe powiązanie na potrzeby morfizmu w czasie wykonywania.
Komentarze