Modules and hot reload

Gameplay is written in C++ and lives in a separate library that the editor loads, unloads and reloads while it is running.

C++ came first because it is what the engine itself is written in: one language means one debugger, and nothing sitting between the engine and the gameplay code that has to be kept in sync as both change. A scripting layer is planned on top of this rather than instead of it.

This came first

The boundary between the engine and your game code was the third thing built, before there was much to convert.

That ordering is the point. Reloading code while it runs places real constraints on how everything is written, so finding out late what those constraints are would have meant rewriting whatever had been built in the meantime.

What survives a reload

Anything that outlives the swap has to be either owned by the engine or rebuildable from a file. Two consequences follow.

Types are identified by a hash of their name. The identity the compiler normally provides belongs to the library that produced it, so when that library is unloaded, every reference to it points at memory that is no longer there. A hash is just a number, and a number survives.

Objects are moved field by field, not copied wholesale. Copying the raw bytes of something that owns memory elsewhere produces two objects that both believe they own it, and the second one to be cleaned up crashes. Because the engine knows what fields each type has, it can move them properly, which is also how it handles a type it has never seen before because you defined it in your game code.

Undo history is cleared on reload

This one is easy to get wrong, so it is worth stating.

Undo history holds objects belonging to types that may no longer exist after a reload, and refers to positions in the level that loading a different level would have reused for something else. Either would corrupt something quietly rather than fail loudly.

So the history is cleared when your game code reloads, and when a level is loaded.

Version mismatches are caught

Game code built against a different version of the engine is a crash with no useful message. The version is recorded when it is built, checked when it is loaded, and a mismatch is reported as a mismatch rather than as corruption several frames later.

The trade-off

Reloading C++ gives fast iteration with no safety net. A crash in gameplay code takes the editor down with it.

The design document says so directly rather than burying it. It is a trade I can accept because I also wrote the engine, and it is one of the reasons a scripting layer is on the roadmap: code that cannot take the whole editor down with it is worth having for the parts that do not need the speed.