Spielarchitektur und Designstrategie für ein Multiplayer-Kartenspiel

8

Ich bin relativ neu in der Spieleentwicklung, also entschied ich, dass ich ein Hobby-Projekt von Grund auf für Erfahrung und Unterhaltung erstellen wollte. Das spezifische Spiel ähnelt dem Poker, der als Three Card Brag bekannt ist. Das Spiel wird im Film Lock, Stock und Two Smoking Barrels gespielt.

Ich habe einige der Themen über SO bezüglich der Spieleentwicklung gelesen, obwohl diese Frage . Dies hat dazu beigetragen, den ursprünglichen Weg, auf dem ich die Objekte erstellt habe, neu zu gestalten.

Ein besonderes Problem, das ich habe, ist das Definieren des Spielstatus. Mein erster Ansatz war es, alles zu trennen (zB Chipstacks in einer Player -Klasse zu halten), aber nach dem Lesen der Antworten auf die question Ich habe bereits erwähnt, dass es scheint, als ob alle möglichen Zustände des Spiels in einem GameState Objekt beibehalten werden sollen. Was ich herausgefunden habe, ist im Wesentlichen folgendes:

%Vor%

wo jeder CardGameState durch eine Aktion geändert wird:

%Vor%

Jetzt bin ich sehr stark davon überzeugt, dass dies den Zweck der objektorientierten Programmierung vereitelt, weil die Daten, die sich speziell auf den Spieler beziehen (in diesem Fall sein Chipstack, seine Hand und sein aktueller Status), nicht von der Player Objekt.

Auf der anderen Seite, wenn ein Spieler den Einsatz erhöhen würde, würde ich ein RaiseAction erstellen, das IAction implementiert, aber das IAction Interface akzeptiert nur den aktuellen Spielstatus, was ich nicht glaube wäre ideal, wenn die Chipstacks in der Klasse Player gespeichert wären.

Grundsätzlich ist meine Frage: Kann ich das Beste aus beiden Welten haben, so dass ich den Spielzustand genau darstellen kann und gleichzeitig alle Daten, die sich spezifisch auf ein Objekt innerhalb des Spielzustandes beziehen, innerhalb des gegebenen Objekts halten kann?

    
John Rasch 03.03.2009, 03:36
quelle

2 Antworten

6

In Online-Spielen mit dem Befehlsmuster (deine IAction) ist der Standard und bewährte Weg es. Es ist nicht objektorientiert im Sinne des Spielers, aber die Aktionen sind objektorientiert, also rein theoretisch gesehen ein solides Designmuster, denke ich. Und in der Praxis implementiert das jedes erfolgreiche Online-Spiel, das ich gesehen habe, aber beachte, dass Action-Spiele normalerweise sehr kleine diskrete Aktionen / Pakete verwenden, bis sie praktisch zu einem Strom von Arten werden.

Bearbeiten:

Eine lange Zeit nachdem ich dies beantwortet habe, kam ich zurück und erkannte, dass eine andere Lösung für dieses Problem darin besteht, GameStates Player, Decks usw. zu implementieren, die von einer IState Klasse mit Anwenden (IAction-Aktion) Mitglied. Auf diese Weise wenden Objekte Aktionen auf sich selbst an, anstatt dass die Anwendung Aktionen auf Objekte anwendet, würde dies Aktionen und Status einem Besuchermuster anstelle eines Befehlsmusters. Beide Lösungen funktionieren, wobei der Besucher den größeren Overhead und mehr Verkapselung hat, während der Befehl die leichtere Lösung mit weniger Verkapselung ist.

    
Robert Gould 03.03.2009, 04:20
quelle
1

Scheint so, als ob Sie Objekt-orientiert sein könnten, um dem Objekt-Orientierungssinn willen ...

Scheint wie Bob Martins klassisches Problem Bowling-Spiel .

BEARBEITEN: -Zusammenfassung-
Es ist ein langer Lese, aber im Grunde, durch TDD und Refactoring, ging eine Bowling-Scoring-Anwendung von einem riesigen Cluster mit vielen Klassen und Polymorphismen auf 20 oder 30 elegante Codezeilen. Warum? Weil sie nicht wirklich in erster Linie da sein mussten

    
Ovi Tisler 03.03.2009 04:08
quelle