RootSpace

I’ve wanted to build a game engine for years.

In fact, I’ve attempted quite a few games and engines, going right back to my teenage programming adventures. Like so many solo developers, most eventually stalled somewhere between the initial excitement, increasingly ambitious ideas and the rather inconvenient amount of work involved in actually finishing a game.

I’m also fairly terrible at art, which doesn’t help.

What has always fascinated me, though, is the machinery underneath a game. The systems that make a world function, the interactions between its components, and the unexpected things that happen when you put enough of them together.

I’ve written a little more about my background and how I ended up spending so much time tinkering with computers in Why CaretC…?.

The engine I’ve had in my head

For years I’ve kept returning to an idea for a heavily content-driven, entity-component-system (ECS)-inspired simulation engine. Something built around small, reusable components that could be combined into increasingly complex assemblies, with those assemblies themselves becoming components of something larger.

I like the idea that the engine wouldn’t necessarily need to understand every detail of the things it simulated. Instead, people with specialist knowledge could build those details into the content.

Want to model a particular piece of industrial equipment down to its individual subsystems? Go for it. Want to approximate the same equipment with a handful of simple behaviours? That should be possible too.

Lua scripting could provide a way to extend and modify those behaviours without constantly changing the engine itself. I love the thought of giving someone who really understands a particular system the tools to go completely mad with the detail.

Of course, there’s quite a difference between imagining an engine like that and actually building one.

Why industrial systems?

Well, they’re what I know.

My background has wandered through electrical engineering, industrial control, software development and cybersecurity. Along the way I’ve encountered plenty of systems that are fascinating precisely because they aren’t neat, clean or particularly consistent.

Real industrial environments accumulate history.

Equipment gets replaced in stages. Networks evolve around systems that nobody wants to switch off. Temporary workarounds become permanent. Documentation goes missing or simply stops reflecting reality. A piece of equipment might be doing something strange for a very good reason that nobody working there today quite remembers.

There’s a sort of industrial detritus that builds up over decades.

And I find that rather interesting.

I’ve wondered whether a simulation could reproduce some of that accumulated complexity. Not by manually scattering broken machines around a virtual factory, but by allowing a world to develop its own history through the interactions of its systems and the decisions made by the people operating them.

This is where the game-engine ideas start to overlap with my interests in industrial control and cybersecurity.

People are part of the system

One of the ideas that excites me most is something I’ve been calling actors.

I don’t want an industrial world where equipment simply changes state because a script says it should. I’d like to explore simulated people with responsibilities, knowledge, priorities and motivations.

Perhaps an engineer changes a configuration because they’re trying to solve a problem. An operator ignores a troublesome alarm because experience has taught them it’s unreliable. A contractor installs a temporary network connection that nobody remembers to remove.

Individually, those decisions might be perfectly understandable.

Years later, their consequences could be rather interesting.

But I also want to explore actors operating on much longer timescales. What would a patient, well-resourced adversary look like in such a world? Perhaps something resembling a state-sponsored campaign, with objectives unfolding over years rather than minutes. Such an actor might observe an environment, adapt to changes and wait for opportunities, while ordinary life at the site continues around them.

Engineers perform maintenance. Operators change shifts. Equipment fails. Infrastructure evolves. Perfectly innocent decisions change the circumstances for everybody else.

Then there’s the question of time.

Could I generate ten years of simulated industrial history in a few hours?

Not ten years of randomly generated log entries, but a world in which systems and actors have interacted across a decade of simulated time. A world with accumulated changes, decisions, incidents, relationships and consequences.

Imagine investigating something that happened in year nine. An investigator would have whatever evidence they could reasonably find, while the simulation itself might know the complete underlying history: what happened, who did it, what they knew and what they were trying to achieve.

Of course, making time pass quickly is not the same thing as making ten years of behaviour believable. Whether actors could make meaningful decisions, remember enough of their histories and produce coherent consequences is a rather large unanswered question.

But goodness, I’d like to try.

What could it be useful for?

The first fairly obvious application is cybersecurity training, particularly industrial capture-the-flag (CTF) environments.

There’s an interesting distinction between finding something wrong in an environment designed to contain vulnerabilities and investigating a system where something unusual might be entirely legitimate.

A RootSpace CTF could contain old equipment, unusual configurations, undocumented services, questionable maintenance decisions and all that accumulated industrial detritus. Some of those things might be vulnerabilities. Some might be evidence of malicious activity. Others might be completely harmless.

The challenge becomes understanding the environment rather than simply finding the deliberately broken thing.

Industrial operator training is another possibility. A simulated process could expose operators to abnormal conditions, equipment failures, misleading instrument readings or the consequences of different decisions without putting a real plant at risk.

And then there’s an idea I find particularly intriguing: synthetic AI training and evaluation data.

A labelled dataset might tell you that an event was normal, malicious or indicative of a fault. But what if the world generating the data also knew the circumstances behind it?

Not just what changed, but who changed it, what information they had, what they believed they were doing, and what happened afterwards. Two events might look nearly identical in a log and yet have very different explanations.

I wonder whether data with that sort of causal context could be useful for training or evaluating systems that need to reason about intent and consequences rather than simply recognise patterns. Whether simulated motivations would be realistic enough to make useful data is, of course, another question entirely.

So, why bother?

I’m not entirely sure.

Some days I think RootSpace is an amazing idea. Other days I wonder whether it’s an extraordinarily elaborate solution to a problem that doesn’t really need solving.

I can imagine it becoming a useful industrial training environment. I can imagine it generating fascinating datasets for research. I can also imagine disappearing down a rabbit hole of simulation architecture and emerging years later with a very sophisticated model of a pump that nobody particularly wanted.

But I keep coming back to it.

I’ve been thinking about variations of this engine for years, and there’s something about combining simulation, industrial engineering, cybersecurity, people and emergent behaviour that I find difficult to leave alone.

Perhaps it’ll turn into something genuinely useful. Perhaps it won’t.

I think I want to find out.

And for now, that’s reason enough to bother.

---

The source code and technical documentation live in the RootSpace GitHub repository (currently private). I’ll use CaretC to write about the ideas, experiments, decisions and inevitable mistakes along the way.