==== RPG Server Backend ==== [[Nations of Orion]] soll ein mehrspielerfähiges Onlinespiel werden. Vielleicht sogar ein Massive Multiplayer Online (MMO) Rollenspiel? Naja, bleiben wir auf dem Teppich: vermutlich nicht... Bei der Internetrecherche zu diesem Thema bin ich auf einen sehr interressanten und eleganten Verfahrensansatz gestossen: [[http://www.enchantedage.com/pymmo|"the simplest thing that could possibly work"]], also die einfachste Implementationsform die die geplante Aufgabe erledigen kann. Der Grundsatz ist ohnehin sehr gut denn er erfordert etwas Planung und Abstraktion im Vorfeld. Der Ansatz ergänzt das bekannte KISS-Prinzip (keep it simple, stupid). ==== Charaktere und Fähigkeiten im Spiel ==== * Primärdirektive: Der RiftRoamers - Nations of Orion Mod muß zu jeder Zeit mit einer Standard Vega Strike SVN-Installation funktionieren (keine änderungen an den VS-Internen Dateien). * Sekundärdirektive: Die gegebenen Möglichkeiten der VS-Engine sollten möglichst ohne gravierende Erweiterungen genutzt werden. === Andockmöglichkeiten === Es kann an Schiffen, Stationen und auf Planeten gedockt werden. Schiffe mit Docking-Port wirken nur aus der CLient-Sicht als solche, das Docking-Menü lässt sich von Bord aus nicht benutzen. === Erkenntnisse und Ansätze === Charaktere und Rollenspielansätze funktionieren nur wenn der Spieler einen Charakter erhält, dessen Fähiglkeiten sich verändern können und einen Einfluß auf das Gameplay haben. Bei Mehrspieler-Sessions sollte jeder Charakter eigenen Fähigkeiten und somit unterschiedliche Einflüsse haben. Da Vega Strike von Haus aus keine RPG-Elemente unterstützt, wohl aber ein durchaus variables Gameplay mit Factions (Fraktionen, Gruppierungen) und veränderlichen Beziehungen dieser untereinander unterstützt, machen wir uns dieses bestehende Framework weiter unten im Implementationsansatz als CharacterFaction zu nutze. Ein Charakter sollte durch ein Bild/Rendering und einige Beschreibungen bzw. persönliche repräsentiert werden. Diesen Aspekt beleuchten wir weiter unten unter dem Implementationsansatz CharacterAvatarContainer. Ein Charakter sollte persönlichen Besitz, Geld und Fähigkeiten haben. Diese Informationen sollten im Spiel darstellbar sein und durch skripte ausgelesen werden können. Zudem sollten diese Reaktionen bei anderen Fraktionen beeinflussen können. Dieser Aspekt wird unter CharacterDataContainer vorgestellt. ==== Implementationsansatz ==== === CharacterFaction === Jede Charakterprofession bildet eine Fraktion, Jeder Charakter eine Gruppierung innerhalb dieser Fraktionen. Für jeden Charakter wird es eine eigene Fraktion geben. === CharacterAvatarContainer === Wir repräsentieren dies durch einen speziellen Behälter im Spiel, der zwei wesentlihce Eigenschaften unterstützt: * a) Er kann an Bord von Raumschiffen mitgeführt werden * b) Er kann weitere Gegenstände (z.B. Cargo) enthalten Beide Eigenschaften werden generell von Raumschiffen bzw. Installationen erfüllt. Damit müste für jeden einzelnen Charakter eine neue Unit erstellt werden. Im Spiel können Raumschiffe andere Raumschiffe mitführen, womit diese Forderung erfüllt wäre. Das Volumen dieses Spieler-//Raumschiffs// entspricht sozusagen dessen persönlichen Gepäckraum der im Lagerraum bereitgehalten wird. Darin werden alle persönlichen Daten und Gegenstände verwahrt. Der CAC nimmt etwa 1 Kiloliter Frachtraum in Anspruch, der dem Spieler/Charakter für seine persönlichen Gegenstände zur Verfügung steht. Er wird durch den CEC zugänglich gemacht. Der CharacterAvatarContainer (CAC) kann nur CharacterDataContainer (CDC) und CharacterEquipmentContainer (CEC) enthalten. Diese haben - als logisches Gruppierungsinstrument - keine eigene Größe, können aber Items mit einer geringen eigenen Größe aufnehmen. Problem: Der Inhalt darf die Größe des freien Frachtraums unterschiedlich großer Schiffe nicht überschreiten. Lösung: Um z.B: Fahrzeuge, Shuttles oder Raumschiffe als Besitz mitzuführen, wird hier nur die Besitzurkunde hinterlegt, die Unit selbst jedoch im Laderaum mitgeführt. Die Größe der Besitzurkunde ist sehr gering und passt auf jeden Fall in den persönlichen Frachtraum (Spind) des Charakters. Eine Art Betriebsurkunde befindet sich im Laderaum des mitgeführten Raumschiffs (analog zu Fahrzeugbrief und Fahrzeugschein), womit sichergestellt werden kann, das Besitz und Besitzurkunde miteinander abgeglichen werden können. Ist eine simplere Implementation machbar wird diese bevorzugt. === CharacterDataContainer === Dieser CharacterDataContainer (CDC) ist ein neuer Unit-/Fracht-Typ. Er kann nicht gekauft werden, sondern wird jeder Unit vom Typ Charakter automatisch einmal zugeordnet. Für jeden Charakter besteht also ein CAC, ein CDC, sowie bei Bedarf weitere Container-Units. Der CDC enthält Fracht vom Typ Attribute, Skill oder Modification in unbegrenzter Zahl. Der CDC hat nur eine virtuelle Größe, nimmt jedoch keinen Frachtraum in Anspruch. === CharacterEquipmentContainer === Der CharacterEquipmentContainer (CEC) ist ein neuer Unit-/Fracht-Typ. Er kann nicht gekauft werden, sondern wird jedem Charakter automatisch einmal zugeordnet. Für jeden Charakter besteht also nun ein CAC, ein CDC und ein CEC. Der CEC kann persönlichen Ausrüstung aufnehmen (Fracht vom Typ Cargo, Gear, License oder Document). Er stellt den gesamten persönlichen Lagerraum des Charakters zur Verfügung. === CharakterUpgrades === Damit Skills einen Einfluß auf das Gameplay haben, müssen alle Upgrades und Schiffseigenschaften durch Variantenergänztwerden, deren Daten den Skill des Charakters berücksichtigen. Z.B: \\ 500MJ Laser, Feuerrate 40, Genaquigkeit 20, Reichweite 2000 - Normalversion\\ 500MJ Laser 1, Feuerrate 40, Genauigkeit 21, Reichweite 2100 - Laser mit Skill auf 1\\ 500MJ Laser 2, Feuerrate 40, Genauigkeit 22, Reichweite 2205 - Laser mit Skill auf 1\\ 500MJ Laser 3, Feuerrate 40, Genauigkeit 23, Reichweite 2315 - Laser mit Skill auf 1\\ 500MJ Laser 4, Feuerrate 40, Genauigkeit 24, Reichweite 2431 - Laser mit Skill auf 1\\ 500MJ Laser 5, Feuerrate 40, Genauigkeit 25, Reichweite 2553 - Laser mit Skill auf 1 Jede Skill Stufe erhöht z.B: in diesem Fall die Leistung um 5%, Der gleiche Laser hat also eine andere Leistung wenn der Charakter den entsprechenden Skill ausgebildet hat als wenn er diesen nicht ausgebildet hätte. Um nun vollautomatisch die Kauf-/Verkauf-Listen beim Schiffsausstatter dazu zu bringen nur bestimmte Modelle als verfügbar anzuzeigen könnte man den Skill Laser oder Leichte Laser als eine installierte Waffe im System einbringen die wiederum einen Slot für eine weitere Waffe enthält, nämlich jene Waffenvarianten die durch den Skill abgedeckt werden. Alternativ bringen wir Skillstufenabhängige Waffen-Hardpoints in das Spiel ein, die beim Speichern durch ein Skript eingetragen werden. Ein Schiff, das einem Charakter mit "Leichte Laser 4" gehört, kann nur Leichte Laservarianten der Skillstufe vier aufnehmen. Der einfacherer Ansatz gewinnt. Falls VS schon andere Mittel dafür bereitstellt werden diese den Vorzug erhaltenl. === CharakterVessels === Individuelle Raumschiffe gehören der Fraktion des Charakters und der Ausstattungsvariante "Custom" an. Ferner enthalten Sie einen Speziellen VesselDataContainer (VDC), der Cargo-Items vom Typ Documents sowie weitere Informationen enthält die das SChiff individualisieren. Ein Script ändert beim Kauf eines solchen Schiffes die installierten Upgrades in die für den Charakter möglichen Upgrades. Eine solche Änderung könnte eine Menge CPU-Zeit verschlingen, so das Schiffe erst nach einer gewisssen Wartezeit wieder verfügbar sind. Dies entspricht der Zeit im Hangar für die Rekonfiguration.