È la domanda giusta?
Il Mediator riguarda le interazioni tra oggetti "colleghi" che non si conoscono. Il Command riguarda come eseguire un'interazione specifica (se il comando è creato da un giocatore o da un mediatore). La domanda quindi non dovrebbe riguardare quale alternativa usare, ma come ognuna di esse potrebbe servire al tuo scopo.
In che modo può aiutare il Mediatore?
Lo scopo del schema del mediatore è incapsulare l'interazione tra diversi oggetti del collega al fine di isolarli da l'un l'altro. Utilizzare il mediatore per disaccoppiare un Player e un Board renderebbe il disegno un po 'complesso:
-
Player e Board implementerebbero la stessa interfaccia Colleague comune
-
Player invia le richieste di spostamento a Mediator
-
Mediator sa che le richieste dei giocatori devono essere inviate a Board
-
Board riceve una richiesta da Mediator
-
Board analizza la richiesta e informa Mediator che è stata accettata (o rifiutata)
-
Mediator sa che questo tipo di interazione deve essere inviato a Player
-
Player riceve risposta da Mediator
Inoltre, come dichiarato in GoF, potrebbe essere utile rendere Mediator un osservatore per i diversi colleghi, in modo che sia informato delle modifiche dello stato rilevanti e possa attivare azioni.
Il vantaggio di questo approccio più complesso è la sua flessibilità: ad esempio potresti avere il 2% diPlayers e un% diBoard. Puoi aggiungere un timer Colleague . Potresti aggiungere un consigliere / allenatore Colleague per informare il giocatore umano di quanto è buona la sua mossa (o fornire informazioni simili a un giocatore di IA con apprendimento automatico).
Inoltre, poiché i colleghi sono disaccoppiati, potresti potenzialmente riutilizzarli in altri giochi.
E il comando?
Lo scopo del schema di comando è quello di incapsulare le richieste. Quindi incapsulare le mosse per la scacchiera e lasciarle essere eseguite (o invertite nel caso in cui l'utente attivi un annullamento).
Utilizzerai certamente un pattern di osservatore, per consentire a Player di osservare la modifica dello stato di Board . E potrebbe essere un secondo Player (AI o umano) anche sottoscrivere il cambiamento Board e impartire comandi per innescare le mosse. E avresti sicuramente un ciclo principale per il gioco, in cui potresti aggiungere un timer.
Alla fine, avresti una struttura simile (il ciclo di gioco incolla i pezzi). Tuttavia, gli oggetti devono conoscersi e un cambiamento nell'interazione tra gli oggetti potrebbe richiedere adattamenti di tutte le classi coinvolte.
Raccomandazioni
- Se vuoi consentire l'annullamento, è meglio usare
Command .
- Se hai solo due colleghi, il mediatore sembra un po 'troppo ingegnerizzato se hai una sola partita. Inoltre può limitare il resto del progetto. Quindi magari iniziare senza di esso e rifattorizzare il codice quando si ha qualcosa di funzionante.
- Se ti interessa il codice del gioco in generale, il libro di Mike McShaffry "Game Coding Complete" è per te: spiega come strutturare un gioco, le sfide e le insidie da evitare. Non c'è molta teoria sui pattern, ma molto buon senso sulle architetture di gioco di lavoro.