From an Editor Project to a PS1 Build

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.

Converting source assets for the console

A texture begins as an image that is convenient to edit. The game needs a representation the GPU can use, with dimensions, color mode, and palette data that fit its constraints. A sound begins as a source recording; a short resident effect needs a different representation from music streamed from the disc.

Meshes and scenes have the same split. Selection data and editable settings are useful on the desktop. Compact vertices, component data, and resolved dependencies are useful on the console. Carrying every editing convenience into the runtime would spend memory on information the player never uses.

Preparing assets on the desktop lets some work be completed before the game runs. If a calculation depends on content that will remain unchanged during play, its result can often be stored in the build. This applies to parts of geometry preparation and navigation data. Moving objects and changes in game state still need updates during execution.

Keeping asset references consistent

Organizing assets also meant preserving their references. If a material uses a texture and I later rename the image, the material should still refer to the same asset. Depending only on a path makes those relationships more fragile when folders are reorganized.

Polygon Engine uses GUID-based asset references to separate identity from presentation. The name helps a person find the asset; its identifier helps the project keep referring to that asset. The build then resolves those references into the data it stages for the console.

Alongside the identifier, the asset database needs to stay current and missing dependencies need to be detected. The converted file must also match its source and import settings. If I change a texture's color mode and reuse an earlier imported copy, its reference can be correct while its content is outdated.

That is why the build also checks for stale imports. Finding the file is not enough: it needs to represent the project's current settings before it is included in the game.

Preparing data during the build

Once references are resolved, the next step is organizing data for loading on PS1. Scenes can be written as bounded binary records and their dependencies can be grouped. This uses information the editor already has to reduce the work needed when a scene starts.

In the current pipeline, scenes are written as .BSN data, and scene-local .PGB bundles arrange dependencies for sequential loading. These are implementation choices serving a practical purpose: reduce interpretation and avoid unnecessary file-by-file disc access when entering a scene.

These formats suit runtime use, although they are less convenient to inspect manually than project files. I therefore need reports that connect the generated data to its source. If an object is missing, I need to be able to trace its data back to the relevant scene or asset.

Preparation must account for temporary loading memory as well. Even when the final scene fits, reading its files and constructing its objects may require additional space. Estimating peak usage means considering old data, new data, and buffers that may coexist during the transition.

Reporting errors before packaging

While developing this process, I wanted errors to identify what needed attention. A generic build-failure message does little to explain a missing script, an invalid startup scene, or a misconfigured external tool. The diagnostic needs to name the relevant asset or setting so it can be corrected in the project.

The order matters too. Finding those problems before packaging is much cheaper than discovering them through an empty screen. At the same time, a successful validator cannot prove every behavior of a game. It can reject known-invalid inputs; it cannot guarantee that a puzzle is solvable or that every camera angle runs smoothly.

I use validation to catch known content problems and runtime tests to check the game's behavior. Both are necessary: a successful build can still contain a misconfigured interaction or a poorly performing area.

Integrating the runtime and disc tools

To complete the process, Polygon Engine uses PSn00bSDK for the PS1 runtime and mkpsxiso for disc-image creation. The engine prepares and validates content, and mkpsxiso arranges it according to the specified layout. Keeping those tasks separate also helps identify whether a failure involves game data or packaging.

The distributed editor uses a precompiled runtime, so the normal user workflow does not require receiving the engine's private source or rebuilding its C code. External tools still need correct setup and appropriate redistribution treatment. Convenience in the interface does not remove dependency maintenance or licensing responsibilities.

Working on export led me to review features from beginning to end. Adding a component to Inspector also means saving its values, restoring them when the project opens, converting them, and using them correctly on PS1. Keeping these stages connected lets me add tools while understanding how their results will reach the game.