Come progettare un motore di gioco in un linguaggio orientato agli oggetti? [chiuso]

Ogni volta che provo a scrivere un gioco in qualsiasi linguaggio orientato agli oggetti, il primo problema che devo sempre affrontare (dopo aver pensato a quale tipo di gioco scrivere) è come progettare il motore. Anche se sto usando librerie o framework esistenti come SDL, mi ritrovo ancora a dover prendere determinate decisioni per ogni gioco, come se usare una macchina a stati per gestire i menu, che tipo di classe usare per caricare le risorse, ecc.

Che cos'è un buon design e come verrebbe implementato? Quali sono alcuni compromessi che devono essere fatti e i loro pro / contro?

Dubito che qualcuno sarà in grado di dire "Devi fare questo e quello e questo e questo slot con quel modello X".

Tuttavia, alcune risorse utili:
Enginuity - una serie di articoli per la costruzione di motori su Gamedev.net.
Codifica del gioco completa - Possiedo questo libro e si occupa di tutti gli aspetti (bene, quasi) della programmazione del gioco. Ha anche un motore incorporato in tutto il libro.
Architettura di Game Engine - Questo è un altro grande libro per la progettazione di motori.
Layout del motore C4 - Tratto dal mio commento, ma questo mostra un modo di alto livello di mettere insieme ciascuna parte del motore.

Questi potrebbero essere un po 'troppo per ciò di cui hai bisogno, ma non puoi sapere troppo di qualcosa e sono sicuro che otterrai da loro un buon piano.

EDIT: ho dimenticato che gli articoli di Gamedev sono stati archiviati dal nuovo sito, risolti :)

Ad esempio, ecco come è strutturato il mio attuale progetto roguelike (in Java). Sta usando un motore grafico 2D, quindi gran parte del codice di rendering è già stato curato per me. Le critiche sono ben accette.

class Game
Questa classe imposta la macchina a stati che gestisce lo stato attuale del gioco. (in un menu vs. iniziare una nuova partita vs. giocare una partita salvata)

interface State
Ogni classe State contiene due loop: un loop per l'aggiornamento della logica e un loop per il rendering. Contengono inoltre il codice per chiamare la Gameclasse e richiedere una modifica a uno stato diverso.

class ResourceManager
Un singleton inizializzato dalla Gameclasse che carica tutte le risorse necessarie e consente l'accesso ad esse. Non mi piace questo design perché rende difficile caricare / scaricare risorse su diversi livelli, ad esempio. Probabilmente lo progetterei diversamente se dovessi ricominciare da capo.

class Map
Una mappa contiene una serie di tessere e un elenco di tutte le creature e gli oggetti sulla mappa. È una classe piuttosto semplice.

class Creature
Le creature contengono informazioni su se stesse, inclusi i calcoli del movimento (che richiedono loro di sapere in quale mappa si trovano e di essere in grado di interrogarle per scoprire gli ostacoli). Decidere se farlo, o fare in modo che un qualche tipo di manager si prenda cura di lui per tutte le creature è qualcosa con cui faccio fatica.

interface AITask
Le creature possono avere un elenco di AITask, che vengono eseguiti ogni volta che viene eseguito il ciclo logico della creatura. L'AITask ha il suo circuito logico che impartisce comandi alla creatura e una condizione di terminazione che determina se l'attività è stata completata con successo o no.

interface UIElement
Ho implementato la mia interfaccia utente per questo motore. Ogni UIElement ha un loop di rendering e un loop logico. Hanno anche un ciclo per l'elaborazione dell'input da tastiera / mouse. Tutti gli elementi possono avere un numero di elementi figlio, che sono resi dopo i loro genitori, e assumono l'input da tastiera / mouse. Ciò consente di avere menu con sottomenu, ad esempio.

Il primo punto importante da sottolineare è che non esiste una risposta "buona" a questa domanda.

La cosa più vicina a una risposta giusta sarebbe qualcosa del genere: dipende molto dal tipo di gioco, dalla piattaforma target, dai vincoli (tempo) ecc.

Detto questo, ci sono alcuni articoli davvero validi là fuori che ti mostreranno come altre persone hanno cercato di rispondere a questo problema (come ho cercato di trovare informazioni su questo in passato).
Mentre The duck comunista menzionava l' articolo sull'ingegnosità sul game dev mi ha aiutato a capire alcune parti dell'architettura di gioco.

Il mio progetto attuale è un ibrido di Quake3 / Doom3 e un po 'della libreria di classi .NET :)

Ho due librerie (statiche o dinamiche dipende da come vuoi costruire / consegnare) Frameworke Library.

La libreria contiene tutte le classi di aiuto che sono lì per aiutare con la produzione di software di gioco ma non sono limitate a questo tipo di prodotto. cioè ha un'implementazione di un elenco collegato che è ottimizzato per il codice di gioco ma potrebbe essere utilizzato da tutto ciò che necessita del servizio di un elenco collegato.

Il Framework è il coraggio del "motore" se vuoi chiamarlo così. Molto di questo segue le filosofie progettuali di Quake3 (solo in un modo più orientato agli oggetti). Contiene l' interfaccia della riga di comando , la gestione dei tempi, il codice specifico del sistema operativo e infine i livelli di rete ecc.

Questi due sono quindi collegati all'app effettiva che viene prodotta. Il Gamese volete, che contiene il codice di gioco specifico. Allo stesso modo, Quake3 carica le DLL in base a quale 'mod' viene riprodotto.

Per darti un'idea della struttura, ecco una rapida suddivisione di cartelle e contenuti per ogni lib:

• Struttura
  • IO (classi di gestione file specializzate, classi di stampa di testo (ad es. Alla CLI) e registrazione ecc.)
  • Rete
    • Cliente (classi che rappresentano ciò che il Framework considera una "persona che gioca / è connessa al gioco")
    • Server (classi per gestire la connessione nel framework e gestire i giocatori)
  • Piattaforma (tastiera / mouse / controller che gestiscono classi, routine specifiche del sistema operativo come getTime ())
  • Sistema (classi di livello molto basso come una classe di errore per facilitare la stampa di messaggi di errore, classi di temporizzazione e CLI stessa.)
  • Renderer (autoesplicativo)
  • eccetera.

• Biblioteca
  
  • Collezioni (classi che rappresentano raccolte di dati, liste / hashtabili collegati ecc.)
  • Matematica (lezioni di base di matematica come vettori e matrici)
  • eccetera.

HTH! Dovresti darti alcuni suggerimenti ...

Cose da considerare

• I linguaggi orientati agli oggetti hanno problemi perché di solito non hanno funzioni di prima classe o non tutti i dati sono oggetti (come numeri interi o float in Java). I motivi di progettazione risolvono questi problemi con diversi motivi. Generalmente è più veloce da programmare e più facile da usare usare un linguaggio che li possa fare (oggetti di prima classe); ad esempio Python (che consente anche la progettazione orientata agli oggetti), avrai una velocità più lenta.
• Event Calculus, almeno per AI
• Hoare la logica, utilizzare precondizioni e postcondizioni per testare almeno il tuo codice
• Agenti, guardate le entità di Quake
• Database relazionali, un modo efficace per archiviare i dati

Buon design

• fare diagramma ER
• renderlo corretto
• crea il tuo database, oggetti o strutture di dati da esso

I dati sono fondamentali per la programmazione. Se desideri che i tuoi dati siano validi, l'algoritmo di solito emerge da essi (se non conti alcuni algoritmi numerici, come il determinante di calcolo).