12.01.2014 Aufrufe

Dokumentation zum Massive Multiplayer Online Game - Universität ...

Dokumentation zum Massive Multiplayer Online Game - Universität ...

Dokumentation zum Massive Multiplayer Online Game - Universität ...

MEHR ANZEIGEN
WENIGER ANZEIGEN

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.

Hurra! Ihre Datei wurde hochgeladen und ist bereit für die Veröffentlichung.

Erfolgreich gespeichert!

Leider ist etwas schief gelaufen!