Map vor Release prüfen: Checkliste für GMod-BSP-Dateien

Vor einem Release prüfst du deine Map in fester Reihenfolge: finaler Compile, Cubemaps, gepackter Content, Test auf einem sauberen Client, danach Name und Version. Typische Release-Fehler sind fehlende Texturen, kaputte Reflexionen und fehlerhafte Spawns, und alle drei fallen dir auf dem eigenen Rechner oft nicht auf. Die folgende Checkliste führt dich in einem Durchgang durch alle Punkte.

Die Checkliste im Überblick

Finaler Compile und Cubemaps

Ein Test-Compile mit schnellem VVIS oder schnellem VRAD reicht nicht für einen Release. Schnelles VVIS berechnet die Sichtbarkeit nur grob, was im Spiel Leistung kostet. Für den Release läuft VVIS normal und VRAD mit -final. Mit -both berechnet VRAD die Beleuchtung für LDR und HDR in einem Lauf. Häufig genutzte Zusätze für bessere Prop-Beleuchtung sind -StaticPropLighting und -StaticPropPolys. Lies danach das Log komplett durch. Wie das geht, steht in Compile-Log lesen.

Cubemaps baust du nach dem Compile im Spiel mit buildcubemaps. Bei einer Map, die für LDR und HDR kompiliert wurde, brauchst du zwei Durchgänge, einmal mit mat_hdr_level 0 und einmal mit mat_hdr_level 2, jeweils nach einem Neuladen der Map. Zwei Dinge sind wichtig:

• Jeder neue Compile verwirft die Cubemaps. Danach musst du sie neu bauen.
• Die Cubemaps hängen am Dateinamen der Map. Benennst du die BSP nachträglich um, gehen die Reflexionen auf Models und Props verloren.

Details zu typischen Problemen findest du in Cubemaps und Reflexionen beheben.

Custom Content packen und auf sauberem Client testen

Alles, was nicht zum Spiel gehört, muss mit der Map ausgeliefert werden. Am zuverlässigsten ist es, den Content direkt in die BSP zu packen. Die Anleitung dazu steht in Custom Content in die BSP packen. Gern vergessen werden:

• Texturen der Skybox und des 3D-Skybox-Bereichs
• Detail-Sprites und eigene Sounds
• das Soundscape-Skript scripts/soundscapes_<mapname>.txt
• das Partikel-Manifest maps/<mapname>_particles.txt
• die Navmesh-Datei maps/<mapname>.nav, die meist als eigene Datei neben der BSP ausgeliefert wird

Nicht in die BSP gehören die VMF, Compile-Logs und Backup-Dateien.

Danach folgt der wichtigste Test: Lade die Map auf einem Client, der deinen Content nicht besitzt. Das kann ein zweiter Rechner sein, ein Bekannter oder eine Installation, aus der du deine Addons vorübergehend entfernst. Achte auf pink-schwarze Flächen, Error-Models und fehlende Sounds, und lies die Konsole. Nutzt die Map Inhalte aus anderen Spielen, etwa Team Fortress 2, gehört das klar in die Beschreibung.

Aufräumen: Texturen, Entities, Spawns

Suche in Hammer gezielt nach Resten aus der Bauphase:

1. Entwickler-Texturen aus dem Ordner dev/ an sichtbaren Flächen ersetzen.
2. Test-Entities entfernen, zum Beispiel provisorische Lichter, Test-NPCs oder Debug-Logik.
3. Map > Check for Problems (Alt+P) ausführen und die Liste abarbeiten.
4. Spawnpunkte prüfen. Es sollte genug info_player_start für einen vollen Server geben, und jeder Spawn steht frei über dem Boden.
5. Für Spielmodi mit eigenen Spawn-Entities die passenden Entities setzen.

Wenn NPCs oder NextBots auf der Map funktionieren sollen, brauchst du AI-Nodes beziehungsweise ein Navmesh. Das Navmesh erzeugst du im Spiel mit nav_generate.

Performance, Dateigröße und Versionierung

Laufe die Stellen ab, an denen am meisten gleichzeitig zu sehen ist: große Plätze, lange Straßen, hohe Aussichtspunkte. cl_showfps 1 zeigt die Bildrate, +showbudget zeigt, womit die Engine ihre Zeit verbringt. Mit mat_wireframe 1 (benötigt sv_cheats 1) siehst du, was hinter Wänden noch gerendert wird. Bedenke, dass ein voller Server mit Spielern und Props deutlich mehr Last erzeugt als dein Einzeltest.

Die Dateigröße entscheidet darüber, wie lange Spieler beim ersten Join warten. Packe nur Content, den die Map wirklich nutzt.

Beim Namen gilt: Kleinbuchstaben, keine Leerzeichen, ein Präfix für den Spielmodus und eine Versionskennung, zum Beispiel rp_beispiel_v2. Jede veröffentlichte Änderung bekommt einen neuen Dateinamen. Sonst haben Spieler die alte Datei unter gleichem Namen und der Server lehnt sie mit einem Hinweis auf abweichende Map-Versionen ab. Hebe zu jeder veröffentlichten Version die VMF und die exakte BSP auf.

Scan und optionaler Schutz

Ein letzter technischer Check fängt Fehler ab, die man im Spiel nicht sieht. Der Map Scanner prüft bei einer BSP den Header, die Lump-Tabelle und die Offsets auf Konsistenz, sucht nach riskanten Entities wie point_servercommand oder lua_run, prüft, ob ein Spawnpoint vorhanden ist, und listet die im Pakfile eingebetteten Lua- und Asset-Dateien auf. Die Pakfile-Liste eignet sich gut, um das Packen zu kontrollieren. Der Scan ist kostenlos, die Datei darf bis zu 50 MB groß sein.

Wenn du die Map verkaufst, kannst du sie danach schützen. BSP Protection bietet die Stufen Audit, Cleanup, Fingerprint, Obfuscation und Server-Exclusive. Ein vollständiger Kopierschutz wird dabei nicht garantiert. Wichtig ist die Reihenfolge: Schutz kommt ganz am Ende, auf die fertig gebaute und getestete Datei. Nach jedem neuen Compile musst du ihn erneut anwenden.

Häufige Fragen

Muss ich nach jedem Compile die Cubemaps neu bauen?

Ja. Ein neuer Compile schreibt die BSP neu, dabei gehen die gebauten Cubemaps verloren. Baue sie deshalb erst, wenn die Geometrie und das Licht endgültig sind.

Kann ich die BSP nach dem Bauen der Cubemaps umbenennen?

Besser nicht. Die Cubemap-Daten sind an den Namen der Map gebunden, nach dem Umbenennen fehlen die Reflexionen auf Models und Props. Benenne stattdessen die VMF um, kompiliere neu und baue die Cubemaps erneut.

Reicht ein Fast-Compile für eine Veröffentlichung?

Nein. Schnelles VVIS führt zu schlechterer Performance, schnelles VRAD zu gröberem Licht. Für einen Release kompilierst du mit normalem VVIS und VRAD mit -final.

Woran merke ich, dass Content fehlt, wenn bei mir alles richtig aussieht?

Auf deinem Rechner liegt der Content im Spielordner, deshalb fällt ein Packfehler dort nicht auf. Sicher bist du nur nach einem Test auf einem Client ohne deine Dateien. Zusätzlich hilft die Pakfile-Liste eines Scans.