Multiplayer Kartenspielsystem Lastenheft

Transkript

1 SEP Informatik Wintersemester 2013/2014 Multiplayer Kartenspielsystem Stefan Löwe, Janet Siegmund, Norbert Siegmund, Andreas Stahlbauer, Philipp Wendler 1 Eine kurze Bemerkung vorab Dies ist Euer Praktikum. Dieses Dokument ist kein Katalog von Aufgaben, der Punkt für Punkt abgearbeitet werden muss, um das SEP zu bestehen, sondern lediglich eine Reihe von Hinweisen, was wir erwarten. Es ist aus diesem Grund knapp gehalten. Wie Euer Programm nachher aussieht, müsst Ihr selbst entscheiden. 2 Motivation Multiplayer-Spiele genießen eine immer größer werdende Beliebtheit. Eines der frühsten Spiele dieser Art ist das Kartenspiel Hearts, welches seit Jahren mit jeder Windows-Installation ausgeliefert wird. Ein Kartenspiel wie eben z.b. Hearts vereint dabei mehrere für Informatiker interessante Herausforderungen: Zum Einen muss das Model-View-Controller Prinzip realisiert werden, um die eigentliche Logik (die Spielregeln von Kartenspielen) von der Oberfläche zu entkoppeln. Dies ermöglicht enorme Flexibilität und Erweiterbarkeit. Eine zweite Herausforderung stellt die Netzwerkkommunikation mit den damit verbundenen Multi-Threading-Anforderungen dar. Insbe-

2 sondere die Synchronizität der Daten und die Abfolge der Spiellogik muss beachtet werden. Daher ermöglicht die Realisierung des Spiels das Kennenlernen von unterschiedlichen Technologien (Multi Threading, Kommunikation, GUI Programmierung, Design Patterns). 3 Aufgabenstellung Ziel des SEP im Wintersemester 2013 ist es, eine Art Hearts-Klon zu entwickeln. Spieler sollen die Möglichkeit haben in einer Lobby eine Spielauswahl vorzunehmen, um gegeneinander antreten zu können. Die Kommunikation läuft dabei über einen zentralen Server, der mehrere Spiele gleichzeitig sowie die Lobby verwalten soll. Bei jedem Spiel muss der Server die Regeln auswerten, um nur legale Züge zuzulassen und das Spiel unter den einzelnen Teilnehmern zu koordinieren. Der Klient soll neben der Darstellung der Lobby ebenfalls das aktuelle Spiel grafisch anschaulich darstellen. Dabei müssen die eigenen Spielkarten, die verdeckten Karten der Mitspieler, und der Kartenstapel dargestellt werden. Hinzu kommt eine Möglichkeit mit den Mitspielern zu chatten. Als besondere Spielhilfe soll der Klient eine Vorab- Regelauswertung ermöglichen, damit der Benutzer sofort Feedback darüber bekommt, welche Spielzüge möglich sind. Das Kartenspiel an sich soll variabel gestaltet werden. Der Spieler soll die Möglichkeit bekommen aus mehreren (zu implementierenden) Kartenspielen auszuwählen. Daher soll bereits frühzeitig auf eine einfache Erweiterbarkeit / Austauschbarkeit des Regelsystems sowohl auf dem Klienten als auch auf dem Server geachtet werden. Die Anwendung muss mit Java 7 und Swing entwickelt werden. Besonders ist die Anwendung des Model-View-Controller-Patterns von Bedeutung. Ebenfalls sollen andere wichtige Design Patterns, wie z.b. das Observer Pattern, bei der Realisierung berücksichtigt werden. Die Netzwerkkommunikation soll per Java-Objektserialisierung erfolgen. 4 Produkteinsatz Zielgruppe der Anwendung sind Personen, die gemeinsam über ein lokals Netzwerk oder das Internet spielen möchten. Auch der Einsatz bei Turnieren im Freundeskreis oder z.b. im Rahmen von Veranstaltungen von Hochschulgruppen soll möglich sein. 5 Produktfunktionen 5.1 Begriffsdefinitionen Regelwerk Das Regelwerk definiert die zugrundeliegende Logik eines bestimmten Kartenspiels. Dabei muss u.a. die Anzahl der Spieler, die Reihenfolge der Spielerzüge, die (un-)erlaubten Züge, die Ausgabe von Karten und die Siegesbedingungen 2

3 definiert werden. Ebenfalls enthält das Regelwerk die Funktionalität, um die Auswirkungen eines Zuges zu berechnen. Client Der Client stellt eine Plattform zur Benutzerinteraktion und zur Kommunikation mit dem Server dar. Dabei ist zwischen der Oberfläche und der Logik zu unterscheiden. Die Oberfläche dient zur Darstellung des aktuellen Standes eines Spiels, als Kommunikationsmittel mit anderen Spielern, sowie als Lobby zur Auswahl eines Spieles. Dabei werden die Aktionen in der Oberfläche an die darunter liegende Logik weitergeleitet. Die Oberfläche soll daher unabhängig von den jeweiligem Regelwerk sein. Die Logik dient zur Vorberechnung von Zügen, sodass eine Art Vorschau ermöglicht werden soll. Server Der Server dient zur Bereitstellung und Verwaltung aller Spiele. Er muss sowohl den internen Zustand aller aktuell laufenden Spiele speichern, die Spiele zu den gewählten Regelwerk zuordnen, die Kommunikation zwischen den Spielern koordinieren und den Spielstand synchron für alle Klienten halten. Spiel Ein Spiel wird auf dem Server von einem Spieler angelegt. Daraufhin erscheint dieses Spiel in der Lobby jedes eingeloggten Spielers. Ein Spiel beginnt sobald alle Plätze vergeben sind oder der Spielleiter das Spiel startet und die Minimalanzahl der Spieler für das jeweilige Regelwerk erfüllt sind. Das Spiel speichert den gerade aktuellen Zustand bzgl. des Regelwerkes. Ein Spiel umfasst mehrere Phasen. Es muss in der Erstellungsphase an ein bestimmtes Regelwerk gebunden werden. Dann muss auf die Mindestanzahl von Spielern gewartet werden. Sobald alle Anforderungen für ein gültiges Spiel erfüllt sind, kann in die nächste Phase (Ausführung) übergegangen werden. Dabei wird der Startzustand des Spiels mit gewissen Zufallsparametern (z.b. zufällige Kartenverteilung) generiert und entsprechend an die teilnehmenden Spieler aufgeteilt. Es wird eine bestimmte Reihenfolge festgelegt (anhand des Regelwerks) und die Aktionen für den jeweilig aktiven Spieler ermöglicht. In dieser Phase muss der Server das jeweilige Spiel so koordinieren, dass alle Zustände und Zustandsübergänge konform zum Regelwerk ablaufen und diese an alle Teilnehmer mitteilen. Es muss ebenfalls geprüft werden, ob die Siegbedingung erfüllt ist. Ist dies der Fall, so tritt das Spiel in die 3. Phase (Auswertung). Bei der Auswertung werden (optional) entsprechend Punkte verteilt, der Sieger ermittelt und die Spieler werden in die Lobby zurück delegiert. 5.2 Minimale Leistungsmerkmale Server Clients können sich verbinden und eindeutigen Benutzernamen auswählen Lobby mit der Möglichkeit, Spiele zu erstellen und offenen Spielen beizutreten Unterstützung mehrere parallel laufender Spiele 3

4 Regelauswertung mit Überprüfung erlaubter Aktionen, Punktezählung, Kartenausgabe, etc. Unterstützung der Spiele Hearts 1 und Wizard 2 Chat in der Lobby Chat mit Mitspielern während eines Spiels Schutz vor Cheats Client GUI: Modell: Darstellungsfenster, das mindestens bei der Auflösung von 1024x768 Bildpunkten benutzt werden kann Darstellung des laufenden Spiels (eigene Hand, verdeckte Hand der anderen Spieler, Ablage- und Aufnahmestapel, Punktestand, evtl. Zusatzinformationen) Eingabemöglichkeiten für erlaubte Aktionen während des Spiels (Karte ablegen, Ansagen, etc.) Die GUI muss den Benutzer sinnvoll unterstützen und benutzerfreundliche Eingabeelemente anbieten Flüssige Darstellung Unabhängigkeit vom Regelwerk Beim Start Auswahl des Servers und des Benutzernamens Anzeige von offenen Spielen in der Lobby mit Möglichkeit zum Erstellen und Beitreten Chat in der Lobby und während des Spiels Verwaltung der Verbindung mit dem Server Verwaltung des aktuellen Spielzustands (soweit Client bekannt) Vorab-Regelauswertung zur Unterstützung des Nutzers (ungültige Spielaktionen sind nicht durchführbar in der GUI)

5 5.3 Optionale Leistungsmerkmale Folgende Ideen können als Anstoß für eigene Erweiterungen des Programms dienen: Weitere Regelwerke Regelwerke mit auswählbaren Spezialregeln Registrierung von Benutzern im Server High-Scores über mehrere Spiele hinweg Statistiken zu Spielen Mehrsprachenfähigkeit Animierte Oberfläche KIs 6 Organisatorisches Für jede Phase des Praktikums muss ein Phasendokument abgegeben werden. Dieses Dokument ist Grundlage für das Kolloquium am Ende jeder Phase, in dem der Phasenverantwortliche die Ergebnisse der Phase vorträgt. Die genauen Termine entnehmt bitte der Homepage 3. 7 Bewertung Die Benotung des SEP richtet sich nach folgenden Kriterien: Qualität aller abgegebenen Dokumente Qualität der Kolloquien und der Individualleistung in wöchentlichen Meetings Qualität der Abschlusspräsentation Erfüllung der minimalen Leistungsmerkmale (s.o.) Sinnvolle Erweiterungen über diese Merkmale hinaus Robustheit des erstellten Programms Diese Liste hat keine Reihenfolge, die einer Gewichtung entspricht. Es gibt sicherlich weitere Punkte, die als selbstverständlich gelten und sich bei Nichterfüllen negativ auswirken (z.b. sollte die Bedienung möglichst einfach von der Hand gehen). Umgekehrt wirkt sich eine besonders gute Erfüllung einer Anforderung natürlich positiv aus. Viel Erfolg und vor allem viel Spaß! 3 5