Revisar un BSP antes de publicar: checklist para mapas de GMod
Revisar un BSP antes de publicar: compilación final, cubemaps, contenido empaquetado, spawns, navmesh, rendimiento y escaneo. La checklist para mappers de GMod.
Antes de publicar, revisas tu mapa en un orden fijo: compilación final, cubemaps, contenido empaquetado, una prueba en un cliente limpio y, después, nombre y versión. Los errores típicos al publicar son texturas que faltan, reflejos rotos y spawns defectuosos, y los tres pasan a menudo desapercibidos en tu propio equipo. La checklist de abajo te lleva por todos los puntos de una sola pasada.
La checklist de un vistazo
| N.º | Comprobación | Hecho cuando |
|---|---|---|
| 1 | Compilación final | VBSP normal, VVIS normal, VRAD con -final y -both, log sin leak |
| 2 | Cubemaps | generados para LDR y HDR, los reflejos se ven bien |
| 3 | Contenido custom | todos tus materiales, modelos y sonidos propios están empaquetados en el BSP |
| 4 | Cliente limpio | una prueba sin tus addons no muestra texturas que falten ni modelos ERROR |
| 5 | Limpieza | sin texturas de desarrollo, sin entities de prueba |
| 6 | Puntos de spawn | suficientes spawns, ninguno atascado en el suelo o en una pared |
| 7 | Navmesh y nodes | presentes si se prevén NPCs o NextBots |
| 8 | Rendimiento | puntos críticos recorridos y medidos |
| 9 | Tamaño del archivo | sin contenido sin usar en el BSP |
| 10 | Nombre y versión | nombre de archivo definitivo con etiqueta de versión |
| 11 | Escaneo | BSP comprobado con el Map Scanner |
| 12 | Protección (opcional) | aplicada solo al archivo terminado |
Compilación final y cubemaps
Una compilación de prueba con VVIS rápido o VRAD rápido no basta para publicar. El VVIS rápido calcula la visibilidad solo de forma aproximada, lo que cuesta rendimiento en el juego. Para la publicación, VVIS se ejecuta en modo normal y VRAD con -final. Con -both, VRAD calcula la iluminación para LDR y HDR en una sola pasada. Para iluminar mejor los props se suelen añadir -StaticPropLighting y -StaticPropPolys. Después, lee el log entero. Cómo hacerlo se describe en cómo leer un compile log.
Los cubemaps los generas dentro del juego después de compilar, con buildcubemaps. Un mapa compilado para LDR y HDR necesita dos pasadas, una con mat_hdr_level 0 y otra con mat_hdr_level 2, cada una después de recargar el mapa. Importan dos cosas:
- Cada compilación nueva descarta los cubemaps. Después tienes que volver a generarlos.
- Los cubemaps dependen del nombre de archivo del mapa. Si renombras el BSP más tarde, los reflejos en modelos y props se pierden.
Los detalles sobre los problemas típicos están en arreglar los reflejos de los cubemaps.
Empaquetar el contenido custom y probar en un cliente limpio
Todo lo que no forma parte del juego tiene que ir con el mapa. La forma más fiable es empaquetar el contenido directamente en el BSP. La guía está en empaquetar contenido custom en un BSP. Lo que más se olvida:
- las texturas del skybox y de la zona del skybox 3D
- los detail sprites y los sonidos propios
- el script de soundscapes
scripts/soundscapes_<mapname>.txt - el manifiesto de partículas
maps/<mapname>_particles.txt - el archivo de navmesh
maps/<mapname>.nav, que normalmente se entrega como archivo aparte junto al BSP
El VMF, los compile logs y los archivos de copia de seguridad no deben ir en el BSP.
Luego viene la prueba más importante: carga el mapa en un cliente que no tenga tu contenido. Puede ser un segundo PC, un amigo o una instalación de la que quites temporalmente tus addons. Fíjate en si hay superficies rosas y negras, modelos ERROR y sonidos que faltan, y lee la consola. Si el mapa usa contenido de otros juegos, como Team Fortress 2, indícalo claramente en la descripción.
Limpieza: texturas, entities, spawns
En Hammer, busca expresamente restos de la fase de construcción:
- Sustituye las texturas de desarrollo de la carpeta
dev/en las superficies visibles. - Elimina las entities de prueba, por ejemplo luces temporales, NPCs de prueba o lógica de depuración.
- Ejecuta Map > Check for Problems (Alt+P) y repasa la lista.
- Revisa los puntos de spawn. Debería haber suficientes entities
info_player_startpara un servidor lleno, y cada spawn tiene que quedar despejado por encima del suelo. - En modos de juego con entities de spawn propias, coloca las entities correspondientes.
Si en el mapa deben funcionar NPCs o NextBots, necesitas AI nodes o un navmesh, respectivamente. El navmesh lo generas dentro del juego con nav_generate.
Rendimiento, tamaño del archivo y versiones
Recorre los lugares donde más cosas se ven a la vez: plazas grandes, calles largas, puntos elevados con buenas vistas. cl_showfps 1 muestra los FPS, +showbudget muestra en qué gasta el tiempo el motor. Con mat_wireframe 1 (requiere sv_cheats 1) ves lo que se sigue renderizando detrás de las paredes. Ten en cuenta que un servidor lleno, con jugadores y props, genera mucha más carga que tu prueba en solitario.
El tamaño del archivo decide cuánto esperan los jugadores en su primera conexión. Empaqueta solo el contenido que el mapa usa de verdad.
Para el nombre: minúsculas, sin espacios, un prefijo del modo de juego y una etiqueta de versión, por ejemplo rp_example_v2. Cada cambio publicado recibe un nombre de archivo nuevo. De lo contrario, los jugadores tienen el archivo antiguo con el mismo nombre y el servidor los rechaza con un aviso de que las versiones del mapa no coinciden. Conserva el VMF y el BSP exacto de cada versión publicada.
Escaneo y protección opcional
Una última comprobación técnica detecta errores que no se ven en el juego. En un BSP, el Map Scanner comprueba la coherencia del header, la tabla de lumps y los offsets, busca entities de riesgo como point_servercommand o lua_run, comprueba si existe un spawnpoint y enumera los archivos Lua y de assets incrustados en el pakfile. La lista del pakfile es una buena forma de verificar tu empaquetado. El escaneo es gratuito, y el archivo puede ocupar hasta 50 MB.
Si vendes el mapa, después puedes protegerlo. BSP Protection ofrece los niveles Audit, Cleanup, Fingerprint, Obfuscation y Server-Exclusive. No se garantiza una protección anticopia completa. El orden importa: la protección va al final del todo, sobre el archivo terminado y probado. Después de cada compilación nueva tienes que volver a aplicarla.
Preguntas frecuentes
¿Tengo que volver a generar los cubemaps después de cada compilación?
Sí. Una compilación nueva reescribe el BSP, y los cubemaps generados se pierden en el proceso. Genéralos solo cuando la geometría y la iluminación sean definitivas.
¿Puedo renombrar el BSP después de generar los cubemaps?
Mejor no. Los datos de los cubemaps están ligados al nombre del mapa, y tras renombrarlo faltan los reflejos en modelos y props. En su lugar, renombra el VMF, compila de nuevo y vuelve a generar los cubemaps.
¿Basta una compilación rápida para publicar?
No. El VVIS rápido da peor rendimiento, y el VRAD rápido, una iluminación más tosca. Para publicar, compila con VVIS normal y VRAD con -final.
¿Cómo noto que falta contenido si en mi PC todo se ve bien?
En tu equipo el contenido está en la carpeta del juego, así que un error de empaquetado no se nota ahí. Solo puedes estar seguro tras una prueba en un cliente sin tus archivos. La lista del pakfile de un escaneo también ayuda.