Technische Akademie Wuppertal / Zentrum Audiovisuelle Medientechnik (TAW/ZAM)
Anwendungsentwickler Inter- / Intranet
Projektarbeit "Diplomacy-Online"
Ein Strategiespiel um die Vorherrschaft in Europa
von Andreas Seier
nähere Infos unter:
http://aseier.de/Diplomacy
Stand: 22. Februar 2002
Projektarbeit "Diplomacy-Online"
Projektentwurf
Das Computer-Spiel "Diplomacy-Online" ist eine Umsetzung des Strategie-Brettspieles "Diplomacy" der Firma PARKER, ? 1993 Tonka Corporation, nach den von Christian Jentzsch überarbeiteten Spielregeln (Heute wird das Brettspiel von der Firma Hasbro vertrieben - nähere Infos unter: http://www.avalonhill.com/default.asp?x=games_diplomacy). Bei diesem Strategiespiel streiten sieben europäische Mächte (Countries), die von jeweils einem Mitspieler (Players) kontrolliert werden, zu Beginn des 20. Jahrhunderts um die Vorherrschaft in Europa.
Europa ist dazu in Land- und See-Gebiete (Land- & Sea-Provinces) gegliedert. Jede Macht verfügt über militärische Einheiten (Units), wobei diese Einheiten entweder Armeen darstellen, die sich in Land-Gebieten, oder Flotten, die sich in See-Gebieten und in Land-Gebieten mit Küste aufhalten können. In jedem Gebiet kann sich jeweils nur maximal eine Einheit aufhalten, die damit dieses Gebiet besetzt. Eine Reihe der Landgebiete beinhalten des weiteren Versorgungszentren (Centers), deren Besetzung durch Einheiten darüber entscheidet, über wie viele Einheiten eine Macht verfügt.
Der Spielablauf gliedert sich in Halbjahre (Frühjahr und Herbst), beginnend mit dem Frühjahr 1901. Ein Habjahr besteht aus folgenden Phasen:
Verhandlungsphase (Phase 0), in der die Spieler frei miteinander kommunizieren und unverbindlich ihre Spielzüge absprechen können (Diplomacy-Phase).
Spielzugsphase (Phase 1a), in der die Spieler festlegen, welche Befehle (Orders) Sie Ihren Einheiten erteilen. Alle Einheiten haben folgende Zugmöglichkeiten:
Halten (Hold): Die Einheit bleibt in dem Gebiet, in dem sie steht.
Bewegen/Angreifen (Move/Attack): Die Einheit wird in ein benachbartes Gebiet gezogen. Armeen können auch von einem Land-Gebiet mit Küste aus mit Hilfe des Geleits einer oder mehrerer Flotte über ein oder mehrere See-Gebiet hinweg in ein Land-Gebiet mit Küste gezogen werden.
Unterstützen (Support): Die Einheit selbst bleibt in dem Gebiet, in dem sie steht, und unterstützt die Bewegung oder das Halten einer anderen Einheit. Support-Befehle entscheiden in Konflikt-Fällen (mehr als eine Einheit versuchen ein Gebiet zu besetzen) darüber, welche Einheit das Gebiet besetzen darf.
Geleiten (Convoy): Dieser Befehl kann nur Flotten erteilt werden, die sich in einem See-Gebiet aufhalten. Die geleitende Flotte selbst bleibt in dem Gebiet, in dem Sie steht, und ermöglicht einer Armee eine Bewegung von einem Land-Gebiet mit Küste über sein Seegebiet (und eventuelle weitere) hinweg in ein anderes Land-Gebiet mit Küste.
Spielzugsauswertungsphase (Phase 1b), in der alle erteilten Befehle aller Spieler gleichzeitig ausgewertet werden.
Rückzugsphase (Phase 2a), in der die Spieler festlegen, in welche Gebiete sie ihre erfolgreich angegriffenen Einheiten zurück ziehen, bzw. ob diese aufgelöst werden sollen.
Rückzugsauswertungsphase (Phase 2b), in der die Rückzugs-Befehle aller Spieler gleichzeitig ausgewertet werden.
Aufbauphase (nur in der Herbstrunde) (Phase 3a), in der die Spieler festlegen, wo sie abhängig von der Anzahl der beherrschten Versorgungszentren, neue Einheiten aufbauen, bzw. abbauen.
Aufbauauswertungsphase (Phase 3b), in der die Auf- und Abbau-Befehle der Spieler gleichzeitig ausgewertet werden.
Am Ende jeder Auswertungsphase erhalten die Spieler eine Übersicht über die Auswertung und den daraus resultierenden Spielstand.
Die vollständigen Spielregeln, sowie die Spielkarte und Links zu anderen Diplomacy-Spielen im Internet finden sich unter: http://aseier.de/Diplomacy
Pflichtkriterien
"Diplomacy-Online" soll als Client- / Server-Lösung realisiert werden.
Der Server übernimmt dabei die gesamte Steuerung des Spielablaufs. Auf dem Server werden Spiele eingerichtet und müssen sich Spieler für ein Spiel anmelden. Der Server sendet den Spielstand an die angemeldeten Spieler, nimmt Mitteilungen von Spielern an andere Spieler in der Verhandlungsphase entgegen und leitet diese entsprechend weiter, nimmt Spielzug-, Rückzugs- und Aufbau-Befehle der Spiele entgegen, wertet diese Befehle aus und erstellt einen neuen Spielstand. Des weiteren ist er für die dauerhafte Speicherung der Spielstände und -verläufe (Produktdaten) verantwortlich.
Der Client ist das User-Interface (UI) für die Mitspieler. Diese UI nimmt die Anmeldedaten, Spielzüge, Mitteilungen an andere Mitspieler des Spielers entgegen, sendet diese an einen ausgewählten Server. Im Gegenzug nimmt er die Datenpakete, die ihm der Server sendet entgegen (Anmeldungsbestätigungen, Mitteilungen der Mitspieler, Spielstände) und stellt diese dar. Der Client soll, da er eventuell als Java-Applet realisiert werden soll, keine Produktdaten dauerhaft speichern, sondern diese immer bei Bedarf vom Server anfordern.
Nach meinen bisherigen Nachforschungen gibt es Spielergemeinschaften im Internet, die Diplomacy bzw. Varianten davon mit anderen Karten über das Netz spielen. Dabei handelt es sich um pbe-Spiele (play-by-eMail). Die Mitspieler kommunizieren untereinander und mit der auswertenden Stelle (dem Judge) via eMail. Als Judge fungieren entweder reale Personen oder Serverprogramme, die in der Lage sind, die eingegangenen eMails an den Judge automatisch einzulesen, auszuwerten und Spielstände per eMail zu versenden, bzw. Spielstände und ganze Spielverläufe auf einem Web-Server abzulegen. Des weiteren existieren Visualisierungsprogramme (u.a. auch in Java), die die formalisierte ASCII-Ausgabe der Judge-Server in Form einer graphischen Karte visualisieren. Diese Visualisierungstools können entweder von den Spielern eingesetzt werden, bzw. werden direkt von Judge-Servern ausgerufen, um die angesprochenen Web-Spielstands-/verlaufs-Seiten zu generieren.
Aufgrund der Tatsache, dass Visualisierungstools existieren und für die Grundfunktionalität des Projekts nicht unbedingt erforderlich sind (auch wenn sie die Attraktivität des Produkts deutlich steigern würde), wird das UI erst einmal keine Visualisierung der Spielstände vorsehen. Die Eingabe der Spielzüge soll jedoch dahingehend vereinfacht werden, dass der Server im Rahmen der Übermittlung der Spielstände auch Listen aller möglichen Zugoptionen für die einzelnen Einheiten mitliefert, aus denen der Spieler nur noch die gewünschten Befehle für seine Einheiten auswählen kann. Dies verhindert auch die Eingabe von nicht gültigen Befehlen.
Auf Seiten des Servers steht erst einmal die Kommunikationsfähigkeit mit den Spieler-Clients im Vordergrund des Projekts. Die Auswertungsfunktionalität des Servers wird im Rahmen dieses Projekts als zweitrangig angesehen, da zum einen schon Judge-System existieren und zum anderen integrierte Kommunikationssysteme zwischen Server (Judge) und Client (Player) fehlen. Nichts desto trotz halte ich die Auswertungsfunktionalität für wichtig, aber für unrealistisch, im Rahmen der kurzen Projektzeit zu realisieren.
Aus der Darstellung der Pflichtkriterien ergeben sich die Wunsch- und Abgrenzungskriterien dieses Projekts. Als Wunschkriterien werde daher angesehen:
Auswertungsfunktionalität des Servers
Als Abgrenzungskriterien gilt:
Visualisierung des Spielstände und -verläufe
Netzwerk-Sicherheitsaspekte (z.B. verschlüsselte Übetragung)
Zielgruppe sind natürlich alle Leute, die gerne Strategiespiele spielen. Da davon auszugehen ist, dass sich ein Spiel über längere Zeiträume hinstrecken können (bei Setzung eines virtuellen Diplomacy-Halbjahres auf eine reale Woche und ca. 15 zu spielenden Diplomacy-Jahren, resultieren ca. 30 Wochen reale Spielzeit), sind natürlich ausdauernde Mitspieler gefragt.
Das Spiel soll in lokalen Netzwerken gespielt werden können (z.B. als Nebenbeschäftigung während eines TAW-Kurses) oder aber auch im Internet.
JRE 1.3 auf Server- und Client-System
TCP/IP-Verbindung zwischen Server und Client
Zugriff des Servers auf ein permanentes Speichermedium (Festplatte)
Beim Starten des statischen Teils des Servers sind folgende Schritte erforderlich:
Auslesen des Basis-Verzeichnisses aus der Liste der übergebenen Parameter (wenn keine Parameter vorhanden, dann unter Vorgabe des aktuellen Verzeichnisses beim Anwender abfragen)
Basis-Verzeichnisses event. neu anlegen
Einlesen des Server-Objekte aus dem Basis-Verzeichnis, wenn nicht existent, neues Server-Objekt anlegen.
Beim Starten des Server-Objekts laufen folgende Schritte ab:
Einlesen der vorhandenen Karten aus dem Basis-Verzeichnis
Einlesen und Starten der vorhandenen Spiele aus dem Basis-Verzeichnis
... weiteres am Montag
Beim Starten des Clients sind folgende Schritte erforderlich:
Eingabe der Server-IP und des Ports
event. Registrierung eines neuen Spielers bei einem Server unter Angabe eines Spielernamens, Passwortes, eMail-Adresse, Wohnort
Anmeldung bei einem Server mit bestehendem Spielernamen und Passwort
Registrierung und Anmeldung werden an den Server gesendet. Dieser bestätigt die Anmeldung / Registrierung , bzw. weist sie zurück.
Bei Zurückweisung oder bei Fehlern des Verbindungsaufbaus wird die Startfolge wiederholt.
Bei Bestätigung der Anmeldung sendet der Server
eine Liste der laufender Spiele,
eine Liste der auf Mitspieler wartender Spiele,
eine Liste der auf dem Server existierender Karten,
eine Liste aller registrierten Spieler mit Angabe, ob diese online sind,
die Spielauswertungen und -stände der Spiele, für die sich der Spieler angemeldet hat und
noch nicht abgerufene Mitteilungen anderer Mitspieler.
Bei Aufrechterhaltung der Verbindung sendet der Server bei Bedarf (d.h. bei Änderungen) aktualisierte Listen und Spielstände.
Aus der Liste der laufenden Spiele kann sich der Spieler Spiele auswählen, um sich den Spielstand anzeigen zu lassen. Die Auswahl wird an den Server gesendet, der wiederum den entsprechenden Spielstand zurückliefert. Der Client zeigt dann den Spielstand an.
Aus der Liste der auf Mitspieler wartender Spiele kann sich der Spieler ein Spiel auswählen, an dem er sich beteiligen möchte. Auch diese Auswahl wird an den Server gesendet. Dieser bestätigt die Spielbeteiligung oder weist sie zurück (vielleicht war jemand schneller mit der Anmeldung). Als Bestätigung wird der Spielstand gesendet.
Aus der Liste der auf dem Server existierenden Karten kann der Spieler eine Karte auswählen, um unter Angabe weiterer Parameter (Dauer der Spielrunden und -phasen, Spielname) ein neues Spiel zu eröffnen. Die Auswahl wird an den Server gesendet, der wiederum kann die Eröffnung bestätigen oder abweisen.
Aus der Zusendung der Spielstände von Spielen, an denen der Spieler beteiligt ist, ergeben sich unterschiedliche Handlungsanforderungen an den Spieler abhängig davon, welche Phase des Spiels gerade ansteht.
Bei einem noch nicht eröffneten Spiel, d.h. einem Spiel das auf weitere Mitspieler wartet, kann sich der Spieler wieder abmelden.
In Phase 0 kann der Spieler Nachrichten, die an andere Mitspieler gerichtet sind, eingeben und an den Server senden. Der Server sendet diese Mitteilungen entweder direkt an die entsprechenden Mitspieler, soweit diese Online sind, weiter, bzw. hält die Nachricht bis zum nächsten Login des Mitspielers vor, um sie dann weiterzuleiten. Der Absender erhält eine Bestätigung, sobald die Mitteilung zugestellt werden konnte.
In Phase 1a, 2a und 3a kann der Spieler die Befehle an seine Einheiten auswählen und an den Server senden. Hat der Spieler seinen Befehle schon gesendet, so hat er die Möglichkeit, diese erneut auszuwählen und zu senden. Gültig ist immer der zum Auswertungszeitpunkt zuletzt gesendete Befehlssatz. Sendet der Spieler keinen Befehlssatz vor dem Beginn der anschließenden Auswertungsphase, so geht der Server in Phase 1 davon aus, dass alle Befehle auf HALTEN gesetzt sind, in Phase 2, dass alle Befehle auf REMOVE gesetzt sind und in Phase 3, dass keine neuen Einheiten aufgebaut werden, bzw. wählt die abzubauenden selbst aus.
In Phase 1b, 2b, 3b erhält der Client wohl vom Server eine Mitteilung darüber und noch den aktuellen Spielstand, jedoch hat der Spieler keine Möglichkeit, Eingaben an den Server zu senden.
Für die permanente Sicherung der Produktdaten ist der Server zuständig. Die Clients nehmen keine permanente Produktdatensicherung vor.