Blog / Consejos

Probar sistemas Blueprint antes de publicarlos

Los sistemas Blueprint son fáciles de romper sin darse cuenta: una variable renombrada, un struct que cambió, una referencia a otra carpeta que funciona en tu equipo y falla en el del comprador. Cada versión de Rookspire pasa por el mismo control antes de publicarse.

Qué ejecuta el control

  1. Una reconstrucción completa de cada Blueprint a partir de su script, para que nada dependa de una edición hecha a mano.
  2. Compilación con cero errores y cero advertencias.
  3. Una comprobación de referencias que rechaza cualquier asset que apunte fuera de la carpeta del propio producto. Es lo que permite instalar cada sistema por separado.
  4. Cada mapa ejecutado durante 30 segundos sin ningún mensaje de ejecución en el log.
  5. Pruebas funcionales en Play In Editor, una por cada comportamiento que importa.

Una prueba que nunca ha fallado no demuestra nada

Cada prueba nueva se escribe para que falle primero: el comportamiento se rompe a propósito, la prueba debe ponerse en rojo y después la corrección la pone en verde. Una prueba que solo ha pasado puede que no esté probando nada.

Y una persona, al final

Hay cosas que solo una persona puede ver: si arrastrar se siente bien, si un aviso se lee bien sobre un cielo claro. Cada versión también se prueba a mano recorriendo su mapa de demostración.