Vilka är några programmeringsdesignmönster som är användbara vid spelutveckling? [stängd]

Nu för ett mindre flippant svar, med några förslag. Ta inte dessa som implementeringsrekommendationer, mer som exempel på möjlig användning.

• Builder: ställa in komponentbaserad enhet en komponent i taget, baserat på data
• Fabriksmetod: skapa NPC eller GUI-widgetar baserat på en sträng som läses från en fil
• Prototyp: lagra ett generiskt ”Elf” -tecken med ursprungliga egenskaper och skapa Elf-instanser genom att klona det.
• Singleton: det här utrymmet lämnas medvetet tomt.
• Adapter: införliva ett valfritt tredjepartsbibliotek genom att lägga det i ett lager som ser ut som din befintliga kod. Mycket användbart med DLL-filer.
• Sammansatt: skapa en scengraf över renderbara objekt eller skapa ett GUI av ett widgetträd
• Fasad: förenkla komplexa tredjepartsbibliotek genom att tillhandahålla ett enklare gränssnitt för att underlätta ditt liv senare.
• Flyweight: lagra de delade aspekterna av en NPC (t.ex. modeller, texturer, animationer) separat från de enskilda aspekterna (t.ex. position, hälsa) i a mestadels transparent sätt
• Proxy: Skapa små klasser på en klient som representerar större, mer komplexa klasser på en server och vidarebefordra förfrågningar via nätverket.
• Ansvarskedja: hantera inmatning som en kedja av hanterare, t.ex. globala tangenter (t.ex. för skärmdumpar), sedan GUI (t.ex. om en textruta är fokuserad eller en meny är uppe), sedan spelet (t.ex. för att flytta en karaktär)
• Kommando: kapsla in spelfunktionalitet som kommandon som kan skrivas in i en konsol, lagras och spelas upp igen, eller till och med skripts för att testa spelet läsning från hälsokomponenten för att skicka data till AI-komponenten)
• Observer: låt den karaktäristiska återgivningen av ett tecken lyssna på händelser från den logiska representationen, för att ändra den visuella presentationen vid behov utan spellogiken behöver veta någonting om renderingskod
• Tillstånd: lagra NPC AI som en av flera stater, t.ex. Att attackera, vandra, fly. Var och en kan ha sin egen uppdateringsmetod () och vilken annan data de behöver (t.ex. lagra vilket tecken de attackerar eller flyr från, området där de vandrar osv.)
• Strategi: växla mellan olika heuristik för din A * -sökning, beroende på vilken typ av terräng du befinner dig i, eller kanske till och med för att använda samma A * -ram för att göra både sökning och mer generell planering
• Mallmetod: skapa en generisk ”strid” -rutin, med olika krokfunktioner för att hantera varje steg, t.ex. minska ammunition, beräkna träffchans, lösa träff eller miss, beräkna skada och varje typ av attackfärdighet kommer att implementera metoderna på sitt specifika sätt

Några mönster utelämnade på grund av brist på inspiration.

Kommentarer

• En mycket upplysande diskussion om singletons finns här: misko.hevery.com / 2008/08/25 / root-cause-of-singletons
• +1 för strategimönstret. Jag ' har använt det för det exakta syftet som anges ovan (kopplar in olika A * heuristik).
• tack för det här svaret, de låter mer som designmönster än det vanliga " singleton " jag ' jag hör överallt …
• Fantastisk lista med exempel. Trots kroniskt missbruk av singletonmönstret (global förklädnad) finns det legitima användningsområden: När det representerar en resurs som du faktiskt bara har (eller vill ha) en. Detta kan vara ungefär som omslagsmaskinvara (t.ex. tangentbord / mus) eller omslagning av ett bibliotek som inte återinträder (det händer och inte alla språk har magiska synkroniseringsnyckelord).
• Jag skulle fortfarande inte vilja ' t använder singletons för hårdvaruresurser – objekt som du tror att du ' bara har 1 av tenderar att multiplicera senare, precis som grafikkort och skärmar gjorde som år gick vidare. På samma sätt måste du läsa två joysticks för att förstå en gamepad under vissa API: er. Så jag säger ', om du bara behöver något av något, bara instansera en enda, don ' t genomföra godtyckliga begränsningar som troligen är inte ' t nödvändigt.

Jag skrev en boka om exakt det ämnet: Spelprogrammeringsmönster . De kapitel som finns där kan vara till hjälp för dig.

Kommentarer

• +1 Jag hoppades att någon hade länkat till det och jag ser att författaren har! Komponentmönsterbeskrivningen där var ganska hjälpsam, och jag tycker att du försöker använda fullständiga kodexempel för att demonstrera.
• Ja – jag kommer ihåg att jag läste din länk för några år sedan. Du bör slutföra artiklarna!
• Nu är boken klar 🙂
• En fantastisk resurs som hjälpte mig att översätta min befintliga programmeringskunskap till programmering för spel. Tack för att du skrev det!
• Denna förklaring av spelprogrammeringsmönster hjälpte mig faktiskt att förstå -designmönster – på ett sätt som ingen mönsterbok för programvarudesign verkligen gjorde! Detta är delvis kraften i spelutveckling (konkreta exempel på ett språk som talar till mig och gör det möjligt för mig att förbättra min utveckling totalt sett), men till en större del eftersom skrivningen är så utmärkt.

En sak Brandon Eich hade den goda känslan att ta upp i Kodare på jobbet är att mönster är hack och lösningar: [Mönster] visar någon form av defekt i språket. Dessa mönster är inte gratis. Det finns ingen gratis lunch. Så vi borde leta efter utveckling på språket som lägger till de rätta bitarna.

Som spelprogrammerare snarare än kompileringsdesigners får vi sällan möjlighet att utveckla språken. vi använder, men vi kan lära oss att utveckla vår egen stil för att bättre passa vårt språk och krav. Mönster är något av detta, men att inte använda mönster är en annan del, särskilt eftersom som Brandon säger, mönster går sällan utan en anmärkningsvärd prestanda eller minne eller kod smidighet kostnad. MVC är bara inte ett bra mönster för många saker i spel. Singleton är en lösning för lama C ++ statiska initialiseringsregler, och du borde förmodligen inte göra det ändå. Fabriken förenklar komplicerat skapande av objekt – kanske dina objekt bör vara enklare till att börja med. De populära mönstren är verktyg att tillgripa när vi behöver dem för att hantera något komplext, inte verktyg som vi borde längta efter att bygga något komplext i början.

Bra (spel) kod kan använda mönster, eller kanske inte. Om den använder mönster, bra – de är ett bra kommunikationsverktyg för att förklara kodstrukturen för andra programmerare på en hög, språkoberoende nivå. Om du tycker att koden är bättre utan att använda ett mönster, slå inte dig själv över det är det förmodligen.

Kommentarer

• Ja, en av de saker som klargörs i originalboken (men ofta förbises) är att om den var skrivna för C snarare än C ++ / Smalltalk, de hade kanske inkluderat ett " Arv " -mönster, och av samma tecken, vissa språk kan innehålla några av de redan inbyggda GoF-mönstren.
• Det andra som ofta förbises i originalboken (originalboken av Alexander, inte GoF) var att mönster är ett verktyg för kommunikation , inte implementering . De låter designers kommunicera om implementering på en högre nivå och identifieras för att de återkommer, inte nödvändigtvis för att de ska användas när det är möjligt.
• Att bara ha terminologin kan dock hjälpa dig att resonera om problemet och känna igen när ett sådant tillvägagångssätt är en bra lösning.De bästa mönstren har vanligtvis förfinats över tid av kvalificerade och erfarna arbetare, och mindre kvalificerade arbetstagare skulle inte själva upptäcka samma mönster utan att det finns dessa kodifierade exempel.
• Jag håller med om att det är bra att ha terminologin och en del av definitionen av ett mönster är att det är en bra återkommande lösning för vissa problem. Tyvärr tenderar de mindre kvalificerade arbetarna att hitta mestadels Singleton och tillämpa det på alla problem, även när det ännu inte finns något problem.
• Tack för detta svar. Jag känner mig lättad att läsa att designmönster är gjorda för att lösa problem som skapats av programvarans ' design. Jag tror att strukturen hos en hel stor mjukvara bör tänkas genomgå från början till slut innan jag faktiskt börjar koda någonting. Du kan ' inte alltid implementera funktioner en gång i taget, någon gång måste du tänka på varje enskild funktion och kontrollera om den vann ' t röra med den globala strukturen i programvaran eller bara sätta dig i vägen för hur programvaran ska fungera. Att dela uppgifter till flera programmerare kan någon gång skapa motsägelser …

Naturligtvis, som andra har sagt , alla mönster är användbara under rätt omständigheter, och en del av att lära sig att använda dem är att lära sig när man ska använda dem. Den utmärkta boken Core Techniques and Algorithms in Game Programming av Daniel Sanchez-Crespo Dalmau listar dock sex programmeringsmönster och sex användbarhetsmönster. som särskilt användbart i spelprogrammering.

Programmering:

• Singleton: Jag hatar inte den här som många gör; den kan användas till saker som spelare eller tangentbordsläsaren.
• Fabrik: Låter dig skapa och förstöra objekt effektivt.
• Strategi: Låter dig ändra ut AI-strategier elegant.
• Rumsligt index : Hjälper till att utföra frågor på rumsliga datauppsättningar.
• Sammansatt: Ställer in en användbar objekthärarki.
• Flyweight: Frigör minne genom att generera saker som identiska fiender.

Användbarhet:

• Sköld: Skyddar mot oavsiktlig aktivering av dramatiska handlingar.
• Tillstånd: Visuella ledtrådar för värld / UI-status.
• Annullering av automatiskt läge: Gör att spelet fungerar mer intutitivt.
• Magnet ism: Autoaiming och enkelt enhetsval.
• Fokus: Eliminerar distraherande användargränssnittselement.
• Framsteg: universellt användbart.

Boken naturligtvis , går närmare in på var och en av dessa.

Kommentarer

• Tack för inmatningen! Jag var inte medveten om den boken, men kommer att undersöka den nu som ett resultat av ditt inlägg. Tack igen!
• Singleton för tangentbordsläsaren är exakt den situation där jag måste fråga – Kan du verkligen inte bara göra det till en global pekare som ställs in tidigt i din huvudfunktion? Har du någonsin av misstag startat två tangentbordsläsare?
• Vänligen hata singleton. Det gör två saker dåligt. Global tillgång och arity. Ofta tänker utvecklare global åtkomst == singleton. Det finns väldigt få problem än att behöva en sann singleton, och möjligen några fler som är mer eleganta när de löses med en singleton.

Enhetssystem är en fin typ av mönster. Det är inte precis ett designmönster eftersom det inte är OOP. Du kan dock blanda det med OOP.

Några bra länkar (börja från början för introduktion):

• 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

Kommentarer

• " Det ' är inte precis ett designmönster eftersom det ' s inte strikt [sic] OOP. " Designmönster har inget att göra med OOP; om något är OOP i sig ett designmönster. Designmönster förekommer inte bara utanför OOP utan helt utanför mjukvaruutveckling.
• Det finns OOP design patterns som vanligtvis visar relationer och interaktioner mellan klasser / objekt. Och det finns många andra designmönster. OOP är en uppsättning begrepp, egentligen inte ett mönster. Design pattern är också ett koncept.
• I stället för att prata om semantisk, bör du inte ' t bedöma användbarheten av svaret jag gav?

Alla. Förutom Singleton. [/ flippancy]

Kommentarer

• Kan du eventuellt namnge ett eller två designmönster som du ' har använts ofta i din spelutveckling, och av vilken anledning?Som nybörjare med avseende på designmönster är " alla " inte ett särskilt användbart svar. Tack för att du svarade.
• Fråga " vilka mönster har du använt? " är som att fråga " vilka variabelnamn har du använt? " Det handlar om personlig stil och krav och domän. Vid någon tidpunkt kommer du förmodligen att använda alla mönster som ' någonsin har fått namnet. Du kommer antagligen använda många fler som inte har fått namnet och kanske till och med uppfinna några nya.
• @ jcurrie33: förlåt, jag kunde bara inte ' en gräva på singletons först. 😉

Inte riktigt om mönster utan om grundläggande principer bakom dem. I ”Design Patterns: Elements of Reusable Object-Oriented Software” (1995) , gänget på fyra (Gamma, Erich; Richard Helm, Ralph Johnson och John Vlissides) rekommenderar endast två principer för objektorienterad design: (1) program till ett gränssnitt och inte till en implementering och (2) gynnar objektsammansättning framför klassarv.

Dessa två principer är till stor hjälp i många speluppgifter utveckling. Till exempel har många spelprogrammerare använt en djup klasshierarki för att representera spelenheter. Det finns en annan metod baserad på komposition – komponentbaserade spelobjekt. Artikel om detta tillvägagångssätt. Ännu fler länkar . Det är ett Dekoratormönster .

Kommentarer

• Komponenter som används i speldesign är mer som ett statligt strategimönster – vilket naturligt uttrycks som stängningar utanför C / C ++ / Java / C #, och som komponentobjekt inuti dem. Dekoratörsmönstret är mer som en proxy; dess ägande och dataflöde är motsatta de vi normalt menar när vi pratar om komponentsystem i spel.
• Komponenter måste också prata med varandra och få in mönster som Mediator, Observer och Composer. " Komponentbaserat spel " är ett sammansatt designmönster i sig.
• @CodexArcanum, Observer, definitivt , men inte alltid Mediator (Chain of Responsibility kan användas istället). Det är bara Composer om GameObject (består av GameObjectComponent) är GameObjectComponent i sig själv (inte nessesary).

nyfiket återkommande mallmönster kan vara riktigt användbart för att undvika virtuella metoder och prestationsstraff som kan komma från de virtuella funktionsanropen. kan vara lämpligt mönster när du inte behöver ha en behållare av basklasstypen som har det gränssnitt du är ute efter, men du vill ha liknande beteenden och gränssnitt.

Du kan till exempel använda detta när du kompilerar klasser för flera plattformar eller motorer (dx vs. opengl) där typens varians är känd vid kompileringstidpunkten.

Kommentarer

• Jag hatade alltid att os-abstraktionsskiktet var virtuellt. Det ' är inte som du ' någonsin behöver två os-abtraktion Mycket bättre att använda CRTP.
• M aybe jag ' jag är bara gammal, men jag skulle ' inte ens använda CRTP för DX / OpenGL eller plattformsgränssnitt. Det ' är för långsamt för att kompilera – jag ' d använder bara typedefs. CRTP är bra när du vill dela gränssnitt och implementeringar mellan klasser men inte har någon annan relation, inte när du bara vill välja en struktur eller den andra.

Ett designmönster som jag utvecklat under många år och som har varit spektakulärt användbart för mig är något jag kallar ”förmedlade definitionssatser”; hur man sammanfattar det i GOF-termer verkar vara kontroversiellt, men den här frågan jag skrev om det på StackOverflow går i detalj om det.

Kärnkonceptet är att någon egenskap hos en modell, som en varels art, ställs in så att varje möjligt värde för fastigheten har ett motsvarande definitionsobjekt – ett enda, delat objekt per värde – som specificerar dess beteende , och dessa nås via en central mäklare (som GOF-vis kan vara ett register, en fabrik eller båda). I min användning är de också allmänt tillgängliga via skalära nycklar för att underlätta svag bindning för morfismändamål.

Kommentarer

• Jag ser inte ' hur det här är en singleton alls och när man diskuterar flugviktsmönster ordet " register " är överflödigt. Det här är bara flygvikt.
• Min förståelse från SO-tråden var att människor identifierade Singleton som en del av det på grund av att definitionerna sattes upp som klasser. När det gäller registret ser jag inte ' hur det kan vara överflödigt när det kan bytas ut eller kombineras med fabrik.
• -1, i den utsträckning mönster handlar om att snabbt kommunicera, detta är förmodligen det största misslyckandet jag ' har sett. Jag kan verkligen inte ' ta den här beskrivningen på allvar.
• Jesus, ursäkta mig för att jag inte är tillräckligt cookie-cutter för dig. Ska du rösta ned " Enhetssystem " också för att det inte är ' t omedelbart sammanfattas i GOF-termer?
• Någon mängd " cookie-cutter, " eller åtminstone semantisk klarhet , är exakt vilka mönster som måste vara för att vara användbara. Termer som " flygvikt " och " singleton " som de brukar förstås utesluter varandra. Den första handlar om att automatiskt dela data mellan flera instanser; den andra handlar om att ha exakt en instans. Jag ' säger inte att ditt designval är värdelöst eller till och med dåligt, men att klämma " tillräckligt nära " mönsternamn tillsammans förvirrar bara alla mer. (Vänligen ' ta inte nedröstningar personligen, särskilt på CW.)