Come si consente di scrivere il codice di rete nelle fasi successive dello sviluppo?

Attualmente sto scrivendo un gioco che alla fine vorrò migliorare in molti aspetti.
Come posso saltare scrivendo il codice di rete ma lasciandolo abbastanza facilmente implementato, cioè non dover riscrivere l'intero gioco solo per aggiungerlo.
Cosa devo tenere a mente?

Ho un modello di componenti in cui separo fisica / rilevazione delle collisioni, logica di gioco, tipi di dati e animazione / rendering l'uno dall'altro.
Come faccio a scrivere un client e un server che non hanno ancora implementato alcun codice di rete che può essere testato localmente?
Cosa devo fare nel client e cosa devo fare nel server? Dovrei solo fingere di avere finito il codice di rete e inviare messaggi tra server e client e tenere conto di ritardi, ecc., Anche se non ce ne saranno?

Modifica: è previsto un gioco di ruolo top down. Il multiplayer semplice in cui si ospita un server per i tuoi amici è quello che sto pensando, quindi imbrogliare non è un grosso problema (chi vorrebbe giocare con gli amici imbroglioni?). Mi piacerebbe comunque andare con un approccio "Il server ha sempre ragione".

Modifica 2: Immagino che sto cercando alcuni suggerimenti su come dovrebbe essere la mia mentalità. Come devo gestire l'input da tastiera, l'animazione, ecc., Invece di applicare immediatamente ogni effetto / modifica. Hmmm, potrei aver bisogno di leggere correttamente sulla rete prima di andare ovunque, dopotutto, che era quello che avevo sperato di scappare facendo uno scheletro di rete di qualche tipo che potesse funzionare localmente.

Senza sapere di più sul gioco esatto che stai scrivendo e su come lo stai scrivendo, è molto difficile dire soluzioni generiche al tuo problema.

Tuttavia, potresti prendere in considerazione questa decisione che stai prendendo di lasciare il codice di rete fino alla fine, a seconda di quanto sia cruciale la rete per il tuo gioco.

Quello che voglio dire è che, se stai scrivendo un gioco pesante di rete, come un MMORPG, potrebbe non essere saggio lasciare la rete fino alla fine.

Ciò considerato, se l'impatto previsto per il codice di rete è basso (come in, non avere affatto il codice di rete non è un gioco da ragazzi), allora potrebbe essere opportuno lasciarlo per una fase successiva (ma non troppo tardi).

Ricorda che scrivere-codice di rete non è lo stesso di -pensarci- a riguardo. Quando prendi decisioni su come viene fatto il tuo gioco, dovresti considerare in che modo ciò influirebbe sulle decisioni di rete e, se l'impatto previsto è elevato, potresti implementarlo come uno stub che fornisce alcune informazioni generiche e quindi quando è il momento di scrivere la rete codice, è solo una questione di collegarlo dove hai lasciato lo stub.

Quindi, ad esempio, se stai facendo una partita a scacchi online, potresti avere una funzione chiamata ExecuteMove()che viene chiamata in qualche modo quando una mossa viene immessa dal mouse e in un altro modo quando una mossa viene immessa dalla tastiera. A questo punto, potresti voler pensare di creare uno stub di rete che, dopo aver ottenuto i dati richiesti dall'altro host (questo è ciò che scrivi in ​​una parte successiva), chiama ExecuteMove().

In questo modo, mentre crei il tuo gioco, saprai quali parti sono interessate dal codice di rete e quando è il momento di scrivere effettivamente il codice di rete, sei diversi passi avanti.

Se è la prima volta che scrivi un gioco in rete, considera di non pensare troppo agli anti-cheat e cose del genere. Realizzare un gioco in rete è abbastanza complesso da richiedere a un intero team di persone di grande esperienza di farlo per un gioco AAA, quindi procedi lentamente e prima crea un gioco che funzioni, prima di concentrarti su argomenti più complessi.

Infine, se è la prima volta che giochi, non farlo in rete, per favore. Creare un gioco è così complesso che ogni requisito aggiunto al tuo gioco lo renderà esponenzialmente più complesso.

Sono in una situazione simile, ma sto provando a fare una simulazione in rete più di un gioco; ma penso che il mio approccio possa aiutare il tuo processo di progettazione.

Il mio approccio è in linea con il tuo commento su IPC (comunicazione tra processi).

In primo luogo, come sfondo sto studiando il libro "Networked Graphics" di Steed e Oliveira. Ciò fornisce un buon background su varie architetture di rete per i giochi a seconda di vari criteri e tipi di gioco. Fornisce uno strumento per aiutarti a decidere la tua architettura di gioco e cosa vuoi mettere esattamente sulla rete e cosa vuoi che avvenga localmente.

In secondo luogo, separa i componenti di rete in un thread in background separato in modo che lo sviluppo iniziale del gioco possa avere il componente codificato localmente, ma sei costretto a gestire la separazione dei thread. Non combinarli con altre funzionalità che saranno in seguito "sfondo locale", ma forzali in thread di sfondo "potenzialmente remoti".

Ciò dovrebbe aiutare a mantenere la logica separata e consentire anche di simulare i fattori di ritardo della rete nel processo in modo da poter vedere anche l'impatto della latenza.

Se stai imparando tutte queste cose, perché non scrivere una semplice versione 1 per giocatore singolo, e una volta che funziona, con le tue conoscenze più profonde, ripensare il tutto in modo approfondito per la versione 2 che sarà multigiocatore?

Implementa una classe "rete falsa" che passa i messaggi tra i thread, che ha la stessa interfaccia della classe di rete. Successivamente è possibile elaborare la rete falsa per avere ritardi casuali e perdita di pacchetti. Sarà sempre più facile eseguire il debug del codice di rete con la classe fake che con la rete reale.