
Specification
Anwendungsfall-Diagramme
Die folgenden Diagramme zeigen die umszusetzenden Anwendungsfälle. Das erste Diagramm (Top Level), beschreibt die allgemeinen Fälle. Die anderen beiden Diagramme zeigen eine Detailansicht der Anwendungsfälle "Spiel konfigurieren" und "Spiel spielen".
Anwendungsfalldiagramm 1, "Top Level"
Anwendungsfalldiagramm 2, "Spiel konfigurieren"
Anwendungsfalldiagramm 3, "Spiel spielen"
Anwendungsfall-Beschreibung
In diesem Abschnitt werden die Anwendungsfälle so genau wie möglich beschrieben. Dazu werden Vorbedingungen und Nachbedingungen im Erfolgs- bzw. im Fehlerfall angegeben. Auf dieser Grundlage entwickeln wir anschließend die Klassen und entscheiden welche Datenstrukturen einzusetzen sind.1.0 Programm starten
Beim Start des Programms werden sowohl die wichtigen Parameter des Spiels vordefiniert als auch die Geometriedaten geladen. Auf diese Weise ist es später schneller möglich, ein Level neu zu starten. Außerdem kann können wir so im Programm davon ausgehen, das alle benötigten Variablen richtig initialisiert wurden. Insgesamt gibt es hier drei Subtasks:1.1 Einstellungen laden | |
Beschreibung |
Lädt die Grundeinstellungen aus der Konfigurationsdatei "config.ini" in die globalen Variablen resolution , level und highscore . Ist die Datei nicht vorhanden, wird sie angelegt.
|
Vorbedingung |
|
Algorithmus | |
Nachbedingung Erfolg |
|
Nachbedingung Fehlschlag |
|
1.2 Modelle Laden | |
Beschreibung | Lädt die Modelldateien von Bomben, Bonusitems und Quax in eine Datenstruktur und überträgt sie in den Grafikspeicher. |
Vorbedingung |
|
Algorithmus | |
Nachbedingung Erfolg |
|
Nachbedingung Fehlschlag |
|
1.3 Bildschrim initalisieren | |
Beschreibung |
Initialisiert den Startbilschirm des Spiels mit dem gewählten Parameter resolution .
|
Vorbedingung |
|
Algorithmus | |
Nachbedingung Erfolg |
|
Nachbedingung Fehlschlag |
|
Wenn alle drei Anwendungsfälle ausgeführt wurden, ist das Spiel fertig initialisiert. Da wir noch nicht wissen, welches Level der Nutzer wählt, können wir das Spielfeld erst später erzeugen.
2.0 Spiel konfigurieren
Anwendungsfall 2 beschreibt die Optionen des Startbildschrims. Sinnvoll wäre hier evtl. eine Menüklasse, zur Anzeige der Optionen, Anzeige der Spielevents/ Goodies im eigentlichen Spiel und der Hilfsausgaben (Framerate, Grafikoptionen, ...), die von der Übungsleitung verlangt sind.2.1 Schwierigkeitsgrad einstellen | |
Beschreibung | Wahl des Schwierigkeitsgrades der Spielumgebung durch Auswahl eines Parameters "EASY", "MEDIUM" und "HARD". |
Vorbedingung |
|
Algorithmus | |
Nachbedingung Erfolg |
Der Schwierigkeitsgrad wird global geändert (Später wichtig bei der Spielfeld Erzeugung und zum Speichern bei Beendigung des Spiels.). |
Nachbedingung Fehlschlag |
- |
2.2 Highscore ansehen | |
Beschreibung | Zeigt die drei besten Zeiten an (eine pro Schwierigkeits-Stufe). |
Vorbedingung |
|
Algorithmus | |
Nachbedingung Erfolg |
|
Nachbedingung Fehlschlag |
- |
2.3 Spiel starten | |
Beschreibung | Aktiviert die Tasten für die Spiel-Steuerung, setzt die Spielparameter (Verfügbare Markierungen=Easy|Medium|Hard, Verfügbare Goodies=0, AbgelaufeneZeit=0) und erzeugt das Spielfeld. |
Vorbedingung | |
Algorithmus | |
Nachbedingung Erfolg |
Die Spielszene wird mit allen Objekten (Statusanzeige, Spielfeld, Quax) dargestellt und es kann losgespielt werden. |
Nachbedingung Fehlschlag |
- |
2.4 Steuerung ansehen (Hilfeschirm anzeigen) | |
Beschreibung | Eine Hilfe für die Spielbedienung wird eingeblendet |
Vorbedingung |
|
Algorithmus | |
Nachbedingung Erfolg |
|
Nachbedingung Fehlschlag |
3.0 Spiel spielen
3.1 Quax bewegen | |
Beschreibung | Bewegt den Akteur in Abhängigkeit von der gedrückten Taste nach rechts, links, oben, unten oder auf der Stelle (Sprung beim Aufdecken und Bewegung gegen den Spielfeldrand). |
Vorbedingung |
|
Algorithmus | |
Nachbedingung Erfolg |
|
Nachbedingung Fehlschlag |
|
3.1.1 Feld betreten | |
Beschreibung | Färbt das Feld entsprechend der Markierung, wenn der Nutzer es betritt. |
Vorbedingung | |
Algorithmus | |
Nachbedingung Erfolg |
|
Nachbedingung Fehlschlag |
3.2 Feld markieren | |
Beschreibung | Setzt die Markierung eines Feldes in Abhängigkeit der vorhandenen Markierung |
Vorbedingung |
|
Algorithmus | |
Nachbedingung Erfolg |
Der Zustand des Feldes ist entsprechend den Änderungen gesetzt und dem Nutzer wird eine Markierung abgezogen. Hat der Spieler 0 Markierungen über und alle Bomben richtig markiert ist das Spiel gewonnen: der Ausgang öffnet sich. |
Nachbedingung Fehlschlag |
- |
Die Aktion "Feld aufdecken" wird vom Anwender ausgelöst und durch die Spiellogik durchgeführt. Für den Spieler sollte das Aufdecken nur ein Sprung auf der Stelle sein.
3.3.1 Feld aufdecken | |
Beschreibung | Deckt das Feld auf, auf dem der Spieler steht |
Vorbedingung |
|
Algorithmus | |
Nachbedingung Erfolg |
|
Nachbedingung Fehlschlag |
3.3.2 Feld sprengen | |
Beschreibung | Löst Explosion aus und brechnet die Beschriftungen neu |
Vorbedingung |
|
Algorithmus | |
Nachbedingung Erfolg |
|
Nachbedingung Fehlschlag |
3.3.3 Goodie erhalten | |
Beschreibung | Weist dem Spieler/ der Spielumgebung ein Goodie |
Vorbedingung |
|
Algorithmus | |
Nachbedingung Erfolg |
|
Nachbedingung Fehlschlag |
- |
Klassendiagramm
Die oben beschriebenen Funktionen sind auf die Klassen in folgendem Diagramm verteilt.
Klassendiagramm (Idee) (Download Visio Datei)
Beschreibung
Mediator
- ~ dient als Mittler zwischen den einzelnen Programmteilen. Sie hat die Aufgabe, alle Nutzereingaben entgegenzunehmen und entsprechend zu verteilen (Mediator Pattern, nur ohne EventListener). Auf diese Weise brauchen wir die Eingaben nur einmal zentral auszuwerten und können später leicht Veränderungen vornehmen.
GameTile
- ~ ist unsere logische Darstellung eines Spielfeldes. Ein Spielfeld besitzt verschiedene Zustände: einen unsichtbaren Zustand
invisibleState = (CLEAN|BOMB|LIFE|TIMEFREEZER)
und einen sichtbaren ZustandvisibleState = (SIMPLE|BOMBMARKED|BOMBPROPOSED|UNCOVERED)
.Der unsichtbare Zustand wird bei Erzeugung des Feldes im Konstruktor mit angegeben und ändert sich im Verlauf des Spiels, z.B. durch das Aufdecken eines Feldes. Der sichtbare Zustand eines Feldes ist initial "SIMPLE", d.h es ist nicht markiert und nicht aufgedeckt. Dieser Zustand kann durch den Spieler während des Spiels verändert werden.
GameArea
- ~ ist die logische Repräsentation des gesamten Spielfeldes. Sie hält drei Arrays: Das
itemArray
, speichert dieinvisibleStates
der einzelnenGameTiles
. mit Bomben oder Goodies. Die ArraysbombCounterArray
undgoodieCounterArray
speichern jeweils die Beschriftung eines Spielfeldes (Label) und die Anzahl der Goodies in der Nähe eines Feldes. Diese Arrays werden zu Beginn einer Runde erzeugt und um Verlauf der Runde teilweise neu berechnet, um Beschriftungen und Farben neu zu berechnen.Die Kompositionsbeziehung zur
GameTile
bedingt ein weiteres (Klassen) Array, das Referenzen auf die einzelnen Spielfelder speichert. Die einzelnenGameTiles
werden dann mit Hilfe anderen Arrays erzeugt. Character
- ~ ist die logische Darstellung des Spielers. Der Besitzt eine Anzahl von eingesammelten Leben, die bei jeder Explosion um 1 dekrementiert werden.
Bomb
undGoodie
- Die Klassen Bomb und Goodie stellen die Spielelemente dar.
Model
- Ein Modell ist die geometrische Darstellung eines Spielobjektes (Bombe, Spieler, Goodie, Spielfeld). Das Modell kapselt damit die Geometrie, die Textur und die Koordinaten eines Objektes. Zur eindeutigen Identifizierung eines Modells besitzt es
ModelManager
- ~ lädt die Objekte beim Programmstart und verwaltet die einzelnen zu rendernden Objekte während des Spielablaufes. Dazu besitzt der Manager eine Liste mit Referenzen auf die Objekte. In einer weitere Liste werden die Referenzen der drazustellenden Objekte gehalten. Die Rendermethode des Programms braucht somit immer nur den Listeninhalt abarbeiten (geht das so..?).