Performance:verwendete Beispielmap:
"tutor37.map" So, nun bist du schon dabei, deine erste Map zu erstellen. Deshalb will ich dir an dieser Stelle erklären, wie man die Performance überprüft. Die Performance heisst übersetzt "Leistung", und gibt an, wie flüssig deine Map auf einem System läuft. Nichts ist ärgerlicher, als wenn die eigene Map nicht auf dem eigenen Rechner läuft. Als erstes wollen wir uns mal die r_speeds von der Map ansehen. R_Speeds sind mehrere Zahlen, die die Auslastung des Systems anzeigen und durchs Bild fliegen. Um diese r_speeds anzeigen zu lassen, musst du die Map natürlich erst einmal compilieren. Dann schaust du nochmal nach, ob die *.bsp Datei im Ordner "Main/Maps" befindet. Sonst kommt nämlich ein Error. Befindet sich diese Datei nicht im Maps-Ordner, hast du die Map noch nicht compiliert, oder du hast einen Fehler. Befindet sich die Datei im Ordner, lädst du erstmal das Spiel, und drückst die Taste "^", damit öffnest du die Console. Hier tippst du die folgenden Befehle ein:
Beim "/devmap X"-Befehl darfst du nicht vergessen, dass du die *.bsp Endung nicht eintippst, sonst läd sich die Map ebenfalls nicht. Nun läd deine Map. Wenn die Map fertig geladen ist, drückst du nochmals die Taste "^", um wieder die Console zu öffnen. Jetzt tippst du ein:
Nun erscheinen die oben erwähnten Zahlen, die die Auslastung des Systems anzeigen. So ungefähr sieht das dann aus: Die markierten Zahlen geben an, wie viele Polygone oder Dreiecke die Engine rendert. Du solltest darauf achten, dass diese Zahl im schlimmsten Fall den Wert 12.000 bis 14.000 nicht überschreitet ( z.b. vom obersten Bunker auf der Map mp_beach liegt diese Zahl bei 13.000. Am besten ist jedoch ein Durchschnitt von 8.000 Polygonen. Du solltest durch deine gesamte Map laufen um diese Polygonen-Anzahl zu überprüfen, da sich diese Anzahl mit jeder Blickwinkeländerung steigen/sinken kann. WICHTIG: Da nachher neben der Map auch noch die Spieler/Bots berechnet werden, solltest du pro Spieler/Bot 800 - 1.000 Polygone hinzuzählen. Nun gibst du in die Console den folgenden Befehl ein:
Mit diesem Befehl schaltest du die r_speeds-Darstellung wieder aus.
r_speeds und VIS:Nun tippst du noch
ein. Nun siehst du, was die Engine von deiner Map berechnet. Im Idealfall sollte nur das berechnet werden, was der Spieler auch sieht. Meist wird jedoch mehr berechnet, als man tatsächlich sieht. Sieht der Spieler beispielsweise durch ein Fenster nur einen kleinen Teil eines Raumer, zeichnet die Engine den ganzen Raum. Die Engine zeichnet nämlich zuerst die am weitesten entfernten Teile und überdeckt diese dann mit den näheren Teilen des Raums. Dies führt dazu, dass auch wenn man nur einen kleinen Teil sieht die Engine dennoch auch das dahinter liegende rendert. Wie du sicher schon gesehen hast, wird eine Map in 3 Prozessen compiliert: BSP, VIS und RAD:
Für die r_speeds ist VIS wichtig. Beim VIS gibt es mehrere Optionen, 2 davon sind fast-vis und full-vis. Für korrekte r_speeds-Angaben solltest du die Map mit full-vis compilieren lassen, da nur hier die VIS-Blocker funktionieren und damit die r_speeds eine genauere Aussagefähigkeit besitzen.
r_speeds und verwandte Befehle:Nun hast du sicher bemerkt, dass wir die Map immer mit dem Befehl "/devmap [Mapname]" starten. Das liegt daran, dass r_speeds und andere nützliche Befehle leider Cheat-geschützt sind - das ist auch gut so, mit r_showtris z.b. werden ja auch die Spieler hinter den Wänden dargestellt. So ist z.b. "/noclip" ein nützlicher Befehl, um die Map aus jedem Blickwinkel betrachten zu können. Hierzu habe ich mal einen Ausschnitt eines Posts von Paul Jaquays gefunden: These are my development
keys. You have to be in devmap mode to use them. bind F2 "toggle
r_nocurves" r_lockpvs locks your
point of view in place so you can wander your map and see r_showtris is showing
you EXACTLY how the world is being broken into triangles. Use the r_nocurves command to remove the confusing curve data from your view. Same with r_drawentities
Nun will ich dir mal einige Beispiele zeigen, wie man die Performance etwas verbessern kann: VIS-Blocker: VIS-Blocker sind gaz normale Konstrucktionen, die verhindern sollen, dass der Spieler zuviel auf einmal von der Map sieht und so die r_speeds in den roten Bereich treibt. So soll also verhindert werden, dass der Spieler im Raum 1 nicht in den Raum 2 sehen kann. Es gibt viele VIS-Blocker-Methoden, aber die folgenden 2 kommen sehr häufig vor: Ein gängiger Vis-Blocker ist diese Eck-Konstruktion. Hier solltest du auf die rote Sichtline vom Spieler achten. Im folgenden Bild funktioniert der VIS-Blocker nicht, da der Spieler vom Raum 1 in den Raum 2 sehen kann: Verlängern wir aber den nach oben laufenden Gang, so kann der Spieler nichtmehr in den Raum 2 sehen. Nun funktioniert der VIS-Blocker:
Eine andere Methode ist die sogenannte "Donut-Konstruktion". Hierbei wird in einen Zwischenraum eine Trennwand eingebaut, der die Sicht vom Raum 1 in den Raum 2 verhindert: Ich habe dir hier mal den Zwischenraum schraffiert, und den "Donut-Brush" markiert. Dieser Brush nimmt nun die Sicht, vom Raum 1 kann man nun nichtmehr in den Raum 2 sehen. Dabei ist zu beachten, dass der Donut-Brush vom Boden bis an die Decke geht, sonst funktioniert er nicht. Ebenso darf sich auf dem Brush keine transparente Textur befinden, sonst kann man ja hindurchsehen, und die ganze Aktion war unnötig. Hint-Brushs: Hint-Brushes sind dünne Brushes, die mit der "common/hint"-Textur belegt sind. Sie dienen dazu, die Map in mehrere VIS-Sektoren zu unterteilen. Sie funktionieren jedoch nur dann, wenn sie mindestens 8 Units in die umliegenden Brushes hineinragen. So muss z.B. ein Hint-Brush in einem Gang den Boden, die Decke und die beiden Wände um jeweils 8 Units überschneiden: Solche Hint-Brushs werden an Stellen eingesetzt, die dem Spieler die Sicht verdecken, z.B. einer Ecke in einem Gang. In einem geraden Gang macht ein Hint-Brush keinen Sinn, aber ich habe mal einen solchen Bruhs gebaut, dass du die Überschneidungen gut sehen kannst. Oft macht es sogar Sinn, in deine Map horizontale Hint-Brushes einzubauen - besonders dann, wenn sich dein Level über mehrere Ebenen erstreckt. Hint-Brushes können auch an andere Hint-Brushes angrenzen. Wichtig ist nur, dass es keine freistehenden Kanten gibt, da sonst der Hint-Brush seine Wirkung verliert. Hier kannst du dir z.B. mal die Maps ansehen, die im Radiant mitgeliefert werden, hier werden die Hint-Portale sehr oft eingesetzt. Ich habe dir ja, wie du oben gesehen hast, eine Beispielmap gebaut, in der du die Hint-Portale gut sehen kannst. Hier mal ein Beispiel: In diesem Bild sieht man die Treppe, doch macht man ein paar Sidesteps, dann sieht es so aus: Wie du siehst, fehlt die gesamte Treppe, beim weiterlaufen poppen hier ganze Räume zu und dafür andere wieder auf. Jetzt zeige ich dir mal die Map "tutor37.map" aus der Vogelperspektive. Hier erkennst du zunächst nur die normalen Wände: Jetzt habe ich dir mal alle Hint-Portale markiert. Zusätzlich habe ich noch 2 horizontale Hint-Brushes eingebaut, die direkt über der Treppe liegen. Alles weitere kannst du dir ja dann in der Map selbst ansehen. Caulk-Textur: Die Caulk-Textur haben wir ja schon bei den Curves kennengelernt - aber auch bei der Performance erledigen sie wertvolle Dienste. Brush-Seiten, die im Spiel nicht sichtbar sind, können mit der Textur belegt werden, und werden so für die Engine unsichtbar. So bringt diese Textur nichtnur bei der Performance Vorteile, sondern auch beim Compilieren, da hier weniger Licht-Oberfläche berechnet werden muss. Ich gehe hier nicht weiter auf die Hint-Textur ein, da diese Textur so wichtig ist, dass sie ein eigenes Thema verdient. In der Map habe ich sie jedoch recht häufig eingesetzt - so habe ich jede Brush-Seite, die nicht in der Map zu sehen ist, mit dieser Textur belegt. |