2009-05-14 17 views

risposta

5
  • Composito per fare tutto per passaggio di aggiornamento (ad esempio rendering) (Ed effettivamente comune tra tutte le librerie UI).
  • mosca per disegnare molti dello stesso tipo di elemento sullo schermo (alberi/cespugli/proiettili)
  • Observer per un sacco di librerie UI (di nuovo, non gioco specifico)
  • Stato per la transizione tra gioco/menù/console/pausa/etc. states
  • Fabbrica astratta in alcuni tipi di giochi beat-em-up per la creazione di mob/NPC (i giochi con quantità ridicole di personaggi IA alla volta, ad esempio Left 4 Dead).
  • Strategia per l'euristica di scambio in algoritmi di ricerca del percorso come A *
  • modifica> Comando per giochi come MMO che hanno una barra di azione con pulsanti intercambiabili su cui è possibile fare clic per lanciare incantesimi e quant'altro.

Questo è tutto ciò che posso pensare di vedere adesso.

0

Le variazioni sul modello di stato sono utili per modellare lo stato del gioco. Lo Enginuity series of articles è una buona panoramica di alcuni degli aspetti di basso livello del design dei motori di gioco. È incompleto, ma buono. I progettisti del framework Guff outlined the use of state hierarchies per la gestione dello stato del gioco. Il concetto di gerarchia è buono, sebbene la loro visione di uno stato di gioco sia limitata (comprende l'intero ciclo di gioco invece del solo stato). Hanno anche un paper on real-time game loops.

Quando si implementa lo scripting, è estremamente utile e potente per utilizzare un linguaggio di scripting che supporti una sorta di multithreading cooperativo. Stackless Python offre questo. Dal momento che Mono 2.6, si can do this in C# using continuations, ma solo sulla piattaforma Mono (non. NET), in quanto ha richiesto modifiche alla VM.

Esistono soluzioni comuni per grafica 2D e 3D, animazione, input, ecc. Molti di questi sono gestiti da DirectX, SDL o framework simili.

1

Non penso che esistano modelli di progettazione software specifici per il gioco. I giochi utilizzano gli stessi linguaggi, librerie, piattaforme come tutti gli altri e affrontano praticamente gli stessi problemi a livello di software.

Esistono alcuni metodi o approcci che sembrano essere popolari, ma che non sono formalizzati a livello di codice nel modo in cui i modelli di progettazione classici sono. Un esempio sono gli attori basati su componenti, spesso non aggregati nello stesso oggetto ma tramite la condivisione di un ID, che comunica tramite un meccanismo di tipo segnali/slot. Un altro sarebbe l'incorporamento di una seconda lingua per scopi di scripting, come Lua, Python o Javascript.

+0

Sto davvero cercando alcuni schemi architettonici generali, ad esempio come organizzare tutte le diverse componenti del gioco in qualcosa che sia comprensibile e mantenibile da un livello elevato. Qualcosa come l'equivalente di sviluppo del gioco di un'architettura di tipo MVC o un'architettura a strati. –

+2

Non esistono, ho paura! Questo tipo di domande viene ripetutamente visualizzato su GameDev.netto ma in realtà non esiste un approccio standard o qualcosa che assomigli a uno. Tutto ha un ciclo input-update-render/output, e spesso c'è un sistema di stato del gioco simile a quello descritto da Matt Olenik, ma oltre a questo, è una disposizione ad-hoc di vari sistemi e pattern su piccola scala. Potrei dare qualche consiglio, ma mentirei se affermassi che i miei suggerimenti erano "comuni". – Kylotan

1

Ho trovato this PDF dettagli architetture di gioco possibili. Sebbene, potrebbe essere "spiacevole per i lettori che sono più inclini a pensare in termini di design orientato agli oggetti".

Problemi correlati