Cómo crear un custom map avanzado de BO3 Zombies

Crear un mapa avanzado es construir un sistema que puedas comprobar

Para crear un custom map avanzado de BO3 Zombies necesitas mantener coherentes el recorrido, los recursos artísticos, la colisión, la navegación, los scripts y el paquete que termina cargando el juego. El orden que seguiría es definir una experiencia, construir un blockout jugable, verificar sus sistemas básicos y añadir arte e iluminación por muestras. Después toca enlazar, instalar una versión identificable y probarla con escenarios concretos. Decorar primero suele encarecer cualquier cambio de escala, puerta o ruta.

Esta guía está pensada para quien ya ha abierto un mapa básico y quiere organizar una producción más exigente. BO3 Mod Tools y los ensayos citados pertenecen a Windows. Preparar modelos con Blender en otro sistema no demuestra que allí funcionen Radiant, el SDK o el juego. Tampoco se ofrece aquí un paquete de mapas, código privado o recursos extraídos. Los ejemplos proponen decisiones y pruebas que puedes adaptar a tu proyecto, sin depender de nuestros generadores.

Los casos de Crystal, Caramel y los demás mapas proceden de registros del proyecto de Windows transmitidos para esta guía. Se indica junto a cada resultado si fue offline, en Radiant o en BO3 Solo. No se han repetido esas ejecuciones al redactar el artículo y no se dispone aquí de sus capturas originales. Las figuras son diagramas conceptuales originales. El cooperativo, el balance y el rendimiento necesitan pruebas propias; no quedan certificados por los resultados parciales que aparecen a continuación.

1. Un entorno reproducible antes de producir contenido

La guía oficial de Workshop identifica Launcher, Radiant y Asset Property Editor como herramientas centrales y remite a docs_modtools para el detalle. Launcher organiza operaciones del proyecto; Radiant permite editar el nivel; APE trabaja con las definiciones de recursos. Conviene distinguir el juego instalado, las herramientas y las fuentes propias. Una prueba que funciona solo porque queda un recurso residual en el SDK todavía no describe una construcción reproducible.

Empieza por una ficha de entorno: versión de tus fuentes, herramientas utilizadas, exportadores, dependencias, configuración regional y ubicación relativa de cada entrada. Conserva un mapa mínimo que compile y cargue antes de incorporar sistemas especiales. Si ese control deja de funcionar, tienes un problema de entorno o de dependencias que debe investigarse por separado de la nueva habitación. No actualices varias herramientas a la vez mientras buscas una regresión.

Una organización ilustrativa puede separar source/maps, source/scripts, source/models, source/textures, config, manifests y releases. Es una propuesta de organización del proyecto, no la estructura obligatoria del SDK. Sus herramientas pueden requerir ubicaciones concretas para importar o enlazar; documenta esa correspondencia en lugar de repartir copias sin saber cuál está activa. Las carpetas de salida no deberían convertirse por accidente en la única copia de un original editable.

El archivo .map y sus prefabs describen fuentes del nivel; las definiciones GDT relacionan recursos con propiedades y archivos; el listado .zone declara recursos del paquete. Una zona de juego, que participa en progresión o activación de enemigos, tiene otra responsabilidad. Confundir ambas acepciones lleva a buscar una dependencia de empaquetado en una configuración de combate, o a creer que declarar un recurso hace accesible un área durante la partida.

Si generas geometría y scripts desde configuración, el generador debe emitirlos con la misma versión del diseño. Editar a mano su salida puede servir para investigar, pero esa corrección desaparecerá en la siguiente generación. Decide si el arreglo vuelve a la configuración, al generador o a una fuente mantenida manualmente. Guarda una muestra pequeña de salida esperada: ayuda a detectar diferencias de formato, nombres o escala antes de reconstruir el mapa completo.

2. Diseñar diversión y progresión antes de decorar

Un blockout útil permite responder cómo empieza la partida, qué decisión toma el jugador después y qué compra modifica su recorrido. Dibuja salas, conexiones, bucles de entrenamiento y puntos de servicio. Coloca primero puertas, electricidad, armas, caja y Pack-a-Punch. Después comprueba que cada servicio tiene un acceso razonable en la etapa donde se necesita. Una recompensa tardía no arregla un comienzo sin espacio para recuperarse de una mala compra.

Representa las dependencias como un grafo. Si abrir la sala de electricidad exige una puerta que solo se compra después de activar la electricidad, has creado un ciclo imposible. No necesitas una herramienta compleja: basta con anotar qué habilita cada puerta y desde qué espacio se puede alcanzar su interacción. Recorre el grafo con las puertas cerradas y repite al abrir cada una. Las rutas alternativas también deben conservar sentido cuando parte del mapa sigue bloqueada.

Para dos jugadores, evalúa el cruce, la retirada y el acceso simultáneo a servicios. Un pasillo que deja pasar a una persona puede transformarse en una trampa cuando la otra compra munición y detrás entra una horda. Desplaza máquinas y obstáculos a bolsillos laterales, conserva salidas legibles y evita obligar a ambos jugadores a ocupar el mismo punto de interacción. La densidad de decoración no debería medirse por cuánto espacio libre consigues llenar.

En los mapas de Vitys se eligió no exigir parkour de precisión. Esa es una preferencia del proyecto, no una obligación de BO3. También hay tipologías diferentes: Aurelian plantea descenso mediante rampas; Laurel Drop usa caída unidireccional sin rampa ni regreso, por decisión específica. El diseño de retorno, los servicios y los enemigos deben respetar esa diferencia. Copiar la lógica de una torre ascendente sobre cualquier descenso puede romper su progresión aunque las plataformas tengan el mismo aspecto.

Antes de añadir arte, escribe tres escenas de prueba: comienzo sin ventajas, compra bajo presión y recuperación después de perder una posición favorable. Observa si el recorrido ofrece decisiones o solo espera. Ajusta costes y distancias con partidas, manteniendo separados el presupuesto económico y la legibilidad espacial. Una puerta barata puede seguir siendo una mala compra si no abre una salida reconocible ni deja margen para descubrir qué contiene la siguiente sala.

3. Escala, rampas y cuatro representaciones del espacio

Separa malla artística, colisión simplificada, navegación y regiones de daño. La primera determina qué se ve; la segunda, dónde puede moverse o chocar una entidad; la tercera ayuda a planificar recorridos; la cuarta participa en qué recibe un impacto. Pueden estar relacionadas, pero sus límites no son intercambiables. Una escultura con una silueta muy precisa puede necesitar una colisión sencilla para que el movimiento no se enganche en cada pliegue.

Las referencias del SDK transmitidas desde Windows describen unidad nominal de una pulgada y estándares artísticos como jugador de 32 por 72, hallway de combate de 160 de ancho con gálibo de 96 y puerta doble de 110 por 96. Son referencias documentales del briefing: los PDF originales no están disponibles para una segunda lectura en esta edición. Comprueba Scale_Standards.pdf de tu instalación antes de adoptarlas. No son garantías de espacio para dos jugadores, una horda o un Mechz.

Mide vértices y transiciones reales, además de los bounds. En una rampa, el máximo Z de su caja envolvente no representa la altura del suelo en todos los puntos. El caso registrado calculaba el suelo de ese modo y provocaba retornos al vacío injustificados. La comprobación adecuada debe considerar el plano inclinado y la posición sobre él. Revisa también uniones coplanares, normales, bordes y pequeños escalones: un intervalo vertical correcto en los extremos no asegura continuidad entre ellos.

Un ensayo con una cápsula de altura 72 solo responde sobre esa cápsula y los puntos examinados. No demuestra todo el gálibo de un portal configurado en 252 ni el paso de un enemigo mayor. Conserva por separado dimensiones de configuración, superficie exportada y resultado en motor. Si una herramienta valida únicamente cajas envolventes, su informe debe decirlo; no lo presentes como inspección de toda la geometría sólida.

Generate Clip puede servir como punto de partida, pero la advertencia comunitaria de Zeroy señala que algunos modelos producen demasiadas caras y pueden hacer fallar la compilación. Revisa el resultado y simplifica con intención. En descensos comprueba además la cota nativa de eliminación: el registro histórico encontró un valor de −1000 que cortaba mapas con conexiones válidas. Es un diagnóstico de aquella revisión, no un valor que debas sustituir a ciegas en cualquier instalación.

4. Una dirección artística que ordene el kit modular

Decide antes de modelar qué hace reconocible al mapa: proporciones, contraste, ritmo de apoyos, materiales dominantes y jerarquía de los servicios. La dirección Stoa de nuestro proyecto propone neoclasicismo luminoso, oliva #809768, cenefas y relieves sobrios, con continuidad de suelo en plataformas y rampas. Esa elección permite evaluar si una pieza encaja. No convierte el neoclasicismo ni ese color en requisitos para un custom map.

Construye un kit con responsabilidades claras: tramo de muro, esquina, base, columna, remate, puerta, techo y transición de suelo. Fija cómo se encuentran las piezas y dónde queda su origen. Una moldura puede ocultar una junta visual, pero no debería tapar una discontinuidad del recorrido. Prueba una habitación pequeña y una rampa con el kit antes de multiplicarlo por todas las alturas. El coste de corregir un módulo aumenta cuando ya sostiene muchas variaciones.

La repetición necesita estructura y excepciones. Conserva una base coherente de materiales y densidad de textura; reserva cambios de color, luz o silueta para orientar. Colocar objetos distintos en cada metro no produce necesariamente variedad útil. Revisa desde la altura del jugador: un detalle elegante desde arriba puede confundirse con una compra o una entrada. El fondo también participa en la composición; un vacío negro puede borrar columnas y enemigos que sobre otro fondo se entenderían bien.

Produce bocetos baratos antes de comprometerte con esculturas o exportaciones costosas. Compara una opción limpia y otra más detallada con la misma cámara y recorrido. Pregunta qué mejora cada añadido: orientación, profundidad, contexto o función. Un HDRI de jardín aporta entorno de iluminación, pero no construye jardines transitables ni vegetación con escala correcta dentro del nivel. Mantén esa distinción al presentar previews y decidir qué trabajo falta.

5. Conseguir assets y estudiar referencias sin perder procedencia

Usa recursos cuya procedencia y condiciones puedas comprobar. Poly Haven publica sus assets bajo CC0, mientras que el uso del sitio y de su API tiene condiciones propias. Guarda recurso, autor, URL, licencia, fecha, tamaño y hash junto a tus dependencias. No necesitas publicar ese manifiesto completo en una imagen, pero sí conservarlo para reconstruir el proyecto y saber qué puedes compartir cuando llegue la entrega.

Gratuito no significa preparado para el motor. Un glTF con texturas reducidas a 1K puede seguir conteniendo una geometría enorme. Examina triángulos, materiales, imágenes adicionales y escala, y calcula qué variantes necesitas antes de importar en masa. Comprueba que la conversión no ha dejado rutas a texturas externas que solo existen en la carpeta del autor. Una preview descargada no sustituye los mapas de textura que requiere el material.

Radiant Hallway y Surreal Hallway, de vuflub_, y JhorpyReedy Tower, de crepp115, se estudiaron como referencias de composición y materiales en el proyecto. La atribución al mapper no implica que todos los recursos internos sean suyos ni que una descarga de Workshop permita redistribuirlos. Analizar una referencia, adquirir recursos con autorización y producir una obra propia son actividades diferentes. No publiques paquetes FF/XPAK, texturas extraídas ni scripts completos de terceros como material de apoyo de la guía.

Una textura recuperada tampoco entrega el mapa editable, la casa completa, un rig o animaciones funcionales. Para aprender de una referencia, describe proporciones, jerarquía de juntas, distribución de vegetación y contraste. Después busca o produce recursos con permiso para construir tu solución. En armas portadas conserva además la procedencia de cada port; que una publicación permita descargarlo no resuelve por sí solo todas las condiciones de otros recursos que quieras incorporar.

6. Preparar modelos en Blender para exportarlos

Importa el original en una escena de trabajo aislada y actualiza su evaluación antes de medir. Anota dimensiones mundiales, origen y transformaciones; distingue el tamaño del objeto de su escala aplicada. Conserva una copia intacta para comparar. El objetivo no es normalizar todos los objetos a una caja idéntica, sino conseguir que cada recurso tenga una escala y una colocación previsibles en el kit y en el motor.

El ensayo principal usó Blender 5.2.2 y conserva una alternativa histórica 4.5.14. No son versiones obligatorias de BO3 Mod Tools. Si automatizas, comprueba la API/RNA de tu instalación antes de copiar un enum. El caso registrado encontró MULTIPLE_SCATTERING donde NISHITA produjo TypeError; es un resultado de ese entorno, no una regla universal de Blender. Separa también la ejecución con interfaz, la línea de comandos y el dispositivo de render disponible.

La vegetación mostró por qué hace falta limitar altura y huella con escala uniforme. En el recurso fern_02, de aproximadamente 1,97 × 1,72 × 0,43 en el escenario del ensayo, llevar solo la altura a 1,3 lo hacía casi 6 de ancho. Limitar la huella a 1,4 corrigió el boceto. Probado offline: esas medidas pertenecen a ese recurso y esa escena. No las conviertas en un preset para todos los helechos ni confundas un boceto correcto con coste de visibilidad medido en BO3.

Revisa triangulación, normales por esquina, UV y materiales antes de exportar. El proyecto utilizó XModel binario v7 mediante PyCoD; comprueba compatibilidad entre exportador, formato y herramienta de destino en tu instalación. No deduzcas que un archivo válido para un conversor lo es para todos. Una comprobación útil reabre el archivo exportado y compara bounds, recuentos y nombres con la escena, además de mantener el hash del binario que realmente se importa.

7. LOD, normales y bake con una comprobación posterior

Decimar cambia la geometría sobre la que viven UV y normales. Después de cada reducción, busca triángulos degenerados, winding invertido, coordenadas inválidas y normales de longitud nula. Revisa la convención vertical de UV que aplica el exportador. Que un lector pueda abrir el archivo demuestra su estructura, pero no que la superficie responda bien a la luz ni que conserve la silueta a distancia.

Probado offline y en el enlace posterior, según el registro Windows: entre ocho modelos y 17 archivos LOD, dos LOD acumulaban 40 normales de esquina nulas. El primer link informó Vertex normal is 0 y sustituyó estáticos. La reparación se limitó a triángulos geométricamente válidos, calculando una normal de cara real y normalizándola; los degenerados deben descartarse. No se rellenó con un vector arbitrario. La relectura y el link posterior comprobaron la corrección, sin certificar que el LOD resultante fuese bonito en partida.

Para una escultura, compara silueta y rostro antes de aceptar una retopología. Una reducción anterior borraba facciones aunque el escaneo original fuese correcto. Conservar muchos detalles de textura no compensa una nariz o un perfil que han desaparecido en la malla. Examina el low poly sin normal map y después con el bake: así puedes distinguir qué depende de la geometría y qué solo cambia el sombreado de la superficie.

Prepara high y low, UV sin solapes no deseados, márgenes, seams y cage adecuados al caso. Haz una muestra de bake y revisa costuras y proyección antes de procesar el conjunto. Un normal tangent y un AO útil tienen que comprobarse sobre el export real. El manual oficial de baking no pudo abrirse íntegro en esta edición; estos pasos se presentan como procedimiento de revisión propuesto, no como transcripción de sus opciones actuales ni como comandos Python ya probados aquí.

8. Materiales, alfa y adaptación del PBR

Antes de convertir mapas de textura, identifica el contrato del shader de destino. El briefing remite a Materials.pdf e Images.pdf del SDK para Lit, Lit Detail, normales y gloss; esos documentos locales deben consultarse en tu instalación. No hay una conversión universal de PBR basada en invertir roughness. Una inversión de gris puede servir para una relación concreta, pero no resuelve canales empaquetados, rangos, convenciones o propiedades adicionales del material.

Conserva albedo sin iluminación pintada cuando ese sea el contrato elegido, y trata la normal como datos, no como una imagen de color. En Blender revisa Non-Color, la UV utilizada y la interpretación del normal map. Comprueba la convención GL/DX en el recorrido de conversión y en una muestra del motor: una junta que parece sobresalir cuando debería entrar es una señal para revisar canales y orientación, no para añadir más intensidad de luz.

La vegetación enseña otro fallo frecuente. Declarar MASK no fabrica transparencia si la imagen diffuse es un JPEG RGB. Necesitas una máscara válida del mismo recurso, con dimensiones, rango y procedencia comprobados, y un material nativo que la utilice correctamente. Mantén PNG RGBA para diagnosticar alfa. Una miniatura JPEG puede ocultar precisamente el canal que contiene la información importante, aunque su aspecto de color parezca normal.

En los chalks del proyecto, el RGB podía parecer cemento mientras el alfa contenía la pistola. El registro comparó originales y copias antes de modificar recursos: la imagen no estaba rota por tener ese RGB. De forma parecida, una normal comprimida en BC5 puede verse verde o amarilla cuando se muestran sus canales sin interpretarlos. Identifica primero qué datos contiene el archivo. Cambiar materiales para corregir una preview mal interpretada introduce una regresión donde antes solo había un diagnóstico incompleto.

9. Crystal: un A/B de juntas con alcance limitado

Probado offline en una copia aislada de Crystal 0.4.35-alpha: la normal original tenía R/G entre 126 y 129, B en 255 y ningún texel inclinado más de un grado. Las juntas ya estaban dibujadas en el albedo. El candidato añadió relieve únicamente a esas juntas, conservando albedo, alfa y geometría mediante un material privado. Hubo 330 sustituciones de token y 55 brushes reconstruidos; solo cuatro entraron en los renders de la muestra.

Se compararon tres pares de plataforma, rampa y unión con cámara y luz constantes. Cycles CPU usó dos hilos, 48 muestras, seed 7319, sin denoise, AgX con exposición 0 y roughness 0,68. Son parámetros del ensayo Blender, no una receta calibrada para las UV y normales nativas de BO3. La profundidad 0,22 y la tesela 128 también eran supuestos de esa escena y deben permanecer identificados como tales.

El resultado inspeccionado fue un borde de junta más legible de cerca y muy sutil a distancia. El candidato tenía 3,4801 % de texeles inclinados más de un grado. La diferencia RGB superior a 2/255 afectó al 2,797 %, 1,949 % y 2,237 % de los píxeles opacos de los tres pares. Esas cifras describen diferencias de imagen; no puntúan calidad estética, respuesta del jugador ni FPS. El registro conserva cero cambios de alfa, siete pruebas y 777 fuentes protegidas intactas.

No se compiló ni instaló esa propuesta y no se extendió a los otros cinco mapas. Tampoco hubo en el ensayo paredes, props o iluminación nativa de BO3. La decisión útil es conservar una muestra comparativa y detener la propagación hasta revisar el material dentro del motor. Un efecto visible en un primer plano puede desaparecer en el recorrido habitual; eso puede justificar una solución más sencilla en vez de multiplicar resolución y mantenimiento.

10. Caramel: separar pavimento, techo y muros

Probado en Radiant, no como paquete jugable: el candidato de Caramel Furnace 0.5.16-alpha investigó baldosas repetidas en techo y muros, ondas diagonales excesivas y paños vacíos. Se partió de una baseline exacta y se seleccionaron caras por geometría y orientación comprobadas. En esa fuente las normales apuntaban al interior del sólido; usar el signo como regla universal habría seleccionado otras superficies. Primero determina cómo representa tu fuente las caras y después decide su función artística.

El candidato cambió tokens de material, conservando UV y planos: 62 caras inferiores a enlucido, 248 cantos a piedra y cuatro grandes caras interiores perimetrales a enlucido. Añadió 48 modelos cosméticos de zócalo, sin nuevos brushes sólidos, clips o triggers. Eso separa una operación de acabado visual de una modificación del espacio jugable, pero no demuestra que el candidato esté libre de problemas de colisión en el motor.

El material partió de White Plaster02 de Poly Haven, atribuido a Rob Tuytel, con procedencia CC0 cotejada en el proyecto. La primera variante se rechazó por oscura y moteada. La segunda ajustó solo albedo: centro RGB 218/214/202, separación de macrovariación con gaussiano 24 envuelto, detalle por 0,35 y macro por 0,1. Son decisiones de esa derivación; no una transformación PBR general. Se mantuvieron shader, normales y gloss, y se usó un namespace nuevo para evitar depender de una caché anterior.

La comparación posterior conservó cuatro PNG originales de 1920×1080, dos cámaras y F7/Normal-based Fake Lighting con EV mostrado 10. Desaparecieron el patrón de baldosa del techo y las ondas grandes de muros; el zócalo se veía alineado sin hueco aparente. Persistían suelo repetitivo y paños vacíos. F7 permite estudiar textura y forma, pero no reproduce el bake ni la iluminación de partida. La captura inicial con Runtime Lighting no se aceptó como A/B fotométrico frente a F7.

La muestra pasó 10 pruebas y las 22 regresiones anteriores, con 18 archivos activos cotejados intactos y tres entradas candidato coincidentes con SDK. No hubo compile/link, paquete, instalación o nueva partida. Los avisos de preview existentes no quedaron resueltos. Antes de promover faltaba declarar la dependencia compartida stoa-relief; un modelo residual en SDK no hace reproducible el build. La comparación de caliza/cenefa en plataforma y rampa seguía pendiente, sin incorporarse por ello a los seis mapas.

11. Iluminar por capas y diagnosticar el coste

Separa cielo, sol, iluminación indirecta, exposición, probes y luces locales. Una escena lavada puede tener albedo demasiado claro, exposición elevada, poca variación de materiales o una combinación de varios factores. Cambia una variable, captura y compara antes de compensar con otra. Conserva un material y una cámara de control. El objetivo no es conseguir que cualquier superficie brille, sino mantener lectura del recorrido y diferencias útiles entre materiales.

El SDK leído en Windows describe selección de ocho reflection probes cercanas y costes asociados a la distribución del grid. Esa referencia documental no se ha reabierto aquí y no justifica llenar el mapa de probes. Un centro global dentro de geometría o demasiado alto puede dar un rebote incorrecto. Las guías comunitarias ayudan a localizar controles, pero una recomendación informal de añadir más no sustituye comprobar colocación, bake y comportamiento del área problemática.

Probado en una exportación histórica de Crystal: el conjunto pasó de 464 luces a 82 y de 386 registros de shadow overflow a cero en una exportación posterior. Quedaban 47 registros del editor, 45 de previews nativos. El resultado respalda una limpieza de ese diagnóstico de export, no una ganancia de FPS ni una iluminación final aprobada. Exportar LED tampoco borra automáticamente todos los mensajes anteriores de Radiant.log.

Duplicar cada dimensión de una shadowmap cuadruplica su área de texeles; eso ayuda a razonar sobre presupuesto, pero no determina por sí solo el tiempo de frame completo. Revisa qué luces necesitan sombras, su alcance, tamaño en pantalla y solapamiento. Los radios 200 o 300 y los spots muy abiertos deben evaluarse en la escena concreta y contra la documentación instalada. Mantén separados los avisos de un recurso propio y los de previews nativos, sin llamar limpio a un log que conserva problemas relevantes.

12. Un cielo negro puede tener más de una causa

Probado en BO3 Solo en el registro de Elysian: la revisión 0.1.0 mostraba cielo negro y la 0.1.1 mostró cielo azul con nubes después de crear cielo/material privados, serializar floats correctamente y recalibrar parámetros. Se usaron skyStops 12, sunStops 11,5 y exposición 12. Como cambiaron varias variables, no hay una causa única aislada ni una receta universal que pueda copiarse atribuyendo todo al recurso stock 135.

El resultado seguía lavado y poco denso. Ese negativo evita cerrar el caso demasiado pronto: recuperar cielo visible resuelve una condición, no la dirección artística completa. Conserva el stock sin modificar y verifica cuál es el override privado cargado. Si tu diagnóstico necesita reemplazar archivos globales para funcionar, será difícil saber qué rompiste en otros mapas o qué ocurrirá en una instalación limpia.

Ante un cielo negro, formula pruebas pequeñas: comprobar recurso referenciado, definición importada, formato numérico, operación de luz realizada y modo de visualización. Registra qué cambiaste y qué se mantuvo constante. Un link con salida correcta solo informa de su etapa; no garantiza que la combinación de cielo, exposición y material produzca el resultado esperado en partida. Tampoco basta con ver la preview de un asset separado del mapa donde se utiliza.

13. GSC, CSC y Lua: responsabilidad y ciclo de vida

Organiza el comportamiento por responsabilidades. En este contexto, GSC participa en lógica de servidor, CSC en comportamiento de cliente y Lua/LUI en interfaz. La relación entre ellos exige un contrato: quién inicia, quién publica un estado, qué cliente lo observa y cuándo se destruye una suscripción. No se incluyen aquí firmas copiables del SDK que no se hayan comprobado en sus fuentes; los nombres de casos sirven para localizar el problema, no como biblioteca pública lista para pegar.

Un clientfield necesita productor y consumidor compatibles. Un clientuimodel por jugador evita que un estado temporal de una persona se confunda con el de otra. Cuando abras un widget, lee el valor inicial y después suscríbete a cambios; esperar solo una notificación futura puede dejar invisible un estado que ya estaba activo. Define también qué ocurre al refrescar, caducar, cerrar el menú, morir o reiniciar, y conserva la propiedad de los callbacks para poder cancelarlos.

Probado en BO3 Solo, Crystal 0.4.35-alpha-hudqa QA2: el icono de munición infinita se vio durante 23 segundos junto a Insta-Kill y dobles puntos y desapareció al caducar. El FF contenía imagen, rawfile y campos, pero antes no aparecía el icono. El arreglo ensayado cargó ui.vitys.hudx desde CSC antes de zm_usermap::main y vinculó T7Hud_zm_factory al constructor custom después de definirlo. Las dos modificaciones se probaron juntas; no se aisló cuál era suficiente.

Nueve tests de fuente acompañaban ese caso, sin probar exactamente el refresco de 30 segundos ni el cooperativo. La lección es seguir la inicialización hasta el constructor activo, no limitarse a verificar que Lua está empaquetado. Si sustituyes un hook nativo, comprueba cómo conservar el comportamiento anterior. Un registro aparentemente completo puede seguir fallando porque el consumidor se creó demasiado tarde, usa otro jugador o mantiene una suscripción de un menú ya cerrado.

14. Spawn y navegación con una política de progreso

Define qué significa progreso antes de seleccionar un spawn. En las torres propias de subida se usó la última etapa abierta: enemigos normales una etapa detrás, con límite inferior cero, y Panzer dos etapas detrás. Es una política del proyecto, no del motor. En descenso y hallway hacen falta políticas distintas; el índice de progreso no debe deducirse del signo de Z ni de qué jugador está más alto o más bajo después de caer.

Coloca spawns en suelo plano con salida libre y distancia a máquinas y paredes. Revisa cómo cambian las listas válidas al abrir una puerta. El sampler propio ensayó márgenes 80, 96 y 112; no son medidas certificadas de otros autores. Distingue entidades de aparición directa, risers y los eventos que realmente emite cada actor. Esperar una señal que no va a llegar puede detener el sistema aunque el navmesh y la ubicación parezcan correctos.

Dos initial_spawn distintos no significan que cualquier campo numérico seleccione el mando correspondiente. El registro encontró que script_int1/2 se interpretaba por filtros nativos como bandos, no como índices de jugador local. Comprueba el contrato en la fuente y después observa dónde aparece cada cliente. También revisa lava y regiones de daño: matar constantemente a los enemigos antes de que lleguen puede vaciar la presión y parecer un fallo de población.

Probado con una cohorte nativa histórica de 60 zombies en Crystal: se alcanzaron cotas 1, 4, 5, 8, 15 y 27 sin muertes ni recuperaciones del watchdog. Eso no acredita ocupación XY simultánea, todas las conexiones o los seis mapas. Un watchdog debería actuar solo ante inmovilidad real, lejos de jugadores y hacia una ubicación legal de la misma etapa. Los teleports rutinarios ocultan rutas defectuosas y pueden convertir una prueba aparentemente fluida en una mala experiencia de combate.

15. Compras, caja, armas y Pack-a-Punch

Conserva la lectura nativa de cada servicio y separa su volumen de interacción del plano visible. Los prefabs medidos del proyecto situaban RK5 en 14×12 y Kuda en 30×16: igualarlos a un cartel enorme elimina diferencias del recurso original. Los ensayos de volumen mínimo 64/64/64 pertenecen al proyecto, no a una norma universal. Revisa aproximación lateral, distancia, visibilidad del prompt y paso de otro jugador durante la compra.

Probado en BO3 Solo en Crystal: una pulsación real de +activate compró RK5 por 500, con puntos de 1000000 a 999500 y munición 15/120. Antes, +usereload solo había recargado. Se cambiaron tecla y volumen conjuntamente, por lo que no existe una causa única aislada. Notificar el trigger mediante script habría comprobado otra ruta; no demuestra que el jugador pueda activar físicamente la compra con su control habitual.

Una caja decorativa no inicializa la Mystery Box nativa. El caso necesitaba su script_struct de uso y zbarrier correspondientes, con inicio accesible y destinos alternativos habilitados por progresión. Para varios Pack-a-Punch, un lookup GetEnt con targetname compartido abortaba; se conservó la referencia directa self.zbarrier y se reservó fallback justificable para legado. Elegir arbitrariamente el primer elemento de una lista no resuelve una identidad ambigua.

El port MW2 Desert Eagle con procedencia TheSkyeLord requería registro antes del init nativo; el PaP dual Ares & Athena quedó probado en Crystal, no en cualquier revisión o mapa. Renombrar animaciones también exige mantener coherentes sus hojas .atr, GDT y referencias #using_animtree. Revisa SkinOverride, bindings, UV y LOD superiores. No basta con cambiar el nombre visible del arma, y esta guía no redistribuye los assets del port ni presume una licencia general sobre ellos.

16. Enemigos especiales, impactos y almas

El Mechz necesita actor, rig, animaciones y representación de daño coherentes. Mide por separado silueta artística, volumen que recibe balas y regiones de impacto. Un AABB ajustado a un modelo no demuestra que la cabeza esté donde la ve el jugador. Antes de cambiar daño, comprueba el resultado de rayos controlados y el recurso realmente cargado. Un enemigo difícil por un volumen incorrecto no aporta el mismo riesgo que uno diseñado para exigir precisión.

Probado con rayos nativos en Crystal: el registro de Panzer conserva HP 5000/4890/4890/0 para estado inicial y las situaciones registradas de cabeza normal, cuerpo con Insta-Kill y cabeza con Insta-Kill. Respalda la excepción propia de Insta-Kill en cabeza de ese ensayo. No permite anunciar Insta-Kill universal en cuerpo, equilibrio de todo el combate ni compatibilidad cooperativa. Conserva estado previo y posterior para que otro diagnóstico pueda distinguir un impacto de una muerte causada por otro sistema.

Las almas deben poder recogerse sin bloquear una compra o un carril. Separa recogida, habilitación de puerta y pago final. En Laurel, completar almas habilita comprar; no abre automáticamente la puerta. Una escultura pequeña con crecimiento acotado ayuda a conservar referencias espaciales. El máximo local de cinco trails era una precaución de diseño, no un límite del motor ni un benchmark. Del mismo modo, un alias de perk correcto no acredita su efecto, icono, animación y convivencia con otras bebidas.

17. Revisar Radiant sin confundirlo con una partida

Planifica cámaras de ida y vuelta a altura de jugador, vistas de compras y puertas y alguna vista global para geometría. Guarda X/Y/Z, pitch, yaw, versión, modo, exposición y calidad de cálculo. El QuickStart del SDK leído en Windows identifica Fullbright F6, RealLighting F8 y GameView F9, además de controles de exposición y calidad L/M/H. Verifica los bindings de tu instalación en vez de cambiarlos para coincidir con una guía. La revisión Caramel también utilizó F7 para forma y textura.

Recalcular luz y exportar LED son operaciones distintas. Una etiqueta Runtime Lighting en el editor no significa que se haya ejecutado BO3. Anota estados como CACHED o Sun not built cuando condicionen la vista. Si cambias geometría o materiales, decide qué evidencia invalida ese cambio antes de comparar capturas. Una vista L puede servir para localizar un problema de composición; no debe presentarse como iluminación H final.

El proyecto registró un error de captura especialmente engañoso: una variable vieja devolvía bytes anteriores aunque la pantalla ya hubiese cambiado. Comprueba hashes, dimensiones y fecha de los archivos recién guardados; rechaza duplicados que deberían mostrar cámaras diferentes. No basta con que existan varios nombres de archivo. Mantén los originales y genera recortes aparte, sin retoque de color cuando el propósito sea comparar materiales o exposición.

Probado en Radiant, con cobertura parcial: Elysian tuvo una revisión inicial de 14 capturas distintas, once iluminadas, dos globales y una diagnóstica, sobre cinco sectores. La ampliación 0.2.0 conservó 16 originales de ocho sectores, con nueve tests de grafo y ocho de galería, sin partida. Detectó bloques, materiales lavados y decoración invadiendo un portal. Ninguno de esos recuentos implica aprobación artística. El método útil es relacionar cada hallazgo con una vista y declarar los sectores aún no revisados.

18. Compilar y enlazar son etapas con contratos diferentes

Registra compilación de geometría y navegación, cálculo de iluminación, exportación LED y enlace por separado. Para cada operación conserva entrada, versión, nativeExitCode, log fresco y archivos esperados. Una línea de éxito o un exit 0 no demuestra que la salida requerida exista ni que se haya sustituido el paquete instalado. Evita builds simultáneos cuando las herramientas comparten bases de assets, listas o cachés, porque mezclar resultados vuelve difícil atribuir un fallo.

El entorno Windows español mostró una interpretación numérica 1.0→10 y un error RowAmbient Invalid Range. El procedimiento registrado utilizó InvariantCulture, representación numérica estable y relectura de SQLite y salidas; .9g fue una solución local de serialización. No se propone cambiar políticas del sistema ni DLL para arreglar el mapa. Valida algunos valores conocidos tras importar: ver un decimal correcto en la configuración no acredita que la herramienta lo haya leído igual.

Los aliases privados se mantuvieron bajo share/raw/sound/aliases, sin pisar user_aliases global. Un conversor de audio con exit 0 pero sin bancos o .alias.sz esperados no completa su contrato. Las entradas nuevas pueden invalidar caché y requerir operaciones all/english según el proyecto. Comprueba qué acción corresponde a tu instalación y documenta sus resultados, en vez de convertir esos nombres en una secuencia universal de comandos sin contexto.

#using participa en compilar dependencias, pero no asegura empaquetarlas. Recorre el grafo de GSC/CSC propios desde las entradas y comprueba sus scriptparsetree explícitos en .zone, además del FF final. El caso registrado encontró pressure.gsc ausente y un link ordinario que omitió tres overrides. Se descartó el paquete y se repitió un enlace aislado restaurando listas compartidas. Un archivo encontrado en una carpeta de trabajo no demuestra que su bytecode esté dentro del paquete utilizado por el juego.

19. Inspeccionar el paquete sin crear nuevas dependencias ocultas

Valida recursos por identidad, nombres y hashes, no solo por tamaño total del archivo. Si una herramienta lee FF, debe manejar sus estructuras y bloques; el proyecto encontró claves Lua que cruzaban límites de bloque. Un buscador de cadenas sencillo puede declarar una ausencia falsa. Distingue un identificador encontrado de una lectura válida de su recurso completo, y conserva qué versión del analizador generó el informe.

En paquetes XPAK mayores de 2 GiB, utiliza lectura, copia y hash en streaming. Cargar todo el archivo de una vez puede fallar por memoria o límites del entorno aunque el paquete sea válido. El hash comprueba identidad de bytes; no demuestra que los recursos sean correctos ni que el runtime los acepte. Para construir una entrega necesitas ambas cosas: integridad del transporte y una comprobación de funcionamiento con ese paquete identificado.

Clasifica diagnósticos: un warning de bulletmesh nativo, un preview ausente, falta de SN-DBS y un error de material propio requieren decisiones diferentes. No borres mensajes para llamar limpio al resultado. Tampoco dejes println de depuración sin guardas adecuadas: el registro incluye un bloqueo de carga aunque el dvar estuviera apagado. Antes de promover una versión, revisa qué se compila e incluye realmente, no solo qué crees que se ejecutará durante la partida.

20. Una matriz de pruebas nativas que no mezcle resultados

Usa una fila por mapa, versión y escenario. Como mínimo, separa carga, recorrido, puertas, compras, armas/PaP, efectos, almas, navegación, jefe, caída, HUD, audio, muerte, reinicio y dos mandos. Añade expectativa, resultado y evidencia asociada. Un test genérico que termina en passed no explica si se observó el prompt, se descontaron puntos, apareció el arma o se mantuvo el recorrido al cerrar otra puerta.

Las cámaras protegidas, el jugador invulnerable y los actores colocados por QA son herramientas útiles para aislar un defecto. No certifican dificultad ni presión normal. Retira imports, entradas .zone y módulos QA, restaura controles byte a byte y vuelve a comprobar la versión normal. Si tu evidencia se tomó con una protección especial, ese estado debe acompañar al resultado. Una cohorte de actores o un raycast no se convierte por acumulación en una partida completa.

El registro conserva un intervalo de 13,389 segundos entre captura y Escape en un ensayo. Que un jugador inmóvil muriese durante ese tiempo no demostraba muerte instantánea en spawn. Un intento de pausa tampoco acredita que el juego estuviese pausado. Anota tiempos y observa el estado real antes de diagnosticar. Guarda además el MIME correcto: cambiar una extensión JPEG a .png no convierte el contenido y puede confundir herramientas o comparaciones posteriores.

Para cooperativo local hacen falta dos mandos y pantalla dividida comprobados específicamente. Revisa aparición de ambos, uso simultáneo de máquinas, estado por jugador, reanimación, muerte, reinicio y menús. Para rendimiento mide frame-time, FPS, estabilidad, carga y memoria con hardware y escena definidos, incluyendo hordas y FX. Esta guía no aporta esas métricas del candidato Caramel ni una certificación cooperativa de los casos anteriores; reducir luces o sumar suites offline no permite inventarlas.

21. HUD, menús y miniaturas fieles al mapa

Una interfaz útil mantiene jerarquía visual, foco y respuesta de mandos sin ocultar información necesaria para decidir. Revisa sus fuentes de datos, listeners y cierres antes de modernizar botones. Un menú debe poder abrirse, cambiar selección, salir y convivir con el estado de ambos jugadores. El candidato registrado acumuló seis compilaciones HKSC y cinco pruebas offline; no incluía reinicio real ni cooperativo observado. La compilación de Lua es una etapa, no la prueba de esa interacción.

Las previews promocionales del proyecto tienen una preferencia específica: mapa reconocible con un zombi neoclásico saludando a cámara y humor contenido. Una composición puede combinar una captura real identificada y un personaje renderizado, pero no presentarse como screenshot puro ni como skin instalada durante gameplay. Los bocetos basados en Crystal 0.4.33 no representan automáticamente 0.4.35 ni los otros mapas. Necesitas imágenes de la revisión que estés anunciando.

Para una guía técnica, usa una captura autorizada cuando quieras demostrar lo que muestra Radiant o BO3. Un diagrama conceptual sirve mejor para explicar capas y dependencias y no requiere fingir una interfaz. Si no tienes el original empírico, conserva el resultado como evidencia descrita y declara ese límite. Una imagen atractiva aporta contexto visual, pero no puede suplir un log, el hash de un paquete o el escenario de una prueba.

22. Entregar una versión reversible

Prepara staging fuera de la instalación activa y registra su manifiesto antes de copiar. Comprueba que el juego está cerrado antes y durante la operación. Conserva el paquete instalado y una reserva identificable según el espacio disponible, además de las fuentes necesarias para reconstruirlos. No limpies contenido ajeno ni borres una revisión anterior para hacer sitio sin una decisión de conservación explícita. Un procedimiento de entrega debería poder detenerse sin dejar una mezcla de versiones.

Compara hashes de staging e instalado y registra mapa, versión y fecha. Arranca después la instalación que acabas de identificar, no otra carpeta con el mismo nombre. Si cambias una fuente, invalida las evidencias afectadas y vuelve a ejecutar las etapas correspondientes. Los hashes de baseline no se actualizan para hacer desaparecer diferencias inesperadas. En Caramel, un primer cierre detectó hashes de configuración antiguos y los reconcilió con una baseline posterior ya existente, sin rebaselinar para ocultar cambios.

Antes de llamar terminada una entrega, revisa continuidad artística, escala, UV/alfa, iluminación, colisión, navegación, servicios, HUD/audio y pruebas normales de muerte y reinicio. Añade cooperativo y rendimiento medidos cuando formen parte de tu objetivo. La comparación con el acabado oficial de BO3 es una aspiración del proyecto, no un logro demostrado por compilar, producir un render o alcanzar una cifra de versiones. Prioriza lo que el jugador usa y percibe sobre el recuento de props o perks.

23. Convertir incidencias en pruebas reutilizables

Escribe un postmortem breve con síntoma, hipótesis, prueba, causa respaldada, cambio, regresión y límite. Si cambian dos variables, conserva esa información. Cuando un resultado solo descarta una hipótesis, no lo conviertas en causa confirmada. El cielo que vuelve a verse tras varias modificaciones, la compra que funciona después de cambiar tecla y volumen y el icono que aparece tras dos arreglos de inicialización son ejemplos donde importa evitar una atribución única.

Elige el experimento más barato que pueda separar las hipótesis. Para hojas opacas, inspecciona primero alfa y material; para una normal nula, valida triángulos antes de rehacer la iluminación; para HUD invisible, sigue su ciclo de creación antes de redibujar iconos. Si el módulo no está empaquetado, no busques todavía una condición de gameplay dentro de él. Ese orden reduce trabajo sin prometer que todas las incidencias tengan una sola causa.

Reutiliza kits, generadores y validadores cuando mantienen invariantes que ya has comprobado. Renderiza muestras antes de propagar un material, recorre cámaras antes de declarar revisado un mapa y aísla paquetes antes de instalar. Automatiza la recogida de evidencia, no una falsa aprobación artística. Un informe puede comprobar dimensiones y detectar un archivo obsoleto; la lectura espacial, el ritmo del combate y el acabado requieren mirar y jugar la revisión concreta.

Glosario para leer los resultados

Blockout es la versión espacial básica con la que pruebas escala y recorrido antes del arte final. Prefab es una composición reutilizable. GDT reúne definiciones de assets; .zone enumera recursos para el paquete y no debe confundirse con una zona de juego. Link es el enlace de recursos hacia una salida, mientras que instalar consiste en trasladar una versión identificada al lugar donde la cargará el juego.

Clip es una representación de colisión; navmesh es información de navegación y no una grabación de persecución exitosa. Bulletmesh y regiones de impacto afectan al daño y requieren revisión separada de la silueta. LOD es una representación con detalle diferente para determinadas distancias o condiciones. Bake es un cálculo almacenado para otro uso, y LED designa una operación de exportación del flujo de iluminación del SDK: no equivale a ejecutar una partida.

Albedo describe color de superficie según el contrato del material; alfa transporta opacidad o una máscara cuando corresponde; normal map altera la orientación usada en sombreado sin añadir necesariamente volumen de colisión. Ground truth, en un informe de QA, debería ser la observación de referencia que se conserva, no un valor deseado. Baseline es una referencia identificada que permite comparar; actualizarla exige una justificación, no únicamente que el resultado anterior moleste.

Preguntas frecuentes y siguiente paso

¿Puedo revisar el mapa sin abrir BO3? Puedes comprobar geometría, composición y determinados estados de iluminación en Radiant, además de validar fuentes y exportaciones offline. No puedes deducir de ahí compras reales, daño, presión, cooperativo o rendimiento de partida. Empieza por un barrido de sectores y reserva las pruebas del juego para las preguntas que solo el runtime puede responder.

¿Puedo pasar directamente una escena de Blender a BO3? Necesitas adaptar escala, recursos, materiales, colisión y formato de exportación al recorrido que admita tu instalación. Un render de Blender no incorpora automáticamente los contratos de los assets de BO3. Prueba primero un módulo pequeño con sus texturas y un LOD, y conserva la comparación del original, la exportación y el resultado en motor.

¿Por qué atravieso o me atasco en un objeto que se ve bien? La geometría artística no demuestra la colisión. Inspecciona clips y sus transiciones, después contrasta el movimiento real. Si quien se atasca es un enemigo, añade navegación, ubicación de spawn y estado de puertas a la investigación. Una recuperación automática no debe reemplazar el arreglo del recorrido.

¿Por qué hay luz negra o un cielo negro aunque el link termine? Revisa qué recurso está cargado, importación, formato numérico, bake/export y exposición. Comprueba el modo de editor o la partida concreta donde ocurre. Mantén el stock intacto y evita copiar juntos todos los parámetros de un ensayo: perderías la capacidad de saber qué resolvió el defecto.

¿Por qué un perk o un HUD empaquetado no funciona? Confirma entrada, inicialización, constructor activo, productor del estado y consumidor por jugador. Después revisa carga inicial, suscripción, refresco, caducidad y cierre. Un alias o un rawfile presente solo prueba una parte del recorrido. Comprueba además el efecto y la interacción en la versión normal, no únicamente el nombre o la imagen.

¿Puedo reutilizar un recurso porque está en Workshop? La posibilidad de descargarlo no demuestra permiso para redistribuir sus activos. Identifica procedencia y condiciones de cada recurso que quieras incorporar. Conserva el análisis de composición separado de la adquisición y no publiques extracciones como material auxiliar. Una referencia bien atribuida puede enseñarte mucho sin convertirse en una dependencia de producción.

¿Cuándo puedo decir que el mapa está listo para dos mandos? Cuando hayas probado esa revisión con ambos jugadores y los escenarios que prometes soportar. Registra compras, HUD, muertes, reanimación y reinicio, además del cruce y presión en espacios estrechos. Un arranque Solo y una matriz offline no completan esa prueba. El siguiente paso razonable es una vertical slice pequeña que cierre todo el recorrido de producción y QA antes de extenderlo al mapa entero.

Fuentes