[print page]

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 1, "Top Level"

Anwendungsfalldiagramm 2, 'Spiel-Konfiguration'
Anwendungsfalldiagramm 2, "Spiel konfigurieren"

Anwendungsfalldiagramm 3, 'Spiel spielen
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
  1. Einstellungsdatei vorhanden
  2. Einträge in der Einstellungsdatei vollständig (Grafikeinstellungen, Schwierigkeitsgrad, Highscore)
Algorithmus

            
Nachbedingung
Erfolg
  1. Die globalen Parameter sind initialisiert und können verwendet werden. .
Nachbedingung
Fehlschlag
  1. Die Einstellungsdatei ist nicht vorhanden und kann auch nicht angelegt werden. Das Programm wird beendet.
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
  1. Alle(!) Modelldateien vorhanden
Algorithmus

            
Nachbedingung
Erfolg
  1. Die Geometriedaten sind in den Grafikspeicher geschrieben und das Programm kann mit einer Referenz darauf zugreifen.
Nachbedingung
Fehlschlag
  1. Eine Modelldatei konnte nicht geladen werden. Das Programm wird mit einer Fehlermeldung beendet.
1.3 Bildschrim initalisieren
Beschreibung Initialisiert den Startbilschirm des Spiels mit dem gewählten Parameter resolution.
Vorbedingung
  1. Auflösung ist auf dem System möglich
Algorithmus

            
Nachbedingung
Erfolg
  1. Der Startbildschirm/ Startmenü mit den gewünschten Parametern erscheint.
Nachbedingung
Fehlschlag
  1. Der gewünschte Modus ist nicht verfügbar. Das Programm wird beendet.

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
  1. Das Spiel ist noch nicht gestartet
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
  1. Das Spiel ist noch nicht gestartet
Algorithmus

            
Nachbedingung
Erfolg
  1. Anzeige aller drei Einträge auf dem Bildschirm
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
  1. Nutzer hat im Startmenü den Eintrag Steuerung gewählt
  2. Nutzer hat im Spiel die Taste F1 gedrückt
Algorithmus

            
Nachbedingung
Erfolg
  1. Das Hilfsmenu wird eingeblendet und das Startmenu ausgeblendet.
  2. Spiel wird angehalten (Siehe UC 3.4) und das Hilfsmenü eingeblendet.
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
  1. Bewegung richtet sich nicht gegen die Kante des Spielfeldes
Algorithmus

            
Nachbedingung
Erfolg
  1. Quax hat sich in die entsprechende Richtung gedreht und entsprechned der Taste bewegt.
Nachbedingung
Fehlschlag
  1. Quax bewegt sich auf der Stelle.
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
  1. Das Feld ist noch nicht aufgedeckt.
  2. Das Feld ist nicht markiert und bekommt die Markierung Bombe
  3. Das Feld ist mit einer Bombe markiert und bekommt die Markierung mögliche Bombe (Das Feld erscheint bis zum Verlassen in blau)
  4. Das Feld ist als mögliche Bombe markiert und bekommt keine Markierung.
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
  1. Das Feld ist noch nicht aufgedeckt
  2. Das Feld ist nicht markiert
Algorithmus

            
Nachbedingung
Erfolg
  1. Beinhaltet das Feld eine Bombe, wird eine Explosion ausgelöst (Fall 3.3.2).
  2. Beinhaltet das Feld ein Goodie, wird dieses dem Spiel gutgeschrieben. (Fall 3.3.3)
Nachbedingung
Fehlschlag
3.3.2 Feld sprengen
Beschreibung Löst Explosion aus und brechnet die Beschriftungen neu
Vorbedingung
  1. Feld das eine Bombe enthält wurde aufgedeckt.
Algorithmus

            
Nachbedingung
Erfolg

            
Nachbedingung
Fehlschlag
3.3.3 Goodie erhalten
Beschreibung Weist dem Spieler/ der Spielumgebung ein Goodie
Vorbedingung
  1. Feld das ein Leben enthält wurde aufgedeckt.
  2. Feld das einen Timefreezer enthält wurde aufgedeckt
Algorithmus

            
Nachbedingung
Erfolg
  1. Spieler hat ein Leben gutgeschrieben bekommen
  2. Spielzeit wurde um 10 sec. zurückgesetzt.
Nachbedingung
Fehlschlag
-

[up to specification] [up]

Klassendiagramm

Die oben beschriebenen Funktionen sind auf die Klassen in folgendem Diagramm verteilt.

Klassendiagramm (Idee)
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 Zustand visibleState = (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 die invisibleStates der einzelnen GameTiles. mit Bomben oder Goodies. Die Arrays bombCounterArray und goodieCounterArray 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 einzelnen GameTiles 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 und Goodie
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..?).

[up to specification] [up]