Răspundeți
Acum pentru un răspuns mai puțin strălucitor, cu câteva sugestii. Nu le luați ca recomandări de implementare, mai mult ca exemple de utilizare posibilă.
- Generator: configurați o entitate bazată pe componente, o componentă pe rând, pe baza datelor
- Metoda din fabrică: creați NPC-uri sau widget-uri GUI pe baza unui șir citit dintr-un fișier
- Prototip: stocați un caracter generic „Elf” cu proprietăți inițiale și creați instanțe Elf clonându-l.
- Singleton: acest spațiu a fost lăsat în mod deliberat gol.
- Adaptor: încorporează o bibliotecă opțională de la o terță parte, înfășurând-o în un strat care seamănă cu codul dvs. existent. Foarte util cu DLL-urile.
- Compozit: creați un grafic de scenă cu obiecte redabile sau creați o interfață grafică dintr-un arbore de widgeturi
- Fațadă: simplificați bibliotecile complexe de la terți oferind o interfață mai simplă pentru a vă face viața mai ușoară mai târziu.
- Flyweight: stocați aspectele comune ale unui NPC (de exemplu, modele, texturi, animații) separat de aspectele individuale (de exemplu. poziție, sănătate) într-o mai ales transparent
- Proxy: creați clase mici pe un client care reprezintă clase mai mari și mai complexe pe un server și redirecționați cereri prin rețea.
- Lanț de responsabilitate: gestionați intrarea ca un lanț de manipulatori, de ex. tastele globale (de exemplu, pentru capturi de ecran), apoi interfața grafică (de exemplu, în cazul în care o casetă de text este focalizată sau un meniu este activat), apoi jocul (de exemplu, pentru mutarea unui personaj)
- Comandă: încapsulează funcționalitatea jocului ca comenzi care pot fi introduse într-o consolă, stocate și redate sau chiar scriptate pentru a ajuta la testarea jocului
- Mediator: implementează entități de joc ca o mică clasă de mediator care funcționează pe diferite componente (de ex. citirea din componenta de sănătate pentru a transmite datele către componenta AI)
- Observator: să aibă reprezentarea redabilă a unui personaj să asculte evenimentele din reprezentarea logică, pentru a schimba prezentarea vizuală atunci când este necesar fără logica jocului care trebuie să știe ceva despre codul de redare
- Stare: stocați NPC AI ca una dintre mai multe stări, de ex. Atac, Rătăcire, Fugire. Fiecare poate avea propria sa metodă update () și orice alte date de care are nevoie (de exemplu, stocarea de care personaj atacă sau care fuge, zona în care rătăcește etc.)
- Strategie: comutați între euristică diferită pentru căutarea dvs. A *, în funcție de tipul de teren în care vă aflați, sau poate chiar pentru a utiliza același cadru A * pentru a face atât căutare de trasee, cât și planificare mai generică
- Metodă șablon: configurați un rutină generică de „luptă”, cu diferite funcții de cârlig pentru a face față fiecărui pas, de ex. diminuarea muniției, calcularea șansei de lovire, rezolvarea loviturii sau ratării, calcularea daunelor și fiecare tip de abilitate de atac va implementa metodele în propriul lor mod specific
Unele tipare au fost lăsate deoparte din cauza lipsei de inspirație.
Comentarii
Răspuns
Răspuns
Un lucru pe care Brandon Eich a avut bunul simț să îl aducă în Codificatori la locul de muncă este că modelele sunt hacks și soluții alternative: [Patterns] arată un fel de defect în limbă. Aceste tipare nu sunt gratuite. Nu există prânz gratuit. Așa că ar trebui să căutăm evoluția în limbajul care adaugă biții corecți.
Ca programatori de jocuri, nu ca designeri de compilatoare, rareori avem opțiunea de a evolua limbile. folosim, dar putem învăța să ne dezvoltăm propriul stil pentru a ne potrivi mai bine limbajului și cerințelor noastre. Modelele sunt unele dintre acestea, dar nu folosi modele este o altă parte, mai ales că, după cum spune Brandon, modelele rareori merg fără o performanță notabilă sau o memorie sau un cost de agilitate a codului. MVC nu este un model excelent pentru multe lucruri din jocuri. Singleton este o soluție pentru regulile de inițializare statică C ++ lame și probabil că nu ar trebui să le faceți oricum. Fabrica simplifică crearea complicată a obiectelor – poate că obiectele dvs. ar trebui să fie mai simplu pentru început. Modelele populare sunt instrumente la care să recurgem atunci când avem nevoie de ele pentru a gestiona ceva complex, nu instrumente pe care ar trebui să le dorim să le folosim pentru a construi ceva complex la început.
Un cod bun (de joc) poate folosi modele sau nu. Dacă folosește tipare, bine – sunt „un instrument excelent de comunicare pentru a explica structura codului altor programatori la un nivel ridicat, independent de limbă. Dacă credeți că codul este mai bun fără a utiliza un model, nu vă bateți peste cap it – probabil că este.
Comentarii
Răspuns
Desigur, așa cum au spus alții , toate tiparele sunt utile în circumstanțele potrivite, iar o parte din învățarea cum să le folosești este să înveți când să le folosești. Cu toate acestea, cartea excelentă Core Techniques and Algorithms in Game Programming de Daniel Sanchez-Crespo Dalmau, listează șase modele de programare și șase modele de utilizare la fel de util în programarea jocurilor.
Programare:
- Singleton: Nu-l urăsc așa cum o fac mulți oameni; poate fi folosit pentru lucruri precum single- player player sau cititorul de tastatură.
- Fabrică: vă permite să creați și să distrugeți obiecte în mod eficient.
- Strategie: vă permite să schimbați elegant strategiile AI.
- Index spațial : Ajută la efectuarea de interogări cu privire la seturi de date spațiale.
- Compozit: configurează o moștenire de obiecte utile.
- Greutate zburătoare: eliberează memoria generând lucruri precum dușmani identici.
Utilizare:
- Scut: protejează împotriva activării accidentale a acțiunilor dramatice.
- Stare: indicii vizuale ale lumii / statutul interfeței.
- Anulare mod automat: face ca jocul să funcționeze mai intuitiv.
- Magnet ism: Autoaiming și selecție ușoară a unităților.
- Focus: Eliminarea elementelor distractive ale interfeței de utilizare.
- Progres: util universal.
Cartea, desigur , intră în mai multe detalii despre fiecare dintre acestea.
Comentarii
Răspuns
Sistemele de entități sunt un tip frumos de tipar. Nu este tocmai un model de design, deoarece nu este OOP strict. Cu toate acestea, îl puteți amesteca cu OOP.
Câteva legături bune (începeți de sus pentru introducere):
Comentarii
Răspuns
Toate. Cu excepția lui Singleton. [/ flippancy]
Comentarii
Răspuns
Nu chiar despre tipare, ci despre principiile de bază din spatele lor. În „Design Patterns: Elements of Reusable Object-Oriented Software” (1995) , banda celor patru (Gamma, Erich; Richard Helm, Ralph Johnson și John Vlissides) recomandă doar două principii pentru proiectarea orientată pe obiecte: (1) program pentru o interfață și nu pentru o implementare și (2) favorizează compoziția obiectului în locul moștenirii clasei.
Aceste 2 principii sunt foarte utile în multe sarcini ale jocului dezvoltare. De exemplu, mulți programatori de jocuri au folosit o ierarhie de clase profundă pentru a reprezenta entitățile de joc. Există o altă abordare bazată pe compoziție – obiecte de joc bazate pe componente. Articol despre această abordare. Chiar și mai multe linkuri . Este un exemplu de model Decorator .
Comentarii
Răspuns
model șablon curios recurent poate fi cu adevărat util pentru evitarea metodelor virtuale și a penalizării de performanță care pot proveni din apelurile funcției virtuale.
poate fi modelul adecvat atunci când nu trebuie să aveți un container de tipul clasei de bază care să aibă interfața pe care o căutați, dar doriți să aveți comportamente și interfețe numite în mod similar.
De exemplu, puteți utiliza acest lucru atunci când compilați clase pentru mai multe platforme sau motoare (dx vs. opengl) în care varianța de tip este cunoscută la compilare.
Comentarii
Răspuns
Un model de proiectare pe care l-am dezvoltat de-a lungul mai multor ani și care mi-a fost spectaculos de util, este ceva la care mă refer ca „seturi de definiții intermediate”; cum să o rezumăm în termeni GOF pare a fi controversată, dar această întrebare pe care am scris-o despre aceasta pe StackOverflow intră în detaliu despre aceasta.
Conceptul principal este că unele proprietăți ale unui model, cum ar fi speciile unei creaturi, sunt configurate astfel încât fiecare valoare posibilă a proprietății să aibă un obiect de definiție corespunzător – un obiect unic, partajat per valoare – care îi specifică comportamentul , iar acestea sunt accesate printr-un broker central (care, în funcție de GOF, poate fi un registru, o fabrică sau ambele). În uzul meu, acestea sunt, de asemenea, accesate în general prin intermediul tastelor scalare, pentru a facilita legarea slabă în scopuri de morfism în timpul rulării.
Comentarii