Joël van der Werf
All posts

From editor to an .exe: the first standalone build

Splitting game code out of the editor, a small runtime that plays one project, and a build button in the editor. Deliberately not an asset pipeline yet.

Until the end of October, Hydro games only ran inside the editor. An engine you can't ship from is a tech demo, so the next step was a game anyone can run: one folder, one .exe.

Step 1: game code out of the editor

The game's scripts lived inside the editor project. They moved into their own library, Game. The editor and the new runtime both link Game and Hydro and register the same generated reflection data at startup. The two can't drift apart: they run the same scripts.

Step 2: a runtime that does one thing

The Runtime project opens one project file, applies its renderer settings, loads the start scene and runs it. In development you pass the project on the command line. In a package, it looks for the project file next to the exe with the same name, and nothing else. A packaged game runs in its own folder, F11 toggles full screen, and a script can quit the game. In the editor, the same call just stops Play mode.

There are two build kinds: Release keeps a console with the log for testing, and Dist is a normal windowed app without one.

Step 3: a build button

Package.bat builds only the runtime and what it links, so the editor can stay open. It then fills Builds/<Project>/ with the exe, the shader compiler DLL, the engine's shaders, the project and its assets, and a build-info file. In the editor, File › Build… saves the project and scene, runs the script with its output live, and offers Run and Open Folder when it's done.

Deliberately not an asset pipeline

The build copies the files the runtime already reads. No cooking, no packing, no compression. That's on purpose: I'd rather design the asset pipeline against measurements of a real build than guess. The one rule to keep in mind until then: code reaches assets by handle through the asset manager, never by path, so packed files can replace loose ones later without touching game code.

Still open

  • Packaging in CI, so every push produces a playable build.
  • Testing on a PC without Visual Studio, which needs the Microsoft Visual C++ Redistributable.
Older: A street lamp is one thing: scene hierarchy and runtime UINewer: Game content as data: Hydro's ScriptableObjects

Building a game, an engine, or the tools around them?

I'm based in Tokyo and open to conversations about Unity, C++ and engine roles, C# and .NET software roles, and teams that want to put AI agents to work on real codebases.