Algorithmen für Indoor Game

[malignate]

Hi,
ich habe mich einige Jahre nicht mehr mit Game Programming beschäftigt und bin deshalb was Algorithmen und Verwendung dieser Algos betrifft nicht mehr auf dem neuesten Stand.

Was wäre denn die optimalste Art ein Top Down Indoor Game wie z.B. http://www.youtube.com/watch?v=d12ICw6JiZ4 szenentechnisch zu verwalten?

Das ganze soll ohne eigenen komplexen Editor auskommen, das heisst ich erstelle mein Raum bspw. in 3DS Max, definiere mir meine Verbindungspunkte zu anderen Räumen und hänge die per Editor zusammen. Per Bounding Box pro Raum würde ich dann alle sichtbaren Räume laden, bei einem großen Saal könnte das aber dann trotzdem problematisch werden.

Was ist denn zZ State of the Art um solche Szenen zu verwalten? Ist BSP noch aktuell und angebracht?

[Chromanoid]

benutz doch einfach die engine... das spiel aus dem video ist doch das beispielprojekt für die source engine (mit quellcode und so)...

[malignate]

Prinzipiell eine gute Idee, ich möchte mich aber als hauptberuflicher Entwickler auch mit den Grundlagen beschäftigen.

Das ist mir schon sehr wichtig, ich habe bisher immer die Erfahrung gemacht, dass es sich irgendwann lohnt.

[Chromanoid]

ok das macht sinn :)
also soweit ich das sehe ist bsp immer noch gang und gäbe - das entnehme ich jedenfalls den spezifikationen des bsp file formats aus der dokumentation der source engine :) http://developer.valvesoftware.com/wiki ... ile_Format

mich persönlich würde auch interessieren, ob es noch andere best practices gibt...

für deine architektur (räume in 3dsmax bauen) wäre vielleicht http://de.wikipedia.org/wiki/Portal-Based_Rendering interessant...

[malignate]

So, ich pushe mal, hier gibt ja soviel gute Developer, dass ich hoffe, es kann noch jemand eine Empfehlung geben.

[glassbear]

ok das macht sinn :)
also soweit ich das sehe ist bsp immer noch gang und gäbe - das entnehme ich jedenfalls den spezifikationen des bsp file formats aus der dokumentation der source engine :) http://developer.valvesoftware.com/wiki ... ile_Format

BSP wurde hauptsächlich eingesetzt, um Front-To-Back schnellstmöglich in Software zu rendern.

für deine architektur (räume in 3dsmax bauen) wäre vielleicht http://de.wikipedia.org/wiki/Portal-Based_Rendering interessant...

Jo. Daneben gibt es noch Adaptive Binary Trees, Anti-Portale, Octrees, für Top-Down Quadtrees und mein Favourit: BVH.

[Krishty]

Bei BSP muss ich aber auch die Stirn runzeln … mal, ganz ohne Valves Spezifikation gelesen zu haben,: Wurde das nicht schon vor zehn Jahren allmählich ineffizient?

Bei Top-Down-Indoor braucht es eigentlich nicht einmal Portals, da wird ja kaum was verdeckt … jeden Raum in ein Mesh zu packen, eine schnelle Sichtbarkeitsprüfung einzubauen (von mir aus auch BSP-mäßig) und dann jeden sichtbaren Raum runterzurendern sollte mehr als ausreichend sein, glaube ich … wenn man so eine Tiefenwirkung wie am Anfang des Videos hat, kann es sich lohnen, das Ganze auch 3D durchzuführen statt nur in der Horizontalen (dass 300 m unter dem Geschehen eine Stütze sichtbar ist, sollte nicht heißen, dass man auch den Raum rendert, der sich darauf stützt und noch fünf Bildschirmbreiten entfernt ist) und einen Z-Prepass durchzuführen (oder direkt alles nichtTransparente Front-to-Back zu rendern).

Gruß, Ky

[Chromanoid]

also soweit ich das sehe wird in allen modernen shootern BSP für das grund level eingesetzt. das sieht man schon wenn man sich den leveleditor (hammer) und die tutorials für levelerstellung ansieht. da bei der zurordnung der spezifikation von "bsp format nummer" und benutzendem spiel Alien Swarm aufgeführt wird, ist es ziemlich sicher, dass dort "immer noch" bsp eingesetzt wird.

genauso steht es übrigens um die unreal3 engine... mit unrealEd schält man auch zunächst ein grobes grundlevel als bsp aus der materie...

siehe http://udn.epicgames.com/Three/GettingS ... yMode.html

Introduction
Geometry mode gives the level designer much greater control over their BSP geometry than was ever possible with vertex editing. Vertex editing is still supported, of course, but you can now also manipulate entire polygons and the edges between them as separate entities.

The best part is that you can do all of this without worrying about the integrity of your BSP data. The editor will keep track of what you're doing and will handle most situations automatically. Collapsing a polygon will see it silently removed from the brush, moving a vertex off of a polygons plane will see that polygon automatically triangulated to compensate, etc. Geometry Mode gives you a lot of power but also offers a safety net.

This document will give you the basic information you need to start using geometry mode.

[Krishty]

also soweit ich das sehe wird in allen modernen shootern BSP für das grund level eingesetzt. das sieht man schon wenn man sich den leveleditor (hammer) und die tutorials für levelerstellung ansieht. da bei der zurordnung der spezifikation von "bsp format nummer" und benutzendem spiel Alien Swarm aufgeführt wird, ist es ziemlich sicher, dass dort "immer noch" bsp eingesetzt wird.

Also, zuerst einmal ist die Source-Engine nach meinem Wikipedia-Google-Querhalbwissen kein positives Beispiel: The Source SDK tools are criticised for being outdated and difficult to use. […] The interface of Valve's Hammer Editor, the SDK's world-creation tool, has not changed significantly since its initial release for GoldSrc and the original Half-Life in 1998.

Soo, weiter: Ich dachte wohl missverständlicherweise, hier sei vom Rendering die Rede … für Physik, schnelles Culling ganzer Sektoren und für Spielmechanik dürfte BSP in der Tat noch brauchbar und effizient sein – das ist dann auch der Zweck, für den Unreal und Source noch BSPs verwenden. Für das Rendering (zumindest erstere) aber ganz sicher nicht.

[glassbear]

genauso steht es übrigens um die unreal3 engine... mit unrealEd schält man auch zunächst ein grobes grundlevel als bsp aus der materie...

siehe http://udn.epicgames.com/Three/GettingS ... yMode.html

Da wird CSG beschrieben und wie man es einsetzt. Aber das hat nix mit BSP zu tun. "BSP" an der Stelle ist wohl nur eine Referenz auf "früher".

[Chromanoid]

Aber wieso muss man dann (wenn man den editor nicht benutzt) auf die "BSP Integrity" achten? Siehe mein Zitat oben...

nachtrag: ich möchte ja gar nicht den anschein geben, dass bsp eine besonders tolle methode für moderne engines ist (kenne das thema einfach zu schlecht), es wird eben meinen erfahrungen nach nur immer noch recht häufig für spiele verwendet (weil mich bsp map compiling schon immer genervt hat und man es für viele spiele immer noch über sich ergehen lassen muss).

Hier noch ein recht aktuelles dokument vom 3d gamestudio culling http://manual.conitec.net/culling.htm

nachdem ich mir _enricos favoriten bounding volume hierarchies mal angeschaut habe, würde ich das einsetzen. macht einen eleganten eindruck :).

[glassbear]

Aber wieso muss man dann (wenn man den editor nicht benutzt) auf die "BSP Integrity" achten? Siehe mein Zitat oben...

um keinen kaputten BSP daraus zu generieren. Zu Quake3-Zeiten hat der Map Compiler gerne mal "Leaks" in einer Map reportet (der User hat kein absolut dichtes Volumen erstellt) und das mag der Map/BSP Compiler gar nicht.

Die BSP/PVS-Systeme haben zum einen den Nachteil, dass die Geometrie vollständig geschlossen sein muss (zumindest in der id tech 3 Implementierung - es gibt nicht nur eine BSP-Implementierung). Als zweites muss das ganze vorberechnet werden, was mehr oder weniger Zeit in Anspruch nimmt. Damit ist so Real Time Editing wie bei der CryEngine natürlich nicht möglich - was ich gerade als den Vorteil v.a. für Hobby-Entwickler ansehe. Jede kleine Änderung mit einem statischem System bedeutet:
1) Ändern
2) Compile
2b) (rumärgern - Lust verlieren) Leaks fixen
3) Level laden
4) anschauen ==> zurück zu 1)

Im Vergleich dazu: Real Time Editing (am Beispiel der Cryengine).

nachtrag: ich möchte ja gar nicht den anschein geben, dass bsp eine besonders tolle methode für moderne engines ist (kenne das thema einfach zu schlecht), es wird eben meinen erfahrungen nach nur immer noch recht häufig für spiele verwendet (weil mich bsp map compiling schon immer genervt hat und man es für viele spiele immer noch über sich ergehen lassen muss).

Du meinst Spiele aus der Quake3-Ära? :mrgreen:
Id Software ist ab Doom3 auf Portale umgeschwenkt (die es auch bei Quake3 schon gab, nur noch nicht genutzt). FarCry 1 nutzt einen Quadtree, wenn ich mich recht entsinne (keine Quelle). Auch wenn es keine kommerziellen Spiele sind: Sauerbraten und Cube nutzen einen Octree und das wurde von einem der Farcry-Entwickler entwickelt ;)
Half Life 2 bzw. die Source Engine nutzt immer noch sehr alten Code - teilweise aus Quake 1 Zeiten.

Du sprichst ja selber an, dass du das compiling "über dich ergehen lassen mußt". Dann probier mal Cube/Sauerbraten oder Crysis, falls zur Hand ;)

nachdem ich mir _enricos favoriten bounding volume hierarchies mal angeschaut habe, würde ich das einsetzen. macht einen eleganten eindruck :).

Ich kann die Implementierung in Bullet empfehlen, (der Source hat auch eine entsprechende Demo dazu) - diese Implementierung bietet noch ein paar Leckerlis ;)

[Chromanoid]

Zumindest Team Fortress 2 und Gears of War 1 haben auch noch BSP Kram drin soweit ich mich erinnere... Naja aber deinen Ausführungen nach wird man das also nicht mehr lange erleben müssen ^^. Naja wenn man eine Map für seine Lieblingsspiele bauen will, ist man den Tools ja praktisch ausgeliefert... :) Aber das ist auch ein Grund warum ich mich dann nie länger mit meinen Versuchen beschäftigt habe...
Kennst du eigentlich Spiele, deren Levels man mit 3D Software wie Blender, Maya, 3DSmax oder Softimage XSI reibunglos erstellen kann? Darin sehe ich nämlich das eigentliche Ziel - wenn man das nämlich tun kann, müssen sich Leveldesigner nicht mehr in irgendwelche Tools einarbeiten und könnten so die statischen Modelle und die allg. Level-Geometrie in einem rutsch machen... Für spielspezifische Einstellungen bieten ja eigentlich alle 3D Tools umfangreiche Plugin/Script-Systeme.

[glassbear]

Naja aber deinen Ausführungen nach wird man das also nicht mehr lange erleben müssen ^^.

Es dauert halt auch ne gaaanze Weile, bis Tools umgestellt sind.

Kennst du eigentlich Spiele, deren Levels man mit 3D Software wie Blender, Maya, 3DSmax oder Softimage XSI reibunglos erstellen kann?

Gibt es sicherlich, Beispiele kann ich nur zu Blender nennen: Yo Frankie und die ganzen anderen Spiele, die mit Blender gemacht sind.

Auch Unity geht ja in die Real Time Editing Richtung.

Darin sehe ich nämlich das eigentliche Ziel - wenn man das nämlich tun kann, müssen sich Leveldesigner nicht mehr in irgendwelche Tools einarbeiten und könnten so die statischen Modelle und die allg. Level-Geometrie in einem rutsch machen...

Gerade das seh ich komplett anders (meine persönliche Meinung): Die Modeling-Tools haben ihren Fokus auf ... Modeling, Animation, etc. Ein schlanker, schneller Level Editor, oder eher Level Designer, erlaubt dir das Fokussieren auf deinen aktuellen Task: den Level zusammen zu bauen. Mit einem Modeling-Tool hast du jede Menge Tools, Buttons, Funktionalität, die du überhaupt nicht brauchst und dir den Fokus raubt. Zusätzlich sieht dein Ergebnis im Modeling-Tool u.U. anders aus als nachher im Spiel, was die Iterationszeiten wieder erhöht.

Youtube ist hier leider gesperrt, deswegen keine Links: Such dort mal nach den Making Ofs zu Torchlight. Die zeigen auch ihren Leveleditor. Ich behaupte, mit so einem kleinen Tool geht das Erschaffen von Leveln wesentlich schneller, komfortabler und zielgerichteter als mit Maya/Blender (w.z.b.w.).

Meine persönliche Meinung und ich bau Level gerade mit Google Sketchup in einer WinXP VM zusammen ;) Damit bin ich einfach übel schnell. Leider brauchen die Level dann noch etwas Nachbearbeitung, die mich momentan aber nicht weiter stört.

[dv]

Ein Paper von Leadwerks passt gut zum Thema: http://forum.leadwerks.com/viewtopic.php?f=20&t=2326

Zusammengefasst: alles besteht aus Meshes, keine BSPs usw. Es gibt ein Grundmesh, welches die grobe Struktur des Levels definiert. Dieses Grundmesh ist absichtlich nicht detailliert, und hat wenige Dreiecke. Und dann gibt es Detailmeshes, die quasi auf dem Grundmesh liegen. Bei UT3 gingen die meisten Levels schon in diese Richtung (so >70% Staticmeshanteil war nicht ungewöhnlich), die Rolle des Grundmeshes haben hier die Brushes genommen.

Levels auf Meshbasis sind heutzutage deutlich effizienter und vereinfachen auch den Grafikcode. Darüberhinaus kann man die Meshes in einem Modeler erstellen, und sie im Leveleditor importieren. In dem instantiiert man die Meshes und stellt das Level zusammen, die Meshes sind hier quasi wie Bausteine. Durch IPC-Mechanismen wie COM oder ICE ist es ausserdem möglich, Meshänderungen im Modeler sofort zum Leveleditor zu übertragen.

Fehlt noch die komplett dynamische Beleuchtung. Der stehe ich allerdings skeptisch gegenüber; wenn man einen nennenswerten Anteil an indirekter Beleuchtung haben will, muss man entweder die noch recht langsamen und/oder sehr aufwändigen Techniken wie Reflective Shadow Maps, Imperfect Shadow Maps, Crytek Light Propagation Volumes einsetzen, oder eben vorberechnen. Ich tendiere zu Letzterem.