What I Have Learned Building Polygon Engine

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.

Adapting a familiar editor workflow to PS1

Hierarchy, Inspector, components, and Play Mode give me a familiar way to organize work. They reduce the number of new concepts someone has to learn before placing a first object or attaching a script.

At the same time, the editor needs to expose PS1 constraints while content is being prepared. Texture memory, draw order, numeric formats, audio, and disc access all affect the result. The earlier I can review those aspects, the easier it is to adjust an asset or scene without reworking a large part of the project.

Keeping the Windows 95 aesthetic has also required practical decisions. Panels and controls need to be recognizable, with readable text and enough room to work on a current computer. I want to retain that appearance while keeping everyday tasks, such as editing a property or finding an asset, straightforward.

Connecting the engine's systems

During development, I added scene editing, asset import, Lua, audio, and interface tools. Having each module was progress, but I then needed to check that data and interactions survived the connections between them.

For example, a UI Canvas button needs to retain its callback after saving and reopening the project. A script needs the same public API when running on PS1, and a mesh must preserve its scale and material references during conversion. Scene transitions bring together even more work by coordinating input, loading, and sound.

Reviewing those connections also means considering routine changes and errors: renaming an asset, trying to save to a full card, or loading a scene omitted from the build. Messages and validation need to explain what happened and where to correct it. That matters particularly when someone is learning the tool.

Polygon Engine currently brings together scene authoring, Level Builder, UV editing, asset import, Lua Behaviours, UI Canvas, audio, controllers, saving, and PS1 packaging. It also includes skeletal animation with defined limits, navigation, and visibility through Rooms and Portals. Documenting each system means explaining its scope so users know what they can build with it and how to prepare their content.

The tutorial and the included example

The Two-Room Relay tutorial follows that workflow from an empty project. It builds a first-person interaction using two rooms, a door, a trigger, a HUD, sound, and saving. Its size makes it possible to explain each part's setup and follow the relationship between player actions and the systems handling them.

The included Polygon: Signal Station example provides a project that is already assembled. Its menu, central area, and demonstration stations show how several features are organized within a scene or project. It offers another way to learn: open an object, inspect its components, and follow its references.

The two projects help me review different aspects of the engine. The tutorial checks whether the steps for creating a game can be explained and repeated. The example provides a broader combination of tools to explore. When a system changes, both offer concrete cases for reviewing its effect on the user's work.

Testing the exported game

Play Mode makes changes easy to try while editing. Export also involves the PS1 runtime, converted data, and disc layout. Project testing therefore needs to continue after generating the build.

Generating a package confirms that the build completed. Running it in an emulator lets me review startup and gameplay behavior, while testing on a console provides information about the hardware and its peripherals. When describing the project's status, I need to specify which tests were performed because each checks something different.

Performance needs a similar distinction. Capacity reports help identify scenes that exceed defined limits, but determining frame rate requires running and measuring the game. The tutorial's small size makes its behavior easier to inspect and problems easier to locate; it still needs those measurements.

Preparing the editor for distribution

Polygon Engine is distributed as an installable editor with a precompiled runtime. Users do not need the engine's internal code to work on their games, so installation, examples, external-tool setup, and documentation need to support the complete process on their own computers.

Startup configuration is also part of the documentation. The Polygon Engine splash identifies the tool used to create the game, but does not grant a Sony license, replace an emulator BIOS, or enable a retail console to run a homebrew disc on its own. The boot-data and splash guide explains the distinction. Exports contain no Sony boot data and include the runtime notices beside and inside the disc image; the publishing guide explains what to retain when sharing a game.

Using an existing SDK and packaging tools has let me concentrate more work on the editor and its systems. Preparing distribution also means keeping their versions, licenses, notices, and provenance clear, as well as explaining how external dependencies are installed.

What I want to improve next

I want the next iterations to improve diagnostics, make performance more predictable, and expand testing across projects and target configurations. Those improvements directly affect creating and exporting a game. They also help me decide which new tools are needed and which existing ones need refinement before adding more.

The Pikuma course, hardware references, and existing tools gave me a foundation to begin. Applying that knowledge in Polygon Engine has required connecting subjects I previously studied separately: memory, graphics, audio, scripts, and editor design. That remains one of the parts of development I enjoy most.

The original intention is still the same: make PlayStation games in an environment that feels comfortable to someone used to Unity. I can now work through a complete workflow and see more clearly where it needs improvement. I hope these articles also help share what I have learned and make it easier for others to begin their own PS1 projects.