Chiamate di funzione per fotogramma rispetto alla messaggistica guidata dagli eventi in Game Design

Il design del gioco tradizionale , per quanto ne so, utilizza il polimorfismo e le funzioni virtuali per aggiornare gli stati degli oggetti di gioco. In altre parole, lo stesso set di funzioni virtuali viene chiamato a intervalli regolari (es: per frame) su ogni oggetto nel gioco.

Di recente, ho scoperto che esiste un altro sistema di messaggistica guidato da eventi disponibile per aggiornare gli stati degli oggetti di gioco. Qui, gli oggetti di solito non vengono aggiornati in base al fotogramma. Invece, viene creato un sistema di messaggistica di eventi altamente efficiente e gli oggetti di gioco vengono aggiornati solo dopo aver ricevuto un messaggio di evento valido.

Event Driven Game Architecture è ben descritta in: Codifica di gioco completa di Mike McShaffry .

Potrei chiedere aiuto per le seguenti domande:

• Quali sono i vantaggi e gli svantaggi di entrambi gli approcci?
• Dov'è uno migliore rispetto all'altro?
• Il design dei giochi Event driven è universale e migliore in tutte le aree? È quindi raccomandato per l'uso anche su piattaforme mombili?
• Quale è più efficiente e quale è più difficile da sviluppare?

Per chiarire, la mia domanda non riguarda la rimozione completa del polimorfismo dal design di un gioco. Desidero semplicemente comprendere la differenza e trarre vantaggio dall'utilizzo della messaggistica guidata dagli eventi rispetto alle normali chiamate (per frame) alle funzioni virtuali per aggiornare lo stato del gioco.

Esempio: questa domanda ha suscitato un po 'di controversie qui, quindi lasciatemi offrire un esempio: secondo MVC, il motore di gioco è diviso in tre parti principali:

1. Livello applicazione (comunicazione hardware e SO)
2. Logica di gioco
3. Vista di gioco

In un gioco di corse, la Vista di gioco è responsabile del rendering dello schermo il più rapidamente possibile, almeno 30 fps. Game View ascolta anche l'input del giocatore. Ora questo succede:

• Il giocatore preme il pedale del carburante all'80%
• GameView costruisce un messaggio "Car 2 Fuel Pedal Pressed to 80%" e lo invia a Game Logic.
• Game Logic riceve il messaggio, valuta, calcola la posizione e il comportamento della nuova auto e crea i seguenti messaggi per GameView: "Disegna pedale carburante auto 2 premuto 80%", "Accelerazione suono auto 2", "Coordinate auto 2 X, Y" .. .
• GameView riceve i messaggi e li elabora di conseguenza

Sono un convinto sostenitore della necessità di essere la madre dell'invenzione. Non mi piace codificare nulla a meno che il suo bisogno sia chiaro e ben definito. Penso che se avvii il tuo progetto impostando un sistema di messaggistica per eventi, lo stai facendo male. Credo che solo una volta che avrai creato e testato la tua infrastruttura e avrai tutti i pezzi del tuo progetto come moduli ben definiti e funzionanti, dovresti concentrarti su come connetterli tra loro. Cercare di progettare un sistema di messaggistica degli eventi prima di comprendere la forma e le esigenze di ciascun modulo è fuori servizio.

Quali sono i vantaggi e gli svantaggi di entrambi gli approcci?

Penso che alcune persone sosterrebbero che ci sono buoni sistemi di messaggistica là fuori pronti per essere installati e utilizzati. Forse è vero. Certamente le prestazioni di una soluzione su misura specificamente adattata alle tue esigenze sarebbero maggiori di un bus di messaggi per tutti gli usi. La grande domanda è: quanto tempo impiegherai a costruire un sistema di messaggistica piuttosto che usare qualcosa che è già stato costruito. Ovviamente, se riuscissi a trovare una sorta di sistema di eventi con esattamente il set di funzionalità di cui hai bisogno, allora è una decisione abbastanza semplice. Questo è il motivo per cui mi assicuro di aver capito esattamente di cosa ho bisogno prima di prendere quella decisione.

Dov'è uno migliore rispetto all'altro?

Potremmo parlare di memoria e risorse qui. Se stai sviluppando per qualsiasi hardware con risorse limitate, è certamente un problema utilizzare un sistema di eventi che lo taglierà in modo significativo. In realtà, tuttavia, penso che il problema sia dovuto a ciò di cui hai bisogno, che come ho già detto è qualcosa che non conosci fino a quando non vedi come appaiono tutti i pezzi. Se hai abbastanza esperienza nella costruzione di questi sistemi che conosci in anticipo esattamente come appariranno tutti i pezzi, allora puoi anche rispondere a questa domanda in anticipo. Immagino che tu non abbia questa esperienza, dal momento che non lo faresti se lo facessi.

Il design dei giochi Event driven è universale e migliore in tutte le aree? È quindi raccomandato per l'uso anche su piattaforme mobili?

Universale e migliore in tutti i settori? Un'affermazione piuttosto generosa come quella viene facilmente respinta. Tutto ciò che aggiunge sovraccarico deve portare la sua quota del carico di lavoro. Se non stai usando abbastanza eventi per giustificare il sovraccarico del design, allora è il design sbagliato.

Quale è più efficiente e quale è più difficile da sviluppare?

L'efficienza dipende da come è stata implementata. Penso che un design tradizionale ben sviluppato supererà un sistema basato su eventi in qualsiasi giorno della settimana. Questo perché la comunicazione tra i pezzi può essere micro-gestita e resa super efficiente. Naturalmente, ciò rende anche più difficile progettare dal punto di vista dell'esperienza e del tempo necessario per completarlo e renderlo più efficiente. D'altra parte, se ti manca questa esperienza o non hai il tempo di sviluppare bene l'applicazione, allora sarà più efficiente utilizzare un design basato su eventi adatto alle tue esigenze. Se hai esigenze di eventi personalizzati che non si adattano facilmente a una struttura basata su eventi, ciò potrebbe rendere la struttura basata su eventi molto difficile da progettare, soprattutto per mantenere efficiente la progettazione.

Penso che tu stia confrontando mele e arance qui. Il polimorfismo non è affatto sostituito dalla messaggistica. Probabilmente vorrai che eventi / messaggi colleghino componenti debolmente accoppiati. Per esempio. per inviare un messaggio da un'entità quando si verifica una collisione, per aggiornare il punteggio del giocatore o forse per attivare un effetto sonoro. In modo che queste singole classi non conoscano le altre classi e inviino e / o gestiscano i messaggi.

Ma il vostro gioco è molto probabilmente avrà un qualche aggiornamento loop e dal momento che si dispone di quel ciclo di aggiornamento, può essere facilmente utilizzato per aggiornare tutte le entità di gioco che devono essere aggiornati ogni fotogramma pure. Questo non ti impedisce di usare la messaggistica però ...

Se hai una sorta di struttura in cui aggiungi / rimuovi entità di gioco, puoi anche includerle nel tuo ciclo di aggiornamento invece di inviare loro un messaggio di aggiornamento in ogni frame. Quindi perché non chiamare l' aggiornamento sulle entità di gioco direttamente mentre si utilizza la messaggistica per connettere diversi sottosistemi del gioco? Mi piace anche il concetto di segnale / slot ( vedi esempio qt ) per sistemi simil-evento.

In conclusione: non esiste un approccio migliore, né sono esclusivi.

Questo è iniziato come un commento alla risposta di bummzack, ma è diventato lungo.

A meno che non lo rendiate effettivamente asincrono (invio di eventi su un nuovo thread), i vostri oggetti continuano a ricevere il promemoria in modo sincrono. Supponendo che il dispatcher di eventi utilizzi una tabella hash di base con un elenco collegato in una cella, l'ordine sarà l'ordine in cui gli oggetti sono stati aggiunti a quella cella.

Inoltre, a meno che tu non decida di utilizzare i puntatori a funzione per qualche motivo, stai ancora utilizzando chiamate di funzione virtuali poiché ogni oggetto che riceve un messaggio deve implementare IEventListener (o come lo chiami). Gli eventi sono un'astrazione di alto livello che costruisci usando il polimorfismo.

Usa eventi in cui ti trovi a dover chiamare un elenco di metodi per vari eventi in-game al fine di sincronizzare diversi sistemi nel gioco o in cui la reazione di vari oggetti e sistemi in modo che tali eventi non possano essere chiaramente definiti o desideri aggiungere ulteriori reazioni a tali eventi in futuro.

Sono un ottimo strumento, ma come ha detto Bummzack, non dare per scontato che il polimorfismo e gli eventi risolvano lo stesso problema.

Direi che scegliere l'uno o l'altro è piuttosto sbagliato. Alcuni oggetti devono chiamare ogni frame, altri no. Se si desidera eseguire il rendering di un oggetto, è necessario effettuare una chiamata di rendering ad ogni frame. Gli eventi non possono apportare questa modifica. Lo stesso vale per qualsiasi oggetto fisico basato sul tempo: devi chiamarli in ogni frame.

Tuttavia, non eseguo chiamate a tutti i frame per i miei oggetti di gestione degli oggetti, i miei oggetti di input dell'utente o qualcosa del genere. Le chiamate virtuali di massa a ogni oggetto sul frame sono un'idea terribile.

Il design utilizzato per un particolare oggetto dovrebbe essere basato sulle esigenze di quegli oggetti e non su alcune ideologie per il sistema nel suo insieme.

Modificato per essere più chiaro sulla mia prima frase.