How Polygon Engine Started

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.

This is the opening chapter of a retrospective development journal. The dates organize the stages of that journey; they are not a release history or dates when individual features shipped.

Choosing the Windows 95 style

The Windows 95 appearance was one of the project's first design decisions. Gray panels, pronounced borders, and compact menus were all part of the experience I wanted to recreate. Alongside the game's retro visuals, I wanted the development tools to feel connected to that period too.

Designing the interface also meant thinking about everyday use. Inspector values needed to be readable, selected objects needed to stand out, and frequently used controls needed to be easy to reach. The visual reference helped define the style, but editing a scene still had to be comfortable.

The editor runs on modern Windows, with an appearance inspired by Windows 95. That lets me use a current computer for editing and asset preparation, while the exported game targets PlayStation 1 hardware.

Adapting the workflow I knew from Unity

My Unity experience helped me organize the editor around scenes, GameObjects, components, and scripts. I know that workflow well, and it lets me try interactions without working through every low-level detail each time. I wanted to keep that convenience when making something like a door with movement, collision, and sound.

I did need to adapt the scope of those systems. Even if Inspector and the components look familiar, rendering, physics, and scripting have to work within PS1 limits. The interface can make that work easier while showing the constraints that affect the project.

Textures are a useful example. Building a room involves more than assigning images to materials: those images must fit in VRAM alongside the display buffers and other graphics data. I wanted that information available during editing, while reducing a texture or changing its format is still straightforward, instead of finding the problem during export.

From there, I began deciding which tasks the engine could automate and which needed visible information for the user. That decision has influenced both the import tools and the memory and validation panels.

Learning how PlayStation hardware works

Pikuma's PS1 programming course helped me a great deal with this. In Unity, much of the rendering and resource management is already handled by the engine. Building a tool for PS1 meant understanding those processes in more detail: how vertices are transformed, how commands reach the GPU, and where textures are stored before they are drawn.

Studying those stages helped me understand the role of each part of the console. The CPU runs gameplay and coordinates work; the GTE accelerates geometry calculations, and the GPU draws the primitives it receives. Sound has its own processor and memory. Loading data from the CD-ROM also requires accounting for the drive's read times.

With that foundation, it became easier to understand why two problems in the same scene might need different solutions. Texture distortion involves interpolation; a polygon appearing in front of another may involve drawing order. A pause when changing rooms, on the other hand, may come from loading data.

In these posts, I want to explain how I connected what I was learning to the engine's needs. Understanding the hardware helped me make decisions about the tools, from the information a texture importer needs to the errors worth catching before building a game.

Separating editing, building, and runtime

To organize that work, I separated three responsibilities: editing the project, preparing the build, and running the game on the console.

The editor can afford rich source data, interactive manipulation, and explanatory panels. The build process can spend time checking references, converting assets, and preparing data. The runtime needs a compact representation it can load and use within a very small budget.

An editable level mesh shows why that separation helps. In the editor, I need information for selecting faces, moving vertices, and saving changes. The console needs the data required to draw the mesh. Preparing that version during the build saves the game from reconstructing information that was only useful for editing.

I took the same approach to existing tools and libraries. They let me make progress on the editor and the game creation workflow while learning how each part worked. Integrating them has also meant understanding what they handle, where their limits are, and how to investigate problems involving them.

Making the full workflow usable

My goal was to complete a small project: create a scene, build a space, add behavior, and export it. Then I needed to return to the editor, make changes, and repeat the process. For that to be practical, saving, importing, and building had to work together.

The Windows 95 style is still a part of the project I enjoy. As development continued, I became just as interested in connecting the tools to the hardware. The next posts explore that work through memory, graphics, level creation, and the systems needed to turn a scene into a PS1 game.