Quali modelli di software / architettura si adatterebbero a questo gioco da tavolo client / server?

Question

Quali modelli di software / architettura si adatterebbero a questo gioco da tavolo client / server?

#1 da (1 voti)
#2 da (1 voti)

0

Negli ultimi mesi ho lavorato con la mia versione di un famoso gioco da tavolo. Dopo molte sperimentazioni, sono arrivato su alcuni punti chiave che descrivono il mio sistema:

Lo stato del gioco è centralizzato e serializzabile. Il server può essere interrotto in qualsiasi momento, ma semplicemente estraendo lo stato dall'archiviazione, un giocatore può riprendere il gioco esattamente dove si è fermato
Le regole del gioco sono semplicemente una funzione dello stato (state, ...args) => newState
I client interagiscono e modificano lo stato tramite azioni , descritto da una regola che modifica lo stato di conseguenza (vedi punto sopra) e un valori function (state, player) => args[] , che, dato lo stato corrente e il giocatore, restituisce i valori validi (se presenti) per quel particolare tipo di azione. Questo è usato per informare il cliente delle sue azioni valide e anche come validatore per le azioni in arrivo
Il giocatore sceglie una delle possibili azioni, lo invia al server nella forma {type, args} , che convalida l'azione contro i possibili valori per quella particolare azione tipo ed esegue la corrispondente regola , restituendo il nuovo stato al giocatore

Non sono riuscito a trovare uno schema ben noto che potrebbe darmi qualche idea su come sfruttare al meglio l'implementazione. Non sto cercando di calzare qualcosa qui per il gusto di farlo, cercando solo di capire da una linea guida generale e altri casi simili nella vita reale da cui ho potuto imparare.

In un certo senso, funziona come una macchina a stati, con qualche tipo di comando paattern e un sistema RPC per mediare tra client / server che attiva le modifiche di stato.

Sto cercando un approccio funzionale qui, quindi nessuna modifica di oggetti e tutti gli effetti dipendono esclusivamente dallo stato del gioco. Inoltre, sto sviluppando questo in JavaScript, ma non penso che importi molto.

architecture design-patterns client-server

posta Thiatt 18.06.2018 - 23:34

fonte

2 risposte

Leggi altre domande sui tag architecture design-patterns client-server

Funzione di utilità o funzione di supporto in classe? Relazione tra il livello del servizio dell'applicazione e la radice aggregata

score 1 · Answer 1

Mi sembra che tu abbia già trovato diversi modelli qui:

The game state is centralized and serializable...

Sembra un modello client-server.

Game rules are simply a function of the state (state, ...args) => newState

Sembra una macchina a stati.

Clients interact and modify the state through actions...

Sembra che l'invio di eventi da una parte e la gestione degli eventi dall'altra.

Questi sono tutti i pattern ben noti usati per scrivere giochi e altri tipi di codice.

score 1 · Answer 2

I haven't managed to find any well-known pattern which could give me some insight on how to best go about implementing this

Per cosa ti serve? Il codice è strettamente accoppiato? Cosa si risolverebbe in un modello rispetto al codice corrente? Se non conosci il problema, non puoi sapere quale pattern utilizzare. Se non hai problemi con il tuo codice attuale, diventa ancora migliore perché chiaramente non devi risolvere nulla.

I'm not trying to shoehorn something here for the sake of it

In realtà sembra che tu sia. Stai guardando un insieme di soluzioni senza avere un problema ben definito che tali schemi potrebbero risolvere.

In some sense, this works much like a state machine, with some kind of Command paattern and an RPC system to mediate between client/server that triggers the state changes.

Anche questa è la stessa cosa. Stai guardando le soluzioni che hai implementato, mentre apparentemente non hai capito quali problemi stavi cercando di risolvere usandoli.

I pattern non sono blocchi. Non è necessario utilizzare un modello noto come lo schema di comando. Se noti che il tuo codice sta diventando strettamente accoppiato, stai costantemente toccando più classi di posti per un piccolo cambiamento, ecc, mentre la descrizione del tuo problema sembra un po 'come menzionata qui ("È necessario inviare richieste agli oggetti senza sapere nulla sull'operazione richiesta o sul destinatario della richiesta."), quindi sì, è possibile considerare l'utilizzo di tale modello per allentare l'accoppiamento.

Ma per prendere questa decisione, hai bisogno di un problema ben definito e se finisci per scegliere un pattern (più conosciuto) come lo schema di comando (anche se non devi sceglierne uno), dovresti assicurarti che in realtà costituisca una soluzione a qualunque problema tu stia tentando di risolvere.

just trying to get a sense of a general guideline

È difficile fare una linea guida per le soluzioni. Non è obbligatorio utilizzare la soluzione y per il problema x né dovrebbe essere una linea guida per utilizzare la soluzione z in qualche punto del codice. La tua soluzione funziona e se non hai problemi con, ad esempio, apportare modifiche, probabilmente non hai bisogno di applicare alcun modello come comando, strategia o altro.

Le uniche linee guida che puoi fare riguardo ai pattern è che non dovresti provare ad incorporarle in ogni applicazione, non dovresti provare ad applicare un pattern senza conoscere il problema da risolvere e non dovresti guardare al popolare e ben noto modelli come le uniche soluzioni per l'ingegneria del software.

Rispettare invece i principi del design SOLID . Potresti finire per avere bisogno di schemi come il modello di strategia e il modello di comando per ottenerlo, forse non lo farai, ma seguire quei principi farà sì che il tuo codice finisca in uno stato buono, a prescindere.