Game Logic - Mapping der Schiffe

[pasndrp]

Mein Vorschlag für das Mapping der "gegnerischen" Schiffe:

ConcurrentHashMap<NodeID, Set>

Damit können die Callbacks asynchron die Map aktuallisieren und das Spiel kann anhand der Informationen die Strategie zum angreifen. Wenn wir das Mapping synchon halten können, muss es doch so auch möglich sein, das Ende des Spiel zu bestimmen.

[lSoleyl]

Ich bin mir nicht sicher, ob wir mehrere Threads brauchen, die auf die Information zugreifen... Ich bin grad am Überlegen, ob wir sowas, wie eine Gameloop überhaupt benötigen, denn das gesamte Spiel läuft vollständig Event-gesteuert.

• Man darf erst einen Zug machen, wenn ein anderer Spieler in den Bereich geschossen hat für den man selbst zuständig ist. (Außnahme: man beginnt das Spiel)
• Erfährt man von einem Retrieve auf den eigenen Bereich, dann muss man die Information über Treffer/Fehlschuss broadcasten.
• Wenn ein Broadcast ankommt, dann muss man die Information speichern und den Broadcast weiterleiten

Mehr tut das Spiel eigentlich nicht. Wir würden also eigentlich nur den Callback-Thread das ganze Spiel über nutzen.

Aber mal was anderes... Wie stellst du dir das Set<Ships> vor? Wir müssen speichern, an welcher ID(Position) sich die Schiffe befinden, welche IDs bereits mit retrieve abgefragt wurden und welche noch nicht.

[pasndrp]

Ich glaube es würde nicht schaden, wenn wir für die Gamelogic das Chord-Netzwerk so abstrahieren, dass es davon unabhänig läuft. Darum eine art Ship-Klasse, die für die Gamelogic die Lokalisierung versteckt. Wir wissen wieviel Schiffe jeder Teilnehmer hat und Mappen darüber die bekannten Informationen. Wir können dann von der asynchronen Chord-Seite aus das Modell mit Informationen füttern und auf der Seite der Gamelogic dann davon unabhänig mit den Infos spielen.

Ist ein Schiff eigentlich mit einem Treffer gesunken? Oder muss das Intervall abgedeckt werden?

[lSoleyl]

Soweit ich das verstanden habe, sinkt das Schiff mit einem Treffer. Sollten wir aber nochmal nachfragen. Und klar sollten wir das in gewissem Maße abstrahieren... ich hatte jetzt nicht vor, die gesamte Logik des Spiels in die Callback-Methoden reinzuschreiben. ^^"

Was mich ein wenig an der Idee mit dem Schiff-Set stört ist, dass ich nicht weiß, wie du vor hast, alle Informationen darin unterzubringen. Wollen wir uns morgen im Praktikum darüber Gedanken machen, oder willst du heute Abend noch was machen?

[pasndrp]

Von mir aus morgen, da ich jetzt unterwegs bin.

Ich stelle mir das folgendermaßen vor:

Das Set aus Schiffen beschreibt die bekannten Positionen von Schiffen. Sobald aus einem Broadcast ein Schiff eines Spielers bekannt wird, schreiben wir aus dem Callback ein neues Schiffs-Objekt in die Map. Die Gamelogic kann dann die positions Informationen benutzen um auf die verbliebenen Schiffe zu schießen.

Nach meinem Verständnis müssen wir uns nur die ID Ranges der bekannten und versenkten Schiffe pro Spieler merken. Dazu dann die gesamte Range pro Spieler. Dann können wir uns ein Verfahren überlegen, nach dem wir auf verbleibende Schiffe schießen.

Denke ich da zu einfach?

[lSoleyl]

Das Set aus Schiffen beschreibt die bekannten Positionen von Schiffen.

Warum ein Set? Ein Set hat "eigentlich" keine Ordnung und man hat keinen Indexzugriff auf die Elemente. Das Intervall ist aber schon geordnet und ein einfaches Array scheint mir das, was wir modellieren wollen, konsistenter abzubilden.

Nach meinem Verständnis müssen wir uns nur die ID Ranges der bekannten und versenkten Schiffe pro Spieler merken.

Naja, es wäre auch hilfreich, sich zu merken, wo man denn bereits hingeschossen hat (auch wenn da kein Schiff war).

Ich würde sagen, wir brauchen einfach ein Array pro Spieler, das so viele Elemente hat, wie der Spieler Teilintervalle hat. Das können wir dann mit einem Enum aus: UNKNOWN, SHIP, NOTHING füllen. Damit wüssten wir, welche Felder von welchem Spieler beschossen wurden (und ob es ein Schiff war, oder nicht) und welche noch unbekannt sind. Mehr Informationen bekommen wir doch nicht soweit ich das sehe.

---

Wenn es noch irgendwie interessant wäre, könnten wir auch mitspeichern, welcher Spieler auf welches Feld geschossen hat... Ich weiß nur nicht, welche Informationen wir daraus gewinnen. Eine spontane Idee wäre: Sich zu merken, welcher Spieler am meisten Schiffe getroffen hat, und gezielt nicht in seinen Bereich zu schießen (denn er scheint eine gute Strategie zu haben und wenn kein Schuss in seinen Bereich geht, dann kann er laut dem Protokoll selbst nicht schießen).

[pasndrp]

Stimmt, die Fehlschüsse hatte ich vergessen. Ich bestehe auch keineswegs auf das Set, es war nur als ein Platzhalter für eine belibige Collection gedacht. Wenn man die Fehlschüsse mit einbezieht stimme ich deiner Enum-Array-Idee uneingeschränkt zu.

Ein Schiff belegt doch dann ein gesamtes Intervall? Wenn wir also den Adressraum eines Spieler kennen und auch die anzahl der Intervalle allgemein bekannt ist, können wir dann einen einzelnen Treffer auf ein ganzes Intervall beziehen, oder sehe ich das Falsch?

Ist es dann von der Gamelogic nicht auch möglich, nur Intervalle als ganzes zu betrachten? Dann sparen wir uns ein unnötig langes Array.

[lSoleyl]

Ja, das hatte ich prinzipiell so vor. Laut Aufgabenstellung hat jeder Spieler 100 Teilintervalle mit 10 Schiffen. Also wäre das Array pro Spieler 100 Elemente groß.

Wenn wir jede ID in dem Array speichern wollten, würden wir ganz schnell Speicherprobleme bekommen (der ID-Raum ist einfach zu groß). Das geht natürlich nur, wenn das Schiff nur an genau einer ID liegt und nicht mehrere belegt. Das hängt davon ab, ob ein Schiff mit einem Schuss versenkt wird und wie es generell abgelegt werden soll.

Dazu habe ich mir bereits TODOs in den Code geschrieben, um die Fragen morgen dann zu klären.