Del proyecto del editor a una compilación para PS1
Para exportar un juego desde Polygon Engine, primero necesitaba convertir el proyecto del editor en datos que pudiera utilizar la consola. Las escenas, las imágenes y los sonidos se guardan en formatos cómodos para trabajar, pero PS1 necesita versiones adaptadas a su memoria y a sus sistemas de renderizado y audio.
Esa conversión se volvió una parte importante del desarrollo. Cada vez que agregaba un tipo de recurso o un componente, también tenía que considerar cómo guardarlo, comprobar sus referencias y cargarlo en el juego. Generar la imagen de disco es el último paso de ese proceso.
Convertir los recursos de origen para la consola
Una textura comienza como una imagen cómoda de editar. El juego necesita una representación que la GPU pueda utilizar, con dimensiones, modo de color y datos de paleta compatibles con sus restricciones. Un sonido comienza como una grabación de origen; un efecto corto residente necesita una representación distinta a la de música transmitida desde el disco.
Las mallas y las escenas tienen la misma separación. Los datos de selección y los ajustes editables son útiles en la computadora. Los vértices compactos, los datos de componentes y las dependencias resueltas son útiles en la consola. Llevar cada comodidad de edición al entorno de ejecución gastaría memoria en información que el jugador nunca utiliza.
Preparar los recursos en la computadora permite resolver una parte del trabajo antes de ejecutar el juego. Si un cálculo depende de contenido que no cambiará durante la partida, muchas veces se puede guardar su resultado en la compilación. Así se prepara parte de la geometría y de los datos de navegación. Los objetos móviles y los cambios de estado, por supuesto, siguen necesitando actualizarse durante la ejecución.
Mantener las referencias entre recursos
Al organizar los recursos también necesitaba conservar sus referencias. Por ejemplo, si un material utiliza una textura y después cambio el nombre de esa imagen, el material debería seguir apuntando al mismo recurso. Depender únicamente de una ruta vuelve más frágiles esas relaciones cuando se reorganizan las carpetas.
Polygon Engine usa referencias de recursos basadas en GUID para separar la identidad de la presentación. El nombre ayuda a una persona a encontrar el recurso; el identificador ayuda al proyecto a seguir apuntando a él. La compilación resuelve después esas referencias en los datos preparados para la consola.
Además del identificador, hay que mantener actualizada la base de recursos y detectar las dependencias ausentes. También es necesario comprobar que el archivo convertido corresponda al origen y a sus ajustes de importación. Si cambio el modo de color de una textura y reutilizo una copia anterior, la referencia puede ser correcta mientras el contenido ya está desactualizado.
Por eso la compilación también revisa las importaciones desactualizadas. La existencia del archivo no basta: hace falta comprobar que representa los ajustes actuales del proyecto antes de incluirlo en el juego.
Preparar los datos durante la compilación
Con las referencias resueltas, el siguiente paso es organizar los datos para cargarlos en PS1. Las escenas se pueden escribir en registros binarios con límites definidos y sus dependencias se pueden agrupar. Esto aprovecha la información que ya tiene el editor y reduce el trabajo necesario al iniciar una escena.
En el proceso actual, las escenas se escriben como datos .BSN, y los paquetes .PGB de cada escena organizan sus dependencias para una carga secuencial. Estas decisiones de implementación tienen un propósito práctico: reducir la interpretación y evitar accesos innecesarios al disco, archivo por archivo, al entrar a una escena.
Estos formatos son más adecuados para la ejecución, aunque resultan menos cómodos de inspeccionar manualmente que los archivos del proyecto. Por eso necesito reportes que permitan relacionar los datos generados con su origen. Si un objeto no aparece, debo poder revisar qué escena o recurso produjo esos datos.
La preparación también debe considerar la memoria temporal de la carga. Aunque la escena final quepa, leer sus archivos y construir sus objetos puede requerir espacio adicional. Para estimar el máximo consumo hay que tener en cuenta los datos anteriores, los nuevos y los búferes que puedan coincidir durante la transición.
Reportar errores antes del empaquetado
Al desarrollar este proceso, me interesaba que los errores indicaran qué revisar. Un mensaje genérico de compilación fallida sirve de poco si el problema es un script ausente, una escena inicial inválida o una herramienta externa mal configurada. El diagnóstico necesita identificar el recurso o el ajuste correspondiente para poder corregirlo desde el proyecto.
El orden también importa. Encontrar esos problemas antes de empaquetar cuesta mucho menos que descubrirlos mediante una pantalla vacía. Al mismo tiempo, un validador exitoso no puede demostrar todos los comportamientos del juego. Puede rechazar entradas que sabe inválidas; no garantiza que un acertijo tenga solución ni que todos los ángulos de cámara se ejecuten con fluidez.
Por eso utilizo la validación para detectar problemas conocidos del contenido y reservo las pruebas del juego para comprobar su comportamiento. Ambas son necesarias: una compilación correcta todavía puede contener una interacción mal configurada o una zona con bajo rendimiento.
Integrar el entorno de ejecución y las herramientas de disco
Para completar el proceso, Polygon Engine se apoya en PSn00bSDK para el entorno de ejecución de PS1 y en mkpsxiso para crear las imágenes de disco. El engine prepara y valida el contenido, y mkpsxiso lo organiza según la distribución indicada. Separar esas tareas también ayuda a identificar si una falla está en los datos del juego o en el empaquetado.
El editor distribuido utiliza un entorno de ejecución precompilado, así que el flujo normal del usuario no requiere recibir el código privado del engine ni recompilar su código C. Las herramientas externas siguen necesitando una configuración correcta y un tratamiento adecuado de su redistribución. La comodidad de la interfaz no elimina el mantenimiento de dependencias ni las responsabilidades de licencia.
Trabajar en la exportación me llevó a revisar las funciones de principio a fin. Agregar un componente a Inspector también implica guardar sus valores, recuperarlos al abrir el proyecto, convertirlos y utilizarlos correctamente en PS1. Al mantener conectadas esas etapas, puedo seguir agregando herramientas sin perder de vista cómo llegará su resultado al juego.