The idea didn’t start as a game
The idea behind Security Architects didn’t begin with a finished game in mind. For a long time, the initial thought was much simpler: a set of educational cards explaining security concepts - attacks, protections, terminology. Useful, perhaps, but something was missing.
It wasn't a game. There was no tension, no decisions to make, no reason to come back and interact with them again. And without that, the learning would always stay on the surface. That realisation marked the turning point. If this was going to work, it needed to be engaging.
The real problem: learning security without making it exclusive
The core challenge wasn’t just how to teach security concepts. It was how to make them approachable. Adrian Sroka and Monika Skoczylas-Sroka didn’t want to create another Elevation of Privilege game, designed explicitly for formal threat modelling sessions. Those tools are valuable, but they’re not for everyone.
The goal here was different:
- A game that non-security professionals could enjoy
- A game playable in a coffee break, not only in workshops
- A game simple enough that children could play it too
If someone could sit down, start playing quickly, and gradually absorb security thinking without realising they were “learning”, that would be a win.
Choosing the right learning goal
With those principles in mind, the first real design decision was educational, not mechanical.
The game needed to expose players to:
- Common attack types
- Practical protections
- How those interact in real systems
But it had to do this without turning into a rigid modelling exercise.
That meant choosing a framework that was well understood, simple enough to explain and flexible enough to support gameplay. STRIDE became the obvious choice, a familiar threat categorisation model that could be simplified and embedded into the game without players needing to know the theory behind it. This decision quietly shaped everything that followed.
Why simplicity mattered more than realism
Another strong constraint guided the early design: mechanics had to be easy. Not because complexity is bad, but because complexity gets in the way of play.
The game needed to: be explainable in minutes, avoid thick rulebooks and make interactions visible on the cards themselves. That requirement ruled out many otherwise interesting ideas. Some early formats were explored and abandoned. Others were noted for “maybe later”.
Eventually, a simple attack–protection structure emerged as the backbone of the game. It was intuitive. It scaled well. And most importantly, it felt like a game.
From intention to reality
At that point, Security Architects finally had something it hadn’t had before.
There was a clear educational purpose, but without being limited to security specialists. The mechanics were simple enough to be approachable and genuinely playable, while still supporting meaningful learning in the background. Most importantly, the structure allowed education and fun to reinforce each other rather than compete. That was the moment the idea stopped being “some cards” and became a game worth building.
And it was only the beginning.
In the next part of the journey, we’ll look at how this idea was turned into a physical prototype, using nothing more than scissors, pens, and coloured paper, and why rough, hands-on testing turned out to be one of the most important design decisions of all.
