Hvad er nogle programmeringsdesignmønstre, der er nyttige i spiludvikling? [lukket]

Nu for et mindre flippant svar med nogle forslag. Du må ikke tage disse som implementeringsanbefalinger, mere som eksempler på mulig brug.

• Builder: opsæt komponentbaseret enhed en komponent ad gangen, baseret på data
• Fabriksmetode: Opret NPCer eller GUI-widgets baseret på en streng, der læses fra en fil
• Prototype: Gem et generisk “Elf” -tegn med indledende egenskaber, og opret Elf-forekomster ved at klone det.
• Singleton: dette rum er bevidst tomt.
• Adapter: inkorporer et valgfrit tredjepartsbibliotek ved at indpakke det i et lag, der ligner din eksisterende kode. Meget nyttigt med DLLer.
• Komposit: lav en scenegraf af gengivelige objekter eller lav en GUI ud af et widgetræ
• Facade: forenkle komplekse tredjepartsbiblioteker ved at give en enklere grænseflade for at gøre dit liv lettere senere.
• Flyvægt: gem de delte aspekter af en NPC (f.eks. modeller, teksturer, animationer) adskilt fra de enkelte aspekter (f.eks. position, sundhed) i en mest gennemsigtig måde
• Proxy: Opret små klasser på en klient, der repræsenterer større, mere komplekse klasser på en server og videresend anmodninger via netværket.
• Ansvarskæde: håndter input som en kæde af håndterere, f.eks. globale taster (f.eks. til skærmbilleder), derefter GUI (f.eks. hvis et tekstfelt er fokuseret, eller en menu er oppe), derefter spillet (f.eks. til at flytte et tegn)
• Kommando: indkapsle spilfunktionalitet som kommandoer, der kan indtastes i en konsol, gemmes og afspilles eller endda scriptes for at hjælpe med at teste spillet
• Mediator: implementer spilenheder som en lille mediator-klasse, der fungerer på forskellige komponenter (f.eks. læsning fra sundhedskomponenten for at videregive dataene til AI-komponenten)
• Observer: få den gengivelige gengivelse af et tegn til at lytte til begivenheder fra den logiske repræsentation for at ændre den visuelle præsentation, når det er nødvendigt uden spillogikken behøver at vide noget om gengivelseskode
• Tilstand: gem NPC AI som en af flere stater, f.eks. Angribende, vandrende, flygter. Hver kan have sin egen opdateringsmetode () og de andre data, den har brug for (f.eks. At gemme hvilket tegn de angriber eller flygter fra, det område, hvor de vandrer osv.)
• Strategi: skift mellem forskellige heuristikker til din A * -søgning, afhængigt af hvilken slags terræn du befinder dig i, eller måske endda for at bruge den samme A * -ramme til at udføre både stifindende og mere generel planlægning
• Skabelonmetode: opsæt en generisk “kamp” -rutine med forskellige krogfunktioner til håndtering af hvert trin, f.eks. mindskelse af ammunition, beregning af hitchance, løsning af hit eller miss, beregning af skade, og hver type angrebskompetencer implementerer metoderne på deres egen specifikke måde

Nogle mønstre udeladt på grund af manglende inspiration.

Kommentarer

• En meget oplysende diskussion om singletoner kan findes her: misko.hevery.com / 2008/08/25 / root-cause-of-singletons
• +1 til strategimønsteret. Jeg ' har brugt det til det nøjagtige formål, der er angivet ovenfor (tilslutning til forskellige A * heuristikker).
• tak for dette svar, de lyder mere som designmønster end den sædvanlige " singleton " jeg ' hører overalt …
• Fantastisk liste med eksempler. På trods af kronisk misbrug af singleton-mønsteret (global tilstand i forklædning) er der legitime anvendelser: Når det repræsenterer en ressource som du faktisk kun har (eller ønsker) en. Dette kan være noget i retning af indpakning af hardware (f.eks. Tastatur / mus) eller indpakning af et bibliotek, der ikke er tilbage (det sker, og ikke alle sprog har magiske synkroniseringsnøgleord).
• Jeg ville stadig ikke have ' Brug ikke singletons til hardware-ressourcer – emner, som du tror, du ' kun har 1 af har tendens til at formere sig senere, ligesom grafikkort og skærme gjorde som år gik. Tilsvarende skal du under nogle APIer læse 2 joysticks for at forstå 1 gamepad. Så jeg ' siger jeg, hvis du kun har brug for en af noget, skal du bare starte en enkelt, ikke ' t håndhæve vilkårlige begrænsninger, der sandsynligvis er ikke ' t nødvendigt.

Jeg skrev en bog om netop dette emne: Spilprogrammeringsmønstre . De kapitler, der er der, kan være nyttige for dig.

Kommentarer

• +1 Jeg håbede, at nogen havde linket til det, og jeg ser, at forfatteren har! Komponentmønsterbeskrivelsen der var temmelig hjælpsom, og jeg kan godt lide, at du prøver at bruge komplette kodeeksempler til at demonstrere.
• Ja – jeg husker at have læst dit link for et par år siden. Du skal afslutte disse artikler!
• Nu er bogen færdig 🙂
• En fantastisk ressource, der hjalp mig med at oversætte min eksisterende viden om programmering til programmering af spil. Tak for at skrive det!
• Denne forklaring på spilprogrammeringsmønstre hjalp mig faktisk til at forstå -designmønstre – på en måde, som ingen software design mønsterbog virkelig gjorde! Dette er til dels styrken ved spiludvikling (konkrete eksempler på et sprog, der taler til mig og giver mig mulighed for at forbedre min udvikling generelt), men i en større del, fordi skrivningen er så fremragende.

Én ting Brandon Eich havde god mening at bringe op i Kodere på arbejdspladsen er, at mønstre er hacks og løsninger: [Mønstre] viser en eller anden form for mangel på sproget. Disse mønstre er ikke gratis. Der er ingen gratis frokost. Så vi skulle være på udkig efter udvikling på det sprog, der tilføjer de rigtige bits.

Som spilprogrammerere snarere end compiler-designere får vi sjældent mulighed for at udvikle sprogene vi bruger, men vi kan lære at udvikle vores egen stil, så de passer bedre til vores sprog og krav. Mønstre er noget af dette, men ikke at bruge mønstre er en anden del, især da som Brandon siger, mønstre sjældent går uden en bemærkelsesværdig ydeevne eller hukommelse eller kode agility omkostninger. MVC er bare ikke et godt mønster for mange ting i spil. Singleton er en løsning til lamme C ++ statiske initialiseringsregler, og du burde sandsynligvis ikke gøre dem alligevel. Fabrik forenkler kompliceret oprettelse af objekter – måske skal dine objekter bare være enklere til at begynde med. De populære mønstre er værktøjer til at ty til når vi har brug for dem for at styre noget komplekst, ikke værktøjer, som vi længes efter at bruge til at bygge noget komplekst i starten.

God (spil) kode bruger muligvis mønstre, eller måske ikke. Hvis det bruger mønstre, fint – de er et godt kommunikationsværktøj til at forklare kodestrukturen til andre programmører på et højt sproguafhængigt niveau. Hvis du mener, at koden er bedre uden at bruge et mønster, må du ikke slå dig selv op over det – det er det sandsynligvis.

Kommentarer

• Ja, en af de ting, der er gjort tydelige i den originale bog (men ofte overset) er, at hvis den blev skrevet til C snarere end C ++ / Smalltalk, de havde muligvis inkluderet et " Arv " mønster, og med samme tegn nogle sprog kan indeholde nogle af de allerede indbyggede GoF-mønstre.
• Den anden ting, der ofte overses i den originale bog (den originale originale bog af Alexander, ikke GoF), var at mønstre er et værktøj til kommunikation , ikke implementering . De lader designere kommunikere om implementering på et højere niveau og identificeres, fordi de er tilbagevendende, ikke nødvendigvis fordi de skal bruges, når det er muligt.
• Men kun at have terminologien kan hjælpe dig med at begrunde problemet og erkende, hvornår en sådan tilgang er en god løsning.De bedste mønstre er typisk blevet forfinet over tid af kvalificerede og erfarne arbejdere, og mindre kvalificerede arbejdstagere ville ikke selv finde de samme mønstre uden at der var disse kodificerede eksempler.
• Jeg er enig i at have terminologien er stor, og en del af definitionen af et mønster er, at det er en god tilbagevendende løsning til nogle problemer. Desværre har de mindre kvalificerede arbejdere en tendens til at finde det meste af Singleton og anvende det på hvert problem, selv når der endnu ikke er et problem.
• Tak for dette svar; Jeg føler mig lettet over at læse, at designmønster er lavet til at løse problemer skabt af softwarens ' design. Jeg synes, at strukturen i en hel stor software skal overvejes fra start til slut, før man faktisk begynder at kode noget. Du kan ' ikke altid implementere funktionaliteter en gang ad gangen, engang skal du tænke på hver enkelt funktion og kontrollere, om den vinder ' ikke rod med den globale struktur af softwaren eller bare komme i vejen for, hvordan softwaren er opført til at opføre sig. At dele opgaver til flere programmører kan engang skabe modsætninger …

Selvfølgelig, som andre har sagt , alle mønstre er nyttige under de rigtige omstændigheder, og en del af at lære at bruge dem er at lære, hvornår man skal bruge dem. Den fremragende bog Core Techniques and Algorithms in Game Programming af Daniel Sanchez-Crespo Dalmau viser imidlertid seks programmeringsmønstre og seks brugervenlige mønstre som især nyttigt i spilprogrammering.

Programmering:

• Singleton: Jeg hader ikke denne, som mange mennesker gør; den kan bruges til ting som afspiller eller tastaturlæser.
• Fabrik: Gør det muligt at oprette og ødelægge objekter effektivt.
• Strategi: Gør det muligt at ændre AI-strategier elegant.
• Rumligt indeks : Hjælper med at udføre forespørgsler på geodatasæt.
• Komposit: Sætter et nyttigt objektarving.
• Flyvægt: Frigør hukommelse ved at generere ting som identiske fjender.

Brugbarhed:

• Skjold: Beskytter mod utilsigtet aktivering af dramatiske handlinger.
• Tilstand: Visuelle tegn på verdens / UI-status.
• Annullering af automatisk tilstand: Gør spillet mere intuitivt.
• Magnet ism: Autoaiming og let enhedsvalg.
• Fokus: Fjernelse af distraherende UI-elementer.
• Fremskridt: Universelt nyttigt.

Bogen selvfølgelig , går nærmere ind på hver af disse.

Kommentarer

• Tak for input! Jeg var ikke opmærksom på den bog, men vil undersøge den nu som et resultat af dit indlæg. Tak igen!
• Singleton til tastaturlæseren er nøjagtigt den situation, hvor jeg er nødt til at spørge – Kan du virkelig ikke bare gøre det til en global markør, der er sat tidligt i din hovedfunktion? Har du nogensinde ved et uheld skabt to tastaturlæsere ved et uheld?
• Hav venligst singleton. Det gør to ting dårligt. Global adgang og arity. Ofte tænker udviklere global adgang == singleton. Der er meget få problemer end behov for en ægte singleton og muligvis et par flere, der er mere elegante, når de løses med en singleton.

Enhedssystemer er en god slags mønster. Det er ikke ligefrem et designmønster, da det ikke er strengt OOP. Du kan dog blande det med OOP.

Nogle gode links (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 ligefrem et designmønster, da det ' s ikke strickly [sic] OOP. " Designmønstre har intet at gøre med OOP; hvis noget, er OOP i sig selv et designmønster. Designmønstre vises ikke kun uden for OOP, men helt uden for softwareudvikling.
• Der er OOP design patterns, der typisk viser relationer og interaktioner mellem klasser / objekter. Og der er mange andre designmønstre. OOP er et sæt koncepter, ikke et mønster virkelig. Design pattern er også et koncept.
• I stedet for at tale om semantisk, bør du ikke ' t bedømme nytten af det svar, jeg gav?

Alle sammen. Undtagen Singleton. [/ flippancy]

Kommentarer

• Kan du muligvis navngive et eller to designmønstre, som du ' har brugt ofte i din spiludvikling, og af hvilken grund?Som nybegynder med hensyn til designmønstre er " dem alle " ikke et særligt nyttigt svar. Tak, fordi du svarede.
• Spørg " hvilke mønstre har du brugt? " er som at spørge " hvilke variabelnavne har du brugt? " Det kommer ned til personlig stil og krav og domæne. På et eller andet tidspunkt vil du sandsynligvis bruge ethvert mønster, som ' nogensinde er navngivet. Du vil sandsynligvis bruge mange flere, der ikke er navngivet, og måske endda opfinde nogle nye.
• @ jcurrie33: undskyld, jeg kunne bare ikke ' t modstå at have grave først på singletoner. 😉

Ikke rigtig om mønstre, men om grundlæggende principper bag dem. I “Design Patterns: Elements of Reusable Object-Oriented Software” (1995) , banden på fire (Gamma, Erich; Richard Helm, Ralph Johnson og John Vlissides) anbefaler kun to principper for objektorienteret design: (1) program til en grænseflade og ikke til en implementering og (2) favoriserer objektsammensætning frem for klassearv.

Disse 2 principper er meget nyttige i mange spilopgaver udvikling. For eksempel har mange spilprogrammerere brugt et dybt klassehierarki til at repræsentere spilenheder. Der er en anden tilgang baseret på komposition – komponentbaserede spilobjekter. Artikel om denne tilgang. Endnu flere links . Det er et Dekoratormønster eksempel.

Kommentarer

• Komponenter som brugt i spildesign er mere som et statefult strategimønster – som naturligt udtrykkes som lukninger uden for C / C ++ / Java / C # og som komponentobjekter inde i dem. Pyntemønsteret ligner mere en proxy; dets ejerskab og datastrøm er modsat dem, vi normalt mener, når vi taler om komponentsystemer i spil.
• Komponenter har også brug for at tale med hinanden og bringe mønstre som Mediator, Observer og Composer. " Komponentbaseret spil " er et sammensat designmønster i sig selv.
• @CodexArcanum, Observer, bestemt , men ikke altid mægler (kæde af ansvar kan bruges i stedet). Det er kun komponist, hvis GameObject (sammensat af GameObjectComponent) er GameObjectComponent i sig selv (ikke nessesary).

nysgerrigt tilbagevendende skabelonmønster kan være virkelig nyttigt for at undgå virtuelle metoder og den præstationsstraffe, der kan komme fra de virtuelle funktionskald.

kan være det passende mønster, når du faktisk ikke behøver at have en beholder af basisklassetypen, som har den grænseflade, du har brug for, men du gerne vil have adfærd og grænseflader, der har samme navn.

For eksempel kan du bruge dette ved kompilering af klasser til flere platforme eller motorer (dx vs. opengl), hvor variansen af typen er kendt på kompileringstidspunktet.

Kommentarer

• Jeg hadede altid, at os-abstraktionslaget var virtuelt. Det ' er ikke som dig ' vil nogensinde have brug for to os-abtraktion lag. Meget bedre at bruge CRTP.
• M aybe jeg ' jeg er bare gammel, men jeg ville ikke ' ikke engang bruge CRTP til DX / OpenGL eller platformgrænseflader. Det ' er for langsomt til at kompilere – Jeg ' bruger bare typedefs. CRTP er godt, når du vil dele grænseflader og implementeringer mellem klasser, men ikke har nogen anden relation, ikke når du bare vil vælge den ene struktur eller den anden.

Et designmønster, som jeg udviklede i løbet af mange år, og som har været spektakulært nyttigt for mig, er noget, jeg omtaler som “formidlede definitionssæt”; hvordan man opsummerer det i GOF-termer synes at være kontroversielt, men dette spørgsmål, jeg skrev om det på StackOverflow , går i detaljer om det.

Kernekonceptet er, at en eller anden egenskab ved en model, ligesom arten af en skabning, er indstillet således, at hver mulige værdi for ejendommen har et tilsvarende definitionsobjekt – et enkelt, delt objekt pr. Værdi – der specificerer dets adfærd , og disse er tilgængelige via en central mægler (som GOF-vis kan være et register, en fabrik eller begge dele). I min brug er de også generelt tilgængelige via skalar nøgler for at lette svag binding til runtime morphism formål.

Kommentarer

• Jeg kan ikke ' ikke se, hvordan dette overhovedet er en singleton, og når man diskuterer flyvevægt mønster ordet " registreringsdatabasen " er overflødigt. Dette er bare flyvægt.
• Min forståelse fra SO-tråden var, at folk identificerede Singleton som en del af det på grund af definitionerne, der blev indstillet som klasser. For så vidt som registreringsdatabasen går, kan jeg ikke ' ikke se, hvordan det kan være overflødigt, når det kan udskiftes eller kombineres med fabrik.
• -1, i det omfang mønstre handler om hurtigt at kommunikere, dette er sandsynligvis den største fiasko, jeg ' har set. Jeg kan virkelig ' ikke tage denne beskrivelse alvorligt.
• Jesus, undskyld mig for ikke at være cookie-cutter nok for dig. Stemmer du ned " Enhedssystemer " svaret også, fordi det ikke er ' t straks opsummeres i GOF-termer?
• En vis mængde " cookie-cutter, " eller i det mindste semantisk klarhed , er nøjagtigt, hvad mønstre skal være for at være nyttige. Udtryk som " flyvægt " og " singleton " som de almindeligt forstås, er gensidigt eksklusive. Den første handler om automatisk deling af data mellem flere forekomster; det andet handler om at have nøjagtigt en instans. Jeg ' siger ikke, at dit designvalg er ubrugeligt eller endda dårligt, men klemmer " tæt nok " mønsternavne sammen forvirrer bare alle mere. (Du må ikke ' ikke tage downvotes personligt, især på CW.)