This is a blueprint of my idea how to implement a scenario system. I'm writing this here so as not to forget about it until I get around to implementing it, and so the other developers can exclaim about anything they dislike about it 😉️

A scenario is, essentially, a savegame. So the scenario editor will look like the normal game plus some extra controls to change things such as land size, money amount, objectives, etc. And then creates an FCT (savegame) file.

In principle, this file could be used as a scenario straight away. But there's one problem, and that's localizing the name and description. Embedding translations in the scenario itself would be a horror for translating so not an option. The proper way to localize anything is via RCD files.

So, there will be a new RCD block MISN ("mission") which contains a string node and multiple scenarios. Each scenario in a MISN block is just the verbatim content of an FCT file.

MISN {
    texts: string { key: "scenarios-easy"; }
    scenario: "../scenarios/forest_frontiers.fct";
    scenario: "../scenarios/barony_bridge.fct";
    scenario: "../scenarios/arid_heights.fct";
    ...
}

scenarios-easy:
    NAME: "Easy"
    DESCR: "Easy official scenarios"
    SCENARIO_FOREST_FRONTIERS_NAME: "Forest Frontiers"
    SCENARIO_FOREST_FRONTIERS_DESCR: "Insert scenario description here."
    SCENARIO_ARID_HEIGHTS_NAME: "Arid Heights"
    SCENARIO_ARID_HEIGHTS_DESCR: "Insert scenario description here."
    ...

Each MISN block corresponds to one tab in the scenario select menu.

And how to link the scenarios to the strings?
A scenario already has a "name" property, which currently is a human-readable string (always "Default" atm). This will be replaced with the name of the translatable string, so a scenario's properties will include the std::string variable name with value "SCENARIO_FOREST_FRONTIERS_NAME" and an std::string variable descr with value "SCENARIO_FOREST_FRONTIERS_DESCR". Instead of rendering these variables verbatim, like now, we'll convert the name to a StringID and use that to render the localized string from the RCD file.

To avoid name clashes, the scenario editor could ask the author to specify their (nick)name, and use it as a prefix for the string names. So if Nordfriese wants to write a scenario called "Hello World Park", the editor would generate the keys "NORDFRIESE_HELLO_WORLD_PARK_NAME" and "NORDFRIESE_HELLO_WORLD_PARK_DESCR".
We can't easily store the base position of each MISN block's strings the way we do for rides and scenery, since we don't know at compile-time how many strings will be contained in any given MISN block.

Writing the FML and YAML files and compiling them into an RCD file will be the scenario designer's responsibility, so creating a custom scenario will be as much effort as creating any other custom RCD file.

This system has, with some modifications in the details, now been implemented in the latest development version.

Thank you. It looks pretty great. Unfortunately, the game crashes for me from time to time (see https://codeberg.org/FreeRCT/FreeRCT/issues/329), so I didn't play it to the end, but it felt pretty cool!