Come consentire a un giocatore di conoscere gli oggetti pubblici di un altro giocatore?

Naviga le tue risposte
3

Contesto : userò il gioco da tavolo Spiacente come esempio, ma questa domanda potrebbe applicarsi ad altri giochi da tavolo. In Scusa, ogni giocatore ha quattro pedine. Basato su carte pescate, un giocatore muove le sue pedine attorno al tabellone. Queste mosse possono influenzare le pedine degli altri giocatori, come battere di nuovo il pedone di un altro giocatore su Start.

Per una possibile implementazione (semplificata) del gioco, considera questa architettura:  1. Classe di gioco - La responsabilità sta gestendo i turni. Ha una collezione di oggetti Player  2. Classe del giocatore: la responsabilità sta permettendo a un giocatore (AI o umano) di agire. Ha una collezione di pedine di quel giocatore.  3. Classe di pedoni: la responsabilità è conoscere il suo stato; ogni istanza rappresenta una singola entità.

Esempio : per alcune azioni del giocatore, come l'esecuzione di un Mi dispiace, il giocatore deve sapere dove tutte le pedine devono prendere una decisione informata. Altre azioni sono simili, come scegliere quale pedina spostare; Potrei muovere una pedina in modo che finisca sulla pedina dell'avversario.

Un approccio semplice sarebbe per la classe Player avere funzioni come: Pawn * ChooseSorryPawn (vector oppPlayers). La funzione quindi interrogherà ogni giocatore per i suoi pedoni, costruirà l'intera lista di pedine avversarie e quindi prenderà una decisione.

Preoccupazione : per una funzione, quanto sopra potrebbe essere ok. Ma questo stesso schema sarebbe necessario per tutte le funzioni del giocatore coinvolte nel prendere una decisione, dal momento che un giocatore ha bisogno di conoscere l'intero stato della scacchiera.

Domanda : questo è davvero il modo migliore per andare, o c'è un modello di progettazione migliore per consentire a un giocatore di prendere decisioni senza passare in riferimento diretto ai giocatori avversari e ai loro pedoni? Potrebbe un mediatore essere l'approccio giusto qui?

Come domanda correlata, sarebbe meglio memorizzare lo stato della posizione di pedone in una classe separata, come una classe di GameBoard, invece che con i pedoni stessi? In questo modo, ogni giocatore prenderà una referenza di GameBoard nel suo costruttore.

    
posta Craig 15.05.2017 - 03:09
fonte

4 risposte

7

La decisione di progettazione migliore da fare qui è la struttura dei dati da utilizzare per rappresentare lo stato del gioco.

Ne vuoi uno che renda facile valutare quanto è buona una posizione di gioco per ogni giocatore e fare mosse.

Non vedo che ciò accada se devi chiedere ai giocatori dove sono i loro pezzi.

Piuttosto, un giocatore dovrebbe fare una mossa dicendo "ecco il tabellone" passando al giocatore successivo la nuova struttura dati che rappresenta il tabellone.

each player would take a GameBoard reference in its constructor.

Non è necessario modificare la scheda. Puoi crearne di completamente nuovi ogni volta e passarli semplicemente.

Non vedo molte funzionalità nelle pedine per renderle degne di essere trasformate in un oggetto. Le carte comunque sono molto interessanti.

    
risposta data 15.05.2017 - 06:14
fonte
2

Un modo per farlo sarebbe attraverso lo schema dell'osservatore. Mentre ogni pedina si muove, notifica agli altri giocatori la sua posizione. In questo caso, se si dispone di un'interfaccia utente, può anche essere un osservatore e ricevere una notifica per visualizzare le posizioni dei pedoni all'utente.

    
risposta data 15.05.2017 - 05:00
fonte
2

Questo contesto (che modella un gioco di Scusa) si presta molto bene a modellare le interfacce / interazioni di classe in modo coerente con le interazioni del mondo reale.

Quando stai giocando Scusa, chiedi ad altri giocatori la posizione delle loro pedine? No. Allora perché modellerai le tue classi in modo tale che il giocatore richieda un vettore di pedone da un altro giocatore?

In che modo interagisci effettivamente con il gioco / la bacheca? "Chiedete" al tabellone lo stato attuale della scacchiera. Non chiedi le pedine del giocatore 1, quindi le pedine del giocatore 2, ecc. Basta fare una richiesta del tabellone (una richiesta visiva per gli avvistati tra noi).

Il giocatore non "ChooseSorryPawn", il giocatore sceglie una pedina per applicare la carta e il risultato di quella pedina che atterra su o scivolando oltre un pedone avversario è il pedone avversario che viene spostato di nuovo a casa. (Scusa se il mio ricordo delle regole non è corretto).

Le interazioni sono tra Player e Board e all'interno del Board. Il Board può avere Card e Pawn, ma probabilmente terrei le interazioni tra Giocatore e Consiglio (il giocatore sceglie Pawn), Board e Card (Board ha un mazzo di carte, Board rivela una carta), Board e Pawn ).

Inoltre, penso che sia utile pensare a come un giocatore umano interagirebbe con il tuo gioco di Scusa elettronico, a differenza di come un giocatore interagisce con un gioco di Scusa fisico. Un giocatore mescola il mazzo perché il Board / Cards di cartone non può farlo da solo; il giocatore sceglie una carta perché la carta non può rivelare se stessa; il giocatore muove il pedone perché il Board / Pawns non può muoversi da solo; il giocatore dice "Scusa!" in un modo super disonesto perché il giocatore è un coglione e il Consiglio è solo un cartone inanimato.

Gli unici aspetti del gameplay che sono pienamente a carico del giocatore sono:

  1. Decidere quale pedina spostare
  2. Essere un coglione
risposta data 16.05.2017 - 00:43
fonte
1

Perdonami! in particolare, lo progetterei personalmente in modo tale che le classi di stato e di gioco siano le stesse. Non c'è la mano privata di un giocatore o una banca o qualcosa del genere. Le carte appartengono al tabellone, i pezzi appartengono al tabellone, e tutti i giocatori lo fanno è disegnare e quindi interpretare lo stato del tabellone per prendere decisioni.

Tutto ciò di cui hai bisogno è una sorta di identità per i pezzi, una sorta di identità per i giocatori e una mappatura tra pezzi e giocatori. Tutta la scheda ha bisogno di esporre è un'interfaccia per visualizzare l'intera scheda, un'interfaccia per disegnare una carta che restituirà una carta / uno stato (cioè saltare la svolta perché non si può agire sulla carta, saltare l'input del giocatore perché c'era solo una possibile cosa che potrebbe accadere con la carta, in attesa dell'ingresso del giocatore), e un'interfaccia per eseguire una mossa per il giocatore corrente che prende un input di un ID pezzo specifico. Puoi organizzare l'API di spostamento in diversi modi.

Potresti avere un metodo per tipo di carta. Potresti avere una funzione più generale che accetta un tipo di movimento specifico e un'eccezione per Scusa / partenza in partenza. Potresti anche usare una sola funzione con vari parametri opzionali. Dipende da ciò che pensi sia il più chiaro.

Potresti anche restituire una serie di mosse valide dalla funzione di disegno della carta, che semplificherebbe la scelta della funzione di mossa (dato che hai appena passato quello che il giocatore sceglie) se c'è più di una mossa. Se c'è una mossa, non puoi far tornare alcuna mossa e solo eseguire quella mossa. Certo, ci dovrebbe essere un modo per interrogare la carta in modo da poterla visualizzare per gli utenti, ma potrebbe anche far parte della query della scheda.

In ogni caso, queste sono davvero le uniche due funzioni del gioco. Tutta la logica del gioco può essere gestita dal consiglio di amministrazione.

    
risposta data 15.05.2017 - 22:58
fonte

Leggi altre domande sui tag

Perché il codice include una chiamata a un database o a un DAL non definito come client? Se una classe non ha dati specifici dell'istanza va bene renderla un singleton?