Vision

Online Spiel und Sandbox Spiel

Der Spieler kann basierend auf beliebigen Spielständen ein Sandbox-Spiel starten, also offline am heimischen Rechner spielen. Umgekehrt jedoch muß ein Sandbox-Spiel vor der Online-Nutzung vom Server geprüft werden (hochgeladen und mit vorgegebenen PArametern verglichen werden). Grundsätzlich sollte beides funktioieren.

Bei technischen Schwierigkeiten werden wir auf den zweiten Weg verzichten, Sandbox-Spielstände im MMO (Ausnahme Test-Server) zu verwenden.

Nach dem erfolgreichen Login (bei dem z.B. der Spieleraccount-Status geprüft wird) landet der Spieler in seiner „Safe Harbour“ Location (z.B. Wohnung, Hotelzimmer, Schiffsquartier). Von hier hat er zugriff auf die News (Universe, Friends, Personal), Nachrichten (PM, Voicemail (Mumble?)), Statistiken und Protokolle der zurückliegenden Aktivitäten, sowie Zugang zum Transportation Hub, oder direkt zu den jeweils möglichen Locations.

Als RPG Spielmodi fallen uns sofort PvP und Coop PvP, wie auch PvE und Coop PvE ein. Weitere sind klassische Quests und Dungeon Crawling im Weltraum (das Dungeon ist hier das Innere eines fremden Schiffes oder einer anderen Location.

Beim Coop Spiel agieren mehrere Spieler auf ein gemeinsames Ziel hin indem sie einer Gruppe beitreten (Flotte, Platoon, Mannschaft, Konzern, Familie, etc.).

Spielergenerierte Inhalte (Modding)

Spieler sollen die Möglichkeit haben eigene Inhalte zu erstellen und an zuvor „gesicherten Orten“ zu installieren. Unter eigenen inhalten verstehe ich speziell Missionen, Stationen, Gebäude, Raumschiffe, Fahrzeuge, Landschaften, Texturen/Skins, Möbel, Fracht, Vegetation und mehr.

Jedes Objekt sollte so einfach wie möglich installiert werden können, am besten einfach das ZIP-Archiv mit der Dateistruktur des Contents in ein Modding-Verzeichnis kopieren (z.B. unterhalb von „Eigene Dateien“ > „RiftRoamers – Dystopia“. Ein Downloadserver mit Usercontent und eine Zugrifffunktion im Spiel mit Browser könnten dies weiter erleichtern. EIn SPieler könnte Missionen mit Erweiterungen basteln und der benötigte Content würde automatisch geladen werden.

Optional könnten auch inGame virtuelle Platzhalter erstellt werden (Blueprint) die der Charakter durch die entsprechenden Skills „erforschen/entwickeln“ kann. Nach dem upload und dem Freigabeprozess kann dieser Spieler das Blueprint verkaufen, lizensieren oder selbst mit der Produktion in eigenen oder angemieteten Anlagen beginnen, sofern er die notwendigen Materialien dafür produziert oder einkauft und heran schafft oder schaffen lässt. Die Gewinnspanne liegt je nach Produktiondmenge und Optimierung bei 10-30 %, der Rest geht für Rohstoffe drauf.

Prozedurale, persistente Welten

In dieser Vision geht es darum mit prozeduralen Methoden die Spielwelt zu füllen – möglichast in „Echtzeit“ zur Laufzeit des Spiels. Einmal erstellte Welten sollen jedoch persistent sein. Dazu kurz meine in diesem angewendete Definition der beiden Begriffe.

  • Prozedural – Auf mathematischen Funktionen basierende Berechnung durch den Computer bzw. Server.
  • Persistent – Prozedural berechnete Elemente werden bei jeder erneuten Nutzung identisch berechnet und dargestellt. Einmal (beim ersten Besuch irgendeines Charakters) berechnete Inhalte sollen im Nachgang immer gleich bleiben und dann lediglich Veränderungen durch Spieler oder Spielleiter erfahren (automatisiertes News-System, Backgroundstory, Missionen, Kampagnen).

Die Prozedurale Berechnung von Elementen des Spiels erlaubt es eine große Zahl von Welten ohne Manpower zu erzeugen und diese unterschiedlich genug zu erhalten, das nicht eine Welt der anderen gleicht. Einige Methoden benötigen fertige 3D-Modelle und Texturen die dann nach prozeduralen Methoden in den erzeugten Spielwelten verteilt werden.

Diese Objekte könnten sowohl dynamisch als auch fest integriert werden. So können einige Welten – in Teilen – von Hand definiert werden und viele automatisch.

Weitere persistenz bezieht sich auf vom Spieler verursachte Schiffswracks oder Zerstörungen. Diese bleiben zerstört bis sie wieder repariert sind. Auf planetenorbits oder im Raum zurückgelassene schiffe vergleiben dort bis sie bewegt werden.

Zentral simuliertes Universum

Der modifizierte VegaStrike Client erlaubt es dem Spieler offline (Sandbox) oder online (Universe) zu spielen. Die Spielstände jedoch sind nur einseitig synchronisierbar. Die Spielerdaten werden in separaten Savegames gespeichert. Ein Savegame besteht nicht notwendigerweise aus einer einzelnen Datei sondern ggf. aus Datenbankeinträgen (aus denen ggf. ein VegaStrike-Kompatibles Seavegame extrahiert und gespeichert werden kann. Diese Savegames können heruntergeladen werden und in der Sandbox weitergespielt werden.

Der Server kann beim Start entweder ein neues Universum erschaffen oder einen Snapshot eines bereits bestehenden Universums laden. Der Snapshot eines Universum enthält dessen aktuellen Zustand minus Spielerdaten (da die Spielerbasis potenziell häufiger wechselt), die separat erfasst sind.

Der Server simuliert natürliche, politische und wirtschaftliche Ereignisse der einzelnen Nationen untereinander, der Systeme innerhalb einer Nation und ggf. der einzelnen Systeme und Planeten jeweils aufeinander aufbauend. Einige Werte werden auf Modifikatoren und Ereignissen basierende Zufallswerte sein um die Serverlast zu minimieren. Diese Modifikatoren und Ereignisbasierten Modifikatoren werden im jeweiligen Locationdatensatz gespeichert und beim Besuch durch einen Spieler abgerufen. Lediglich die Ereignisbezogenen Modifikatoren sind variable Werte, die übrigen Modifikatoren werden bei der erstellung des Universums entsprechend der Objektdaten (Stern, Planet, Raumstation) vorgegeben.

Dabei wir ein „casual believability“ Ansatz zum tragen. Dabei soll die Engine Simulationsdaten mehr oder weniger langsam berechnen sagen wir 1-4 tägliche Updates statt stündlich oder gar minütlich neu berechnete Daten, wobei direkte Spieler-Aktionen unter umständen sofortige Berechnungen nach sich ziehen.

Bei zeitkritischen Situationen müssen wir uns latenzarme Methoden ausdenken. Denkbar wären entfernungsabhängige Aktualisierungszeiten, zwischen denen Interpoliert wird. Es macht wirklich nur Sinn die genauen Positions- und Bewegungsdaten von Schiffen zu monitoren, die auch in Sichtweite sind. Unter Umständen sollte sogar unterschieden werden ob ein Schiff in direkter Interaktion steht (z.B: Zielaufschaltung, Tracking, etc.) oder einfach nur in der Nähe ist.

Eine Möglichkeit wäre eine Tabelle in die alle Clients Ihre ID-, Typ-, Positions- und Vektordaten schreiben und die von allen Clients lesbar und auswertbar ist. Die CLients nutzen die Infos für die Darstellung im HUD, für die Positionsberechnung bzw. Abstandsberechnung und teilt die einzelenen Positionen in Bereiche auf die jeweils zu unterschiedlichen Zeiten berechnet werden. Dabei sollen möglichst keine kompletten Überlappungen auftreten (Zeitpunkte zu denen alle Daten gleichzeitig neu berechnet werden). Je weiter weg die Positionen sind desto seltener werden sie aktualisiert. Ein Beispiel ist hier zu finden.

Handelssimulation

In meiner (Wahn-) Vorstellung schwebt mir vor ein universelles Assett Management System (AMS) zu implementieren das auch die Infos auf dem eCharakterbogen berücksichtigt, Einkäufe und Verkäufe, wie auch Auktionen ermöglicht und das Management und Tracking aller Gegenstände (die im Besitz eine PC oder NPC sind) innerhalb des Spiels erlaubt. Das ganze könnte soweit gehen, das über das Handelssystem auch Skillpakete (Bücher, Kurse, Seminare) und Fittings (Schiffskomponenten) besorgt und verwendet werden können.

Die Preise sollten die lokale Marktsituation wiederspiegeln können und Angebot und Nachfrage unterliegen. Je nach Anzahl der Spieler könnte man dies entweder anhand der verhältnismäßigen Nachfrage oder anhand angenommener Werte realisieren. Auf diese Weise wäre das Pen&Paper Spiel gut mit dem Computerspiel verknüpfbar. Auch Warentransporte oder zerstörte oder verlorene Besitztümer könnten im Auge behalten werden. Wenn der Spielleiter am Ende eines Abenteuers über ein geeignetes Tool/ Formular die entsprechenden Bewegungen ins Netz einpflegt oder den Spielern ermöglicht selbst die geänderten Werte zu überspielen (Freigabe durch GM) so könnte ein unbeschreiblicher Mehrwert gewonnen werden.

Reisezeiten und Realismus

Wir sind auch in diesem Spiel aus Gründen der Glaubhaftigkeit und Persistenz (insbesondere im Multiplayer-Kontext) auf die Beachtung einer wichtigen Limitation angewiesen: Es gibt keine „Fast Forward“ Funktion.

Die Quintessenz: Wartezeiten sind unvermeidbar.

Es ist also sehr Sinnvoll dem Spieler während dieser Wartezeiten etwas „den Spielspaß förderndes“ zu tun zu geben, oder ihm die Möglichkeit zu geben sich auszuloggen und die Simulation für ihn weiter machen zu lassen. Die Automatik sollte dabei ein „Safe Harbour“ Konzept verfolgen.

Wann immer der Spieler ausgeloggt ist und die Simulation für Ihn interagiert – das Schließt auch technisch bedingte Disconnects mit ein – sollte er:

  • über die Konsequenzen informiert sein (ob und welches Risiko besteht)
  • die Automatik konfigurieren können (z.B: ob Systeme mit zweifelhaftem Sicherheitsstatus vermieden werden sollen).
  • sich nicht wesentlich verschlechtern können (um den Spielspaß zu erhalten)
  • das Spiel zu einem beliebigen späteren Zeitpunkt wieder fortsetzen können
  • eine Spielmechanik (z.B. Versicherung) nutzen können die ihn vor größeren Schäden schützt
  • einen Log-Ausdruck erhalten der den Aktivitätenverlauf anzeigt

Die Simulation ermittelt für jeden Zeitabschnitt (durch Server-Config bestimmt) die Aktionen und Resultate bis zur nächstbesten „Safe Harbour“ Lösung, die letztlich als Safegame gespeichert wird. Von dort wird wie bei allen Safegames passiv verfahren.

Individuelle Charaktererschaffung

Der Spieler soll sich seinen 3D Charakter nach eigenen Wünschen (in Grenzen) erstellen können. Dabei sollen die Regeln des RiftRoamers RPG soweit für das Spiel nötig befolgt werden. Idealerweise lädt der Spieler ein Charakterblatt hoch (zumindest einen Export des eCharakterbogens von Clem C. Schermann) und erhält daraufhin eine zu seinen Attributen passende 3D-Figur (auf MakeHuman Basis), die er mit einem Satz universeller Kleider und Ausrüstung ausstatten kann.

First & Third Person Adventure

Eine Interaktive Spielumgebung wahlweise aus der Perspektive der 1. und der 3. Person. Die Rotation der Figur bzw. der Blickwinkel wird mit der Maus gesteuert. Zur Fortbewegung stehen die üblichen Tasten W,A,S,D oder UP, DN, RIGHT, LEFT zur Verfügung mit Bevorzugung WSAD (aufgrund der Erreichbarkeit weiterer Aktionstasten: QERT, FG, YXCV, ^, TAB, SHIFT, STRG, ALT, SPACE, 1-0, etc.).

Der Funktionsumfang sollte in Richtung GTA-SA gehen (GTA-4 habe ich nicht verwendet). Eine den Tasten zugeordnete Moves-Library soll bestimmte Bewegungsabläufe per Skript bereitstellen (ein-/aussteigen, setzen, stellen, legen, zielen, nachladen, werfen, springen, cliffhanging, klettern, etc.), dabei soll der Charakter auch sogenannte Idle-Moves durchführen (heben und senken des Brustkorbs, Gewichtsverlagerung, Gestik, etc.).

Der Charakter soll Objekte greifen können, Fahrzeuge nutzen können und schwimmen können. Moves für die Schwerelosigkeit wären auch interessant, vieleicht mit Steuerung der Wirkungkraft. Was besser sein sollte als in GTA wäre der Transport von Fahrzeugen in oder auf anderen Fahrzeugen.

Das Advanced Third Person Template for BGE bietet bereits vielen der genannten Eigenschaften außer das Ergreifen und Tragen von Objekten.

Beim ergreifen eines Objektes werden Attachment-Points des Objektes mit solchen am Charakter mittels parenting verbunden, aus der Moves-Library wird eine zum Objekt passende Pose ausgelesen und verwendet. Man könnte jedem Attachment-Point ein Array mit Pose-ID’s mit auf dem Weg geben die beim Parenting des Objektes mit dem Charakter ausgelesen und verwendet werden. Diese Daten könnten in einer externen Config-Datei gespeichert sein um einen nachträgliche bearbeitung zu ermöglichen. ggf. wäre auch eine zentrale Config je Objektgruppe denkbar die beim Laden des Levels bei Bedarf ausgelesen wird oder im RAM vorgehalten wird (RAM-Disk?).

Fahrzeuge

Die Benutzung von Fahrzeugen involviert auch Skriptabläufe zum ein und aussteigen. Evtl. sollten diese auch den gerade getragenen Gegenstand berücksichtigen (wenn dieser das rechtfertigt. Mit eine in beiden händen getragenen Kiste kann man nicht mal eben eine PKW-Tür öffnen und einsteigen ohne vorher die Kiste aus der Hand zu legen.

Dabei wäre es aus meiner sicht wichtiger die Fahrzeuge quasi überall nutzen und überall hin mitnehmen zu können, was mit den in FPShootern üblichen Cuts in der Perspektivendarstellung und einblenden der Sicht aus dem jeweiligen Vehikel (Gerät) erreicht werden könnte. Fahrzeuge mit LAderaum sollten für geeignete Fahrzeuge Atachment-Points besitzen mit denen diese fixiert und transportiert werden könnten. Eleganter wäre ein relatives Koordinatensystem und ein automatisches freigeben des mitgeführten Fahrzeugs, so das bspw. auch der LAderoboter im Kampf gegen ein ALien verwendet werden könnte. Die Einflüsse der Physik Engine müsten berücksichtigt werden, das mitgeführte Fahrzeug sollte sich nach dem Ausklinken realistisch verhalten und nicht einfach entgegen der Bewegungsrichtung des Transporter wegrutschen.

Ein gutes Gameplay bietet Agels Fall First – Planetstorm, das neben den vollständigen Raumschiffinteriors auch den Raumkampf vom Pilotensitz, das bemannen von Geschützen, das verlassen des Schiffes in Fightern, das Boarding anderer Schiffe und das Boarding einer Station ermöglicht. Alle Umgebungen jeweils in 3D ausmodelliert als Level. Zudem gibt es noch Planetenkarten. Bis auf den Spielstil (Tournament) und die FPS Darstellung ist das schon recht nah am oben beschriebenen. Da es UT3 (eine Unreal Tournament 3 Vollversion wird benötigt) für weniger als 10 Teuronen gibt kann man mit dem Download der Planetstorm Full Conversion das ganze Mal in Augenschein nehmen. Da weiß man gleich wie aufwänding das ganze ist. Die haben weit mehr als ein Jahr mit mehreren Leuten daran gebastelt.

Space Vistas

Die Weltraum Szenen sollen eine grosse Tiefe aufweisen. Anders als in einigen Games, wo eine Szene auf ein paar Vordergrundobjekte beschränkt ist soll hier die wahre Größe des All erlebbar werden.

vgl. X Reunion, X-TC und das konmende X Rebirth mit dem aktuellen VS/ PU Material.

X Rebirth Screenshot 1 – Space Vista Example
X Rebirth Screenshot 2- Space Vista Example
X Rebirth Screenshot 3 – Space Vista Example
X Rebirth Screenshot 4 – Space Vista Example