Sistema di riproduzione: registra input o eventi?

Ho letto questo: Come progettare un sistema di riproduzione Ma non risponde alla mia domanda.

Il mio gioco è costruito con il client "view" del gioco come programma separato dal "modello" del server e "controller". (un po 'come un mmo o qualsiasi gioco multiplayer costruito in questo modo). Il lato server è sempre la "verità" del gioco, accetta solo richieste di azione come input dai client ed eventi di output e messaggi di "stato attuale".

Il modello di gioco e le regole sono completamente deterministici con un ciclo di aggiornamento "tick" fisso, quindi sul lato server posso registrare sia gli eventi inviati alle viste client, sia le richieste di azione. Entrambi sono associati a un numero di ciclo specifico.

La domanda è: in questo caso, per configurare un sistema di riproduzione, dovrei usare l'input, o le richieste di azione dell'utente (come suggerito lì) o gli eventi?

Mi sembra che entrambi darebbero esattamente lo stesso risultato. Le uniche differenze che posso vedere sono:

• Eventi fornisce l'output reale mentre le richieste di azione devono essere elaborate per fornire eventi.
• Le richieste di azione potrebbero contenere molti meno dati da registrare.

Ci sono altre cose da considerare?

Dato un sistema deterministico sono logicamente equivalenti, quindi il tuo sommario è praticamente corretto. Tuttavia, ci sono altre 2 cose che mi spingono verso la registrazione di azioni di input piuttosto che eventi di output:

1. Se si salvano le azioni, è possibile utilizzarle come dati di test in un secondo momento, poiché esercitano una quantità maggiore del codice rispetto alla sola riproduzione degli eventi. Questo può aiutare a diagnosticare i bug di arresto, a trovare regressioni comportamentali tra build, ecc.
2. In futuro potresti cambiare gli eventi che invii per una determinata azione o potresti inviare eventi diversi a clienti diversi per qualche motivo. In questo caso, il replay potrebbe diventare non valido o incompleto. Lo stesso problema potrebbe in teoria applicarsi agli input, ma di solito il dominio degli input è più limitato degli output e quindi è meno probabile che cambi e sia più facile adattarsi alla retrocompatibilità quando lo fa. (Gli input sono limitati a ciò che il giocatore e altre fonti di input (ad es. Generatore di numeri casuali) possono fare, mentre gli output includono tutti i risultati di quegli input oltre a qualsiasi altro output generato dalle regole del gioco, come suggerimenti di presentazione, server periodico- eventi collaterali, ecc.)

Entrambi funzionano, anche se ci sono alcune cose da considerare.

Innanzitutto, ricorda che devi registrare le informazioni sul tempo. Per i giochi con qualsiasi tipo di frame rate variabile, questo può essere particolarmente complicato; devi assicurarti che i tuoi dati di replay possano fornire esattamente le stesse informazioni temporali utilizzate dal gioco per la simulazione.

Devi anche tenere conto delle modifiche al comportamento del gioco. Se registri input e poi modifichi qualsiasi parte di come viene gestito l'input, di come la fisica si risolve, ecc., La tua registrazione diventa non valida. Anche se registri eventi di gioco, se qualsiasi parte del modo in cui tali eventi vengono interpretati cambia, sei bloccato.

Se vuoi solo riproduzioni, un buon approccio è quello di registrare un elenco specifico di posizioni e rotazioni per l'entità giocatore insieme alle informazioni sui tempi. Disattiva la maggior parte della fisica e altre logiche di gioco mentre esegui la riproduzione il più possibile. Quanto sia facile o fattibile dipende da quanti altri oggetti devi sincronizzare.