Jaké jsou některé návrhové vzory programování, které jsou užitečné při vývoji her? [uzavřeno]

Nyní pro méně uvážlivou odpověď s několika návrhy. Neberte je jako doporučení implementace, spíše jako příklady možného použití.

• Tvůrce: nastavit entitu založenou na komponentách po jednotlivých komponentách na základě dat
• Tovární metoda: vytváření NPC nebo widgetů GUI na základě řetězce načteného ze souboru
• Prototyp: uložte jeden obecný znak „Elf“ s počátečními vlastnostmi a vytvořte instance Elf jeho klonováním.
• Singleton: tento prostor byl záměrně ponechán prázdný.
• Adaptér: zahrňte volitelnou knihovnu třetí strany zabalením do vrstva, která vypadá jako váš stávající kód. Velmi užitečné s knihovnami DLL.
• Složená: vytvořte graf scény z vykreslovatelných objektů nebo vytvořte grafické uživatelské rozhraní ze stromu widgetů.
• Fasáda: zjednodušte složité knihovny třetích stran poskytnutím jednoduššího rozhraní, které vám usnadní život později.
• Flyweight: ukládejte sdílené aspekty NPC (např. modely, textury, animace) odděleně od jednotlivých aspektů (např. pozice, zdraví) v a většinou transparentním způsobem
• Proxy: Vytvářejte malé třídy na klientovi, které představují větší a složitější třídy na serveru, a předávejte požadavky prostřednictvím sítě.
• Řetěz odpovědnosti: zpracovávejte vstup jako řetězec manipulátorů, např. globální klávesy (např. pro snímky obrazovky), pak grafické uživatelské rozhraní (např. v případě, že je zaměřeno textové pole nebo je otevřena nabídka), pak hra (např. pro přesun postavy)
• Příkaz: zapouzdřit herní funkce jako příkazy, které lze psát do konzoly, ukládat a přehrávat nebo dokonce skriptovat, aby se hra otestovala
• Mediator: implementujte herní entity jako malou třídu mediátorů, která funguje na různých komponentách (např. čtení ze složky zdraví za účelem předání dat do složky AI)
• Observer: mít vykreslitelnou reprezentaci postavy poslouchat události z logické reprezentace, aby bylo možné v případě potřeby změnit vizuální prezentaci bez logika hry, která potřebuje vědět něco o vykreslování kódu
• Stav: ukládá NPC AI jako jeden z několika stavů, např. Útočení, putování, útěk. Každý může mít svou vlastní metodu update () a jakákoli další data, která potřebuje (např. Uložení toho, na kterou postavu útočí nebo z níž prchá, oblasti, ve které bloudí atd.)
• Strategie: přepínat mezi různé heuristiky pro vaše hledání A *, v závislosti na tom, v jakém terénu se nacházíte, nebo snad dokonce použít stejný rámec A * k vyhledání cesty i obecnějšímu plánování
• Metoda šablony: nastavit obecná „bojová“ rutina s různými hákovými funkcemi pro zvládnutí každého kroku, např. snižování munice, výpočet šance na zásah, vyřešení zásahu nebo úniku, výpočet poškození a každý typ schopnosti útoku bude implementovat metody svým vlastním specifickým způsobem

Některé vzorce byly vynechány kvůli nedostatku inspirace.

Komentáře

• Lze najít velmi poučnou diskusi o singletonech zde: misko.hevery.com / 2008/08/25 / root-cause-of-singletons
• +1 pro vzor strategie. Použil jsem ji ' k přesnému účelu uvedenému výše (připojení různých heuristik A *).
• děkuji za tuto odpověď, zní to spíš jako designový vzor než obvyklý " singleton " i ' m všude …
• Skvělý seznam příkladů. Navzdory chronickému zneužívání singletonového vzoru (globální stav v přestrojení) existují legitimní použití: Když představuje zdroj , z nichž ve skutečnosti pouze máte (nebo chcete) jeden. Může to být něco jako zabalení hardwaru (např. Klávesnice / myši) nebo zabalení knihovny, která není reentrantní (stává se to a ne všechny jazyky mají magická synchronizační klíčová slova).
• Stále bych ' nepoužíváte pro hardwarové prostředky singletony – položky, o kterých si myslíte, že ' budete mít vždy jen 1 tendenci se později množit, stejně jako grafické karty a monitory roky pokračovaly. Podobně pod některými API musíte číst 2 joysticky, abyste porozuměli 1 gamepadu. Takže ' řeknu, že pokud potřebujete něco z něčeho, stačí vytvořit instanci jediného, nevynucovat svévolná omezení, která by pravděpodobně byla ' není to ' nutné.

Napsal jsem kniha o tomto tématu: Herní programovací vzory . Kapitoly, které tam jsou, vám mohou být užitečné.

Komentáře

• +1 Doufal jsem, že to někdo propojil, a vidím, že autor má! Popis vzoru komponenty tam byl docela užitečný a líbí se mi, že se pokusíte demonstrovat pomocí úplných příkladů kódu.
• Ano – pamatuji si, že jsem váš odkaz četl před několika lety. Tyto články byste měli dokončit!
• Nyní je kniha hotová 🙂
• Úžasný zdroj, který mi pomohl převést mé stávající znalosti programování do programování pro hry. Děkujeme, že jste to napsali!
• Toto vysvětlení vzorů programování her mi vlastně pomohlo pochopit – návrhové vzory – tak, jak to ve skutečnosti žádný vzorník softwarového designu neudělal! To je z části síla vývoje her (konkrétní příklady v jazyce, který ke mně mluví a umožňuje mi celkově lepší vývoj), ale z větší části proto, že psaní je tak vynikající.

Jedna věc, kterou měl Brandon Eich, byla rozumná vychovávat v kodérech at Work je, že vzory jsou hacky a řešení: [Patterns] show some defect in the language. Tyto vzory nejsou zdarma. Neexistuje žádný oběd zdarma. Měli bychom tedy hledat evoluci v jazyce, který přidává správné bity.

Jako herní programátoři spíše než designéři kompilátorů dostáváme zřídka možnost vyvíjet jazyky používáme, ale můžeme se naučit vyvíjet náš vlastní styl tak, aby lépe vyhovoval našemu jazyku a požadavkům. Patří sem vzory, ale nepoužívání vzorů je další část, zejména proto, jak říká Brandon, vzory zřídka bez pozoruhodného výkonu, paměti nebo nákladů na agilitu kódu. MVC prostě není skvělý vzor pro mnoho věcí ve hrách. Singleton je řešení pro chromá statická inicializační pravidla C ++ a pravděpodobně byste je stejně nedělali. Továrna zjednodušuje vytváření komplikovaných objektů – možná by vaše objekty měly být pro začátek jednodušší. Populární vzory jsou nástroje, které se uchylují k když je potřebujeme ke správě něčeho složitého, nikoli k nástrojům, které bychom měli toužit použít k vytvoření něčeho složitého na začátku.

Dobrý (herní) kód může používat vzory, nebo nemusí. Pokud používá vzory, je to skvělý komunikační nástroj, který vysvětluje strukturu kódu ostatním programátorům na vysoké jazykově nezávislé úrovni. Pokud si myslíte, že je kód lepší bez použití vzoru, nenechte se zmást to – pravděpodobně je.

Komentáře

• Ano, jedna z věcí vyjasněných v původní knize (ale často přehlížená) je, že pokud byly napsány spíše pro C než pro C ++ / Smalltalk, mohly obsahovat vzor " Inheritance " a ze stejného důvodu i některé jazyky mohou obsahovat některé již zabudované vzory GoF.
• Další věcí, kterou v původní knize (původní původní kniha od Alexandra, nikoli GoF) často přehlíželi, bylo, že vzory jsou nástrojem pro komunikaci , ne implementace . Umožňují návrhářům komunikovat o implementaci na vyšší úrovni a jsou identifikováni proto, že se opakují, ne nutně proto, že by se měli používat, když je to možné.
• Pouhá terminologie vám však může pomoci zdůvodnit problém a rozpoznat, kdy je takový přístup dobrým řešením.Nejlepší vzorce obvykle zdokonalili kvalifikovaní a zkušení pracovníci a méně kvalifikovaní pracovníci by sami stejné vzorce neobjevili, aniž by existovaly tyto kodifikované příklady.
• Souhlasím s tím, že mít terminologii je skvělé a součástí definice vzoru je, že je dobrým opakujícím se řešením nějakého problému. Méně kvalifikovaní pracovníci mají bohužel tendenci najít většinou Singleton a aplikovat jej na každý problém, i když problém ještě není.
• Díky za tuto odpověď; Cítím úlevu, když jsem si přečetl, že návrhové vzory jsou určeny k vyřešení problémů způsobených designem softwaru ' s. Myslím si, že struktura celého velkého softwaru by měla být promyšlena od začátku do konce, než se skutečně začne něco kódovat. Nemůžete ' vždy implementovat funkce najednou, někdy musíte myslet na každou konkrétní funkci a zkontrolovat, zda zvítězila ' Neztrácejte se s globální strukturou softwaru, nebo se jen postavte do cesty tomu, jak se má software chovat. Rozdělení úkolů na několik programátorů může někdy způsobit rozpory …

Samozřejmě, jak už řekli ostatní , všechny vzorce jsou užitečné za správných okolností a součástí učení, jak je používat, je učení, kdy je používat. Vynikající kniha Základní techniky a algoritmy v programování her od Daniela Sanchez-Crespo Dalmau však uvádí šest programovacích vzorů a šest vzorů použitelnosti zvláště užitečné při programování her.

Programování:

• Singleton: Nenávidím to jako mnoho lidí; lze jej použít pro věci jako single- hráč hráč nebo čtečka klávesnic.
• Továrna: Umožňuje efektivně vytvářet a ničit objekty.
• Strategie: Umožňuje elegantně měnit strategie AI.
• Prostorový index : Pomáhá provádět dotazy na soubory prostorových dat.
• Kompozitní: Nastavuje užitečnou dědičnost objektů.
• Flyweight: Uvolňuje paměť generalizací věcí, jako jsou identičtí nepřátelé.

Použitelnost:

• Štít: Chrání před náhodnou aktivací dramatických akcí.
• Stav: Vizuální narážky na stav světa / uživatelského rozhraní.
• Automatické zrušení režimu: Umožňuje hře pracovat intuitivněji.
• Magnet ism: Automatické zobrazování a snadný výběr jednotek.
• Zaměření: Odstranění rušivých prvků uživatelského rozhraní.
• Pokrok: Univerzálně užitečné.

Kniha, samozřejmě , jde podrobněji o každém z nich.

Komentáře

• Děkujeme za vstup! O té knize jsem nevěděl, ale na základě vašeho příspěvku se jí nyní budu věnovat. Ještě jednou děkuji!
• Singleton pro čtečku klávesnic je přesně ta situace, kdy se musím zeptat – Dokážete to opravdu udělat nejen globálním ukazatelem nastaveným na začátku vaší hlavní funkce? Už jste někdy náhodou vytvořili instanci dvou čteček klávesnic?
• Nenávidíte prosím singleton. Dělá dvě věci špatně. Globální přístup a přehlednost. Vývojáři si často myslí, že globální přístup == singleton. Existuje velmi několik problémů, než je potřeba skutečného singletonu, a možná ještě několik dalších, které jsou elegantnější, když jsou řešeny pomocí singletonu.

Entitní systémy jsou pěkným druhem vzoru. Není to úplně designový vzor, protože to není stroze OOP. Můžete jej však kombinovat s OOP.

Některé dobré odkazy (pro úvod začněte shora):

• http://www.csharpfriends.com/Articles/getArticle.aspx?articleID=387
• http://t-machine.org/index.php/2007/09/03/entity-systems-are-the-future-of-mmog-development-part-1/
• http://games.fh-hagenberg.at/wiki/index.php?title=Componentbased_entity_systems

Komentáře

• " ' není to úplně designový vzor, protože ' není stroze [sic] OOP. " Návrhové vzory nemají nic společného s OOP; pokud vůbec, samotný OOP je designový vzor. Návrhové vzory se neobjevují jen mimo OOP, ale mimo vývoj softwaru úplně.
• Existují OOP design patterns, které obvykle ukazují vztahy a interakce mezi třídami / objekty. A existuje mnoho dalších designových vzorů. OOP je soubor konceptů, nikoli vzor. Design pattern je také koncept.
• Místo toho, abychom mluvili o sémantice, neměli byste ' hodnotit užitečnost odpověď, kterou jsem dal?

všechny. Kromě Singletona. [/ flippancy]

Komentáře

• Můžete pojmenovat jeden nebo dva návrhové vzory, které ' Používáte je často při vývoji her a z jakého důvodu?Jako začátečník, pokud jde o návrhové vzory, " všechny " nejsou nijak zvlášť užitečnou odpovědí. Děkujeme vám za odpověď.
• Ptáte se " jaké vzory jste použili? " je jako ptát se " jaké názvy proměnných jste použili? " Jde o osobní styl, požadavky a doménu. V určitém okamžiku pravděpodobně použijete jakýkoli vzor, který kdy byl ' pojmenován. Pravděpodobně budete používat mnohem více, které ještě nebyly pojmenovány, a možná dokonce vymyslíte nějaké nové.
• @ jcurrie33: promiňte, prostě jsem nemohl odolat ' tomu, aby nejdříve kopat v singletonech. 😉

Ve skutečnosti ne o vzorcích, ale o základních principech, které za nimi stojí. V „Design Patterns: Elements of Reusable Object-Oriented Software“ (1995) skupina čtyř (Gamma, Erich; Richard Helm, Ralph Johnson a John Vlissides) doporučuje pro objektově orientovaný design pouze dva principy: (1) program na rozhraní a ne na implementaci a (2) upřednostňují složení objektu před dědičností třídy.

Tyto dva principy jsou velmi užitečné při mnoha úkolech hry rozvoj. Mnoho herních programátorů například používá k reprezentaci herních her hlubokou třídní hierarchii . Existuje další přístup založený na kompozici – herních objektech založených na komponentách. Článek o tomto přístupu. Ještě více odkazů . Je to vzor dekorátoru .

Komentáře

• Komponenty použité v herní design připomíná spíše stavový strategický vzor – který se přirozeně vyjadřuje jako uzávěry mimo C / C ++ / Java / C # a jako součást objektů uvnitř nich. Vzor dekorátoru je spíše jako proxy; jeho vlastnictví a tok dat jsou opačné než ty, které obvykle myslíme, když mluvíme o systémech komponent ve hrách.
• Komponenty také musí mluvit navzájem a přinést vzory jako Mediator, Observer a Composer. " Hra založená na komponentách " je kompozitní návrhový vzor sám o sobě.
• Pozorovatel @CodexArcanum, určitě , ale ne vždy Mediator (místo toho lze použít Chain of Responsibility). Skladatelem je pouze v případě, že GameObject (složený z GameObjectComponent) je GameObjectComponent sám (nikoli nutný).

Zvědavě se opakující vzor šablony může být opravdu užitečný, pokud se chcete vyhnout virtuálním metodám a omezení výkonu, které může pocházet z volání virtuálních funkcí.

Toto může být vhodný vzor, když ve skutečnosti nepotřebujete mít kontejner typu základní třídy, který má rozhraní, po kterém jste, ale chtěli byste mít podobně pojmenované chování a rozhraní.

Můžete to například použít při kompilaci tříd pro více platforem nebo motorů (dx vs. opengl), kde je variace typu známa v době kompilace.

Komentáře

• Vždycky jsem nenáviděl, že vrstva abstrakce operačního systému byla virtuální. ' se vám nelíbí ' Vždy budete potřebovat dvě abstrakce os mnohem lépe používat CRTP.
• M Ano, jsem ' m starý, ale ' bych ani nepoužíval CRTP pro rozhraní DX / OpenGL nebo platformy. Je to ' příliš pomalé na kompilaci – stačí použít '. CRTP je dobré, když chcete sdílet rozhraní a implementace mezi třídami, ale nemáte žádný jiný vztah, ne když si chcete vybrat jen jednu nebo druhou strukturu.

Návrhový vzor, který jsem vyvinul v průběhu mnoha let a který je pro mě mimořádně užitečný, označuji jako „zprostředkované definice“; jak to shrnout v pojmech GOF se zdá být kontroverzní, ale tato otázka, kterou jsem o tom napsal na StackOverflow , jde do podrobností.

Základní koncept spočívá v tom, že některá vlastnost modelu, jako je druh tvora, je nastavena tak, aby každá možná hodnota vlastnosti měla odpovídající definiční objekt – jeden sdílený objekt na hodnotu – který určuje jeho chování , a k nim se přistupuje prostřednictvím centrálního makléře (kterým může být GOF, registr, továrna nebo obojí). Podle mého použití k nim také obecně přistupujeme pomocí skalárních klíčů, aby se usnadnilo slabé vázání pro účely morfismu za běhu.

Komentáře

• Nevidím ' vůbec, jak se jedná o singleton a při diskusi o vzor muší váhy slovo " registr " je nadbytečné. To je jen setrvačná váha.
• Z vlákna SO jsem pochopil, že lidé identifikovali Singleton jako jeho součást, protože definice byly nastaveny jako třídy. Pokud jde o registr, nevidím ', jak to může být nadbytečné, když jej lze vyměnit nebo kombinovat s Factory.
• -1, v rozsahu vzory jsou o rychlé komunikaci, je to pravděpodobně největší selhání, jaké jsem ' viděl. Opravdu nemůžu ' brát tento popis vážně.
• Ježíši, promiň, že pro tebe nejsem dost omezovač cookie. Budete hlasovat pro " Entity systems " odpověď také proto, že to není ' t okamžitě shrnutelné z hlediska GOF?
• Nějaké množství " cookie-cutter, " nebo alespoň sémantická jasnost , je přesně to, jaké vzory musí být užitečné. Výrazy jako " flyweight " a " singleton " jak jsou běžně chápány, se vzájemně vylučují. První je o automatickém sdílení dat mezi více instancemi; druhá je o tom mít přesně jednu instanci. Ne ' neříkám, že váš výběr designu je zbytečný nebo dokonce špatný, ale přeplňování " dostatečně blízko " názvy vzorů všechny jen více matou. (Nevezměte prosím ' osobní hlasování, zejména na CW.)