Wat zijn enkele programmeerontwerppatronen die nuttig zijn bij het ontwikkelen van games? [gesloten]

Nu voor een minder luchthartig antwoord, met enkele suggesties. Beschouw deze niet als implementatieaanbevelingen, meer als voorbeelden van mogelijk gebruik.

• Builder: stel component-gebaseerde entiteit één component tegelijk in, gebaseerd op gegevens
• Fabrieksmethode: maak NPCs of GUI-widgets op basis van een string die uit een bestand wordt gelezen
• Prototype: sla één algemeen “Elf” -teken op met initiële eigenschappen en maak Elf-instanties door deze te klonen.
• Singleton: deze ruimte is met opzet leeg gelaten.
• Adapter: neem een optionele bibliotheek van derden op door deze in te pakken een laag die eruitziet als je bestaande code. Erg handig met DLLs.
• Composiet: maak een scènegrafiek van renderbare objecten, of maak een GUI van een boom met widgets
• Gevel: vereenvoudig complexe bibliotheken van derden door een eenvoudigere interface te bieden om uw leven later gemakkelijker te maken.
• Vlieggewicht: sla de gedeelde aspecten van een NPC (bijv. modellen, texturen, animaties) apart van de individuele aspecten (bijv. positie, gezondheid) in een meestal transparante manier
• Proxy: maak kleine klassen op een client die grotere, complexere klassen op een server vertegenwoordigen, en stuur verzoeken door via het netwerk.
• Verantwoordelijkheidsketen: behandel invoer als een keten van handlers, bijv. algemene toetsen (bijv. voor schermafbeeldingen), vervolgens de GUI (bijv. in het geval dat een tekstvak is gefocust of een menu omhoog is), dan het spel (bijv. voor het verplaatsen van een personage)
• Commando: spelfunctionaliteit inkapselen als commandos die in een console kunnen worden getypt, opgeslagen en opnieuw afgespeeld, of zelfs scripted om het spel te testen.
• Mediator: implementeer game-entiteiten als een kleine mediatorklasse die op verschillende componenten werkt (bijv. lezen van de gezondheidscomponent om de gegevens door te geven aan de AI-component)
• Waarnemer: laat de renderbare representatie van een personage luisteren naar gebeurtenissen uit de logische representatie, om de visuele presentatie indien nodig te veranderen zonder de spellogica die iets moet weten over het weergeven van code
• Staat: sla NPC AI op als een van de verschillende toestanden, bijv. Aanvallen, zwerven, vluchten. Elk kan zijn eigen update () -methode hebben en alle andere gegevens die het nodig heeft (bijv. Opslaan van welk personage het aanvalt of vlucht, het gebied waarin het ronddwaalt, enz.).
• Strategie: schakelen tussen verschillende heuristieken voor uw A * -zoekopdracht, afhankelijk van het soort terrein waarin u zich bevindt, of misschien zelfs om hetzelfde A * -raamwerk te gebruiken voor zowel het zoeken naar paden als voor een meer algemene planning.
• Sjabloonmethode: een generieke “gevechts” -routine, met verschillende hook-functies om elke stap af te handelen, bijv. munitie verminderen, hitkans berekenen, hit of misser oplossen, schade berekenen, en elk type aanvalsvaardigheid zal de methoden op hun eigen specifieke manier implementeren

Sommige patronen zijn weggelaten door gebrek aan inspiratie.

Reacties

• Er kan een zeer verhelderende discussie over singletons worden gevonden hier: misko.hevery.com / 2008/08/25 / root-cause-of-singletons
• +1 voor het strategiepatroon. Ik ' heb het gebruikt voor het exacte doel dat hierboven is vermeld (verschillende A * heuristieken aansluiten).
• bedankt voor dit antwoord, die klinken meer als ontwerppatroon dan de gebruikelijke " singleton " i ' die ik overal hoor …
• Geweldige lijst met voorbeelden. Ondanks chronisch misbruik van het singleton-patroon (globale staat in vermomming), zijn er legitieme toepassingen: wanneer het een resource vertegenwoordigt waarvan je er eigenlijk maar één hebt (of wilt). Dit kan zoiets zijn als het inpakken van hardware (bijv. Toetsenbord / muis) of het inpakken van een bibliotheek die niet opnieuw binnenkomt (het gebeurt, en niet alle talen hebben magische synchronisatie-trefwoorden).
• Ik zou nog steeds niet ' t gebruik singletons voor hardwarebronnen – items waarvan je denkt dat je ' er maar één zal hebben die zich later vermenigvuldigen, net zoals videokaarten en monitoren deden zoals de jaren gingen voorbij. Evenzo moet u onder sommige APIs 2 joysticks lezen om 1 gamepad te begrijpen. Dus ik ' d zeg, als je maar één van iets nodig hebt, instantieer dan een enkele, ' niet willekeurige beperkingen afdwingen die waarschijnlijk zijn ' niet nodig.

Ik heb een boek over precies dat onderwerp: Game Programming Patterns . De hoofdstukken die er zijn, kunnen nuttig voor je zijn.

Reacties

• +1 Ik hoopte dat iemand daar naar had gelinkt en ik zie dat de auteur heeft! De beschrijving van het componentpatroon daar was behoorlijk nuttig, en ik vind het leuk dat je probeert om complete codevoorbeelden te gebruiken om te demonstreren.
• Ja – ik herinner me dat ik je link een paar jaar geleden las. Je zou die artikelen moeten afmaken!
• Nu is het boek af 🙂
• Een geweldige bron die me hielp mijn bestaande programmeerkennis te vertalen naar programmeren voor games. Bedankt voor het schrijven!
• Deze uitleg van spelprogrammeerpatronen hielp me in feite -ontwerppatronen- te begrijpen op een manier die geen enkel softwareontwerppatroonboek echt deed! Dit is gedeeltelijk de kracht van game-ontwikkeling (concrete voorbeelden in een taal die me aanspreekt en waarmee ik mijn algehele ontwikkeling kan verbeteren), maar voor een groot deel omdat het schrijven zo uitstekend is.

Een ding dat Brandon Eich zo verstandig had te bespreken in Coders at Work is dat patronen hacks en tijdelijke oplossingen zijn: [Patronen] vertonen een soort defect in de taal. Deze patronen zijn niet gratis. Er is geen gratis lunch. We zouden dus moeten zoeken naar evolutie in de taal die de juiste stukjes toevoegt.

Als game-programmeurs in plaats van compilerontwerpers krijgen we zelden de mogelijkheid om de talen te ontwikkelen we gebruiken, maar we kunnen leren onze eigen stijl te ontwikkelen om beter te passen bij onze taal en vereisten. Patronen zijn hiervan een deel, maar geen patronen gebruiken is een ander onderdeel, vooral omdat, zoals Brandon zegt, patronen zelden zonder noemenswaardige prestaties of kosten voor geheugen- of code-agility. MVC is gewoon niet een geweldig patroon voor veel dingen in games. Singleton is een oplossing voor lame C ++ statische initialisatieregels, en die zou je waarschijnlijk toch niet moeten doen. Fabriek vereenvoudigt het maken van gecompliceerde objecten – misschien moeten uw objecten in het begin gewoon eenvoudiger zijn. De populaire patronen zijn hulpmiddelen om wanneer we ze nodig hebben te gebruiken om iets complexs te beheren, geen hulpmiddelen die we in het begin zouden moeten gebruiken om iets complexs te bouwen.

Goede (game) code gebruikt mogelijk patronen, of niet. Als het patronen gebruikt, prima – ze zijn een geweldig communicatiemiddel om de codestructuur uit te leggen aan andere programmeurs op een hoog, taalonafhankelijk niveau. Als je denkt dat de code beter is zonder een patroon te gebruiken, sla jezelf dan niet op het – waarschijnlijk ook.

Opmerkingen

• Ja, een van de dingen die in het originele boek duidelijk werden gemaakt (maar vaak over het hoofd gezien) is dat als het zijn geschreven voor C in plaats van C ++ / Smalltalk, hadden ze mogelijk een " Inheritance " patroon toegevoegd, en op dezelfde manier talen bevatten mogelijk enkele van de reeds ingebouwde GoF-patronen.
• Het andere dat vaak over het hoofd werd gezien in het originele boek (het originele originele boek van Alexander, niet GoF) was dat patronen een hulpmiddel zijn voor communicatie , niet implementatie . Ze laten ontwerpers communiceren over implementatie op een hoger niveau, en worden geïdentificeerd omdat ze terugkerend zijn, niet noodzakelijk omdat ze waar mogelijk moeten worden gebruikt.
• Alleen al het hebben van de terminologie kan je helpen om over het probleem en erken wanneer een dergelijke benadering een goede oplossing is.De beste patronen zijn doorgaans in de loop van de tijd verfijnd door bekwame en ervaren werknemers, en minder geschoolde werknemers zouden niet dezelfde patronen zelf ontdekken zonder deze gecodificeerde voorbeelden.
• Ik ben het ermee eens dat het hebben van de terminologie geweldig is, en Een deel van de definitie van een patroon is dat het een goede terugkerende oplossing is voor een bepaald probleem. Helaas vinden de minder geschoolde arbeiders meestal Singleton, en passen ze het toe op elk probleem, zelfs als er nog geen probleem is.
• Bedankt voor deze reactie; Ik voel me opgelucht om te lezen dat ontwerppatronen zijn gemaakt om problemen op te lossen die zijn gemaakt door het ontwerp van de software '. Ik denk dat de structuur van een hele grote software van begin tot eind moet worden doordacht voordat je daadwerkelijk begint met coderen. U kunt ' t functionaliteiten niet altijd één keer per keer implementeren, soms moet u aan elke specifieke functie nadenken en controleren of deze heeft gewonnen ' rommel niet met de globale structuur van de software of sta gewoon in de weg met hoe de software zich zou moeten gedragen. Het verdelen van taken over verschillende programmeurs kan soms tegenstrijdigheden creëren …

Natuurlijk, zoals anderen hebben gezegd , alle patronen zijn nuttig in de juiste omstandigheden, en een deel van het leren gebruiken is leren wanneer je ze moet gebruiken. Het uitstekende boek Core Techniques and Algorithms in Game Programming door Daniel Sanchez-Crespo Dalmau somt echter zes programmeerpatronen en zes bruikbaarheidspatronen op zoals vooral handig bij het programmeren van games.

Programmeren:

• Singleton: ik haat deze niet zoals veel mensen doen; hij kan worden gebruikt voor zaken als de single- speler-speler of de toetsenbordlezer.
• Fabriek: hiermee kunt u efficiënt objecten maken en vernietigen.
• Strategie: hiermee kunt u AI-strategieën op elegante wijze veranderen.
• Spatial Index : Helpt bij het uitvoeren van querys op ruimtelijke gegevenssets.
• Samengesteld: stelt een bruikbare objecthiërarchie in.
• Vlieggewicht: maakt geheugen vrij door zaken als identieke vijanden te generaliseren.

Bruikbaarheid:

• Schild: beschermt tegen onbedoelde activering van dramatische acties.
• Staat: visuele aanwijzingen van de wereld / UI-status.
• Automatische modus annulering: zorgt ervoor dat het spel intuïtiever werkt.
• Magneet ism: automatisch doel en gemakkelijke eenheidsselectie.
• Focus: elimineren van afleidende UI-elementen.
• Voortgang: universeel bruikbaar.

Het boek natuurlijk , gaat dieper in op elk van deze.

Reacties

• Bedankt voor de input! Ik was niet op de hoogte van dat boek, maar zal er nu naar kijken naar aanleiding van uw bericht. Nogmaals bedankt!
• Singleton voor de toetsenbordlezer is precies de situatie waarin ik moet vragen: kun je er echt niet zomaar een globale aanwijzer van maken die al vroeg in je hoofdfunctie is ingesteld? Heb je ooit per ongeluk twee toetsenbordlezers geïnstantieerd?
• Haat alstublieft de singleton. Het doet twee dingen slecht. Wereldwijde toegang en ariteit. Vaak denken ontwikkelaars global access == singleton. Er zijn zeer enkele problemen die een echte singleton nodig hebben, en mogelijk nog een paar die eleganter zijn wanneer ze worden opgelost met een singleton.

Entiteitssystemen zijn een aardig soort patroon. Het is niet echt een ontwerppatroon, aangezien het niet strikt OOP is. Je kunt het echter mengen met OOP.

Enkele goede links (begin van boven voor 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

Opmerkingen

• " Het ' is niet bepaald een ontwerppatroon aangezien het ' s niet strickly [sic] OOP. " Ontwerppatronen hebben niets te maken met OOP; als er iets is, is OOP zelf een ontwerppatroon. Ontwerppatronen verschijnen niet alleen buiten OOP, maar volledig buiten softwareontwikkeling.
• Er zijn OOP design patterns die doorgaans relaties en interacties tussen klassen / objecten laten zien. En er zijn veel andere ontwerppatronen. OOP is een verzameling concepten, niet echt een patroon. Design pattern is ook een concept.
• In plaats van over semantiek te praten, zou je ' het nut van het antwoord dat ik gaf?

Allemaal. Behalve Singleton. [/ flippancy]

Reacties

• Zou je een of twee ontwerppatronen kunnen noemen die je ' vaak gebruikt bij de ontwikkeling van je games, en om welke reden?Als beginner met betrekking tot ontwerppatronen is " allemaal " geen bijzonder nuttig antwoord. Maar bedankt voor je reactie.
• Vragen aan " welke patronen heb je gebruikt? " is als vragen aan " welke variabelenamen heb je gebruikt? " Het komt neer op persoonlijke stijl en vereisten en domein. Op een gegeven moment zul je waarschijnlijk elk patroon gebruiken dat ' ooit genoemd is. Je zult er waarschijnlijk nog veel meer gebruiken die geen naam hebben, en misschien zelfs nieuwe uitvinden.
• @ jcurrie33: sorry, ik kon ' gewoon niet weerstaan aan eerst een opgraving bij singletons. 😉

Niet echt over patronen, maar over basisprincipes erachter. In “Design Patterns: Elements of Reusable Object-Oriented Software” (1995) , de bende van vier (Gamma, Erich; Richard Helm, Ralph Johnson en John Vlissides) beveelt slechts twee principes aan voor objectgeoriënteerd ontwerp: (1) programma naar een interface en niet naar een implementatie en (2) geeft de voorkeur aan objectcompositie boven klasse-overerving.

Deze 2 principes zijn erg nuttig bij veel taken van het spel ontwikkeling. Veel game-programmeurs hebben bijvoorbeeld een diepe klassehiërarchie gebruikt om game-entiteiten weer te geven. Er is een andere benadering gebaseerd op compositie – op componenten gebaseerde game-objecten. Artikel over deze aanpak. Nog meer links . Het is een Decorateurpatroon voorbeeld.

Opmerkingen

• Componenten zoals gebruikt in game-ontwerp lijkt meer op een stateful strategiepatroon – dat natuurlijk wordt uitgedrukt als sluitingen buiten C / C ++ / Java / C #, en als componentobjecten erin. Het decorateurpatroon lijkt meer op een proxy; het eigendom en de gegevensstroom zijn tegengesteld aan wat we normaal bedoelen als we het hebben over componentensystemen in games.
• Componenten moeten ook met elkaar praten, waardoor patronen als Mediator, Observer en Composer binnenkomen. " Component-based game " is een geheel op zichzelf staand ontwerppatroon.
• @CodexArcanum, Observer, zeker , maar niet altijd Mediator (in plaats daarvan kan Chain of Responsibility worden gebruikt). Het is alleen Composer als GameObject (samengesteld uit GameObjectComponent) GameObjectComponent zelf is (niet noodzakelijk).

Het merkwaardig terugkerend sjabloonpatroon kan erg handig zijn om virtuele methoden en de prestatieverbeteringen die kunnen voortvloeien uit de virtuele functieaanroepen te vermijden.

Dit kan het juiste patroon zijn als je eigenlijk geen container van het type basisklasse nodig hebt die de interface heeft waarnaar je op zoek bent, maar je zou graag gelijkaardige gedragingen en interfaces willen hebben.

U kunt dit bijvoorbeeld gebruiken bij het compileren van klassen voor meerdere platforms of engines (dx vs. opengl) waarvan de variantie van het type bekend is tijdens het compileren.

Opmerkingen

• Ik heb er altijd een hekel aan gehad dat de os-abstractielaag virtueel was. Het ' s niet zoals jij ' zal ooit twee os-abstractie nodig hebben lagen. Veel beter om CRTP te gebruiken.
• M aybe Ik ' ben gewoon oud, maar ik zou ' zelfs geen CRTP gebruiken voor DX / OpenGL of platforminterfaces. Het ' is te traag om te compileren – ik ' zou gewoon typedefs gebruiken. CRTP is goed als je interfaces en implementaties tussen klassen wilt delen, maar geen andere relatie hebt, niet als je alleen de ene structuur of de andere wilt kiezen.

Een ontwerppatroon dat ik in de loop van vele jaren heb ontwikkeld en dat spectaculair nuttig voor me is geweest, noem ik “brokered definition sets”; hoe het in GOF-termen samen te vatten lijkt controversieel, maar deze vraag die ik erover schreef op StackOverflow gaat er in detail op in.

Het kernconcept is dat een eigenschap van een model, zoals de soort van een wezen, zo is opgezet dat elke mogelijke waarde voor de eigenschap een bijbehorend definitieobject heeft – een enkel gedeeld object per waarde – dat zijn gedrag specificeert , en deze zijn toegankelijk via een centrale broker (die, GOF-gewijs, een register, een fabriek of beide kan zijn). In mijn gebruik zijn ze over het algemeen ook toegankelijk via scalaire toetsen, om zwakke binding voor runtime-morfismedoeleinden te vergemakkelijken.

Reacties

• Ik ' zie niet hoe dit een singleton is en wanneer ik het heb over de flyweight-patroon het woord " registry " is overbodig. Dit is gewoon vlieggewicht.
• Ik begreep uit de SO-thread dat mensen Singleton identificeerden als een deel ervan vanwege de definities die werden opgezet als klassen. Wat het register betreft, ik zie ' niet hoe het redundant kan zijn wanneer het kan worden vervangen of gecombineerd met Factory.
• -1, voor zover patronen gaan over snel communiceren, dit is waarschijnlijk de grootste fout die ik ' heb gezien. Ik kan deze beschrijving echt niet ' nemen.
• Jezus, neem me niet kwalijk dat ik niet genoeg koekjesvorm voor je ben. Gaat u het " Entiteitssystemen " antwoord ook tegenstemmen omdat het niet ' is Kan het niet meteen worden samengevat in GOF-termen?
• Een beetje " cookie-cutter, " of op zijn minst semantische duidelijkheid , is precies wat patronen moeten zijn om bruikbaar te zijn. Termen als " flyweight " en " singleton " zoals ze algemeen worden begrepen, sluiten elkaar wederzijds uit. De eerste gaat over het automatisch delen van gegevens tussen meerdere instanties; de tweede gaat over het hebben van precies één exemplaar. Ik ' m zeg niet dat je ontwerpkeuze nutteloos of zelfs slecht is, maar prop " dichtbij genoeg " patroonnamen samen verwart iedereen alleen maar meer. (Gelieve ' niet persoonlijk te stemmen, vooral op CW.)