Bei der zu entwickelnden Applikation handelt es sich um ein zugbasiertes Mehrspieler Strategiespiel, wobei der grundlegende Unterschied in der Art und Weise der Erstellung der zu benutzenden Einheiten liegt.
Bei Programmstart muss sich eingeloggt oder registriert werden (dabei sollen alle Daten in einer MySQL-Datenbank gespeichert werden). Im Hauptmenü soll es die Möglichkeit geben direkt in vier verschiedene Untermenüs zu kommen. Das erste ist das “Host Game”-Menü, das zweite das “Join Game” Menü, das dritte das “Map-Editor”-Menü und das vierte das “Options”-Menü. Außerdem gibt es noch das “Lobby”-Menü, welches aber nicht auf direktem Wege vom Hauptmenü aus erreichbar ist.
Das erste Menü soll zum Erstellen und Verwalten einer neuen Lobby bzw. eines neuen Spieles sein.
Dort könnten sowohl die schon bereits beigetretenen Spieler verwaltet und beispielsweise in Teams aufgeteilt werden, aber auch die allgemeinen Lobby Einstellungen verändert werden, wie zum Beispiel: Der Name der Lobby, die maximale Anzahl der Spieler, die Spielgeschwindigkeit oder etwa die Einheitenobergrenze und vieles mehr.
Von diesem Menü aus soll man das Spiel dann auch starten können.
Im “Join Game”-Menü soll man dann die Möglichkeit haben zwischen allen geöffneten Lobbys auswählen zu können. Wählt man eine der Lobbys aus und tritt dieser bei, so kommt das zuvor erwähnte “Lobby”-Menü zu Vorschein. Dort kann man nun alle bereits beigetreten Spieler plus dem Lobby-Host selber mit den jeweiligen Teams einsehen. Auch dargestellt sollten alle Information bezüglich den Lobby Einstellungen selbst sein, sodass jeder Spieler weiß unter welchen Bedingungen das Spiel laufen wird.
Im dritten Menü sollte es die Möglichkeit geben alle Einstellungen für den Map-Editor zu treffen (beispielsweise die Größe der Map oder für wie viele Spieler die Map gedacht ist) und dementsprechen auch zwischen den schon vorhanden Maps auszuwählen oder wenn gewünscht vollkommen neue, noch leere, Maps zu generieren. Auch in diesem Menü sollte es eine Möglichkeit geben die “Maptile”-Palette so zu gestalten wie man sie gerne möchte.
Diese so genannte “Maptile”-Palette ist im Endeffekt nichts weiter als eine Palette auf der sich alle Möglichen “Maptiles”, also Kartenbausteine befinden können, die man benutzen kann um sich seine eigene Karte zu erstellen.
Das letzte Menü, das “Options”-Menü, soll selber noch mal in “Grafik” , “Audio/ und “Tastenbelegung” bzw. “Spielsteuerung” unterteilt werden.
Der größte Unterschied zu vielen anderen Strategiespielen ist das Design der Einheiten.
Diese sollen hier also nicht wie gewöhnlich fertig entworfen in das Spiel implementiert werden, sondern werden von den Spielern selber desinged. Hierbei bekommt der Spieler während das Spiel läuft, oder auch davor, die Möglichkeit unter vorher festgelegten Regeln seine eigenen Einheiten zu entwerfen. Er kann zunächst den Einheitentyp auswählen (Infanterie, Flugzeug, Fahrzeug oder Schiff) und bekommt darauf hin die Statistik für dieses Model angezeigt.
In dieser Statistik sind dann Informationen zu finden zu der Sichtweite, der Geschwindigkeit, der Ladekapazität, der Lebenspunkte, der Rüstung und einigen anderen Eckdaten.
Diese Statistik kann dann durch das hinzufügen von Modulen beziehungsweise Upgrades verändert werden, sowohl Negativ als auch Positiv. Beispielsweise könnte ein Modul das Ortungssystem einer Einheit verbessern und damit die Sichtweite erhöhen. Im Gegenzug verbraucht dieses Modul jedoch Platz und verringert deswegen die Ladekapazität der Einheit.
Um nun eine Einheit zu erstellen, die auch Kämpfen können soll, braucht man erstmal Waffen. Diese sollten durch ein ähnlich anpassbares System modelliert werden, sodass jede Waffe auch ihre eigenen Upgrades haben kann und genauso frei angepasst werden kann wie die Einheiten selber es können.
Jede Einheit soll dann jede beliebige Anzahl Waffe tragen und nutzen können, solange diese nicht zu Schwer sind. Ein Infanterist mit einer Ladekapazität von 15 kg kann also keine 45 kg schweren Raketen ausrüsten, ein Fahrzeug allerdings kann, wenn das jemand möchte, gut und gerne auch 20 Maschinepistolen ausrüsten, sollte die Ladekapazität das zulassen.
Alternativ ist es auch möglich statt einer Waffe ein Werkzeug auszurüsten. Dadurch ist es dann möglich dass ein Infanterist mit einem Werkzeugkasten, statt Soldat halt Bauarbeiter wird, mit einem Medipack wird er zum Sanitäter oder mit einem Messgerät (Reagenzglas oder was auch immer) zu einem Wissenschaftler.
Die Gebäude die sich der Spieler errichten kann, sollten strukturell ähnlich wie die Einheiten in der Datenbank verankert sein, sodass man jederzeit neue Gebäude hinzufügen kann, ohne sie komplett neu in das Spiel rein zu programmieren.
Die Ressourcen im Spiel sind “population capacity”, “energy“, “research points” und “credits”. Die “population capacity” gibt an wie viele Einheiten ein Spieler maximal besitzen darf, hierbei kann ein Fahrzeug auch als zwei oder mehr Einheiten zählen. Außerdem kann sich die “population capacity” während des Spieles ändern und ist nicht bei jedem Spieler gleich. Die zweite Ressource “energy” könnte man auch als “population capacity” für Gebäude bezeichnen.
Diese Ressource kann in Stromreaktoren produziert werdenund ist eine der wichtigsten Ressourcen. Sollte diese “energy” Ressource vollkommen erschöpft werden, so ist es nicht mehr möglich, eigene Einheiten befehle zu erteilen, wenn sie sich nicht in einem kleinen Radius um das “Research Center” herum befinden.
Die “research points” an sich werden für das Design neuer Einheiten verwendet, dabei kostet jedes neue Design, ob Waffe oder Einheit, eine bestimmte Summe an “research points”.
Die Ressource “credits” ist das Geld in diesem Spiel und wird benötigt, um Einheiten zu rekrutieren oder Gebäude zu errichten.
Das eigentliche Spielprinzip ist eine Mischung aus “Realtime” und “Turnbased” Strategiespielen. Man soll zwar gleichzeitig, also nicht nacheinander wie beim Turnbased-Prinzip spielen, aber trotzdem in aufeinanderfolgenden Zügen agieren.
Das Spiel ist dafür pro Zug in zwei Phasen aufgeteilt. In der ersten Phase können die Spieler ihren Einheiten Befehle geben, neue Einheiten designen oder Einheiten rekrutieren. In der zweiten Phase werden dann all diese Befehle gleichzeit mit den Befehlen der anderen Spieler umgesetzt, Kämpfe von aufeinandertreffenden Einheiten werden Simuliert und die Ressourcen für die nächste Runde werden berechnet.
Zu Beginn eines jeden Spieles startet jeder Spieler mit einem Stromreaktor und einem Research Center. Zusätzlich bekommt er auch noch zwei Einheiten der Infanterie-Klasse, die mit einem Werkzeugkasten ausgerüstet sind und neue Gebäude bauen können.
Gewonnen hat der Spieler beziehungsweise das Team, welches als erstes die gegnerische Stromversorgung zerstört oder den Gegner zum Aufgeben zwingt.
Da dies nicht alles innerhalb der vorgegeben Zeit zu erreichen ist, sollte sich zunächst auf den Aufbau der Datenbank wie auch auf die Implementierung eines Login/Registrierungssystems, das Hauptmenüs und der Verbindung mehrerer Spieler in einer Lobby konzentriert werden.
Dokumentation
Datenbank
Die Datenbankstruktur lässt sich grob in zwei Kategorien auf teilen, die Spielelemente und die Spielverwaltung.
Eine weitere Tabelle mit fast den gleichen Spalten findet man unter dem Namen “unitUpgrades”. Hierbei handeln es sich vorallem um Modifikatoren für die dazugehörige Einheit. Möchte man also wie in der Anforderungsanalyse beschieben einer Einheit ein neues Modul für ein besseres Radargerät hinzufügen, so kann man dies hiermit machen. Dafür muss man lediglich in das Feld “visionrange” eine +2 (oder welche Zahl auch immer) eintragen und kann damit ein Upgrade erzeugen, welches einer Einheit +2 auf die Sichtweite gibt.
Der wichtigste Unterschied zwischen Unit und UnitUpgrades ist, dass UnitUpgrades vom Spieler selber nicht mehr hinzugefügt werden, alle UnitUpgrades sind mit vom Spiel/Entwickler vordefiniert und nicht wie die Einheiten an sich anpassbar. Jede Einheit kann in der Theorie unendlich viele Upgrades besitzen, diese kann vom Spiel nur durch ein geschicktes Upgrade-Design unterbunden werden.
Wenn jedes Upgrade einfach zusätzlich zu den Vorteilen immer den Preis erhöht, so macht sich jeder Spiel zweimal Gedanken über die Anzahl und Auswahl seiner Upgrades. Die Waffen funktionieren im Prinzip genauso wie die Units auch. Kleiner aber feiner Unterschied: Die Waffen und die Waffen-Module sind genauso wie die UnitUpgrades vordefiniert und nur durch Kombination anpassbar.
Dort werden neben Name und Beschreibung der Kachel auch der Dateipfad zu der dazugehörigen Textur gespeichert und ganz wichtig auch ein Wert mit der Bezeichnung “Z-Value”. Dieser Wert ist für den Aufbau der Map von äußerstem Interesse, er beschreibt nämlich die Höhe dieses Kartenteils auf der Z-Achse, welche auf Grund der Natur eines 2D Spiels, visuell nicht all zu gut zu erkennen ist.
Dadurch steigert sich die mögliche Komplexität der Karten exponentiell. Man kann in das Terrain vom Spiel automatisch erkannte Hindernisse wie Flüsse und Berge einfügen. Um nun eine Karte abspeichern zu können, gibt es eine dritte Tabelle in der neben Karten-ID und Kachel-ID auch die Position der Kachel in der gegeben Karte gespeichert wird.
Die zweite Kategorie ist im allgemeinen für das Abspeichern alle Daten zuständig, die für die Verwaltung des Spieles zuständig sind. Dazu gehören vorallem die Tabellen, welche den User mit den verschieden Spielelementen oder anderen Usern verknüpft. Die wichtigste Tabelle in dieser Sektion ist daher die “Game”-Tabelle. Über diese Tabelle werden Verknüpfungen mit andern Spielern als auch mit den Einheiten und Gebäuden selber möglich.
Separat dazu gibt es eine Tabelle mit der Bezeichnung “Deck”, die eigens dafür da ist, dem Spieler die Möglichkeit zu geben, seine selbst erschaffenen Einheiten abzuspeichern und in späteren Spielen wieder nutzen zu können.
Java Programm
Das Programm ist zunächst in vier Teile strukturiert: Die “Assets”, das “Gameinterface”, das “Userinterface” und eine Art “Kern”.
Bei dem “Kern” welcher im Projekt schlicht mit “mts” bezeichnet ist, handelt es sich um ein Java-Package in der sich alle Klassen befinden, welche für den Grundaufbau des Spiels nötig sind. In diesem Fall ist das bisher nur eine Klasse zur Verwaltung der Datenbank und die “MTS.java”, welche die Main-Methode beinhaltet. Von der “DB.java” werden absolut alle Ab-und Anfragen vom Programm an die Datenbank geregelt.
Man findet dort Methoden wie createLobby, checkLoginData, removeUser, updateLobbySettings oder addLobbyMember.
Alle diese Methoden sind dabei grundlegend gleich aufgebaut. Erst wird über DB.Connect () eine Verbindung zur Datenbank aufgebaut, dann wird innerhalb eines “try and catch”-Befehls die Query an die Datenbank geschickt und mögliche Resultate verarbeitet und zum Schluss wird die Verbindung mit DB.close () wieder geschlossen. Diese Struktur sorgt durchgehen für eine saubere Kommunikation mit der Datenbank und verhindert sowohl hunderte von offenen Verbindungen, als auch Fehler innerhalb des Programmes sollte sich beispielsweise die Verbindung aus irgendwelchen Gründen von selber schließen.
Die Benutzeroberfläche des Spieles ist selber stark strukturiert und besteht aus bis zu sechs Ebenen. Ganz unten befindet sich das Fenster selber und beinhalten ein so genanntes “ContentPane”. Diesem wird bei Starten des Programmes ein JPanel mit dem Namen “User Interface” hinzugefügt, welches das gesamte Userinterface der verschiedenen Menüs regelt.
Möchte man zu späterem Punkt anfangen die Oberfläche für das wirkliche Spiel mit Darstellung aller Einheiten, der Gebäude und der Karte zu implementieren, wäre in dieser Ebene der richtige Ansatzpunkt. Einfach das Gameinterface dem ContentPane hinzufügen und das UserInterface deaktivieren.
Im UserInterface finden wir nun wieder zwei neue Ebenen, die erste, untere Ebene ist die Ebene des Hintergrundbildes. Über ihr liegt das Logo und die verschiedenen Menü-Panels, welche je nach bedarf in das UserInterface geladen werden können.
Bei Programmstart werden diese Menü-Panels allesamt deklariert und dem UserInterface hinzugefügt. Möchte man beispielsweise nur das “MainMenu” sehen, so muss man dafür einfach erst alle Panels unsichtbar schalten und das “MainMenu” dann wieder sichbar.
Alle Komponenten sind relativ zu deren “Eltern”-Komponenten angeordnet. So befindet sich beispielsweise das Hauptmenü immer Mittig auf der X-Achse und leicht unterhalb der Mitte auf der Y-Achse und ist immer 97.5% der UserInterface Größe breit und 60% hoch.
So verhält es sich auch bei allen Buttons, Labeln, Panels und Tables die verteilt über die Benutzeroberflächen zu finden sind.
Ein genaueren Blick sind die Menüs bezüglich der Spielerstellung und des Spielbeitretens wert. Dazu müssen wir uns vorallem das HostMenu und JoinMenu angucken.
Das HostMenu sollte dem Ersteller einer Lobby die Möglichkeit geben, sowohl die Spieleinstellungen an sich, als auch die beigetretenen Spieler verwalten zu können.
Dies wurde dadurch realisiert, dass man auf der linken Hälfte des Menüs eine Tabelle mit allen Spielern hatte und auf der rechten Seite Textfelder und ComboBoxen zum Editieren der Spieleinstellungen. Bei einem klick auf den”refresh”-Button werden alle Informationen geupdatet. Die Spieleinstellungen werden neu in die Datenbank übertragen, neue Spieler werden der Tabelle im Menü hinzugefügt und die Teams bereits beigetretener Spieler werden mit der Datenbank synchronisiert.
Daraufhin öffnet sich das “LobbyMenu”. Dieses Menü ist ein Vererbung des “HostMenu”, die wichtigsten Unterschiede liegen in den ausgeschalteten Buttons, Eingabefeldern und ComoBoxen und in der Art und Weise der Synchronisation der Daten. Das LobbyMenu läd nämlich keine Daten zur Datenbank hoch, sondern updatet nur immer die Daten für die Benutzeroberfläche. Dies sorgt dafür, dass nur der Host die Möglichkeit besitzt, die Lobby und Spieler zu verwalten.
Theoretische Implementierung
Map und Map-Editor
Für eine vernünftige Darstellung der Map braucht man zunächst ein funktionierendes Gameinterface, also die Grundlage für eine gut Strukturierte Oberfläche. Diese könnte wie folgt aufgebaut sein:
Die Unterste Ebene im Gameinterface-Panel ist ein Map-Panel und nimmt die volle Größe ein. Innerhalb dieses Map-Panels sind je nach Mapgröße n*m viele Maptile-Panels angeordnet. Diese befinden sich allerdings nicht alle gleichzeig im Panel. Die Anzahl der dargestellten Panels sollte von der Größe des Gameinterfaces abhängen und nie Maptile_Panels unter einer bestimmten Größe erlauben.
In die Maptile-Panel können nun Texturen von Gebäuden und Einheiten platziert werden, welche dann automatisch jeder Scroll-Bewegung folgen. Über das Map-Panel können darauf hin parallel zu einander alle Steuerelemente, möglichst in eigene Panel gruppiert, gelegt werden. Zu implementieren wären da zum Beispiel eine Auswahl an Einheiten und Gebäuden oder etwa eine ansprechende Benutzeroberfläche zur Gestaltung seiner eigenen Einheiten.
Für den Map-Editor im Speziellen sollte es auf der linken Seite zwei Panels geben, einmal mit einer Darstellung aller Mapbausteine und einmal mit allen Werkzeugen, die man für einen Map-Editor braucht, wie beispielsweise “löschen”, “kopieren”, “auswählen” und “verschieben”.
Ein großer Vorteil dieses Designs ist es, dass man sehr simpel dem Nutzer die Möglichkeit bieten kann, die einzelnen Steuergruppen der Steuerelemente, solange sie in verschiedenen Panels gruppiert sind, nach belieben zu verschieben und anzuordnen. Auch möglich wäre es immer wieder ganz leicht neue Elemente hinzuzufügen, wie zum Beispiel eine kleine Minimap oder eine Einzigetafel für Ressourcen.
Die Gameplay-Mechaniken beinhalten alle Mechanismen die für die Durchführung der Spielregeln sind. Dazu gehört zunächst einmal die Abfolge der Züge und die Unterteilung dieser in die zwei bereits beschriebenen Phasen. Das Problem, welches sich schon bei dem Aufbau der Datenbank stellte, war: “Wie schaffe ich es mit möglichst wenig aufwand, nicht nur die Einheiten und Gebäude jedes Spielers mit der richtigen Position, als auch die Ressourcen abzuspeichern, sondern auch noch die Befehle, die man als Spieler geben kann.”
Bricht man das gesamte Spielgeschehen so weit es geht hinunter, so kommt man schnell auf nur 4 Aktionen die ein Spieler wirklich tätigen kann: Einheiten bewegen, Einheiten rekrutieren, neue Einheiten designen und Gebäude bauen. Gebäude bauen ist relativ leicht, man kann sie einfach der game_buildings Tabelle hinzufügen und schon sind sie da. Das Designen von Einheiten ist ähnlich simpel.
Dafür muss man die Einheit zwar in ein paar mehr Tabellen eintragen, aber das macht ja auch nicht wirklich etwas. Einfach schnell in unit_deck, und wenn nötig in unit_unitUpgrade und unit_weapon eintragen und fertig. Etwas komplizierter wird es da, wenn man Einheiten produzieren, möchte. Der Hacken hierbei; sie haben eine Produktionsdauer, die berücksichtigt werden muss, und sie können nur in bestimmten Gebäuden produziert werden.
Mehrspieler-Mechaniken (Synchronisation)
Die Synchronisation in diesem Mehrspieler gestaltet sich glücklicherweise nicht ganz so schlimm, wie in einem Realtime Strategiespiel. Auch wenn es sich hierbei um kein gewöhnliches Turnbased-Spiel handelt, so ist es trotzdem möglich nur mit einer MySQL Datenbank zu arbeiten. Die Synchronisation läuft dabei hauptsächlich nicht zwischen den beiden Programmen ab, sondern in der Durchführung eines vordefinierten Regelwerkes mit den gleichen Daten.
Die Programme bekommen lediglich die Informationen über die Positionen aller Einheiten und derer “Destinationpoints”, also den Koordinaten, zu denen sie laufen sollen. Beide Programme führen dann genau die gleichen Operationen durch, welche zuvor definiert wurden. Dieses Regelwerk muss beispielsweise Informationen zur Handhabung einer Feindessichtung haben, greift man automatisch an, oder zieht man sich sofort zurück.
Desweiteren muss man neben einem guten Regelwerk für eine erfolgreiche Synchronisation sicher gehen, dass beide Programme mit den gleichen Information arbeiten, dies kann man machen, indem man den verschiedenen Daten Timestamps hinzufügt und mit Hilfe dieser versucht mögliche Fehler zu erkennen.
GESCHRIEBEN VON: Spieleprogrammieru­ng in java Vorwort “Warum Spieleprogrammieru­ng?” Diese Frage ist einfach zu beantworten, wenn man selbst gerne spielt und vielleicht auch schon ab und zu davon geträumt hat ein “eigenes” Spiel zu entwickeln: es macht einfach großen Spaß! Aber wenn…
...[weiter lesen]