MaxScripts (28.04.2010)
in: Leveldesign, Modelling, Screenshots, Worlddesign

Ich habe mir, als eine Art zusätzliche Unterstützung für meine Pipeline, zwei Scripts gebastelt, welche in 3dsmax zur Anwendung kommen. (Sie wurden also in MaxScript geschrieben.)

Das erste ist für's Exportieren da:



Mit einem Klick habe ich dann meine Objekte im Spiel. Das Script nutzt hierbei die Scripting-API von OgreMax. Da OgreMax ein Szenen-Exporter ist, legt es bei jedem Klick auch eine .scene-Datei an, die ich nicht benötige (genauso wenig wie die Materialenbeschreibungs-Datei) - mein Script löscht sie daher.
Etwas komplexer wurde mein Script durch die Tatsache, dass ich Objekte mit unterschiedlichen Material IDs habe, auf denen aber keine echten 3dsmax-Materialien liegen - OgreMax fasst solcherlei Teil-Objekte dann automatisch zusammen (mit einem Material namens "NoMaterial"). Daher muss mein Script Meshes selbst erst einmal aufsplitten, bevor sie exportiert werden.

Mein zweites Script ist eigentlich eine (ständig wachsende) Script-Sammlung, mit kleinen aber feinen Funktionalitäten:



Wichtig ist vor allem die "Distributing"-Gruppe - schnell und einfach lassen sich dann kleinere Assets auf einem größeren Mesh entlang der Oberflächennormale verteilen, mit zufälliger Skalierung und Rotation. Das kann dann so aussehen aus wie auf diesen Bildern:

Ingame-Editor (14.09.2009)
in: Leveldesign, Prototyp, Screenshots

Nach der letzten Konsultation bei meinem betreuenden Professor (bezüglich der Gliederung meiner schriftlichen Arbeit), habe ich endlich mal wieder die Muße, ein wenig zu schreiben.
Zur Zeit arbeite ich ab und zu mal an dem bereits erwähnten Ingame-Editor. Wie man auf den Screenshots sieht, kann das Verschieben, Rotieren, Skalieren von Objekten jetzt auch mittels "Gizmos" ausgeführt werden. Das Vergeben von neuen Meshes, Shapes und Materialien ist ebenfalls möglich. Nicht im Bild: Das Erstellen, Löschen und Kopieren von Gegenständen, sowie ein halbwegs funktionierendes Undo/Redo.
Im Grunde ist die Implementierung eines Editors für ein Projekt dieser Größe eigentlich sinnlos, weil unnötig zeitraubend. Andererseits muss ein Großteil der Funktionalität, die ich für den Editor basteln muss, am Ende sowieso vorhanden sein. Überdies hat es mir nochmals ein paar Ideen zum sinnvolleren Codedesign geliefert - auch wenn der Editor selbst nicht gerade sauber programmiert wird. Hauptsache, er läuft mehr oder weniger, und ich kann am Ende schnell ein paar Levels basteln. Je weniger Schritte die Pipeline bedarf, desto besser.

(Was man auf den Screenshots eventuell ebenfalls sieht: Ich habe AntTweakBar zugunsten einer einfacheren Debug-Anzeige entfernt.)

Interface-Sachen (25.08.2009)
in: Leveldesign, Prototyp, Screenshots

Da ich bis jetzt nichts über das Thema "Interface" geschrieben habe, will ich das jetzt mal nachholen. Auf dem Screenshot sieht man dabei die drei Arten an Menüs, die mich zur Zeit begleiten. Jedes der Fenster lässt sich ein- und ausblenden.

Unten links befindet sich das Hauptmenü. Es ist das einzige der drei, das später auch der Spieler zu Gesicht bekommen wird (natürlich nicht in dieser Gestalt). Momentan kann man hier vor allem die Bildschirmeinstellungen verändern. Wechselt man den Renderer (Direct3D oder OpenGL), muss man das Spiel allerdings neu starten.
Um dieses Menü anzuzeigen benutze ich Hikari, eine Bibliothek, die es erlaubt, Flash-Inhalte in OGRE darzustellen. Auf diese Weise werde ich recht einfach anspruchsvolle Menüs erstellen können.

Links oben sieht man eine Art Debug-Fenster, erstellt mittels AntTweakBar. AntTweakBar ist unabhängig von OGRE, daher war der Einbau etwas schwieriger (und ist es noch). Aber dank diesem leicht anpassbaren Fenster kann ich mir schnell und übersichtlich diverse Variablen innerhalb meines Programmcodes anzeigen lassen. Es ist sogar interaktiv, sodass ich diese Variablen auch unmittelbar verändern kann, so ich denn will.
Selbstverständlich wird das fertige Produkt dieses Fenster nicht beinhalten.

Den aktuellen Stand meines Ingame-Editors sieht man ganz rechts auf dem Screenshot. Das meiste davon ist noch Fake, aber das Darstellen und Ändern der Eigenschaften Masse, Gravitation, Position und Rotation eines ausgewählten Objektes (erkennbar an der roten Wireframe-Box) funktioniert bereits relativ problemlos. Als nächstes steht hierbei das Hinzufügen und Löschen von Objekten auf dem Plan.
Mittels dieses Menüs werde ich innerhalb der Applikation neue Level erstellen und vorhandene ohne Umwege bearbeiten können; was das Testen einer Spielsituation wesentlich vereinfachen sollte.
Natürlich müssen die eigentlichen Meshes bereits in 3D Studio Max oder einem anderen 3D-Modeller gebaut worden sein - mehr aber auch nicht.

Jetzt sollte ich aber mal aufhören, mich vor der Erweiterung und Bearbeitung meines Konzepts zu drücken ... So viel zu tun, so wenig Zeit!

Es bewegt sich was (23.06.2009)
in: Konzept, Leveldesign, Modelling, Physikrätsel, Prototyp, Screenshots

Ein frühes Testlevel wurde in den Prototypen eingebaut, und auch gleich mal ein Testcharacter. (Die Figur stammt aus Omertà.) Wichtig ist erst einmal, herauszufinden, welches Terrain welche Physikrätsel begünstigt bzw. welche Physikrätsel welches Leveldesign benötigen.

Momentan kann der User die Taste G drücken und verändert damit seine persönliche Gravitation. Insgesamt hat das schon jetzt einen sehr eindrucksvollen Effekt, wenn man plötzlich auf der Wand läuft, und Kugeln und Kisten so aussehen, als ob sie verrückt spielen, da sie - natürlich aus Sicht des Spielers - seitwärts fallen ...

Weiterhin ist es möglich, zwischen Ego- und Third-Person-Perspektive zu wechseln. Da ich mir selbst noch unsicher bin, welchen Blickwinkel ich verwenden werde, hilft mir diese Funktion, Situationen in dieser Hinsicht sofort testen zu können.

© 2009 Friedrich Hanisch