Technik

Die Randwelt baut auf etablierte Technik, damit wir uns um den Inhalt kümmern können, nicht um die Grundlagen

Ogre

Als Grafik-Engine kommt seit kurzem Ogre zum Einsatz. Das Verhältnis zwischen Qualität und Performance ist äußerst gut, außerdem existieren eine Vielzahl von Plugins sowie eine riesige Community.

Newton

Als Physik-Engine wird Newton eingesetzt, da es perfekt mit Ogre zusammenspielt (über das Ogre-Plugin OgreNewt). Auf eine eigene Physik-Engine, die bei der Irrlicht-Implementierung notwendig war, konnte somit verzichtet werden.

Audiere

Die Audio-Engine kommt derzeit nur für die Hintergrundmusik zum Einsatz. Die Anwendung ist extrem einfach und intuitiv, jedoch können mit Audiere keine 3D-Sounds realisiert werden, was langfristig zu einer neuen Wahl führen könnte.

Caelum

Dieses Ogre-Plugin realisiert einen Tag-und-Nacht-Wechsel inklusive dynamischer Beleuchtung durch die Sonne und einem wunderschönen Sternenhimmel. Leider ist die Darstellung von Wolken etwas dürftig, aber die kann man ja auch anderweitig generieren.

PagedGeometry

Mit diesem Ogre-Plugin ist es möglich, viele gleichartige 3D- und 2D-Modelle sehr performant zu rendern (z.B. für Wälder oder Wiesen). 3D-Modelle werden ab einer gewissen Entfernung als Low-Poly-Version dargestellt und ab einer noch größeren Entfernung nur noch als Sprite. Beides wird automatisch von PagedGeometry erzeugt. Wir benutzen lediglich das 2D-Feature, um Grasstrukturen zu generieren (die sich auch im Wind bewegen). Das 3D-Feature ist für unsere Zwecke nicht geeignet, da wir aufgrund der Kachelung unserer Welt zu viele PagedGeometry-Loader benötigen würden und dadurch dann die Framerate sehr stark schwankt.

XML

Ist die Beschreibungssprache für fast alle Daten im Spiel, egal ob es sich dabei um Monster, Items, Dialoge oder Quests handelt. Wir verwenden einen selbst implementierten Serializer, der auf sehr abstrakter Ebene bestimmte Attribute einer Klasse speichert oder lädt. Als zugrunde liegender XML-Parser wird tinyXML verwendet.

LUA

Diese Skriptsprache wird zukünftig für Handlungen und Events verwendet.

Ogitor

Mit diesem 3D-Welteditor sieht man schon während der Gestaltung eines Sektors, wie dieser später im Spiel aussehen wird. Eine Ogitor-Szene hat bei uns eine Kantenlänge von 200 Metern und wird standardmäßig als .scene-Datei hinterlegt, welche dann mit dem OpenSource-Tool "DotSceneLoader" in die Ogre-Szene integriert wird. Um eigene Anforderungen wie beispielsweise Kollisionserkennung, Koordinatentransformation oder auch Vorhalten der Modelle fürs spätere Entladen zu berücksichtigen, haben wir vom DotSceneLoader einen "RandweltDotSceneLoader" abgeleitet. Derzeit werden von all den schönen Ogitor-Features nur 3D-Modelle und 3D-Lichtquellen unterstützt.

Synchronisation der Entwickler

Der Quellcode unterliegt einem Versionsmanagement via SVN. Größere Dateien wie Modelle, Bilder oder Musikstücke werden in einem Dropbox-Ordner gehalten. Executables fließen periodisch von SVN zu Dropbox, während die besagten Ressourcendateien in die andere Richtung unterwegs sind. Darüber hinaus verläuft die Kommunikation über ein strukturiertes Forum und monatliche Skyperunden.

KI

Die KI wird derzeit über einen Zustandsautomaten realisiert. Wechsel zwischen den Zuständen Idle, Walk, Fight, Hit, Die können zeitbasiert (intern) oder eventbasiert (extern) eintreten. Damit lassen sich schon Kämpfe in interessanten Formationen realisieren (s. Prolog). Langfristig werden Handlungen auch geskriptet werden können, jedoch wird es auf jeden Fall Experimente mit neuronalen Netzen und genetischen Algorithmen geben.

Regelwerk

Das Rollenspiel-Regelwerk wurde von einem Mitglied unseres Entwicklerteams und dessen Rollenspiel-Mitstreitern entworfen. Ziel war es, Nachteile bekannter Systeme (D3D, DSA) zu eliminieren und Vorteile zu vereinen. Das Produkt wurde monatelang in Pen-and-Paper-Sessions getestet und optimiert. Die Umsetzung auf den Computer verlief problemlos, obwohl weitere Komponenten (Ausdauer, Rundenbasiert->Echtzeit) erforderlich waren. Jedem Lebewesen in der Randwelt, egal ob Baum, Mensch oder Monster, liegt das Regelwerk zugrunde (Besitz von Attributen, Möglichkeit zum Kampf). Nur KI und graphische Attribute ändern sich in der ersten Ableitungsebene.

Eventmanager

Es wurde mittels Template-Metaprogrammierung eine Bibliothek entwickelt, welche die Verwaltung von Events übernimmt. Dazu können beliebige Events erstellt werden, die anhand einer Funktionssignatur, einem ID-Typ und einer Auslöser-Typliste spezialisiert wird.
Durch Verwendung von Letztem kann festgelegt werden, welche Klassen dieses Event auslösen dürfen. Als weiteres Feature gibt es für die Clients(die auf ein Event reagieren wollen) die Möglichkeit, dass sie sich zur Laufzeit für nur bestimmte Übergabeparameter beim Event registrieren. Dadurch wird der Client bei einem Ereignis nur aufgerufen, wenn die passenden Parameter beim Auslösen des Events übergeben wurden. Die Prüfung der passenden Übergabeparameter ist dabei über eine Hashmap realisiert, um optimale Performance zu erhalten.

GUI

Die verschiedene GUIs (sei es das Inventar, geöffnete Truhen, Statusleisten usw.) werden vom selben GUI-Framework abgeleitet. Es basiert auf MyGUI und wurde sehr generisch entwickelt, um eine maximale Wiederverwendbarkeit des Codes zu realisieren. Mit dem Framework ist es relativ einfach, weitere GUIs in die Randwelt einzufügen (zum Beispiel Dialoge mit NPCs), die auf ein ähnliches anmutendes Interface wie die der anderen basiert und somit von sofort intuitiv vom Spieler angenommen werden. Nur Hintergrundbild, die Auswahl und Position der graphischen Elemente muss neue erstellt werden. Das Framework bietet so genannten Callback-Funktionen, die vom Entwickler mit eigenem Code überschrieben werden können.
Es ist geplant, neben den klassischen GUIs auch ein kreisförmiges Menü-System zu entwickeln, welches die wichtigsten Spieleraktionen steuern wird...

Unendliche Welt

Zur Illusion einer unendlichen Welt ist unsere Welt in quadratische Kacheln mit 200 Metern Kantenlänge aufgeteilt. Der Spieler wechselt zwischen den Kacheln, ohne den Übergang zu bemerken, da er sich immer in seinem lokalen Koordinatensystem (-100, +100) befindet. Vielmehr schieben sich die Kacheln unter ihm hinweg (Modelle, Kollisionsobjekte, Trigger). Zu jedem Zeitpunkt sind genau 9 Kacheln geladen (3x3), wodurch der Spieler von allen Seiten von Kacheln umringt ist. Mit einem simplen Paging-Algorithmus werden Kacheln in Bewegungsrichtung geladen sowie Kacheln der entgegengesetzten Richtung gelöscht. Das dynamische Nachladen ist derzeit noch nicht threadbasiert, was vereinzelt zu Ladezeiten führen kann. Des Weiteren ist die Sichtweite durch diesen Mechanismus auf maximal 400 Meter begrenzt. Zukünftig werden wir zu 4x4 und 5x5-Ringen übergehen. Derzeit besteht die Randwelt aus 150 Kacheln, was einer Größe von 2x3 km entspricht. Die "Verschiebung" wird immer dann ausgelöst, wenn sich der Spieler 20 Meter aus seiner Zentralkachel entfernt hat. Dadurch wird nicht ständig gepagt, wenn der Spieler zwischen zwei Kacheln entlangläuft.