This week I started working on the game editor for Rival Fortress.

In a way similar to how Unreal Engine does it, I chose to implement the game editor as DLL module that gets loaded by the game executable on demand, instead of writing a separate application that edits game data.

I think this is the most sensible approach as I intend to ship the editor with the game to allow modders to easily and quickly make tweaks and test their mods without having to open a separate application.

The dual platform layer

Architecturally I want to have a clear separation between platform specific code and engine/game code, as this make it much easier to port the game to new platforms.

Since the editor needs to interact much more with the platform (mostly in the form of file/directory IO) than the game, I decided to split the platform layer in two: Game platform and Editor platform.

The game platform exposes functions for basic file I/O (for reading and writing of config, save games and assets), rendering, user input and audio.

The editor platform is a superset of the game platform, and exposes many more fine grain I/O related functions that are essential for managing temporary files/directories, monitoring file changes, deleting and moving around files, as well as packaging game assets. All this functionality is loaded into memory only if the editor is active.

Passing platform functions through DLL boundaries

The editor is loaded as a dynamically linked library and to avoid duplicating functionality, it receives a struct containing function pointers to the platform layer, the engine and game contexts.

This facilitates the modularization of editor components that can easily reuse engine, game and platform functionality.