Empecé Polygon Engine porque quería crear juegos de PlayStation con un flujo de trabajo que me resultara familiar como desarrollador de Unity. La estética de Windows 95 formaba parte de esa idea desde el principio: buscaba recuperar algo de la experiencia de trabajar con herramientas de aquella época, pero con las facilidades de un editor basado en escenas y componentes.

Después de varios meses de desarrollo, esa idea se ha convertido en un conjunto de herramientas para crear un proyecto, construir niveles, programar interacciones y exportar el juego a PS1. En los artículos anteriores fui repasando las partes de ese proceso. Para cerrar esta serie, quería reunir lo que aprendí al conectarlas y explicar cómo ha cambiado mi forma de trabajar en el engine.

Al trabajar en las interacciones del juego, necesitaba que la entrada del mando funcionara de forma consistente en los scripts y la interfaz. También hacía falta guardar el progreso y recuperarlo en otra sesión. Son dos sistemas que se utilizan constantemente, pero que requieren considerar más situaciones que la configuración habitual de mi computadora de desarrollo.

Un jugador puede iniciar sin el mando conectado o usar uno con capacidades distintas. La Memory Card puede estar llena, faltar o contener datos dañados. Al integrar estos sistemas en Polygon Engine, tuve que tener en cuenta esos casos y ofrecer información suficiente para que cada juego pueda responder a ellos.

Conforme fui integrando gráficos, scripts, colisiones, animación y audio en Polygon Engine, tuve que revisar el trabajo que realizan en conjunto. Contar los polígonos de una escena ayuda a entender parte de ese trabajo, pero deja fuera muchas operaciones necesarias para que el juego funcione.

Incluso una habitación pequeña puede tener scripts que se ejecutan constantemente, objetos animados, luces y varios sonidos activos. Además, algunas superficies pueden dibujarse unas sobre otras y ocupar gran parte de la pantalla. Para decidir qué conviene optimizar, necesitaba distinguir el costo de cada sistema y la forma en que se combinan.

Quería que los usuarios pudieran programar el comportamiento de sus juegos sin modificar ni recompilar el código del engine. Una puerta, por ejemplo, necesita reaccionar a la entrada, recordar su estado, reproducir un sonido y actualizar un mensaje. Lua me permitía ofrecer una forma de conectar esas acciones desde el proyecto.

Al integrarlo, tuve que decidir qué trabajo quedaría en los scripts y qué sistemas seguirían implementados en código nativo. La facilidad para probar una idea era importante, pero también necesitaba controlar el uso de memoria y el tiempo de ejecución en PS1. Esa división define buena parte de la API de Polygon Engine.

Al trabajar en la carga de escenas de Polygon Engine, el CD-ROM fue una de las diferencias más claras respecto al desarrollo para una computadora actual. El disco ofrece mucho más espacio que la RAM de PS1, pero los datos tienen que leerse y prepararse antes de que el juego pueda utilizarlos. La velocidad de la unidad y la ubicación de los archivos influyen en ese tiempo.

Esto también afecta a las transiciones del juego. Antes de entrar a otra zona hay que decidir qué recursos estarán cargados, qué se mostrará durante la espera y qué ocurrirá con la música. Para implementar ese flujo necesitaba considerar juntas la carga de datos y la reproducción desde el disco.

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.

Además de dibujar modelos, Polygon Engine necesitaba herramientas para construir espacios que se pudieran recorrer. Una habitación sencilla reúne varios de los problemas que quería resolver: pisos vistos en perspectiva, paredes cercanas a la cámara, puertas y colisiones que permitan moverse sin atravesar la geometría.

Trabajar con ese tipo de espacio me permitió relacionar el renderizado con la edición del nivel. Al cambiar el tamaño de una pared o la forma de una entrada, también tenía que considerar cómo se vería en PS1 y qué volumen de colisión necesitaría. Level Builder forma parte de ese flujo de creación y revisión.

Al trabajar en el renderizado de Polygon Engine, necesitaba entender cuáles de los defectos visuales asociados con PS1 venían del hardware y cuáles podían ser errores de implementación. La deformación de las texturas, los pequeños saltos de los vértices y los polígonos que aparecen en un orden incorrecto pueden coincidir en una escena, pero tienen causas distintas.

Separarlos me ayudó a revisar cada etapa del renderizado con más claridad. Para explicar cómo se relacionan, primero conviene seguir el proceso que convierte los vértices de un modelo en una imagen. Después se puede ver dónde aparece cada problema y qué opciones hay para reducirlo.

Al estudiar la memoria de PlayStation 1 para preparar la importación de recursos, tuve que separar tres cosas: los datos del juego, los gráficos y el sonido. Cada uno utiliza una memoria distinta, así que no bastaba con calcular cuánto ocupaba una escena en total.

Por ejemplo, una escena puede dejar espacio disponible en la RAM principal y aun así superar la capacidad de VRAM con sus texturas. Lo mismo ocurre con los sonidos que se mantienen cargados. Esa separación me ayudó a definir qué información debía mostrar el engine para revisar los recursos antes de exportar.

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.