Mitkä ovat joitain ohjelmointisuunnittelumalleja, joista on hyötyä pelikehityksessä? [suljettu]

Nyt saat vastauksen vähemmän räikeästi ja joitain ehdotuksia. Älä ota näitä käyttöönottosuosituksina, pikemminkin esimerkkeinä mahdollisesta käytöstä.

• Rakentaja: määritä komponenttipohjainen entiteetti yksi komponentti kerrallaan tietojen perusteella
• Tehdasmenetelmä: luo NPC: t tai GUI-widgetit tiedostosta luetun merkkijonon perusteella
• Prototyyppi: tallenna yksi yleinen ”Elf” -hahmo alkuperäisillä ominaisuuksilla ja luo Elf-esiintymiä kloonaamalla se.
• Singleton: tämä tila jätettiin tarkoituksella tyhjäksi.
• Sovitin: sisällytä valinnainen kolmannen osapuolen kirjasto käärimällä se taso, joka näyttää nykyiseltä koodiltasi. Erittäin hyödyllinen DLL-tiedostojen kanssa.
• Yhdistetty: tee näkymäkuvaaja renderöitavista objekteista tai tee GUI widget-puusta
• Julkisivu: yksinkertaista monimutkaisia kolmannen osapuolen kirjastoja tarjoamalla yksinkertaisempi käyttöliittymä, joka helpottaa elämääsi myöhemmin.
• Flyweight: tallenna NPC: n jaetut näkökohdat (esim. mallit, tekstuurit, animaatiot) erillään yksittäisistä näkökohdista (esim. asema, terveys) a enimmäkseen läpinäkyvä tapa
• Välityspalvelin: Luo asiakkaalle pieniä luokkia, jotka edustavat suurempia, monimutkaisempia luokkia palvelimella ja välittävät pyynnöt verkon kautta.
• Vastuuketju: käsittele syötettä ketju käsittelijöitä, esim. globaalit näppäimet (esim. näyttökuvia varten), sitten käyttöliittymä (esim. jos tekstiruutu on kohdistettu tai valikko on ylöspäin), sitten peli (esim. merkin siirtämiseen)
• Komento: kapseloi pelitoiminnot komentoiksi, jotka voidaan kirjoittaa pelikonsoliin, tallentaa ja toistaa tai jopa komentosarjoittaa pelin testaamiseksi.
• Mediator: toteuttaa pelikokonaisuudet pienenä välittäjäluokana, joka toimii eri komponenteilla (esim. lukeminen terveyskomponentista tietojen siirtämiseksi tekoälykomponenttiin)
• Tarkkailija: anna hahmon renderoitavan esityksen kuunnella tapahtumia loogisesta esityksestä, jotta visuaalista esitystä voidaan muuttaa tarvittaessa ilman pelilogiikan, joka tarvitsee tietää mitään koodin renderoinnista
• Tila: tallenna NPC AI yhtenä tilana, esim. Hyökkääminen, vaeltelu, pakeneminen. Jokaisella voi olla oma päivitysmenetelmä () ja mitä tahansa muuta tarvitsemaansa dataa (esim. Tallennetaan mikä merkki hyökkää tai pakenee, alue, jolla vaeltaa jne.)
• Strategia: vaihda erilaiset heuristiikat A * -hakullesi riippuen siitä, millaisessa maastossa olet, tai ehkä jopa käyttää samaa A * -ympäristöä sekä polun etsinnässä että yleisemmässä suunnittelussa.
• Mallimenetelmä: määritä yleinen ”taistelu” -rutiini, jossa on useita koukkufunktioita jokaisen vaiheen käsittelemiseksi, esim. vähennyslasku, laskea osuman mahdollisuus, ratkaista osuma tai epäonnistuminen, laskea vahingot, ja kukin hyökkäystaitotyyppi toteuttaa menetelmät omalla erityisellä tavalla

Jotkut mallit jätettiin pois inspiraation puutteen vuoksi.

Kommentit

• Erittäin valaiseva keskustelu yksittäisistä kappaleista löytyy täällä: misko.hevery.fi / 2008/08/25 / singletonien perimmäiset syyt
• +1 strategiakuvioon. Olen ' käyttänyt sitä tarkkaan yllä mainittuun tarkoitukseen (kytkemällä eri A * -heuristiikkaan).
• kiitos tästä vastauksesta, ne kuulostavat enemmän kuin suunnittelukuviot kuin tavallinen " singleton " i ' m kuulo kaikkialla …
• Suuri luettelo esimerkkejä. Huolimatta singleton-mallin (naamioituneen globaalin tilan) kroonisesta väärinkäytöstä on laillisia käyttötarkoituksia: Kun se edustaa resurssia , josta sinulla on vain yksi (tai haluat). Tämä voi olla jotain laitteiston (esim. Näppäimistö / hiiri) käärimistä tai kirjaston käärimistä, joka ei ole uudelleenkäynnistynyt (se tapahtuu, eikä kaikilla kielillä ole maagisia synkronointiavainsanoja).
• En silti halua ' älä käytä yksikköjä laitteistoresursseihin – kohteisiin, joiden uskot ' ll vain 1: llä on taipumus lisääntyä myöhemmin, aivan kuten näyttökortit ja näytöt tekivät kuten vuotta kului. Vastaavasti joissakin sovellusliittymissä sinun on luettava 2 ohjainta, jotta ymmärrät yhden peliohjaimen. Joten sanon ' sanon, jos tarvitset vain jotain jostakin, suorita vain yksi, älä ' t ota käyttöön mielivaltaisia rajoituksia, jotka todennäköisesti areena ' ei ole välttämätöntä.

Kirjoitin kirja tarkalleen aiheesta: Pelin ohjelmointikuviot . Löydetyt luvut voivat olla hyödyllisiä sinulle.

Kommentit

• +1 Toivoin, että joku oli linkittänyt siihen, ja näen, että kirjoittaja on! Komponenttimallikuvaus oli melko hyödyllinen, ja pidän siitä, että yrität käyttää täydellisiä esimerkkejä koodeista.
• Joo – muistan lukenut linkkisi muutama vuosi sitten. Sinun pitäisi viimeistellä nuo artikkelit!
• Nyt kirja on valmis 🙂
• Hämmästyttävä resurssi, joka auttoi minua kääntämään olemassa olevan ohjelmointitietoni pelien ohjelmointiin. Kiitos, että kirjoitit sen!
• Tämä pelin ohjelmointimallien selitys auttoi minua ymmärtämään – suunnittelumalleja – tavalla, jota mikään ohjelmistosuunnittelumallikirja ei todellakaan tehnyt! Tämä on osittain pelikehityksen voima (konkreettisia esimerkkejä kielellä, joka puhuu minulle ja antaa paremman kehitykseni kokonaisuutena), mutta suuremmaksi osaksi, koska kirjoittaminen on niin erinomaista.

Yksi asia Brandon Eichillä oli hyvä mieli tuoda esiin koodereita työssä on, että mallit ovat hakkereita ja kiertotapoja: [Patterns] näyttää jonkinlaisen puutteen kielessä. Nämä mallit eivät ole ilmaisia. Ilmaista lounasta ei ole. Joten meidän pitäisi etsiä kehitystä kieleltä, joka lisää oikeat bitit.

Pelien ohjelmoijina eikä kääntäjäsuunnittelijoina meillä on harvoin mahdollisuus kehittää kieliä käytämme, mutta voimme oppia kehittämään omaa tyyliämme vastaamaan paremmin kieltämme ja vaatimuksiamme. Kuviot ovat osa tätä, mutta mallien käyttämättä jättäminen on toinen osa, varsinkin kun kuten Brandon sanoo, kuviot menevät harvoin ilman merkittävää suorituskykyä tai muistin tai koodin ketteryyttä. MVC ei vain ole hyvä malli monille peleille. Singleton on kiertotapa ontoville C ++ staattisille alustussäännöille, ja sinun ei todennäköisesti pitäisi tehdä niitä. Tehdas yksinkertaistaa monimutkaisten objektien luomista – kenties kohteidesi pitäisi olla yksinkertaisia aluksi. Suositut mallit ovat työkaluja, joihin voidaan turvautua kun tarvitsemme niitä hallitaksemme jotain monimutkaista, eivät työkaluja, joita meidän pitäisi kaipaa rakentaa jotain monimutkaista alussa.

Hyvä (peli) koodi saattaa käyttää malleja tai ei. Jos se käyttää malleja, hieno – ne ovat loistava viestintäväline selittämään koodirakenne muille ohjelmoijille korkealla, kielestä riippumattomalla tasolla. Jos luulet koodin olevan parempi käyttämättä mallia, älä voita itseäsi se – se luultavasti onkin.

Kommentit

• Kyllä, yksi alkuperäisessä kirjassa tehdyistä (mutta usein huomiotta jätetyistä) asioista on, että jos se kirjoitettiin C: lle eikä C ++ / Smalltalkille, he ovat saattaneet sisällyttää " perintömallin " ja samalla tavoin jotkut kielet saattavat sisältää joitain jo sisäänrakennettuja GoF-malleja.
• Toinen asia, jota alkuperäisessä kirjassa (Alexanderin alkuperäisessä alkuperäisessä kirjassa, ei GoF: ssä) usein unohdetaan, oli se, että mallit ovat työkalu viestintään , ei toteutus . Ne antavat suunnittelijoiden kommunikoida toteutuksesta korkeammalla tasolla, ja heidät tunnistetaan, koska ne toistuvat, ei välttämättä siksi, että niitä tulisi käyttää aina, kun mahdollista.
• Pelkkä terminologian käyttö voi kuitenkin auttaa sinua ajattelemaan ongelmaa ja ymmärtää, milloin tällainen lähestymistapa on hyvä ratkaisu.Parhaat ja ammattitaitoiset työntekijät ovat yleensä ajan mittaan parantaneet parhaita malleja, ja vähemmän ammattitaitoiset työntekijät eivät itse löytäisi samoja malleja ilman näitä kodifioituja esimerkkejä.
• Olen samaa mieltä siitä, että terminologia on hienoa, ja osa mallin määritelmää on, että se on hyvä toistuva ratkaisu johonkin ongelmaan. Valitettavasti vähemmän ammattitaitoiset työntekijät löytävät yleensä enimmäkseen Singletonin ja soveltavat sitä jokaiseen ongelmaan, vaikka ongelmaa ei vielä olisikaan.
• Kiitos vastauksesta; Minusta on helpointa lukea, että suunnittelumalli on tehty ratkaisemaan ohjelmiston ' suunnittelun aiheuttamat ongelmat. Uskon, että kokonaisen suuren ohjelmiston rakenne tulisi miettiä alusta loppuun ennen kuin todella alkaa koodata mitään. Voit ' t aina toteuttaa toimintoja kerran kerrallaan, joskus sinun täytyy miettiä jokaista ominaisuutta ja tarkistaa, voitiinko se ' Älä sekaudu ohjelmiston maailmanlaajuiseen rakenteeseen tai vain estä ohjelmiston käyttäytymistä. Tehtävien jakaminen useille ohjelmoijille voi joskus aiheuttaa ristiriitoja …

Tietysti, kuten muut ovat sanoneet , kaikki mallit ovat hyödyllisiä oikeissa olosuhteissa, ja osa niiden käytön oppimisesta on oppia, kun niitä käytetään. Daniel Sanchez-Crespo Dalmaun erinomaisessa kirjassa Peliohjelmoinnin ydintekniikat ja algoritmit on kuitenkin lueteltu kuusi ohjelmointimallia ja kuusi käytettävyysmallia yhtä hyödyllinen pelien ohjelmoinnissa.

Ohjelmointi:

• Singleton: En vihaa tätä kuten monet ihmiset; sitä voidaan käyttää esimerkiksi single- soitin tai näppäimistönlukija.
• Tehdas: Antaa sinun luoda ja tuhota esineitä tehokkaasti.
• Strategia: Antaa sinun vaihtaa tekoälyn strategioita tyylikkäästi.
• Spatial Index : Auttaa tekemään kyselyjä paikkatietojoukoille.
• Yhdistelmä: Asettaa hyödyllisen objektin heirarkian.
• Lentopaino: Vapauttaa muistia luomalla asioita, kuten identtiset viholliset.

Käytettävyys:

• Suoja: Suojaa dramaattisten toimien tahattomalta aktivoitumiselta.
• Tila: Visuaaliset vihjeet maailman / käyttöliittymän tilasta.
• Automaattinen tilan peruutus: Peli toimii entistä intutiivisemmin.
• Magneetti ism: Autoaiming ja helppo yksikön valinta.
• Kohdistus: häiritsevien käyttöliittymän elementtien poistaminen.
• Edistyminen: Yleisesti hyödyllinen.

Kirja tietysti , kerrotaan tarkemmin kaikista näistä.

Kommentit

• Kiitos panoksesta! En ollut tietoinen siitä kirjasta, mutta tutkin sitä nyt viestisi seurauksena. Kiitos vielä kerran!
• Singleton näppäimistönlukijalle on juuri se tilanne, jossa minun on kysyttävä – Voitteko todellakin tehdä siitä vain globaalin osoittimen, joka asetetaan päätoiminnon varhaisessa vaiheessa? Oletko koskaan todella vahingoittanut kahta näppäimistönlukijaa?
• Vihaa yksin. Se tekee kaksi asiaa huonosti. Globaali pääsy ja arity. Usein kehittäjät ajattelevat, että globaali käyttöoikeus == yksittäinen. Siellä on hyvin muutama ongelma kuin tarvitaan todellista singletonia, ja mahdollisesti muutama muu, joka on tyylikkäämpi, kun se ratkaistaan singletillä.

Entiteettijärjestelmät ovat mukava malli. Se ei ole aivan suunnittelumalli, koska se ei ole tiukasti OOP. Voit kuitenkin sekoittaa sen OOP: n kanssa.

Hyviä linkkejä (aloita ylhäältä introlle):

• 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

kommentit

• " Se ' ei ole aivan suunnittelumalli, koska se ' ei ole tiukasti [sic] OOP. " Suunnittelumalleilla ei ole mitään tekemistä OOP: n kanssa; jos mitään, OOP itsessään on suunnittelumalli. Suunnittelumallit eivät näy pelkästään OOP: n ulkopuolella, vaan myös kokonaan ohjelmistokehityksen ulkopuolella.
• On OOP design patterns, jotka tyypillisesti näyttävät luokkien / objektien välisiä suhteita ja vuorovaikutusta. Ja on olemassa monia muita suunnittelumalleja. OOP on joukko käsitteitä, ei oikea malli. Design pattern on myös käsite.
• Semanttisesta puhumisesta ei pidä ' luokitella antamasi vastauksen?

Kaikki. Paitsi Singleton. [/ flippancy]

Kommentit

• Voisitko mahdollisesti nimetä yhden tai kaksi suunnittelumallia, jotka ' Oletko käyttänyt sitä usein pelikehityksessäsi, ja mistä syystä?Aloittelijana suunnittelumallien suhteen " ne kaikki " eivät ole erityisen hyödyllisiä vastauksia. Kiitos vastauksestasi.
• Kysymällä " mitä malleja olet käyttänyt? " on kuin kysymään " mitä muuttujien nimiä olet käyttänyt? " Se riippuu henkilökohtaisesta tyylistä, vaatimuksista ja toimialueesta. Jossain vaiheessa luultavasti käytät mitä tahansa mallia, joka ' on koskaan nimetty. Käytät todennäköisesti monia muita, joita ei ole nimetty, ja ehkä jopa keksit uusia.
• @ jcurrie33: Anteeksi, en vain voinut ' olla vastustamatta kaivaa ensin singletoneille. 😉

Ei oikeastaan kuvioista, vaan niiden taustalla olevista perusperiaatteista. Julkaisussa ”Suunnittelumallit: uudelleenkäytettävien olio-ohjelmistojen elementit” (1995) neljän hengen jengi (Gamma, Erich; Richard Helm, Ralph Johnson ja John Vlissides) suosittelee vain kahta periaatetta objektisuuntautuneelle suunnittelulle: (1) ohjelmaa käyttöliittymälle eikä toteutukselle ja (2) suosivat esineiden sommittelua luokan perimiseen nähden.

Nämä kaksi periaatetta ovat erittäin hyödyllisiä monissa pelin tehtävissä kehitystä. Esimerkiksi monet peliohjelmoijat ovat käyttäneet syvä luokan hierarkiaa pelikokonaisuuksien esittämiseen. On olemassa toinen lähestymistapa, joka perustuu sävellykseen – komponenttipohjaisiin peliobjekteihin. Artikkeli tästä lähestymistavasta. Lisää linkkejä . Se on esimerkki sisustajakuviosta .

Kommentit

• Komponentit, joita käytetään pelisuunnittelu muistuttaa pikemminkin tilannekohtaista strategiakuviota – joka ilmaistaan luonnollisesti sulkemina C / C ++ / Java / C #: n ulkopuolella ja komponenttiobjekteina niiden sisällä. Sisustuskuvio on enemmän kuin välityspalvelin; sen omistajuus ja tietovirta ovat päinvastaisia kuin mitä tarkoitamme normaalisti puhuessamme komponenttijärjestelmistä peleissä.
• Myös komponenttien on puhuttava keskenään, tuoden sisään mallia kuten Mediator, Observer ja Composer. " Komponentteihin perustuva peli " on itsessään yhdistelmämalli.
• @CodexArcanum, Observer, definetely , mutta ei aina sovittelija (sen sijaan voidaan käyttää vastuuketjua). Se on Composer vain, jos GameObject (koostuu GameObjectComponentista) on itse GameObjectComponent (ei välttämätön).

uteliaasti toistuva mallikuvio voi olla todella hyödyllinen välttämään virtuaalisia menetelmiä ja virtuaalisten toimintokutsujen seurauksia.

Tämä voi olla sopiva malli, kun sinulla ei todellakaan tarvitse olla perusluokan tyyppistä säilöä, jolla on käyttöliittymä, jota olet seuraamassa, mutta haluat samalla tavalla nimetä käyttäytymismalleja ja käyttöliittymiä.

Voit esimerkiksi käyttää tätä laatiessasi luokkia useille alustoille tai moottoreille (dx vs. opengl), joiden tyypin varianssi on tiedossa kääntöhetkellä.

Kommentit

• Vihasin aina, että os-abstraktiokerros oli virtuaalinen. Se ' ei ole kuin sinä ' Tarvitsen koskaan kaksi os-tiivistystä Paljon parempi käyttää CRTP: tä.
• M aybe I ' m vain vanha, mutta en edes ' edes käyttäisi CRTP: tä DX / OpenGL- tai alustarajapinnoissa. ' on liian hidas kääntää – minä ' d vain käyttää typedefs. CRTP on hyvä, kun haluat jakaa rajapintoja ja toteutuksia luokkien välillä, mutta sinulla ei ole muuta suhdetta, ei silloin, kun haluat vain valita yhden tai toisen rakenteen.

Suunnittelumalli, jonka olen kehittänyt monien vuosien aikana ja josta on ollut minulle erittäin hyödyllistä, on asia, jota kutsun ”välitetyiksi määritelmäjoukoiksi”; kuinka tiivistää se GOF-termeillä näyttää olevan kiistanalainen, mutta tämä kysymys, jonka kirjoitin siitä StackOverflow-palvelussa , käsittelee sitä yksityiskohtaisesti.

Peruskäsite on, että osa mallin ominaisuuksista, kuten olentolajit, on asetettu siten, että jokaisella ominaisuuden mahdollisella arvolla on vastaava määritelmäobjekti – yksi, jaettu objekti arvoa kohti -, joka määrittää sen käyttäytymisen , ja niihin pääsee keskusvälittäjän kautta (joka voi GOF: n mukaan olla rekisteri, tehdas tai molemmat). Käytössäni he ovat yleensä päässeet myös skalaarinäppäimillä helpottamaan heikkoa sitoutumista ajonaikaisen morfismin tarkoituksiin.

kommentit

• En näe ' en näe, miten tämä on yksin, ja keskustellessani lentopainokuvio sana " register " on turha. Tämä on vain lentopaino.
• Ymmärsin SO-ketjusta, että ihmiset tunnistivat Singletonin olevan osa sitä luokkiin perustuvien määritelmien takia. Rekisterin osalta en näe ', kuinka se voi olla tarpeeton, kun se voidaan korvata tai yhdistää tehtaaseen.
• -1 siinä määrin kuin se on kuviot ovat nopeaa viestintää, tämä on luultavasti suurin epäonnistuminen, jonka olen nähnyt '. En todellakaan voi ' ottaa tätä kuvausta vakavasti.
• Jeesus, anteeksi, etten ole tarpeeksi evästeiden leikkaaja. Aiotko äänestää myös " entiteettijärjestelmien " vastauksen, koska se ei ole ' tko heti yhteenvetona GOF-termeillä?
• Joitakin määriä " evästeitä, " tai ainakin semanttista selkeyttä , on tarkalleen mitä kuvioiden on oltava hyödyllisiä. Termit, kuten " lentopaino " ja " singleton " koska ne yleisesti ymmärretään, sulkevat toisensa pois. Ensimmäinen koskee tietojen automaattista jakamista useiden instanssien välillä; toisessa on kyse tarkalleen yhdestä instanssista. En ' en sano, että suunnitteluvaihtoehtosi on hyödytön tai edes huono, mutta ahdin " tarpeeksi lähellä " kuvioiden nimet sekoittavat vain enemmän kaikkia. (Älkää <