Simon Interface Strukturierung

[Pfaeff]

Hallo,

Ich plane momentan an einem Netzwerk-basierten Spiel, ähnlich wie Schach.
In diesem Spiel gibt es mehrere Phasen: Einheiten kaufen, Einheiten platzieren und das eigentliche abwechselnde Ziehen der Figuren.

Meine Idee war es jetzt, dass ein Spieler ein Spiel erstellt und sich ein weiterer Spieler in das Spiel einklinkt.
Der erste Spieler fungiert somit als Client und Server zugleich, wobei hier kein Unterschied zu einem normalen Client gemacht werden soll.
Die Clients sollen nun nur die nötigsten Informationen an den Server senden (Spielzüge), dieser berechnet dann den nächsten Schritt und sendet die Änderungen an alle Clients. Ich denke das ist soweit ganz sinnvoll.
Nun habe ich allerdings ein kleines Strukturierungsproblem. Es gibt nun, aufgrund der unterschiedlichen Phasen eine Menge Funktionen, die das Server-Interface bereitstellen muss. Ich will jetzt dem Interface nicht einfach alle möglichen Funktionen unterschieben. Ich habe vor, den Server wie eine State Machine laufen zu lassen. Sprich es gibt für jede Phase einen Zustand.
Nun Frage ich mich, wie ich da für die unterschiedlichen Phasen am besten Struktur hineinbringen kann. Soll ich für jede Phase ein eigenes Interface schreiben? Der Server hätte dann trotzdem alle diese Funktionen, die nicht alle etwas miteinander zu tun haben, zu implementieren. Gibt es für solche Probleme, eine elegante Lösung?

Gruß, Pfaeff

[tuxedo]

Also prinzipiell macht es natürlich schon Sinn Methoden logisch zu gruppieren und in einzelne Interfaces zu packen (die dann natürlich irgendwo [Server] implementiert werden müssen).

Aber in wieweit es Sinn macht einen Serverzustand auf ein Interface (oder umgekehrt) abzubilden: Kein Plan. Ich würde es wohl nicht tun. Aber das kommt auf den einzelfall an.

Und nur um es erwähnt zu haben: Das ist ein allgemeines "Designproblem" und nicht SIMONspezifisch

Gruß
Alex

[Pfaeff]

Ja ich weiß, dass es ein relativ allgemeines Problem ist, es tauchte bei mir aber im Zusammenhang mit Simon und Interfaces auf Bei RMI wäre es ja auch nicht anders.

Wenn ichs nicht besser strukturiert bekomme, dann muss ich irgendwie für mehr Abstraktion sorgen.
So wie es jetzt geplant ist, wird es von jeder Methode, die fürs Netzwerk relevant ist, drei Sorten geben. Nennen wir sie mal wie folgt:

1
2
3
fooUserInteract() {}
fooServer() {}
fooClient() {}

Der Benutzer "sorgt" also für den Aufruf von fooUserInteract(). Diese Methode ruft dann fooServer() auf dem Server auf. Dieser berechnet den nächsten Zustand und ruft wiederum fooClient() als Callback auf.
Ich hätte also eine Methode auf der Ebene der Interaktion, eine auf der die relevanten Berechnungen für das Spiel stattfinden und eine bei der das Ergebnis dem Client angezeigt wird. Ist das soweit sinnvoll? Ich hätte dann halt zwei Interfaces (Client und Server) voller Funktionen, die fast gleichnamig wären. Die Datenstruktur auf der beide operieren soll identisch sein. Der Client hat praktisch nur eine Kopie von dem was auf dem Server lagert und bekommt immer mit, wenn sich etwas ändert.

Ich würde mir auch gerne mal anschauen, wie andere so etwas realisiert haben, gibt es irgendwo Beispiel-Sources in der Richtung?

[tuxedo]

Wie wär's denn mit dem definieren der guten alte Use-Cases...
Fangen wir doch also mal von vorne an:

Was macht denn der Client alles? Ist das Spiel wirklich "rundenbasiert"? Gibt es einen geregelten Ablauf?

Bisher konnte ich aus deiner Beschreibung lesen:

1) Einheiten kaufen
2) Einheiten platzieren
3) und das eigentliche abwechselnde Ziehen der Figuren

Sofern 2 und 3 wirklich unterschiedliche Dinge sind, und alle 3 in dieser Reihenfolge ablaufen sollen, würde ich dafür 3 Interfaces anlegen und im Server abverfolgen welche Schritte/Abläufe schon erledigt sind. Sofern der Schritt "einheiten kaufen" nicht nicht vom Client abgehandelt wurde, und dieser dann quasi vorzeitig Einheiten platzieren wollte, würde der Server bei diesem Versuch eine Exception von wegen "IllegalStateException" oder so werfen. Die ganze Ablauflogik sollte also im Server vorhanden sein (allein schon deswegen damit keiner bescheißen kann).

- Alex

[Pfaeff]

Ja, genauso meinte ich das in meinem Ursprungspost. Für jede Phase des Spiels praktisch ein Interface und wenn der Client auf ein Interface zu greift, welches außerhalb des jetzigen "States" des Servers liegt, lehnt dieser dann ab.
Use-Case-Diagramm hab ich vor mir liegen (wenn auch nicht in UML-Standard) .

[tuxedo]

Okay, dann versteh ich nur noch nicht was du mit den vielen Methoden hast?
Viele Methoden sind erstmal nicht schlimm. Schlimm ists wenn du nur ein Objekt das das alle Methoden enthält und alle Methoden thematisch wild durcheinander wuchern.

Würde in jedes Interface dann noch ne Methode packen mit der der Client signalisieren kann "ich hab Phase 1 jetzt abgeschlossen und werde mit Phase 2 weiter machen". Damit kann der Server dann den State für diesen Client entsprechend anpassen.

- Alex

[Pfaeff]

Genau das wäre nämlich passiert, wenn ich nur ein Interface gehabt hätte. Dann wären dort nämlich allerlei unterschiedliche Methoden drin gelandet, die thematisch nichts mit einander zu tun haben. Aber jetzt ist alles klar, danke

[Empire Phoenix]

Ich weiß nicht ob simon das so macht, aber ihs chicke bei meinem simplen Netzwerksystem Objecte die von Message erben.
Mein ansatz wäre jetzt 3 Statemessages zu erstellen, also eine BuyPhaseMessage;PlacePhaseMessage,PlayPhaseMessage.
Beim server werden dann 3 messageevent listener hinzugefügt, die jeweils als erste zeile enthalten if(bla.Phase == "Buy" && recivedmessage instanceof BuyMessage). sprich cih würde das ganze klassenbasiert Lösen.

Zudem ist Simon schon leichter overkill für Schach ^^ einfach nen Socket mit nem Object Output/Input Stream dran sollte in diesem Fall tatsächlich einfacher zu implementieren sein.

[tuxedo]

@Empire

Naja. Objekte und Spiellogik muss man so oder so erstellen. Da noch SIMON mit rein zu basteln ist 5min Arbeit. Mehr nicht. Selbst auf den Sockets rumzuwerkeln dauert defintiv länger. Als Overkill kann man maximal das hinzufügen der benötigten Libs bezeichnen. Aber im Endeffekt ist es eine einzige Library die man in den Classpath mit aufnehmen muss.

Wer das nicht will kann ja immer noch auf RMI zurückgreifen. Der "Aufwand" ist der gleiche. Aber man muss keine Lib hinzunehmen (hat dann aber das Callback-Problem).

Intern werden bei SIMON keine "Transportobjekte" für Nachrichten erstellt und serialisiert. Die kommunikation basiert auf Rohdaten. Nur Methodenargumente und evtl. Rückgabewerte werden extra mit der javatypischen Serialisierung in byte[]s gewandelt.

[Noctarius]

Nur kurz als Einwurf:
SIMON ist eine tolle Sache (tuxedo du weiß wie ich das Ding mag *gg*) aber man sollte sich an gewissen Punkten überlegen, ob es sinnvoller ist eine Art TransportObjects zu nutzen um einen großen Haufen Daten auf einmal zum Client zu übertragen (z.B. Positionsdaten oder Gegnerdaten). Dies ist bei SIMON Trafficlastiger (wenn auch nur minimal) und Zeitkostenintensiver, da jeder Methodenaufruf gegen das Interface gesondert zum Server übermittelt wird. Hier sollte man an gewissen Punkten ein TO als Rückgabe für eine Methode in Betracht ziehen.

[Pfaeff]

Das würde ja aber nur bei einem Echtzeitsystem ein Problem darstellen. Da es sich hier um ein Runden-basiertes Spiel handelt, spielt die Zeit und der Traffic-Overhead nicht wirklich eine Rolle.

Wäre es nicht auch möglich, statt jeder Menge Methoden eine Referenz auf das Objekt (also zum Beispiel das Schachbrett) zu übergeben, sodass wenn der Client etwas am Objekt ändert, dies dann auch automatisch an den Server und alle Clients weitergeleitet wird. Wird dann nur die Änderung übertragen oder sämtliche Daten des Objektes?

[Noctarius]

Ja ok, dann ist das kein Problem