content-hot-reload

Content Hot-Reload in FlatRedBall2

When iterating on content during development — tweaking JSON configs, swapping a sprite, editing a TMX map — you don't want to restart the game. The engine watches your source content folder (the one with the .csproj, the one your editor saves to) and reloads on change.

Two-folder model

A built .NET game has content in two places:

Folder	What it is
<csproj_dir>/Content/	Source. Where you edit. Lives in source control.
bin/Debug/.../Content/	Output. Build copies here. App reads from here.

Default game code reads the output (PlatformerConfig.FromJson("Content/player.json") resolves against AppContext.BaseDirectory). When the user edits the source, the output is stale until MSBuild re-copies.

The engine handles this by copying source → output as part of the watch pipeline, before invoking your callback. You write reload logic that reads from the output path as usual; the engine just makes sure the output is fresh.

API

Directory watch (the common case)

public override void CustomInitialize()
{
    // Restart the screen on any change under Content/. Restart handles every file type — entities,
    // sprites, tile collections all rebuild from scratch via CustomInitialize.
    WatchContentDirectory("Content", _ => RestartScreen(RestartMode.HotReload));
}

To dispatch by file type:

WatchContentDirectory("Content", relPath =>
{
    switch (Path.GetExtension(relPath))
    {
        case ".json":
            ReloadJsonConfig(relPath);  // in-place, no restart
            break;
        default:
            RestartScreen(RestartMode.HotReload);
            break;
    }
});

Single-file watch

WatchContent("Content/player.platformer.json", () =>
    PlatformerConfig.FromJson("Content/player.platformer.json").ApplyTo(player.Platformer));

Use when you want surgical control or to skip the cost of watching a whole tree.