Dynamisches Einlesen der Objekte im Spiel

(Christoph Stenkamp)

Beim Nutzen des virtuellen Rundgangs des AVZs fiel uns auf, dass sich die Struktur des AVZs über sämtliche Stockwerke genügend ähnelt, dass es für unsere Zwecke ausreichend ist, einen Prototypen sämtlicher Räume zu entwickeln, welche dann in der zu sehenden Szene auf immer ähnliche Weise aneinander ge-"klebt" werden. Dadurch entsteht ein sehr hoher Wiedererkennungswert des originalen AVZs ohne die Mühe jedes einzelne Stockwerk einzeln zu modellieren. Desweiteren ist es so prinzipiell möglich, mehr als die 5 bekannten Stockwerke des AVZs zu erzeugen, da ja in unserem Spiel jedes Stockwerk ein Level des Spiels ist. Um den Wiedererkennungswert anschließend dann zu maximieren, wurde allerdings entschieden, das unterste Stockwerk des AVZs ("Pförtneretage", "Groundlevel") dennoch als zusammenhängend zu modellieren, da dadurch mehr Fokus auf kleinere Details gelegt werden kann. Die Prototypen der Räume die wir neben des Groundlevels erstellt haben sind 1 Büro, 1 Vorlesungsraum, 3 verschiedene Arten von Flur sowie den mittleren Flur mit Treppenhaus. Einher mit der Idee, einzelne Räume zu exportieren und entsprechend zu importieren kam die Idee, dass sämtliche Meshes1 nicht hart eincodiert werden sollen, sondern dynamisch ausgelesen werden sollen, sodass man Objekte, Räume und ganze Level hinzufügen kann ohne den Quellcode des Spiels zu ändern. So wurde sich darauf geeinigt, den Aufbau des Levels in folgende drei Kategorien zu unterteilen:

  • In einer Datei stehen sämtliche Stockwerke. Ein Stockwerk enthält, neben weiteren Informationen über das jeweilige Level (z.B. Rauchentwicklung, ambientes Licht oder Codes für spezielle Türen), eine Auflistung an sämtlichen Räumen innerhalb dieses Stockwerkes, inklusive ihrer Verschiebung und Rotation, sodass sie das jeweilige Level bilden.
  • Ein Raum enthält Informationen über sämtliche Objekte o.ä., die sich in diesem Raum befinden, zusätzlich zu Informationen über X- und Y- Ausdehnung des Raumes sowie den Verweis auf das exportierte JSON-File2 des Raumes selbst. Im späteren Verlauf dieses Kapitels wird noch drauf eingegangen, welche Art an Objekten sich in einem Raum befinden kann.
  • Was für Objekte in unserem Spiel überhaupt existieren, ist in einer weiteren Datei gespeichert, als Liste zusammen mit Informationen über z.B. Skalierung und Glättung. Das Speichern aller Objekte in einer Datei hat den unter anderem Vorteil, dass der Fileloader3 durch sämtliche Objekte durchgehen kann und sie vor Gebrauch cachen kann, neben des einfachem Hinzufügens neuer Objekte nach Bedarf.

Die Entscheidung, welcher Dateityp für diese Art Datei gewählt werden sollte, fiel recht schnell auf XML, da diese sehr übersichtlich sind und sowohl von Java4, als auch von Javascript via API unterstützt werden.


1. Die Grundlage sämtlicher Objekte in THREE.js ist das Mesh, siehe dazu die Dokumentation
2. Siehe hierzu die Kapitel zum Blender-Export
3. Informationen über den FileLoader finden sich im Kapitel "Vorladen von Meshes", im Abschnitt Performance.
4. Der Level-Editor ist in Java geschrieben, für mehr Informationen siehe entsprechende Kapitel.

results matching ""

    No results matching ""