Map Design

Nicht nur ästhetische, sondern auch technische Kriterien müssen beim Level-Design beachtet werden. Ein BSP-Tree Level besteht nur aus einer Anordnung von sich schneidenden Flächen. Die Kanten und Eckpunkte werden automatisch aus den Schnittlinien der Flächen berechnet. Der Vorteil dieses Konzepts ist, dass Blocks sich beliebig durchdringen können - die unsichtbaren, überlappenden Teile werden beim Build-Prozess automatisch 'abgeschnitten'. Die erhöht die Framerate, da nur die wirklich sichtbaren Teile der Blocks gerendert werden (andere Engines würden einfach alle Blocks komplett übereinander rendern). Der Nachteil ist, dass kleine Winkeldifferenzen große Eckpunkt-Verschiebungen bewirken. Wenn sich Flächen unter einem sehr kleinen Winkel berühren oder schneiden, können Ungenauigkeiten vor nur einem hunderstel Grad zu einer Verschiebung der Schnittkante von mehreren Pixeln führen. Dies ist im Level durchaus sichtbar.

Vermeiden Sie daher extrem schmale, langgezogene oder spitzwinkelige Blocks. Bauen Sie keine Blocks mit Kanten, die kürzer als 2 Quants sind. Versuchen Sie mit so wenig Flächen wie möglich auszukommen, und arbeiten Sie mit möglichst dicken Blocks. Manchmal können Sie nicht vermeiden, dass sich Flächen unter einem kleinen Winkel berühren - aber auch dann gibt es schlechte und gute Methoden. Nehmen wir als Beispiel eine Straße, die über einen Hügel führt (Seitenansicht):

Schlechtes Design: lange dünne Platten. Kleine Winkelungenauigkeiten können an den markierten Stellen zu von oben sichtbaren 'Lücken' oder 'Stufen' führen.

Besseres Design: 3 Blocks mit 13 Flächen anstelle von 5 Blocks mit 20. Winkelungenauigkeiten, falls welche auftreten, sind hier nicht sichtbar.

Winkelungenauigkeiten werden verbessert, wenn Sie den High Prec Modus beim Map Compilieren verwenden. Hierfür müssen Sie allerdings einen Preis in Form längerer Build-Zeiten und größerer Dateien bezahlen. Wenn Sie Software von Drittanbietern, wie Gensurf, zum Erzeugen von Map basiertem Terrain benutzen, müssen Sie in der Regel High Prec aktivieren, um Spalten und Linien im Terrain zu vermeiden.

Noch einige Ratschläge zum Leveldesign:

• Benutzen Sie beim Level-Design die Snap-Funktion so oft wie möglich. Blocks, die perfekt aneinander ausgerichtet sind und deren Seiten in allen drei Fenstern genau vertikal oder horizontal verlaufen, sehen nicht nur besser aus - sie werden auch schneller compiliert und dargestellt.

• Umgeben Sie den Level mit einer Sky-Box. Eine Sky-Box ist einfach ein ausgehöhlter Kubus mit einer Sky- oder anderen Textur. Ihr Level wird davon umschlossen, wie Sie es im Office-Level sehen.

• Benutzen Sie das Detail Flag für kleine Details, die weder die Sichtweite begrenzen, noch Kollisionserkennung brauchen.

• Halten Sie Ihre Map klein. Je näher ein Block dem Map-Nullpunkt ist, desto genauer wird er gerendert. Wenn Sie eine große Map brauchen, z.B. für eine ganze Stadt, benutzen Sie Blocks für grobe Strukturen wie Gebäude, und Entitites oder Detail-Blocks für Details wie z.B. Laternenpfähle. Andernfalls können in weiter Entfernung vom Nullpunkt sichtbare Fehler im BSP-Tree auftreten. Sie können mit dem d3d_nobsp Engine-Flag verhindert werden, aber es ist besser, sie gar nicht erst auftreten zu lassen.

• Setzen Sie bei allen Oberflächen, die im Spiel nicht sichtbar sind - etwa bei der Unterseite von Bodenplatten oder den Seiten von Wasserblocks - das None Flag. Damit sparen Sie etwas Compilierzeit sowie Texturspeicher, der sonst für Shadow-Maps verbraucht würde.

Compilieren

Um eine Map zu generieren, kann WED ein paar Sekunden oder auch einige Stunden brauchen - im Extremfall sogar Tage. Das hängt vom Design der Map ab, speziell davon, wie viele Blocks und Lichtquellen vorhanden sind. Die Abhängigkeit ist quadratisch, das heisst, bei Verdoppeln der Blocks dauert das Generieren ungefähr vier mal so lang. Ein Indikator dafür ist die Anzahl der Portale, die vom Build-Prozess ausgegeben wird. Portale sind die Trennflächen zwischen Regionen, in die der BSP-Prozess den Level aufteilt. Jede Fläche eines Blocks kann als Trennfläche dienen und so ein oder mehrere Portale erzeugen. das Skalieren von Blocks kann die Anzahl von Portalen erhöhen respektive verringern.

Wenn Sie mehr als 5000 Portale haben, versuchen Sie Ihr Level zu reduzieren - etwa indem Sie Prefabs durch Map Entities und normale Blocks durch Detail-Blocks ersetzen. Wenn Sie wirklich extrem riesige Levels kompilieren wollen, rüsten Sie Ihren PC mit einer Menge RAM aus - Sie brauchen mindestens 128 MB für bis zu 10.000 Portale, und 256 MB für 15.000 Portale. Im Vorschau-Modus (Preview) geht es sehr viel schneller, aber die WMB-Datei wird dabei nicht optimiert, d.h. die Frame Rate im Spiel ist deutlich geringer, und die Schatten haben "Zacken". Die kürzeste Generierungszeit wird erreicht, wenn Test Map und Preview gleichzeitig markiert sind.

Levels sollten während der Entwicklung mit Preview, und für die endgültige Version ohne Preview compiliert werden. Jeder angezeigte Punkt in der Portals und Visibility-Berechnung entspricht 20 Portalen, also können Sie abschätzen, wie lange der Level noch brauchen wir. Die Berechnungszeit pro Punkt läßt sich allerdings nur schwer vorhersagen und ist in der Regel bei den letzten Punkten viel größer als bei den ersten. Wenn Sie ein sehr großes Level haben, aber keine Zeit für eine tagelange Berechnung, compilieren Sie die Endversion mit Preview aus, aber Test Map eingeschaltet.

Fehler

Es kann vorkommen, dass Warnungen oder sogar Fehlermeldungen während des Compiliervorgangs ausgegeben werden. Im letzteren Fall wird keine WMB-Datei erstellt. Eine Liste der Meldungen finden Sie im Referenz-Handbuch. Die Fehler stammen gewöhnlich von Problemen in Ihren Maps. Zu den üblichen Fehlern, die vorkommen, zählen unter anderem

- Ändern der WMP-Datei von Hand
- Zuweisen von Wasser-, Himmels- und normalen Texturen dem gleichen Block
- Überschreiten der im Level erlaubten Maximalanzahl von Blocks, Oberflächen oder Texturens

Manchmal sind solche Probleme nicht offensichtlich. Sehr schmale, langgezogene oder spitzwinkelige Blocks - z.B. extrem lange dünne Platten - können im Extremfall 'Löcher' im Level oder in der Kollisions-Hülle verursachen. Vermeiden Sie kleine Winkeldifferenzen zwischen benachbarten Blocks. Wenn Sie eine Warnmeldung (Warning) erhalten, können Sie diese normalerweise ignorieren; die meisten Warnungen schaden dem Level nicht weiter. Wenn Sie aber einen sichtbaren Fehler im Level entdecken, sollten Sie versuchen herauszufinden, wo das Problem liegt. Meist hängt es an einem bestimmten Block, dessen Nummer in der Warnmeldung angegeben wird. Benutzen Sie den Find Block-Befehl, um den in Frage kommenden Block zu untersuchen. Es kann vorkommen, dass nachdem Sie einen verdächtigen Block gelöscht haben, ein anderer mit derselben Warnung auftaucht. Der BUILD-Prozess gibt nur eine Warnung der gleichen Art auf einmal aus, wenn also Dutzende von fehlerhaften Blocks vorhanden sind, wird nur der erste gemeldet.

Eine andere Art von Fehlermeldungen wird von einem zu großen oder zu komplexen Level produziert. Wenn Sie Meldungen wie 'Map size - too much blocks', 'too much surfaces', 'too much portals' oder 'visibility list overrun' sehen, ist die Lösung zwar schmerzhaft, aber einfach: Entfernen Sie ein paar Blocks oder ein Gebäude aus Ihrem Level. Sonst passt es nicht mehr in den Speicher. Wenn Sie wirklich ein riesiges Level brauchen - etwa für eine ganze Stadt - versuchen Sie es in einzelne Map Entities zu unterteilen und diese separat zu generieren. Plazieren Sie diese dann in ein fast leeres Level, das nur aus einer Sky Box (und evtl. einer Grundplatte) mit aktiviertem Sonnenlicht besteht. Die Frame Rate wird etwas niedriger sein, als wenn Sie alles zusammen generieren, aber manchmal gibt es keine bessere Lösung.

Manche Fehler werden nicht angezeigt, sondern sind nur im Level sichtbar. Der BSP-Tree Prozess unterteilt die Map in Regionen entlang aller Nicht-Detail-Oberflächen. Dies kann zu starker Zerteilung von Oberflächen in Räumen mit komplexer Geometrie führen. Sie sehen die Unterteilung, wenn Sie die [D]-Taste zweimal drücken, während die Engine läuft. Manche 3D-Karten stellen "T-Verbindungen" - wo sich drei Flächen berühren - ungenau dar, was zu sichtbaren "Säumen" im Level führen kann. Aus diesem Grund versucht der Compiler, T-Verbindungen möglichst zu vermeiden. Ein weiteres Problem kann entstehen, wenn Unterteilungen einer Fläche kleiner sind als ein Pixel der Shadowmap (= 16 Texturpixel). In seltenen Fällen kann ein leichter "Schattensaum" entlang der Kante dieser Fläche entstehen. All diese Probleme sind keine "Bugs", sie ergeben sich aus dem BSP-Tree-Algorithmus und der Auflösung der Shadowmap, und sind in der Regel nicht sichtbar. Sie können andernfalls durch Vereinfachung der Geometrie oder Verwendung von mehr Detailblocks gelöst werden.

Texturen

Um Ihr Level im D3D (16 Bit oder 32 Bit) Modus laufen zu lassen, müssen Sie die maximale Texturgröße und die Größe des Video-Speichers berücksichtigen, mit dem Ihre 3D Karte (und die Ihrer Kunden) ausgestattet ist. Manche alten 3D Karten haben nur 8 MB Videospeicher. Breite und Höhe von Level-Texturen sollten eine Zweiterpotenz sein, wie 64, 128, oder 256. 3dfx / Voodoo Karten kommen nur mit Texturen von maximal 256x256 Pixeln zurecht. Im Zweifelsfall werden die Texturen von der Engine automatisch umgerechnet, was aber zu schlechterer Darstellungsqualität, höherem Speicherverbrauch und längeren Ladezeiten führt.

Videospeicher wird nicht nur von den Texturen, sondern auch von allen schattierten Oberflächen in der Map verbraucht. Jedes Texturpixel braucht 5 Byte Speicher, schattierte Oberfläche braucht pro 64 Pixel ein weiteres Byte für die Shadowmap. Hinzu kommt der Speicherbedarf für das Bild selbst, das bei hoher Auflösung in 16 Bit Farbtiefe allein über 3 MB verbraucht. Große Level können daher den Grenzwert von 8 MB rasch überschreiten. Das Spiel wird zwar trotzdem laufen, aber einige Texturen werden nun ausgelagert, was - je nach 3D Karte - zur Verlangsamung oder gar zu plötzlichen 'Stockungen' oder 'Ruckeln' während des Spiels führen kann. Fortgeschrittene Anwender können den Verbrauch von Videospeicher mit der d3d_texsize Variablen feststellen und das berüchtigte 'Ruckeln' durch Einstellen der d3d_texreserved Variablen verhindern (s. C-Script Handbuch).

Map-Grenzwerte

Map Größe (Quants) . 100000 (bei Koordinaten-Nullpunkt im Zentrum der Map)
Polygone pro Block .......... 30
Ecken pro Polygon ........... 15
Texturgröße ......... 1024x1024 (alte 3D-Karten, wie Voodoo3, rendern Texturen über 256x256 in schlechter Auflösung)
Texturen gesamt ........ 32 MB (alte 3D-Karten haben begrenzten Texturspeicher, z.B. 8 oder 12 MB)