Cómo empezó Polygon Engine

Desde hace mucho tiempo he querido hacer juegos para PlayStation 1. Como desarrollador de Unity, imaginaba poder hacerlo con un flujo parecido al que uso habitualmente: crear una escena, colocar objetos, asignar componentes y programar su comportamiento. De ahí surgió la idea de Polygon Engine.

Quería reunir ese flujo de trabajo con una interfaz inspirada en Windows 95. Me gustaba la idea de abrir el editor y sentir que estaba desarrollando un juego en aquella época, pero con las comodidades de una herramienta actual. Para conseguirlo, primero tenía que entender cómo llevar una escena creada en la computadora a un juego que pudiera ejecutarse en PS1.

Este es el primer capítulo de un diario retrospectivo de desarrollo. Las fechas organizan las etapas de ese recorrido; no son un historial de versiones ni las fechas de publicación de funciones específicas.

La elección de la estética de Windows 95

La apariencia de Windows 95 fue una de las primeras decisiones del proyecto. Los paneles grises, los bordes marcados y los menús compactos eran parte de la experiencia que quería recrear. No se trataba solamente de que el juego tuviera una estética retro; también quería disfrutar esa sensación mientras lo desarrollaba.

Al diseñar la interfaz, también tuve que pensar en su uso diario. Los valores de Inspector debían leerse con claridad, la selección de objetos tenía que distinguirse y los controles más frecuentes necesitaban estar a la mano. La referencia visual me ayudaba a definir el estilo, pero no debía volver incómodo el trabajo de editar una escena.

El editor funciona en Windows moderno, con una apariencia inspirada en Windows 95. Así puedo aprovechar una computadora actual para editar y preparar los recursos, mientras que el juego exportado está pensado para el hardware de PlayStation 1.

Adaptar el flujo de trabajo de Unity

Mi experiencia con Unity me sirvió para organizar el editor alrededor de escenas, GameObjects, componentes y scripts. Es una forma de trabajar que ya conozco y que me permite probar interacciones sin tener que resolver todos los detalles técnicos cada vez. Quería conservar esa facilidad al crear, por ejemplo, una puerta con movimiento, colisión y sonido.

Lo que sí necesitaba adaptar era el alcance de cada sistema. Aunque Inspector y los componentes resulten familiares, el renderizado, la física y el scripting tienen que funcionar dentro de los límites de PS1. La interfaz puede facilitar ese trabajo, pero también necesita mostrar las restricciones que afectan al proyecto.

Las texturas son un buen ejemplo. Al crear una habitación, no basta con asignar imágenes a sus materiales: también hay que comprobar que quepan en VRAM junto con los búferes de imagen y los demás datos gráficos. Preferí que esa información estuviera disponible durante la edición, cuando todavía es fácil reducir una textura o cambiar su formato, en lugar de descubrir el problema al exportar.

A partir de ahí fui definiendo qué tareas podía automatizar el engine y cuáles necesitaban información visible para el usuario. Esa decisión ha influido tanto en las herramientas de importación como en los paneles de memoria y validación.

Entender cómo funciona el hardware de PlayStation

El curso de programación de PS1 de Pikuma me ayudó mucho en este proceso. En Unity, buena parte del trabajo de renderizado y manejo de recursos ya está resuelto por el engine. Al desarrollar una herramienta para PS1, necesitaba entender esos procesos con más detalle: cómo se transforman los vértices, cómo llegan los comandos a la GPU y dónde se guardan las texturas antes de dibujarlas.

Estudiar esas etapas me ayudó a ubicar la función de cada parte de la consola. La CPU ejecuta la lógica del juego y coordina el trabajo; el GTE acelera cálculos geométricos, y la GPU dibuja las primitivas que recibe. El sonido tiene su propio procesador y memoria. Además, cargar datos desde el CD-ROM requiere considerar los tiempos de lectura de la unidad.

Con esa base fue más fácil entender por qué dos problemas que aparecen en la misma escena pueden necesitar soluciones distintas. La deformación de una textura tiene que ver con su interpolación; un polígono que aparece delante de otro puede deberse al orden de dibujo. Una pausa al cambiar de habitación, en cambio, puede estar relacionada con la carga de datos.

En estas entradas quiero contar cómo fui relacionando lo que aprendía con las necesidades del engine. Entender el hardware me ayudó a tomar decisiones sobre las herramientas, desde la información que necesita un importador de texturas hasta los errores que conviene detectar antes de generar un juego.

Separar la edición, la compilación y la ejecución

Para organizar ese trabajo, separé tres responsabilidades: editar el proyecto, preparar la compilación y ejecutar el juego en la consola.

El editor puede permitirse datos de origen detallados, manipulación interactiva y paneles explicativos. El proceso de compilación puede dedicar tiempo a comprobar referencias, convertir recursos y preparar datos. El entorno de ejecución necesita una representación compacta que pueda cargar y utilizar con un presupuesto muy reducido.

Una malla editable muestra bien esa separación. En el editor necesito información para seleccionar caras, modificar vértices y guardar los cambios. La consola necesita los datos necesarios para dibujarla. Preparar esa versión durante la compilación evita que el juego tenga que reconstruir información que solo era útil para editar.

Con ese mismo criterio decidí apoyarme en herramientas y librerías existentes. Me permitían avanzar en el editor y en el flujo de creación de juegos mientras aprendía cómo funcionaba cada parte. Integrarlas también ha requerido entender qué resuelven, qué limitaciones tienen y cómo revisar los problemas que aparecen al utilizarlas.

Completar el flujo de trabajo

Mi objetivo era poder completar un proyecto pequeño: crear una escena, construir un espacio, agregar comportamiento y exportarlo. Después tenía que poder volver al editor, hacer cambios y repetir el proceso. Para que esa forma de trabajar fuera práctica, el guardado, la importación y la compilación necesitaban funcionar juntos.

La estética de Windows 95 sigue siendo una parte del proyecto que disfruto mucho. Conforme fui avanzando, también me interesó cada vez más resolver esa integración entre herramientas y hardware. Las siguientes entradas recorren ese proceso: memoria, gráficos, creación de niveles y los sistemas necesarios para convertir una escena en un juego de PS1.