[Dev Diary #35] Behind the Curtain: Our Design Process and the Event Editor

Salutations, Industrialists!

I’m Marc, a Producer on Gilded Destiny. Today’s Dev Diary is a little different. Rather than pulling back the curtain on a new game system, we’re pulling back the curtain on how we make the game, specifically, the tools and workflows our team uses to build the event content you’ll eventually be playing.

We’ll be covering our Design Docs process, and then diving deep into our Event Editor, which has seen some significant additions since we last showed it off. One thing that matters a great deal to us is that Gilded Destiny is a game modders can easily understand and enjoy. A lot of what we’re showing today reflects that commitment, showing functionality that veterans of the genre will recognise, wrapped in a visual editor that we hope makes it more approachable than ever.

We also have a video version of this Dev Diary, which walks through the Event Editor in action, and you can watch this below:

If you haven’t already, please wishlist Gilded Destiny on Steam and subscribe on YouTube. You can additionally join our Discord or Reddit community to stay up to date.

First, thank you for your patience, during the recent pause in regular monthly Dev Diaries. We haven't just been hanging fire. Rather, we have been working hard behind the scenes on completing a major refactoring project on Gilded Destiny's codebase to deal with technical debt and optimize performance for future builds. Many new features and systems have recently been added into the game and are undergoing final refinement now. We look forward to sharing more regular Dev Diaries again going forward. We have some big ones planned for the coming months!

Without further ado, let’s dive in

Design Docs

Before a single line of script is written, every major piece of content in Gilded Destiny goes through a structured design process. It’s a four-stage pipeline, and each stage serves a distinct purpose:

The first stage is High-Level Design. This is where the team rallies around an idea and agrees on its scope. For country-based events, this is where we decide which historical events we’re covering and how broadly we’re interpreting them. For system events —those that serve as the content counterpart to a game system or feature, such as Authority or Elections—High-Level Design is where we align on the gameplay loop and its goals, the key player fantasies the content should serve, and the overall scope of what this particular set of events will cover.

From there we move into Outlines: a quick lay of the land for all the event content we have. Here we map out the general flow of events and their effects, getting a bird’s-eye view of how everything connects before we commit to specifics.

Then comes Detailed Design, where we iron out the balance, pin down precise numbers, and write the narrative text. This is where the content goes from a skeleton to something that feels like a real piece of the game.

Finally, there’s Implementation —where it all gets built. By the time we reach this stage, decisions have been made and the work is well-defined. The ideal is that any ambiguity has been resolved during Detailed Design, which keeps testing as clean as possible. It’s not a glamorous process, but it keeps the team aligned and ensures that by the time something reaches the player, it’s been thought out properly.

Summary

• Every major piece of content moves through four stages: High-Level Design, Outlines, Detailed Design, and Implementation.

• High-Level Design sets scope and goals; Outlines map the general flow; Detailed Design pins down balance, numbers, and narrative text.

• Resolving ambiguity early keeps Implementation clean and testing focused.

Event Editor

For those of you who have been following our Dev Diaries, the Event Editor won’t be a stranger. This is our custom-built tool for writing and managing the events that drive much of Gilded Destiny’s narrative and mechanical content.

What we want to show today isn’t the basics, but rather what’s new. Over the past year we’ve made several additions that significantly expand what content designers can do inside the editor, and they’re worth walking through in some detail.

Hiding and Disabling Code Blocks

The first addition is small but surprisingly useful in practice: the ability to hide and disable individual code blocks within the editor. Think of this as the visual equivalent of commenting out code. When you’re iterating on a complex event—testing different branches, temporarily setting aside logic you’re not ready to use—you want a way to deactivate parts without deleting them. Previously, that meant workarounds. Now, a single toggle lets you hide or disable any block cleanly, keeping your workspace tidy and your work-in-progress intact.

It’s a small quality-of-life change, but once you have it you can’t imagine working without it.

Summary

• The Event Editor is our custom tool for writing and managing the events that drive narrative and mechanical content.

• Several substantial additions have been made over the past year, including the topics discussed below: Hiding and Disabling Code Blocks, Scopes, Modifier Groups, On-Actions, and Situations.

• A simple hide/disable toggle on individual code blocks now lets designers deactivate logic without deleting it—the visual equivalent of commenting out code.

Scopes

The next addition is a more substantial architectural change, and one we think will feel immediately intuitive to players familiar with grand strategy games.

Previously, how we targeted entities in our scripting—which Country, which Character, which Province a piece of logic was acting on—was handled in a way that was functional but could be cumbersome. We’ve now moved to a Scopes -based system.

The core idea is straightforward: every piece of logic now operates within a defined Scope that tells it what it’s acting on. You can move between Scopes explicitly—stepping from a country Scope into a character Scope, for example—and the logic within each Scope knows exactly what it’s addressing. This makes complex chains of logic far easier to read and reason through, because at any point in a script you can see clearly what the current target is.

Summary

• Scripting now operates within explicit Scopes that define the entity each piece of logic is acting on (Country, Character, Province, etc.).

• Designers can step between Scopes explicitly, making complex logic chains easier to read and reason through.

• The system will feel familiar to grand-strategy modders.

Modifier Groups

Modifiers—the numerical effects that influence your nation, your characters, and your economy—are a fundamental part of how Gilded Destiny works. Creating and managing them, however, used to require more manual work than we were happy with.

Our Modifier Group editor is designed to make creating such a pivotal part of the game easier. Everything to do with modifiers is exposed in one unified screen—not only the modifiers you want to group together, but also things like conditions and text localisation, which would normally be scattered across separate game files. The result is that you can fully complete a modifier in one place, with no jumping between files to finish the job.

Summary

• The Modifier Group editor brings everything related to modifiers into one unified screen.

• Modifiers, conditions, and text localisation are all editable from the same place, instead of being scattered across separate game files.

• Designers can build a complete modifier without leaving the editor.

On Actions

Another addition that will feel familiar to veterans of the genre is On Actions.

On Actions are essentially event hooks—defined trigger points in the game simulation that fire automatically when certain things happen. Rather than building complex conditional checks into every event, you register an On Action and it listens for the relevant moment: a new ruler ascending, a war ending, a new building constructed. When that moment arrives, the On Action fires and does its work.

On Actions also serve a second, equally important function: the periodic firing of events. An On Action can be set to trigger on a regular basis—monthly, for example—and this is the engine that drives much of our repeatable content. Rather than leaving the game to decide arbitrarily when certain events should appear, periodic On Actions give us precise control over frequency: how often a particular type of event should show up, and how to make sure the player isn’t flooded or starved.

What ties both functions together is integration with our Conditions system. Every On Action carries a weight, and that weight can be modified by the full power of our generic Conditions, meaning designers can build nuanced, contextually-aware responses without hard-coding anything. An On Action that fires when a war ends might trigger a political scandal, but whether that scandal materialises, and how likely it is, depends entirely on the conditions defined for it.

Summary

• AddedOn Actions are event hookstrigger points that fire automatically when defined moments happen in the simulation, such as a war ending or a new ruler ascending.

• They also drive periodic, repeatable content by firing on a regular cadence (e.g. monthly), giving precise control over event frequency.

• Each On Action’s weight can be modified by the Conditions system, enabling nuanced, contextually-aware responses without hard-coding.

Situations

The final addition we’re showing today is the one we’re most excited about, and we think it represents something meaningful about the direction of Gilded Destiny as a whole.

Situations are our way of encapsulating self-contained pieces of game content by wrapping them up into something the game can track, display, and communicate to the player.

At their core, Situations expose a tracker, which is a counter that can represent almost anything you need it to. In their simplest form, a Situation might follow the course of the July Revolution. Or consider the Springtime of Nations: a Situation might track the balance of sentiment between liberal and conservative forces across a country as Unrest spreads and governments scramble to respond. A Situation doesn’t even have to be on a sliding scale—it might simply represent whether Napoleon III sits on the throne.

What matters is not just what Situations track, but what they surface. A recurring frustration of games in this genre is that important things can happen without the player ever knowing—or, more importantly, knowing why. Content gets buried. Consequences go unnoticed. With Situations, we’re making a deliberate commitment: content that exists in the game should be visible to the player. Situations are our first concrete step toward that goal—a way to ensure that the stories being told don’t just unfold in the background, but are present and legible to anyone paying attention.

This is an early implementation of Situations, and we have a lot more we want to do with them. We’ll be expanding on them as development continues.

Summary

• Situations encapsulate self-contained pieces of game content into something the game can track, display, and communicate to the player.

• They expose a tracker—a counter that can represent the progress of an event chain (e.g. the July Revolution), the balance of opposing forces (e.g. the Springtime of Nations), or a simple state (e.g. whether Napoleon III sits on the throne).

• The goal is visibility: ensuring that important content surfaces to the player rather than unfolding silently in the background.

• This is an early implementation, with more planned as development continues.

Postamble

That’s probably a good place to end for today.

We hope you’ve enjoyed this Dev Diary, and as always, if you have any questions or comments, let us know. You can find us on Discord, YouTube, X, Facebook, and Reddit for discussions, updates, and feedback.

Until our paths converge once more, we bid thee farewell!

May your destiny be a gilded one.

Development Update

What we've accomplished so far in 2026

• A whole bunch of tech icons

• Situations

• Area/Region/Subcontinent/Continent system

• Cultural Heritages and Religious Convictions

• Added Civil Service (Bureaucrats) and Military Service to Religious Rights - previously only Cultural Rights had these

• Budget Slider Limits are now driven by modifier. This includes taxation, government expenses, tariffs - anything with a slider can have these limits now. The main applicator of these modifiers for the time being is Policies

• Massive overhaul of policies, from adding new ones to utilizing new modifiers and rebalancing

• Revised how Welfare and Pensions work, making them a Budget slider like Tax. How they function is now driven by modifiers, such as how much you can spend on it

What we have planned next

• Authority Events

• Election Events

• Unrest Events

• Final implementation of Qing Events

• Final implementation of Prussia Events

• Cholera Events

• Springtime of Nation Events