Now say you have a unit in your game that fires a cannon with a certain cooldown. The reason it can't fire continuously is because it has to reload. This is represented by an animation. But the server also needs to be aware of the cooldown so you end up having to sync up the animation duration and the cooldown that the server understands.
La consapevolezza del server è primaria e la prima preoccupazione. La cosa più importante è che accada la cosa giusta e solo il server può decidere che. L'unica cosa che dovrebbe mai credere al cliente è l'input dell'utente. So che lo sai, ma questo deve essere dichiarato.
Quindi, supponendo che la tua proposta sia che l'animatore decida i tempi e queste informazioni siano passate allo sviluppatore sul lato server ... non hai semplificato nulla e il codice è ancora "duplicato". L'applicazione server deve ancora forzare il cooldown. Il codice deve ancora essere scritto. Potrebbe essere un codice peggiore di quanto sarebbe stato altrimenti e sicuramente sarà più fragile perché è stato dettato dall'immaginazione di un grafico e non dalla meccanica interna del gioco. Non è più semplice.
Se la proposta fosse che l'applicazione client dice al server "Ho finito di ricaricare, sto sparando di nuovo ora", quindi hai consegnato la tua applicazione agli hacker. Hai creato un gioco in cui l'utente può lanciare una moneta e decidere se è o non è venuta fuori testa, quindi chiedere denaro al giocatore NPC che ha "perso" la scommessa. Anche se l'utente non è un imbroglione, ricorda che gli MMO soffrono di ritardo e che il software client soffre anche del carico sul computer client (forse alcune attività di auto-disk-defrag decidono di avviarsi). Non è in grado di inviare back time affidabili né di mostrare in modo affidabile all'utente cosa sta succedendo now . Che si nutre del mio prossimo punto ...
Duplicazione del codice? L'applicazione server decide cosa succede, in base a una combinazione di ciò che l'utente ha richiesto di accadere, che cosa il gioco impone, quali eventi e condizioni forniscono altri input (attività NPC, altra attività dell'utente ecc.) E cosa l'applicazione permetterà dal prodotto di tutti quelli. Il cliente cerca semplicemente di presentare una rappresentazione plausibile di ciò che è stato detto sta accadendo, avvolto in un sacco di glitter che non ha esistenza nel gioco reale, dopo aver detto al server ciò che l'utente voleva fare (andare avanti, oscillare una spada , passare all'arma secondaria, qualunque cosa). Questi sono compiti completamente diversi.
Ma ...
Il mondo di gioco "esiste" nei tuoi server. Il giocatore sta cercando di "vivere" in quel mondo dal suo computer di casa. Il giocatore non può farlo (e non vuole giocare più) se la rappresentazione degli eventi di gioco non è sia plausibile che coerente. Possono vivere con un gioco in cui a volte le cose diventano troppo lente e rallentate (come in un enorme raid / battaglia multi-player) perché vedano sempre che hanno finito le munizioni - se il gioco è affidabile nella gestione di quegli eventi. Non rimarranno in una partita in cui potrebbero sembrare aver ricaricato e sparare, ma non viene sparato nulla. Non si fideranno di un gioco del genere per gestire qualsiasi evento, lato server o meno.
Quindi, affinché il tuo gioco sia accettabile, la duplicazione del codice è essenziale . Gli sviluppatori / animatori lato client devono sapere qualcosa su ciò che sta succedendo sul lato server, perché devono essere approssimativamente sincronizzati con esso in condizioni molto impegnative e renderlo credibile e accettabile per il giocatore. Stai cercando di far esistere lo stesso mondo in due luoghi ampiamente separati e in due applicazioni separate che assolutamente non dovrebbero condividere alcun codice (per ragioni di sicurezza e separazione dei problemi). Prova a farlo senza ripetere qualsiasi cosa . La duplicazione degli elementi essenziali del gioco è l'intero punto.