Separazione della logica dai risultati della presentazione nella ripetizione del codice

3

Ecco cosa stavo pensando.

Dì che stai facendo una partita multiplayer. Un buon modo per strutturarlo è avere tutta la logica di gioco sul server e avere i client solo responsabili della trasmissione di input al server, disegnando lo stato attuale del gioco e l'interfaccia utente. Questo di solito porta a un codice pulito e impedisce anche l'imbroglio sul lato client.

Ora dì che hai un'unità nel tuo gioco che spara un cannone con un certo cooldown. Il motivo per cui non può sparare continuamente è perché deve essere ricaricato. Questo è rappresentato da un'animazione. Ma il server deve anche essere consapevole del cooldown in modo da finire per dover sincronizzare la durata dell'animazione e il cooldown che il server comprende. In questo semplice esempio puoi accelerare o rallentare l'animazione se decidi di cambiare il cooldown, ma ci sono sicuramente processi in cui sarebbe più ragionevole animarli e poi fare in modo che i valori di gioco dipendano dall'animazione attuale.

C'è un modo intelligente per evitarlo? Sembra che apporti un carico significativo al programmatore perché deve assicurarsi manualmente che due pezzi di codice disaccoppiati, che probabilmente sarebbero meglio accoppiati, siano sincronizzati. Se non hai separato la presentazione dalla logica, ti piacerebbe semplicemente collegarti direttamente all'animazione e attivarla nel gioco.

    
posta Darwin 13.02.2015 - 11:28
fonte

2 risposte

2

Se stai facendo partite multiplayer, i tempi delle varie azioni devono essere ben pensati. Dai un'occhiata a World of Warcraft, Diablo 3, League Of Legends ... Le persone creano fogli di calcolo con righe e file di dati e calcoli per determinare la combinazione di abilità più efficace per il loro scopo. E i game designer bilanciano il gioco di conseguenza.

In alcuni casi i giochi cambieranno l'ordine in cui gli effetti vengono applicati a un'abilità nel gioco perché è completamente sopraffatto. Ad esempio, pensa a un'abilità che abbassa l'armatura e infligge danno. L'ordine in cui ciò accade può fare una differenza enorme, poiché prima abbassando l'armatura si causerebbe più danno da infliggere.

I grandi giochi multiplayer hanno persone che si occupano di problemi di bilanciamento e in particolare esaminano i tempi. Penserei che i tempi sono programmati nel gioco e le animazioni devono corrispondere ai tempi. Il "Feel" del designer per le animazioni è importante, ma alla fine l'equilibrio è una questione di numeri e quindi il regno del programmatore.

    
risposta data 13.02.2015 - 12:12
fonte
2

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.

    
risposta data 13.02.2015 - 15:19
fonte

Leggi altre domande sui tag