By the time Security Architects had gone through multiple rounds of playtesting, the core mechanics were well understood. However, a fundamental limitation remained. While manual playtesting was invaluable for understanding how the game felt in practice, it was far less effective as a way of validating whether the system was truly balanced. Each session required time, and the natural variability between runs made it difficult to distinguish between meaningful improvements and simple randomness.
At a certain point, it became clear that observation alone would not be sufficient. If the goal was to understand how the system behaved more broadly, a different approach was needed.
Translating the game into code
The next step was to represent the game in code.
This built on earlier work, where a simple tool had already been created to randomise card combinations and speed up experimentation. From there, the rules were gradually implemented in a structured way, first as a basic console application and later as a more complete simulation tool.
The intention was not to create a digital version of the game for players, but to establish a controlled environment where the behaviour of the game could be tested repeatedly and consistently
Automating the game
Adrian approached the next step in a practical way, by writing a program to automate gameplay.
The first step was implementing the game engine and loading all designed cards (initially text-only). This made it possible to play the game on a computer with proper randomness. The tool evolved gradually. It started as a simple console application, and with a bit of “vibe coding”, was extended into a basic desktop app. Adding full visuals proved more challenging, so the focus remained on functionality rather than presentation.
The real value of the tool was not in playing the game visually, but in enabling repeated runs with full logs of actions and decisions. This made it significantly easier to test different configurations and understand how the game behaved.
Automating testing at scale
Manual playtesting made it clear that running enough games to observe meaningful patterns would take too much time. To address this, Adrian extended the tool to automate gameplay.
The system could run N number of games and calculate key metrics such as:
- number of wins and losses
- average number of turns
- average reputation at the end of the game
Early experiments showed that running 100 simulations still produced too much variance between results. Increasing the number of runs was necessary to stabilise the outcomes. In practice, around 10,000 simulations provided a consistent baseline.
To make this work, it was also necessary to implement different player strategies within the simulation, rather than relying on a single deterministic approach.
Parameterising the design
With simulation in place, the design process became more systematic. Key elements of the game were treated as parameters:
- number of turns
- starting conditions
- cards drawn per turn
- limits on defensive actions
- distribution of attacks and protections
This made it possible to isolate variables and observe their impact. A single parameter could be adjusted, the simulation rerun, and the effect measured across thousands of games.
The process moved from intuition-driven adjustments to controlled experimentation.
Extending the model: introducing “Shift Left”
Once the system was stable, it became possible to explore extensions without changing the core mechanics. One such extension was the introduction of a “Shift Left” mode.
The intention was to bring decision-making earlier in the process, encouraging players to anticipate vulnerabilities rather than simply react to them. This reflects real-world security practices, where identifying issues earlier reduces downstream impact.
From a design perspective, this was achieved by adjusting parameters and gameplay emphasis rather than introducing entirely new mechanics. The same underlying system could support a different way of thinking.
From idea to engineering
The development of Security Architects shows how a relatively simple concept can evolve into a structured system. What began as an idea progressed through prototyping, balancing, modelling, and simulation. Each stage introduced a different level of rigour, gradually moving from intuition towards measurable behaviour.
The introduction of automation marked a clear shift. Game design became, in part, an engineering problem, one that could be explored through data rather than guesswork alone.
Closing the journey
By the end of this process, Security Architects had been shaped into a game that behaves consistently while still allowing for variability and discovery. The combination of experimentation, simulation, and refinement made it possible to move from concept to a game that can be reliably played and explored. And now, after all that work, it is ready to be experienced!
