Dokumentation zum Massive Multiplayer Online Game - Universität ...
Dokumentation zum Massive Multiplayer Online Game - Universität ...
Dokumentation zum Massive Multiplayer Online Game - Universität ...
Sie wollen auch ein ePaper? Erhöhen Sie die Reichweite Ihrer Titel.
YUMPU macht aus Druck-PDFs automatisch weboptimierte ePaper, die Google liebt.
4. Schiffe und Missionen<br />
35<br />
• Spionage: Flotte fliegt zu einem Planeten um ihn auszuspionieren<br />
• Transport: Flotte fliegt zu einem Planeten um ihm Rohstoffe zu liefern<br />
Bei jedem Missionstyp gibt es wiederum 4 Möglichkeiten sich bei Ankunft am Zielplaneten zu verhalten, da<br />
dieser verschiedene Zustände haben kann:<br />
• unbekannt (kein Spieler ist dort angesidelt)<br />
• besiedelt von einem Freund aus der Allianz<br />
• eigener Planet<br />
• Planet eines gegenerischen Spielers<br />
Das ergibt insgesamt 20 Fälle die zu beachten waren bei der Implementation des Bewegungsmechanismus'.<br />
Eine detaillierte Übersicht bietet folgendes Bild.<br />
| Aktionen die am jeweiligen Zielplaneten bei einer bestimmten Mission durchgeführt werden<br />
Model<br />
Vorüberlegungen<br />
Die Schwierigkeit bei der Planung der Missionen fing bei der Zuordnung der Attribute der Flotten an. Wir<br />
brauchten so viele Attribute, dass sich eindeutig aussagen lässt wo sich die Flotte genau befindet, wohin sie<br />
fliegt, wann sie ankommt, etc. Gleichzeitig, wollten wir nicht zu viele Attribute einführen um eventuelle<br />
Redundanzen zu vermeiden.<br />
Da Flotten beim Abflug Energie benötigen, mussten wir mitbedenken, dass Flotten genug Energie "tanken",<br />
sodass diese für eine Rückkehr reicht. Zusätzlich kommt hinzu, dass bei Missionstyp Travel geplant ist, seine<br />
Flotten auf anderen befreundeten Planeten stationieren zu können. Diese verteidigen den Planeten im Falle<br />
eines Kampfes zusätzlich zu der heimischen Flotte. Dort stationiert muss es also möglich sein, die Flotte wieder<br />
zurückkehren zu lassen zu ihrem Heimatplaneten und dies zu einem beliebigen Zeitpunkt.<br />
Ferner müssen Flüge abgebrochen werden können. Dafür müssen die Attribute noch die Informationen enthalten,<br />
welche den Auftrag, der in die Resque eingefügt wurde, wieder eindeutig identifiziert um ihn dann zu löschen.<br />
Eine weitere Schwierigkeit bestand darin Technologieerweiterungen miteinfließen zu lassen. Sollten Flotten<br />
auf einer Mission sein, muss <strong>zum</strong> Beispiel bei einem Abbruch des Fluges die Geschwindigkeit der Flotte noch<br />
mit den alten Technologiefaktoren berechnet werden.<br />
Umsetzung<br />
Beziehungen<br />
Die grobe Struktur (komplettes ER-Diagramm) unseres Schemas ist die, dass jeder User mehrere Flotten<br />
haben kann, wobei er jeweils immer nur eine an einem Planeten hat, die sogenannte Heimatflotte. Eine Flotte<br />
hat eine Mission und besitzt Start-, Ziel- und Heimatplaneten. Diese mussten wir, da eine mehrfache Relation<br />
<strong>zum</strong> Model Planet besteht mit foreign_keys versehen (siehe folgenden Codeblock). Einer Flotte können mehrere<br />
Schifftypen zugeordnet sein. Da wir in der Relation zu Ship ein Attribut amount unterbringen wollten, war die<br />
Umsetzung in Rails ein wenig komplizierter. So mussten wir ein eigenes Model Shipfleet erstellen, welches in<br />
Fleet mithilfe einer has_many .. through Beziehung angesprochen wird. Weiterhin sollte beim Löschen von<br />
Flotten die Änderung auch fortgetragen werden.