I started Polygon Engine because I wanted to make PlayStation games with a workflow that felt familiar to me as a Unity developer. The Windows 95 aesthetic was part of that idea from the beginning: I wanted to recapture something of working with tools from that period, while keeping the convenience of a scene- and component-based editor.

After several months of development, that idea has become a set of tools for creating a project, building levels, programming interactions, and exporting a PS1 game. The previous articles covered individual parts of that process. To close this series, I wanted to bring together what I learned by connecting them and explain how that has changed my approach to developing the engine.

While working on gameplay interactions, I needed controller input to behave consistently across scripts and the interface. Players also needed to save progress and recover it in another session. Both systems are used constantly, but require considering more situations than the usual setup on my development computer.

A player may start without a connected controller or use one with different capabilities. A memory card may be full, missing, or contain damaged data. Integrating these systems into Polygon Engine meant accounting for those cases and providing enough information for each game to respond to them.

As I brought graphics, scripts, collision, animation, and audio together in Polygon Engine, I needed to look at the work they perform as a whole. Counting a scene's polygons helps explain part of that workload, but leaves out many operations needed to run the game.

Even a small room can contain scripts running continuously, animated objects, lights, and several active sounds. Some surfaces may also overlap and cover much of the screen. To decide what to optimize, I needed to understand the cost of each system and how those costs add up.

I wanted users to program their games without modifying or rebuilding the engine's code. A door, for example, needs to respond to input, remember its state, play a sound, and update a message. Lua gave me a way to let users connect those actions within the project.

Integrating it meant deciding which work belonged in scripts and which systems should remain in native code. Quick experimentation mattered, but I also needed to control memory use and execution time on PS1. That division shapes much of Polygon Engine's API.

While working on scene loading in Polygon Engine, CD-ROM access was one of the clearest differences from development for a current desktop computer. The disc provides much more storage than PS1 RAM, but data must be read and prepared before the game can use it. Drive speed and file placement both affect that time.

This also affects game transitions. Before entering another area, I need to decide which assets will be loaded, what appears during the wait, and what happens to the music. Implementing that flow meant considering data loading and disc playback together.

To export a game from Polygon Engine, I first needed to turn the editor project into data the console could use. Scenes, images, and sounds are stored in formats convenient for development, but PS1 needs versions suited to its memory, rendering, and audio systems.

That conversion became an important part of development. Whenever I added an asset type or component, I also had to consider how to save it, check its references, and load it in the game. Creating the disc image is the final step in that process.

Beyond drawing models, Polygon Engine needed tools for building spaces a player could walk through. A simple room brings together several problems I wanted to solve: floors seen in perspective, walls close to the camera, doorways, and collision that lets the character move without passing through the geometry.

Working with that kind of space helped me connect rendering to level editing. Changing a wall's size or the shape of an entrance also meant considering how it would look on PS1 and what collision volume it needed. Level Builder is part of that process of creating and reviewing the level.

While working on Polygon Engine's renderer, I needed to understand which visual artifacts associated with PS1 came from the hardware and which could be implementation errors. Texture distortion, small jumps in vertex positions, and incorrectly ordered polygons can appear in the same scene, but they have different causes.

Separating them helped me review each stage of rendering more clearly. To explain how they relate, it helps to start with the process that turns model vertices into an image. From there, I can identify where each problem occurs and what can reduce it.

While studying PlayStation 1 memory for asset importing, I had to separate three things: game data, graphics, and sound. Each uses a different memory region, so calculating the total size of a scene was not enough.

A scene can leave space in main RAM and still exceed VRAM capacity with its textures. Resident sounds have a separate limit as well. Understanding that separation helped me decide what the engine needed to show when reviewing assets before export.

I have wanted to make games for the original PlayStation for a long time. As a Unity developer, I imagined doing it through a workflow similar to the one I already used: create a scene, place objects, add components, and write their behavior. That was the starting point for Polygon Engine.

I wanted to combine that workflow with a Windows 95-inspired interface. I liked the idea of opening the editor and feeling as though I were developing a game in that period, with the conveniences of a current tool. To make it work, I first needed to understand how a scene built on a desktop could become a game running on PS1.