Lo que he aprendido al desarrollar Polygon Engine

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.

Adaptar un flujo de trabajo conocido a PS1

Hierarchy, Inspector, los componentes y Play Mode me dan una forma conocida de organizar el trabajo. Reducen la cantidad de conceptos nuevos que alguien necesita aprender antes de colocar su primer objeto o asignar un script.

Al mismo tiempo, el editor necesita mostrar las restricciones de PS1 durante la preparación del contenido. La memoria de texturas, el orden de dibujo, los formatos numéricos, el audio y la lectura del disco influyen en el resultado. Cuanto antes puedo revisar esos aspectos, más fácil es ajustar un recurso o una escena sin rehacer gran parte del proyecto.

Mantener la estética de Windows 95 también ha requerido decisiones prácticas. Los paneles y controles deben ser fáciles de reconocer, pero además necesitan texto legible y espacio suficiente para trabajar en una computadora actual. Me interesa conservar esa apariencia sin que dificulte las tareas habituales, como editar una propiedad o encontrar un recurso.

Conectar los sistemas del engine

Durante el desarrollo fui agregando edición de escenas, importación de recursos, Lua, audio y herramientas de interfaz. Tener cada módulo por separado era un avance, pero después necesitaba comprobar que los datos y las interacciones se conservaran al pasar de uno a otro.

Por ejemplo, un botón de UI Canvas debe conservar su callback después de guardar y volver a abrir el proyecto. Un script necesita encontrar la misma API pública al ejecutarse en PS1, y una malla debe mantener su escala y las referencias a sus materiales durante la conversión. Las transiciones entre escenas reúnen todavía más trabajo, porque coordinan la entrada, la carga y el sonido.

Revisar esas conexiones también implica considerar cambios y errores habituales: renombrar un recurso, intentar guardar en una tarjeta llena o cargar una escena que no se incluyó en la compilación. En esos casos, los mensajes y las validaciones necesitan indicar qué ocurrió y dónde corregirlo. Eso es especialmente importante cuando alguien está aprendiendo a usar la herramienta.

Actualmente, Polygon Engine reúne creación de escenas, Level Builder, edición de UVs, importación de recursos, Lua Behaviours, UI Canvas, audio, mandos, guardado y empaquetado para PS1. También incluye animación esquelética con límites definidos, navegación y visibilidad mediante Rooms y Portals. Al documentar cada sistema, necesito explicar su alcance para que los usuarios sepan qué pueden construir con él y cómo prepararlo.

El tutorial y el ejemplo incluido

El tutorial Two-Room Relay permite recorrer ese flujo desde un proyecto vacío. Propone una interacción en primera persona con dos habitaciones, una puerta, un trigger, un HUD, sonido y guardado. Su tamaño permite explicar cómo se configura cada parte y seguir la relación entre las acciones del jugador y los sistemas que las resuelven.

El ejemplo incluido Polygon: Signal Station permite explorar un proyecto que ya está armado. Su menú, área central y estaciones de demostración sirven para revisar cómo se organizan varias funciones en una misma escena o proyecto. Es otra forma de aprender: abrir un objeto, revisar sus componentes y seguir sus referencias.

Los dos proyectos me ayudan a revisar aspectos distintos del engine. El tutorial permite comprobar si los pasos para crear un juego se pueden explicar y repetir. El ejemplo permite explorar una combinación más amplia de herramientas. Cuando cambia un sistema, ambos ofrecen casos concretos para revisar cómo afecta al trabajo del usuario.

Probar el juego exportado

Play Mode facilita probar cambios mientras se edita. Al exportar, también intervienen el entorno de ejecución de PS1, los datos convertidos y la organización del disco. Por eso las pruebas del proyecto necesitan continuar después de generar la compilación.

Generar el paquete confirma que terminó la compilación. Ejecutarlo en un emulador permite revisar el arranque y el comportamiento del juego, mientras que probarlo en una consola aporta información sobre el hardware y sus periféricos. Al describir el estado del proyecto, necesito indicar cuáles de esas pruebas se hicieron, porque cada una comprueba algo diferente.

Con el rendimiento ocurre algo similar. Los reportes de capacidad ayudan a detectar escenas que exceden los límites definidos, pero para conocer los cuadros por segundo hace falta ejecutar y medir el juego. El tamaño reducido del tutorial facilita revisar su comportamiento y localizar problemas; aun así, necesita esas mediciones.

Preparar el editor para su distribución

Polygon Engine se distribuye como un editor instalable con un entorno de ejecución precompilado. El usuario no necesita el código interno del engine para trabajar en su juego, así que la instalación, los ejemplos, la configuración de herramientas externas y la documentación deben permitirle completar el proceso desde su propia computadora.

La configuración de arranque también forma parte de la documentación. El splash de Polygon Engine identifica la herramienta con la que se creó el juego, pero no otorga una licencia de Sony, sustituye el BIOS de un emulador ni permite por sí mismo ejecutar un disco homebrew en una consola comercial. La guía de datos de arranque y splash explica esa diferencia. Las exportaciones no contienen datos de arranque de Sony e incluyen los avisos del entorno de ejecución junto a la imagen de disco y dentro de ella; la guía de publicación explica qué debes conservar al compartir un juego.

Usar un SDK y herramientas de empaquetado existentes me ha permitido concentrar más trabajo en el editor y sus sistemas. Al preparar la distribución, también necesito mantener claras sus versiones, licencias, avisos y procedencia, además de explicar cómo se instalan las dependencias externas.

Qué quiero mejorar después

Quiero dedicar las siguientes iteraciones a mejorar los diagnósticos, hacer más predecible el rendimiento y ampliar las pruebas con proyectos y configuraciones de destino distintas. Esas mejoras afectan directamente al proceso de crear y exportar un juego. También me ayudan a decidir qué herramientas nuevas hacen falta y cuáles necesitan ajustes antes de seguir creciendo.

El curso de Pikuma, las referencias de hardware y las herramientas existentes me dieron una base para empezar. Aplicar ese conocimiento en Polygon Engine me ha obligado a conectar temas que antes estudiaba por separado: memoria, gráficos, audio, scripts y diseño del editor. Esa parte del desarrollo sigue siendo de las que más disfruto.

La intención inicial sigue siendo la misma: hacer juegos de PlayStation en un entorno que resulte cómodo para alguien acostumbrado a Unity. Ahora puedo trabajar sobre un flujo completo y ver con más claridad qué necesita mejorar. Me gustaría que estos artículos también sirvan para compartir lo que he aprendido y facilitar que otras personas empiecen sus propios proyectos para PS1.