Wie bau ich mir meinen Dungeon?

[Matze]

Hallo,

vielleicht kennen einige von Euch noch so alte RPG-Perlen wie Dungeon Master, Eye Of The Beholder, Ultima Underworld, usw. Was ich mich schon seit einiger Zeit frage: Würde man solche Spiele heutzutage machen wollen und hätte man den Anspruch, dass die Dungeons wie in Ultima Underworld flüssig scrollen (à la 1st-Person-Shooter), wie könnte man da die einzelnen Level (Dungeons) am einfachsten implementieren? Müsste man sich dafür extra einen Level-Editor programmieren (wie z.B. den GTKRadiant) oder ließe sich so ein Dungeon auch komplett in einer 3D-Software (z.B. Blender) bauen, so dass man dann für jedes Dungeon eine einzige .x/.obj/.fxb Datei einliest. Gegenstände oder andere interaktive Objekte könnte man dann ja programmatisch im Level verteilen, oder?

Hat jemand da vielleicht etwas mehr Erfahrung als ich und kann mir in der Hinsicht einen Tipp geben?


Beste Grüße,
Matze

[TGGC]

Ja, geht beides. f'`8k

[ ] Autocogito


Gruß, TGGC (Was Gamestar sagt...)

[Matze]

Ja, geht beides.

Ok, gibt es vielleicht hinsichtlich der einen oder anderen Variante wesentliche Nachteile? Wie sieht es z.B. hinsichtlich der Performance aus, wenn man das Level als einziges, riesiges Modell realisiert? Welche Optimierungsverfahren braucht man in so einem Fall? Reicht z.B. einfaches Z-Culling aus oder nimmt man da lieber einen Quad- bzw. Oct-Tree, oder noch was anderes?

[ ] Autocogito

Ich hoffe das Link-Ziel hatte keinen Bezug zu meinem Beitrag hier.


Beste Grüße,
Matze

[Chromanoid]

Hi :)

nananana ob das nicht eher in Algorithmen und Datenstrukturen gehört :) ?

Also am besten ist es wohl eine gute Mischung zwischen eigenen Tools und guter 3D Software zu finden. Die meisten kommerziellen Spiele arbeiten mit eigenen Leveleditoren, um Möglichkeiten zur Optimierung (BSP, Terrain-Daten als HeightMaps usw.) voll auszunutzen. D.h. die meisten Level-Designer würden liebend gerne in Maya 3Dsmax und Co. komplett ihre Levels bauen, aber dort sind eben so spezifische Sachen meistens nicht unterstützt und würden auch nicht unbedingt einen Vorteil bringen, weil die 3D Bearbeitungsmöglichkeiten ja immer noch beschränkt wären.

Trotzdem man natürlich auf solche Sachen wie BSP optimierte Level-Architektur verzichten kann, fehlt es 3D Software und den entsprechenden 3D Formaten oft an Möglichkeiten spielbezogene Informationen wie Skripte, Platzhalter für Aktoren usw. zu speichern. Daher ist es ab einer bestimmten Komplexität immer wichtig mindestens kleine Addons zu Entwickeln, die eben solche Spielinformationen zusätzlich zur Geometrie abspeichern.

Ich glaube jede gute 3D Software bietet eine Möglichkeit zu 3D Objekten benutzerdefinierte Informationen abzulegen. Leider werden diese dann meistens nicht in das Exportformat mit übernommen. Daher ist ein kleiner Script, der diese Informationen dann in einer XML-Datei oder Ähnliches ablegt, vielleicht die einfachste Möglichkeit für ein Spiel aus einer ausgereiften 3D Software einen Leveleditor zu machen. Man könnte in 3Dsmax zum Beispiel sog. Dummy Objekte als Platzhalter für Aktoren verwenden. Im Benutzerdefinierten Text für die Dummy Objekte legt man dann einfach die Eigenschaften wie "script=player_start" o.Ä. ab (oder sogar ganze Scripte usw.). Ein Export-Script sollte dann diese Texte in einer Datei speichern und die Zuordnung anhand von Objekt Namen im FBX Dokument vornehmen. In ähnlicherweise könnte man auch für normale Geometrieobjekte einen Text hinterlegen, der dann zum Beispiel aus einem Quader einen Fahrstuhl macht oder ein Mesh als Collsion Mesh oder vielleicht als Navigation Mesh für das Level markiert.

Dungeon Explorer spezifisch würde ich wie eben beschrieben vorgehen aber in der 3D Anwendung statt ganzen Levels eben modulare Teil-Levels aufbauen. In jedem Teil-Level würde ich dann Flächen als Sichtbarkeits-Fenster kennzeichnen und Andockstellen für andere Teillevels. Befindet man sich in einem Teillevel, wird dort dann vielleicht mit Octree alles gerendert was im Sichtbereich liegt. Der Inhalt anderer Teillevels wird dann allerdings nur gerendert wenn man eben durch die Sichtbarkeitsfenster die äußeren Sichtbarkeitsfenster des anderen Teillevels sehen kann (Sichtbarkeitsfenster haben dann Normalen und es gibts sie für aus dem Level rausschauen und in das Level reinschauen) und von da dann rekursiv so weiter durch die Sichtbarkeitsportale in weitere Teil-Level. Den Sichtbereich kann man dann immer pro durchschrittenem Sichtfenster verkleinern. Ich weiß nicht ob das sehr effizient ist, aber ich würde intuitiv so an die Sache rangehen. Durch die Logik mit den Sichtbarkeitsfenstern, kann man schön die verwinkelte Struktur von Dungeons ausnutzen und trotz prozeduralem Aufbau schick designte Räume präsentieren. (das ganze heißt glaube ich portal culling/Visibility Culling hier hab ich was dazu gefunden http://www.3dkingdoms.com/weekly/weekly.php?a=26 http://www.cs.virginia.edu/~gfx/Courses ... ility1.ppt usw.)
Ggf. könnte man die Teil-Level ja parametrisieren und bestimmte Objekte nur bei einem bestimmten Parameter anzeigen. Als Parameter dient dann zum Beispiel eine Pseudozufallszahl zwischen 1-5. In jedem optionalen Objekt gibt man dann eine Erstell-Bedingung an a'la "creationOn=randomNumber == 1" usw.. So kann man dann mal den kaputten Kronleuchter mal die abgewetzten Möbelüberhänge oder mal den von Motten zerfressenen Samtsessel anzeigen.

Naja so würde ich jedenfalls an einen Dungeon Crawler rangehen...

Liebe Grüße
Christian :)

PS: Gesamte level könnte man dann eben entweder mit einem kleinen ingame Editor zusammenbasteln oder ebenfalls mithilfe von einem 3D Programm und Platzhaltern und Scripten zusammensetzen oder von einem Expertensystem zufällig generieren lassen.

[Schrompf]

Das klassische Dungeon Master würde ich als TileMap umsetzen. Nur halt das jedes Tile ein 3D-Objekt ist. Zusammensetzen kannst Du die mit einem Tool Deiner Wahl: Textdatei, einen der Tile-Editoren aus dem Netz oder halt schnell einen eigenen Editor gezimmert. Die freie Bewegung in so einer TileMap sollte dann trivial umzusetzen sein, den Rendercode kannst Du auch anfangs sehr schlicht halten.

[TGGC]

Ja, geht beides.

Ok, gibt es vielleicht hinsichtlich der einen oder anderen Variante wesentliche Nachteile? Wie sieht es z.B. hinsichtlich der Performance aus, wenn man das Level als einziges, riesiges Modell realisiert? Welche Optimierungsverfahren braucht man in so einem Fall? Reicht z.B. einfaches Z-Culling aus oder nimmt man da lieber einen Quad- bzw. Oct-Tree, oder noch was anderes?

It depends. f'`8k

[ ] Autocogito


Gruß, TGGC (Was Gamestar sagt...)

[Chromanoid]

lol Da will wohl jemand seinen Beitragszähler erhöhen...

@Matze: Btw. Falls du Addons für eine 3D Software entwickeln möchtest: das Addon-Framework von 3dsmax ist eher unangenehm (ziemlich komplexes System, wo man viel nur für die Plugin-Architektur an sich programmieren muss). Maya's kenn ich net, aber da gibt's wie bei Blender Python als Scriptsprache. Softimage XSI bietet eine gute .Net Schnittstelle. Bei 3Dsmax finde ich MaxScript ebenfalls eher unangenehm (irgendwie unintuitiv)... Wenn du also noch die Wahl hast dich in ein System einzuarbeiten, kann ich 3Dsmax nur mit Vorbehalt empfehlen (obwohl ich das für meine eigenen Projekte benutze).

[Matze]

@Christian
Vielen Dank für deine sehr ausführliche Antwort. Du hast mir damit eine ganze Menge Denkansätze gegeben. Die Idee ein großes Level zufallsmäßig aus kleineren Levelfragmenten zusammenzubauen ist sehr interessant. Ich denke, da werde ich mich mal ein bißchen einlesen.

@Thomas
Zwar ein sehr einfacher Ansatz, aber durchaus etwas, womit ich einfach mal beginnen könnte. Danke auch Dir!