Melyek azok a programozási tervezési minták, amelyek hasznosak a játékfejlesztésben? [zárt]

Írtam egy könyv pontosan erről a témáról: Játékprogramozási minták . Az ott található fejezetek hasznosak lehetnek az Ön számára.

Megjegyzések

• +1 Reméltem, hogy valaki linkelt ehhez, és úgy látom, hogy a szerző van! Az ott található komponensminta leírása nagyon hasznos volt, és tetszik, hogy megpróbál teljes kódpéldákat használni a bemutatáshoz.
• Igen – emlékszem, hogy néhány évvel ezelőtt olvastam a linket. Be kell fejezned ezeket a cikkeket!
• Most elkészült a könyv 🙂
• Egy csodálatos forrás, amely segített abban, hogy meglévő programozási ismereteimet a játékok programozásába fordítsam. Köszönöm, hogy megírta!
• A játékprogramozási mintáknak ez a magyarázata valóban segített abban, hogy megértsem a – tervezési mintákat – oly módon, amit egyetlen szoftvertervezési mintakönyv sem tett meg! Ez részben a játékfejlesztés ereje (konkrét példák egy olyan nyelven, amely velem beszél és lehetővé teszi számomra a fejlődésem általános javulását), de nagyobb részben azért, mert az írás olyan kiváló.

Egy dolgot Brandon Eichnek jó esze volt felhozni a kódolókban a munkahelyen az, hogy a minták feltörések és megoldások: a [Patterns] valamiféle hibát mutat a nyelvben. Ezek a minták nem szabadok. Nincs ingyen ebéd. Tehát arra a nyelvre kell keresnünk az evolúciót, amely hozzáadja a megfelelő biteket.

Játékprogramozókként és fordítótervezőként ritkán kapunk lehetőséget a nyelvek fejlesztésére. használjuk, de megtanulhatjuk saját stílusunk kialakítását, hogy jobban illeszkedjen nyelvünkhöz és követelményeinkhez. A minták ezek, de a másik rész a nem minták használata , főleg, hogy mint Brandon mondja, a minták ritkán mennek figyelemre méltó teljesítmény, memória vagy kód agilitási költség nélkül. Az MVC egyszerűen nem nagyszerű minta sok dologban a játékokban. A Singleton megkerüli a béna C ++ statikus inicializálási szabályokat, és valószínűleg úgysem kellene ezeket megtenni. A gyár leegyszerűsíti a bonyolult objektumok létrehozását – lehet, hogy az objektumainak csak egyszerűbbnek kell lenniük a kezdéshez. A népszerű minták olyan eszközök, amelyek amikor szükségünk van rájuk ahhoz, hogy valami komplexumot kezeljünk, nem pedig olyan eszközök, amelyek használatával vágynunk kellene arra, hogy kezdetben valami komplexet építsünk.

A jó (játék) kód használhat mintákat, vagy nem. Ha mégis mintákat használ, akkor remek – nagyszerű kommunikációs eszköz, amely magas, nyelvfüggetlen szinten magyarázza el a kódstruktúrát más programozóknak. Ha úgy gondolja, hogy a kód jobb mintázat használata nélkül, akkor ne verje át magát ez – valószínűleg így van.

Kommentárok

• Igen, az eredeti könyvben egyértelművé tett (de gyakran figyelmen kívül hagyott) dolgok egyike az, hogy ha C-re írták, nem pedig a C ++ / Smalltalk-ra, lehet, hogy tartalmaztak egy " Öröklés " mintát, és ugyanezzel a jelzővel néhányat a nyelvek tartalmazhatnak néhány már beépített GoF mintát.
• A másik dolog, amelyet az eredeti könyvben gyakran elhanyagoltak (Alexander eredeti könyve, nem a GoF), az volt, hogy a minták a kommunikáció eszközei és nem megvalósítás . Lehetővé teszik a tervezők számára, hogy magasabb szintű kommunikációt folytassanak a megvalósításról, és azért azonosítják őket, mert ezek ismétlődnek, nem feltétlenül azért, mert lehetőség szerint használniuk kellene őket. ismerje fel, ha egy ilyen megközelítés jó megoldás.A legjobb mintákat általában idővel finomították képzett és tapasztalt munkavállalók, és a kevésbé képzett munkavállalók nem fedeznék fel ugyanazokat a mintákat anélkül, hogy lennének ezek a kodifikált példák.
• Egyetértek azzal, hogy a terminológia nagyon jó, és a minta definíciójának része, hogy jó probléma visszatérő megoldás. Sajnos a kevésbé képzett munkavállalók általában Singletont találják, és alkalmazzák minden problémára, még akkor is, ha még nincs probléma.
• Köszönöm ezt a választ; Megkönnyebbülten olvasom, hogy a tervezési mintát a szoftver ' szoftver által okozott problémák megoldására tervezték. Úgy gondolom, hogy egy egész nagy szoftver felépítését átgondolni kell az elejétől a végéig, mielőtt bármit is elkezdene kódolni. ' nem mindig tudja egyszerre megvalósítani a funkciókat, néha át kell gondolni az egyes funkciókat, és ellenőrizni kell, hogy nyert-e ' Ne keveredjen a szoftver globális felépítésével, vagy csak akadályozza meg a szoftver viselkedését. A feladatok több programozóra történő felosztása néha ellentmondásokat okozhat …

Természetesen, ahogy mások mondták , minden minta hasznos a megfelelő körülmények között, és a használatuk megtanulásának része annak megtanulása, hogy mikor kell használni őket. Daniel Sanchez-Crespo Dalmau kiváló könyve A játékprogramozás alapvető technikái és algoritmusai azonban hat programozási mintát és hat használhatósági mintát sorol fel mint különösen hasznos a játék programozásában.

Programozás:

• Singleton: Nem utálom ezt, mint sokan; használható olyan dolgokra, mint az egy- lejátszó vagy a billentyűzet olvasó.
• Gyár: Lehetővé teszi az objektumok hatékony létrehozását és megsemmisítését.
• Stratégia: Lehetővé teszi az AI stratégiák elegáns megváltoztatását.
• Térmutató : Segít lekérdezéseket végrehajtani a téradatkészleteken.
• Kompozit: Hasznos objektum-heirarchiát állít be.
• Légsúly: Megszabadítja a memóriát azáltal, hogy olyan dolgokat generál, mint az azonos ellenségek.

Használhatóság:

• Pajzs: Véd a drámai cselekedetek véletlen aktiválódásától.
• Állapot: A világ / felhasználói felület állapotának vizuális jelzései.
• Automatikus mód törlése: A játék intutitívabb működésre készteti.
• Mágnes ism: Autoaiming és egyszerű egységválasztás.
• Fókusz: A zavaró felhasználói felület elemeinek kiküszöbölése.
• Haladás: Egyetemesen hasznos.

A könyv természetesen , ezek mindegyikét részletesebben bemutatja.

Megjegyzések

• Köszönjük a hozzászólást! Nem tudtam erről a könyvről, de a bejegyzés eredményeként most megvizsgálom. Még egyszer köszönöm!
• A Singleton a billentyűzetolvasónak pontosan olyan helyzet, amikor fel kell tennem a kérdést – Tényleg nem csak globális mutatóvá teheti a fő funkciójának elején Tényleg véletlenül példányosítottál két billentyűzet-olvasót?
• Kérlek, utáld a szingulettet. Két dolgot rosszul csinál. Globális hozzáférés és aritás. A fejlesztők gyakran azt gondolják, hogy a globális hozzáférés == szinglik. Nagyon kevés probléma van, mint amennyire igazi szingulettre van szükség, és esetleg még néhány, amelyek elegánsabbak, ha szingulettel megoldják őket.

Az entitásrendszerek egy szépfajta minta. Ez nem éppen tervezési minta, mivel nem szigorúan OOP. Keverheti azonban az OOP-val.

Néhány jó link (az intro elejétől kezdve indul):

• 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

megjegyzések

• " Ez ' nem éppen tervezési minta, mivel ' s nem szigorúan [sic] OOP. " A tervezési mintáknak semmi közük az OOP-hoz; ha van valami, maga az OOP is egy tervezési minta. A tervezési minták nemcsak az OOP-n kívül, hanem a szoftverfejlesztésen kívül is teljes egészében megjelennek.
• Vannak OOP design patterns, amelyek általában az osztályok / objektumok közötti kapcsolatokat és interakciókat mutatják be. És sok más tervezési minta is létezik. Az OOP egy sor fogalom, nem pedig egy minta. A Design pattern is fogalom.
• A szemantikáról való beszéd helyett nem ' t kell értékelnie a az általam adott válasz?

Mindegyik. Kivéve Singletont. [/ flippancy]

Megjegyzések

• Nevezhetne esetleg egy vagy két tervezési mintát, amelyet ' Gyakran használtad játékfejlesztésed során, és miért?Kezdőként a tervezési minták tekintetében " mindegyik " nem különösebben hasznos válasz. Köszönjük, hogy válaszoltál.
• " megkérdezése, milyen mintákat használtál? " olyan, mint a " milyen változóneveket használtál? " Ez a személyes stílusra, követelményekre és tartományra vonatkozik. Valamikor valószínűleg bármilyen olyan mintát használ, amelyet ' valaha is megneveztek. Valószínűleg még sok mást fog használni, amelyek még nem kerültek megnevezésre, és talán még újakat is kitalál.
• @ jcurrie33: Sajnálom, nem tudtam ' ellenállni annak, hogy előbb egy szingliknél ásni. 😉

Nem igazán a mintákról, hanem a mögöttük álló alapelvekről. A “Tervezési minták: az újrafelhasználható objektumorientált szoftver elemei” (1995) részben a négytagú banda (Gamma, Erich; Richard Helm, Ralph Johnson és John) Vlissides) csak két alapelvet javasol az objektumorientált tervezéshez: (1) programot egy interfészhez, nem pedig egy megvalósításhoz és (2) előnyben részesíti az objektumkompozíciót az osztályörökléssel szemben.

Ez a 2 elv nagyon hasznos a játék számos feladatában fejlődés. Például sok játékprogramozó mély osztályhierarchiát használt a játék entitások ábrázolására. Van egy másik megközelítés, amely a kompozíció – komponens alapú játékobjektumokon alapul. Cikk erről a megközelítésről. Még több link . Ez egy dekoratorminta példa.

Megjegyzések

• A a játékterv inkább hasonlít egy állapotszerű stratégiai mintához – ami természetesen a C / C ++ / Java / C # kívüli bezárásokként és azokon belüli összetevő objektumokként fejeződik ki. A díszítő minta inkább egy proxy; tulajdonjoga és adatáramlása ellentétes azzal, amire általában úgy gondolunk, amikor a játékok alkatrészrendszereiről beszélünk.
• Az alkatrészeknek szintén beszélniük kell egymással, olyan mintákat hozva be, mint a közvetítő, a megfigyelő és a zeneszerző. A " Komponensalapú játék " önmagában egy összetett tervezési minta.
• @CodexArcanum, Observer, definetely , de nem mindig közvetítő (helyettük a felelősség láncát is lehet használni). Csak akkor zeneszerző, ha a GameObject (amely a GameObjectComponentből áll) maga a GameObjectComponent (nem szükséges).

A furcsán visszatérő sablonminta valóban hasznos lehet a virtuális módszerek és a virtuális függvényhívásokból eredő teljesítménybüntetések elkerülése érdekében.

Ez akkor lehet a megfelelő minta, ha valójában nem kell rendelkeznie egy olyan alaposztály típusú tárolóval, amelynek a felülete van, amelyet Ön követ, de hasonlóan megnevezett viselkedéseket és interfészeket szeretne.

Például ezt akkor használhatja, amikor osztályokat állít össze több platformra vagy motorra (dx vs. opengl), ahol a típus szórása ismert a fordítás idején.

Megjegyzések

• Mindig utáltam, hogy az os absztrakciós réteg virtuális volt. ' nem tetszik neked, hogy te ' mindig szükséged lesz két os absztrakcióra rétegek. Sokkal jobb a CRTP használata.
• M aybe I ' m csak öreg, de még ' nem is használnék CRTP-t DX / OpenGL vagy platform interfészekhez. ' túl lassú a fordításhoz – én ' csak typedef-eket használok. A CRTP akkor jó, ha meg szeretné osztani az interfészeket és megvalósításokat az osztályok között, de nincs más kapcsolata, és nem akkor, amikor csak egyik vagy másik struktúrát akarja kiválasztani.

Az a tervezési minta, amelyet hosszú évek alatt alakítottam ki, és amely számomra látványosan hasznos volt, olyan dolog, amelyet “közvetített definíciókészletekként” emlegetek; hogyan lehet összefoglalni GOF-kifejezésekkel, ellentmondásosnak tűnik, de ez a kérdés, amelyet a StackOverflow-n írtam róla, részletesen ismerteti.

Az alapkoncepció az, hogy a modell bizonyos tulajdonságait, mint a lény fajait úgy állítják be, hogy a tulajdonság minden lehetséges értékének megfelelő definíciós objektum legyen – értékenként egyetlen, közös objektum -, amely meghatározza a viselkedését , és ezekhez egy központi brókeren keresztül férhet hozzá (amely GOF szempontból lehet nyilvántartás, gyár vagy mindkettő). Használatomban általában skaláris billentyűkön keresztül is elérik őket, hogy megkönnyítsék a futásidejű morfizmus céljából történő gyenge kötést.

Megjegyzések

• Nem látom ', hogy egyáltalán hogyan látom ezt a szingletet, és amikor megvitatom a légsúlyos minta, a " registry " szó felesleges. Ez csak légsúlyos.
• Az SO szál alapján megértettem, hogy az emberek Singletont azonosították részeként az osztályként felállított meghatározások miatt. Ami a Registry-t illeti, nem látom, hogy ' hogyan lehet felesleges, ha helyettesíthető vagy kombinálható a gyárral.
• -1, olyan mértékben a minták a gyors kommunikációról szólnak, valószínűleg ez a legnagyobb kudarc, amelyet <