MS_00

Zusammenfassung des Systempraktikums zur Entwicklung eines Neunermühle-Clients

Überblick

Dieses Dokument fasst die Anforderungen und Vorgaben für die Entwicklung eines Clients für das Spiel Neunermühle im Rahmen des Systempraktikums der Ludwig-Maximilians-Universität München zusammen. Der Client soll in der Programmiersprache C entwickelt werden und mit einem bereitgestellten Gameserver sowie einem Webinterface interagieren.

Projektphasen

Das Systempraktikum ist in zwei Hauptphasen unterteilt:

1. Prolog: Beitritt zum Spiel und Austausch von Spielinformationen.
2. Spielverlauf: Verwaltung des Spiels, einschließlich Idle-Zeiten, Zügen und Spielende.
3. Spielzug: Übermittlung und Verarbeitung von Spielzügen.

Systemkomponenten

Gameserver

• Implementiert den Spielablauf und fungiert als Spielleiter.
• Verantwortlich für die Einhaltung der Spielregeln.
• Stellt eine zeilenorientierte TCP-Verbindung zur Verfügung.

Webinterface

• Zugang unter http://sysprak.priv.lab.nm.ifi.lmu.de.
• Ermöglicht die Verwaltung von Partien.
• Bietet die Möglichkeit, als menschlicher Mitspieler an Partien teilzunehmen (Beobachter oder Mitspieler).
• Nur über das MWN1-Netzwerk erreichbar (z.B. via SSH-Tunnel).

Clientarchitektur

Der zu entwickelnde Client besteht aus zwei Prozessen:

1. Thinker

   • Berechnet den nächsten Spielzug.
   • Empfängt Signale vom Connector und liest Informationen aus dem gemeinsamen Speicherbereich.
   • Sendet das berechnete Spielzug-Ergebnis über eine unnamed Pipe an den Connector.

2. Connector

   • Verantwortlich für die Kommunikation mit dem Gameserver.
   • Verarbeitet Anfragen vom Gameserver und teilt Informationen dem Thinker mit.
   • Sendet berechnete Spielzüge an den Gameserver.

Übersicht der Client-Komponenten

Thinker Connector
    Spielfeld / Infos
    Shared Memory
    Bereich
    (Pipe)
    Übertragung Spielzug
    Denkanstoß
    (Signal)
    TCP Verbindung
    zum Server

Kommunikationsprotokoll

Der Client kommuniziert mit dem Gameserver über ein zeilenorientiertes TCP-Protokoll. Jede Zeile endet mit einem Newline-Zeichen (\n).

Verbindungsdetails

• Hostname: sysprak.priv.lab.nm.ifi.lmu.de
• Port: 1357 (TCP)

Antwortkennzeichen

• Positive Antwort: Zeile beginnt mit +
• Negative Antwort: Zeile beginnt mit - gefolgt von einer Fehlermeldung. Anschließend wird die Verbindung getrennt.

Protokollphasen

1. Prolog
2. Spielverlauf
3. Spielzug

1. Prolog

• Verbindungsaufbau:

  • Server: + MNM Gameserver <Version> accepting connections
  • Client: VERSION <Client Version>
  • Server: + Client version accepted - please send Game-ID to join
  • Client: ID <Game-ID>
  • Server:
    • + PLAYING <Gamekind-Name>
    • + <Game-Name>
  • Client: PLAYER [[ Gewünschte Mitspielernummer ]]
  • Server:
    • + YOU <Mitspielernummer> <Mitspielername>
    • + TOTAL <Mitspieleranzahl>
    • Für jeden Mitspieler:
      • + <Mitspielernummer> <Mitspielername> <Bereit>
    • + ENDPLAYERS

• Versionierung:

  • Major-Versionsnummern müssen übereinstimmen (z.B., v2.x).
  • Inkompatible Versionen führen zum Abbruch.

• Spielart:

  • Gamekind-Name muss NMMorris sein, sonst Abbruch mit Fehlermeldung.

2. Spielverlauf

Enthält drei mögliche Befehlssequenzen:

2.1 Idle Befehlssequenz

• Server: + WAIT
• Client: OKWAIT

Hinweis: WAIT-Befehle müssen regelmäßig bestätigt werden, sonst wird die Verbindung getrennt und die Partie als verloren gewertet.

2.2 Move Befehlssequenz

• Server:

  • + MOVE <Maximale Zugzeit>
  • + CAPTURE <Anzahl zu schlagender Steine>
  • + PIECELIST <Anzahl Mitspieler>,<Anzahl Steine>

• Für jeden Spielstein:

  • + PIECE<Mitspielernummer>.<Steinnummer> <Position>

• Ende der Liste:

  • + ENDPIECELIST

• Client:

  • THINKING

• Server:

  • + OKTHINK

Anforderungen:

• Berechnung des Spielzugs innerhalb der angegebenen maximalen Zugzeit unter Berücksichtigung der Verbindungs-Latenz.
• Positionsangaben der Spielsteine:
  • A: Verfügbar
  • A0 - C7: Auf dem Feld positioniert
  • C: Geschlagen

2.3 Game Over Befehlssequenz

• Server:

  • + GAMEOVER
  • + PIECELIST <Anzahl Mitspieler>,<Anzahl Steine>

• Für jeden Spielstein:

  • + PIECE<Mitspielernummer>.<Steinnummer> <Position>

• Ende der Liste:

  • + ENDPIECELIST

• Server:

  • + PLAYER0WON <Yes|No>
  • + PLAYER1WON <Yes|No>
  • + QUIT

Hinweise:

• Spiel kann in einem Sieg, einer Niederlage oder einem Unentschieden enden.
• Nach QUIT wird die Verbindung vom Server abgebaut.

3. Spielzug

• Client: PLAY <Spielzug>
• Server: + MOVEOK

Spielzug-Format:

• In der ersten Phase: Name des Zielfeldes (z.B., A1)
• Bei CAPTURE: Feld des zu schlagenden Steins (z.B., B4)
• Bei Ziehen/Springen: Von:FeldZu (z.B., A1:B4)

Fehlerbehandlung:

• Ungültige Spielzüge führen zu einer Fehlermeldung und Trennung der Verbindung.

Bugreports

• Fehlermeldungen: Meldung unter https://gitlab.lrz.de/sysprak/frontend/issues unter Verwendung der passenden Meldevorlage.
• Organisatorische Anliegen: Kontakt per E-Mail an sysprak-admin@nm.ifi.lmu.de.

Zusätzliche Ressourcen

• MWN Informationen: http://www.lrz.de/services/netz/
• SSH Informationen: https://www.rz.ifi.lmu.de/infos/ssh_de.html
• Spielregeln: http://sysprak.priv.lab.nm.ifi.lmu.de/help/

Diagramme

• Abbildung 1: Übersicht über den Client
• Abbildung 2: Protokollübersicht

Hinweis: Die Abbildungen sind in der Original-PDF enthalten und bieten eine visuelle Darstellung der Clientstruktur und des Kommunikationsprotokolls.

---