Hva er noen programmeringsdesignmønstre som er nyttige i spillutvikling? [lukket]

Nå for et mindre flippant svar, med noen forslag. Ikke ta disse som implementeringsanbefalinger, mer som eksempler på mulig bruk.

• Builder: sett opp komponentbasert enhet en komponent om gangen, basert på data
• Fabrikkmetode: Opprett NPCer eller GUI-widgets basert på en streng som er lest fra en fil
• Prototype: lagre ett generisk «Elf» -tegn med innledende egenskaper og opprett Elf-forekomster ved å klone det.
• Singleton: dette rommet er bevisst tomt.
• Adapter: innlemme et valgfritt tredjepartsbibliotek ved å pakke det inn et lag som ser ut som den eksisterende koden din. Veldig nyttig med DLL-filer.
• Kompositt: lag et scenegraf av gjengivelige objekter, eller lag et GUI ut av et tre med widgets
• Fasade: forenkle komplekse tredjepartsbiblioteker ved å tilby et enklere grensesnitt for å gjøre livet ditt lettere senere.
• Flyvekt: lagre delte aspekter av en NPC (f.eks. modeller, teksturer, animasjoner) atskilt fra de enkelte aspektene (f.eks. stilling, helse) i en mest gjennomsiktig måte
• Proxy: Opprett små klasser på en klient som representerer større, mer komplekse klasser på en server, og videresend forespørsler via nettverket.
• Ansvarskjede: håndter input som en kjede av håndterere, f.eks. globale taster (f.eks. for skjermbilder), deretter GUI (f.eks. hvis en tekstboks er fokusert eller en meny er oppe), deretter spillet (f.eks. for å flytte et tegn)
• Kommando: kapsle spillfunksjonalitet som kommandoer som kan skrives inn i en konsoll, lagres og spilles på nytt, eller til og med skriptes for å teste spillet
• Mediator: implementer spillenheter som en liten mediatorklasse som fungerer på forskjellige komponenter (f.eks. lesing fra helsekomponenten for å overføre dataene til AI-komponenten)
• Observer: la den gjengivelige representasjonen av et tegn lytte til hendelser fra den logiske representasjonen, for å endre den visuelle presentasjonen når det er nødvendig uten spilllogikken som trenger å vite noe om gjengivelseskode
• Tilstand: lagre NPC AI som en av flere stater, f.eks. Angripende, vandrende, på flukt. Hver kan ha sin egen oppdateringsmetode () og hvilke andre data de trenger (f.eks. Lagre hvilket tegn de angriper eller flykter fra, området der de vandrer osv.)
• Strategi: bytt mellom forskjellige heuristikker for A * -søket ditt, avhengig av hva slags terreng du er i, eller kanskje til og med for å bruke samme A * -rammeverk for å gjøre både stifinnende og mer generell planlegging
• Malmetode: sette opp en generisk «kamp» -rutine, med forskjellige krokfunksjoner for å håndtere hvert trinn, f.eks. redusere ammunisjon, beregne hit sjanse, løse hit eller miss, beregne skade, og hver type angrep ferdighet vil implementere metodene på sin egen spesifikke måte

Noen mønstre utelatt på grunn av manglende inspirasjon.

Kommentarer

• En veldig opplysende diskusjon om singletons kan bli funnet her: misko.hevery.no / 2008/08/25 / root-cause-of-singletons
• +1 for Strategimønsteret. Jeg ' har brukt den til det nøyaktige formålet som er angitt ovenfor (plugger inn forskjellige A * heuristikker).
• takk for dette svaret, de høres mer ut som designmønster enn det vanlige " singleton " jeg ' m hører overalt …
• Flott liste med eksempler. Til tross for kronisk misbruk av singleton-mønsteret (global tilstand i forkledning), er det legitime bruksområder: Når det representerer en ressurs som du faktisk bare har (eller ønsker) en av. Dette kan være noe som å pakke inn maskinvare (f.eks. Tastatur / mus) eller å pakke inn et bibliotek som ikke er reentrant (det skjer, og ikke alle språk har magiske synkroniseringsnøkkelord).
• Jeg vil fortsatt ikke ' t bruk singletons for maskinvarressurser – elementer du tror du ' bare har 1 av en tendens til å formere seg senere, akkurat som skjermkort og skjermer gjorde som år gikk. Tilsvarende må du under noen API-er lese 2 joysticks for å forstå 1 gamepad. Så jeg ' vil si, hvis du bare trenger en av noe, er det bare å sette i gang en enkelt, ikke ' t håndheve vilkårlige begrensninger som sannsynligvis er ikke ' t nødvendig.

Jeg skrev en bok om akkurat det emnet: Spillprogrammeringsmønstre . Kapitlene som er der kan være nyttige for deg.

Kommentarer

• +1 Jeg håpet noen hadde lenket til det, og jeg ser at forfatteren har! Komponentmønsterbeskrivelsen der var ganske nyttig, og jeg liker at du prøver å bruke komplette kodeeksempler for å demonstrere.
• Ja – jeg husker jeg leste linken din for noen år siden. Du bør fullføre artiklene!
• Nå er boken ferdig 🙂
• En fantastisk ressurs som hjalp meg med å oversette min eksisterende programmeringskunnskap til programmering av spill. Takk for at du skrev det!
• Denne forklaringen på spillprogrammeringsmønstre hjalp meg faktisk til å forstå -designmønstre – på en måte som ingen mønsterbok for programvaredesign virkelig gjorde! Dette er delvis kraften i spillutvikling (konkrete eksempler på et språk som snakker til meg og gjør at jeg kan forbedre utviklingen min generelt), men i en større del fordi skrivingen er så utmerket.

En ting Brandon Eich hadde god mening å ta opp i Kodere på jobben er at mønstre er hacks og løsninger: [Mønstre] viser en slags mangel på språket. Disse mønstrene er ikke gratis. Det er ingen gratis lunsj. Så vi burde lete etter evolusjon på språket som legger til de rette bitene.

Som spillprogrammerere i stedet for kompilatørdesignere får vi sjelden muligheten til å utvikle språkene. vi bruker, men vi kan lære å utvikle vår egen stil for å passe bedre til språket vårt og kravene. Mønstre er noe av dette, men å ikke bruke mønstre er en annen del, spesielt siden som Brandon sier, mønstre går sjelden uten en bemerkelsesverdig ytelse eller minne eller kode smidighetskostnad. MVC er bare ikke et flott mønster for mange ting i spill. Singleton er en løsning for halt C ++ statisk initialiseringsregler, og du burde sannsynligvis ikke gjøre det uansett. Fabrikk forenkler komplisert gjenoppretting av objekter – kanskje objektene dine bare skal være enklere til å begynne med. De populære mønstrene er verktøy å ty til når vi trenger dem for å håndtere noe komplekst, ikke verktøy vi burde lengte etter å bruke for å bygge noe komplekst i starten.

God (spill) kode kan bruke mønstre, eller ikke. Hvis det bruker mønstre, er det bra – de er et flott kommunikasjonsverktøy for å forklare kodestrukturen til andre programmerere på et høyt, språkuavhengig nivå. Hvis du synes koden er bedre uten å bruke et mønster, må du ikke slå deg selv over det – det er det sannsynligvis.

Kommentarer

• Ja, en av tingene som er tydeliggjort i originalboka (men ofte oversett) er at hvis den ble skrevet for C i stedet for C ++ / Smalltalk, hadde de kanskje tatt med et " Arv " mønster, og på samme måte noen språk kan inneholde noen av GoF-mønstrene som allerede er innebygd.
• Den andre tingen som ofte ble oversett i den originale boka (den originale originale boka av Alexander, ikke GoF), var at mønstre er et verktøy for kommunikasjon , ikke implementering . De lar designere kommunisere om implementering på et høyere nivå, og blir identifisert fordi de er gjentatte, ikke nødvendigvis fordi de skal brukes når det er mulig.
• Bare det å ha terminologien kan imidlertid hjelpe deg å resonnere om problemet og gjenkjenne når en slik tilnærming er en god løsning.De beste mønstrene har vanligvis blitt raffinert over tid av dyktige og erfarne arbeidere, og mindre kvalifiserte arbeidstakere ville ikke oppdage de samme mønstrene selv uten at det var disse kodifiserte eksemplene.
• Jeg er enig i at det å ha terminologien er flott, og en del av definisjonen av et mønster er at det er en god tilbakevendende løsning for noen problemer. Dessverre har de mindre dyktige arbeidstakerne en tendens til å finne det meste av Singleton, og bruke det på hvert problem, selv når det ennå ikke er noe problem.
• Takk for dette svaret; Jeg føler meg lettet over å lese at designmønster er laget for å løse problemer opprettet av programvaren ' s design. Jeg tror at strukturen til en hel stor programvare bør tenkes gjennom fra start til slutt før du faktisk begynner å kode noe. Du kan ' t alltid implementere funksjoner en gang om gangen, en gang må du tenke på hver enkelt funksjon, og sjekke om den ikke vant ' ikke rote med den globale strukturen til programvaren eller bare komme i veien for hvordan programvaren er ment å oppføre seg. Å dele oppgaver til flere programmerere kan en gang skape motsetninger …

Selvfølgelig, som andre har sagt , alle mønstre er nyttige under de rette omstendighetene, og en del av å lære å bruke dem er å lære når man skal bruke dem. Den utmerkede boka Core Techniques and Algorithms in Game Programming av Daniel Sanchez-Crespo Dalmau, viser imidlertid seks programmeringsmønstre og seks bruksmønstre som spesielt nyttig i spillprogrammering.

Programmering:

• Singleton: Jeg hater ikke denne som mange gjør; den kan brukes til ting som spillerspiller eller tastaturleser.
• Fabrikk: Lar deg lage og ødelegge objekter effektivt.
• Strategi: Lar deg endre AI-strategier elegant.
• Romlig indeks : Hjelper med å utføre spørsmål om geodatasett.
• Sammensetning: Setter opp et nyttig objektarving.
• Flyvekt: Frigjør minne ved å generere ting som identiske fiender.

Brukbarhet:

• Skjold: Beskytter mot utilsiktet aktivering av dramatiske handlinger.
• Tilstand: Visuelle signaler om verdens / brukergrensesnittstatus.
• Automatisk avlysning av modus: Gjør at spillet fungerer mer intuitivt.
• Magnet ism: Autoaiming og enkelt enhetsvalg.
• Fokus: Eliminerer forstyrrende UI-elementer.
• Fremgang: Universelt nyttig.

Boken, selvfølgelig , går nærmere inn på hver av disse.

Kommentarer

• Takk for innspillet! Jeg var ikke klar over den boka, men vil se på den nå som et resultat av innlegget ditt. Takk igjen!
• Singleton for tastaturleseren er akkurat situasjonen der jeg må spørre – Kan du virkelig ikke bare gjøre det til en global peker som er satt tidlig i hovedfunksjonen din? Har du noen gang faktisk tilfeldigvis satt i gang to tastaturlesere?
• Hat ikke singleton. Det gjør to ting dårlig. Global tilgang og arity. Ofte tenker utviklere global tilgang == singleton. Det er veldig få problemer enn behov for en ekte singleton, og muligens noen flere som er mer elegante når de løses med en singleton.

Enhetssystemer er en fin slags mønster. Det er ikke akkurat et designmønster siden det ikke er strengt OOP. Du kan imidlertid blande det med OOP.

Noen gode lenker (start fra toppen for intro):

• 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 ' er ikke akkurat et designmønster siden det ' s ikke strickly [sic] OOP. " Designmønstre har ingenting å gjøre med OOP; om noe, er OOP i seg selv et designmønster. Designmønstre vises ikke bare utenfor OOP, men helt utenfor programvareutvikling.
• Det er OOP design patterns som vanligvis viser relasjoner og interaksjoner mellom klasser / objekter. Og det er mange andre designmønstre. OOP er et sett med begreper, egentlig ikke et mønster. Design pattern er også et konsept.
• I stedet for å snakke om semantisk, bør du ikke ' t vurdere nytten av svaret jeg ga?

Alle sammen. Bortsett fra Singleton. [/ flippancy]

Kommentarer

• Kan du muligens nevne ett eller to designmønstre som du ' har du brukt ofte i spillutviklingen din, og av hvilken grunn?Som nybegynner med hensyn til designmønstre er " alle " ikke noe spesielt nyttig svar. Takk for at du svarte.
• Spør " hvilke mønstre du har brukt? " er som å spørre " hvilke variabelnavn har du brukt? " Det kommer ned til personlig stil og krav og domene. På et eller annet tidspunkt vil du sannsynligvis bruke et hvilket som helst mønster som ' noen gang har fått navnet. Du vil sannsynligvis bruke mange flere som ikke har fått navn, og kanskje til og med finne på noen nye.
• @ jcurrie33: beklager, jeg kunne bare ikke ' t motstå å ha en grave på singletons først. 😉

Ikke egentlig om mønstre, men om grunnleggende prinsipper bak dem. I «Design Patterns: Elements of Reusable Object-Oriented Software» (1995) , gjengen på fire (Gamma, Erich; Richard Helm, Ralph Johnson og John Vlissides) anbefaler bare to prinsipper for objektorientert design: (1) program til et grensesnitt og ikke til en implementering og (2) favoriserer objektsammensetning fremfor klassearv.

Disse to prinsippene er veldig nyttige i mange oppgaver i spillet utvikling. For eksempel har mange spillprogrammerere brukt et dypt klassehierarki for å representere spillenheter. Det er en annen tilnærming basert på komposisjon – komponentbaserte spillobjekter. Artikkel om denne tilnærmingen. Enda flere lenker . Det er et Dekoratormønster .

Kommentarer

• Komponenter som brukes i spilldesign er mer som et statelig strategimønster – som naturlig uttrykkes som nedleggelser utenfor C / C ++ / Java / C #, og som komponentobjekter inne i dem. Dekoratormønsteret er mer som en proxy; dets eierskap og dataflyt er motsatt av det vi vanligvis mener når vi snakker om komponentsystemer i spill.
• Komponenter trenger også å snakke med hverandre, og bringe mønstre som Mediator, Observer og Composer. " Komponentbasert spill " er et sammensatt designmønster alene.
• @CodexArcanum, Observer, definitivt , men ikke alltid Mediator (Chain of Responsibility kan brukes i stedet). Det er bare komponist hvis GameObject (sammensatt av GameObjectComponent) er GameObjectComponent i seg selv (ikke nessesary).

nysgjerrig tilbakevendende malmønster kan være veldig nyttig for å unngå virtuelle metoder og ytelsesstraff som kan komme fra de virtuelle funksjonsanropene.

Dette kan være riktig mønster når du ikke trenger å ha en beholder av baseklassetypen som har grensesnittet du er ute etter, men du vil ha lignende oppførsel og grensesnitt.

For eksempel kan du bruke dette når du kompilerer klasser for flere plattformer eller motorer (dx vs. opengl) der variansen av typen er kjent på kompileringstidspunktet.

Kommentarer

• Jeg hatet alltid at os-abstraksjonslaget var virtuelt. Det ' er ikke som deg ' Jeg trenger noen gang to os-abtraksjon lag. Mye bedre å bruke CRTP.
• M aybe jeg ' jeg er bare gammel, men jeg ville ikke ' ikke engang bruke CRTP for DX / OpenGL eller plattformgrensesnitt. Det ' er for sakte til å kompilere – jeg ' d bruker bare typedefs. CRTP er bra når du vil dele grensesnitt og implementeringer mellom klasser, men ikke har noe annet forhold, ikke når du bare vil velge den ene strukturen eller den andre.

Et designmønster som jeg utviklet i løpet av mange år, og som har vært spektakulært nyttig for meg, er noe jeg omtaler som «meglert definisjonssett»; hvordan det å oppsummere det i GOF-termer ser ut til å være kontroversielt, men dette spørsmålet jeg skrev om det på StackOverflow går inn i noen detaljer om det.

Kjernekonseptet er at noen av egenskapene til en modell, som arten til en skapning, er satt opp slik at hver mulige verdi for eiendommen har et tilsvarende definisjonsobjekt – et enkelt, delt objekt per verdi – som spesifiserer atferd , og disse er tilgjengelige via en sentral megler (som GOF-vis kan være et register, en fabrikk eller begge deler). I min bruk er de vanligvis også tilgjengelige via skalar nøkler, for å lette svak binding for morfisme.

Kommentarer

• Jeg ser ikke ' t hvordan dette i det hele tatt er en singleton og når vi diskuterer flyvevekt mønster ordet " register " er overflødig. Dette er bare flyvekt.
• Min forståelse fra SO-tråden var at folk identifiserte Singleton som en del av det på grunn av definisjonene som ble satt opp som klasser. Så langt som register går, ser jeg ikke ' hvordan det kan være overflødig når det kan byttes ut eller kombineres med Factory.
• -1, i den grad mønstre handler om å raskt kommunisere, dette er sannsynligvis den største feilen jeg ' har sett. Jeg kan virkelig ikke ' ikke ta denne beskrivelsen på alvor.
• Jesus, tilgi meg for at jeg ikke er kakekutter nok for deg. Skal du stemme ned " Enhetssystemene " svaret også fordi det ikke er ' t øyeblikkelig oppsummert i GOF-termer?
• Noe mengde " cookie-cutter, " eller i det minste semantisk klarhet , er nøyaktig hva mønstre må være for å være nyttige. Begreper som " flyvekt " og " singleton " som de ofte forstås, utelukker hverandre. Den første handler om automatisk deling av data mellom flere forekomster; den andre handler om å ha nøyaktig en forekomst. Jeg ' sier ikke at designvalget ditt er ubrukelig eller til og med dårlig, men klemmer " nær nok " mønsternavn sammen forvirrer bare alle mer. (Ikke ' Ikke ta nedstemmene personlig, spesielt på CW.)