Roots of a Kingdom is a colony-building game inspired by classic games like Gnomoria, RimWorld and Dwarf Fortress. Mine deep into a procedurally generated world, grow your own food, craft hundreds of items, build workshops and defenses, trade with neighboring kingdoms, and keep your gnomes alive through changing seasons and nightly threats.

The game: https://magetec.itch.io/roots-of-a-kingdom-kickstarter-demo

The campaign: https://www.kickstarter.com/projects/magetec/roots-of-a-kingdom?tab=prelaunch-up...

Steam: _pending_

Youtube: https://www.youtube.com/@RootsOfAKingdom

BlueSky: https://bsky.app/profile/rootsofakingdom.bsky.social

What happened so far / Game design (History...):  

Back in August of 2025 i began working on a small prototype of a colony sim by drawing yellow dots onto green sqares on a simple grid. After a few hours those green dots moved arround and took blue quares into black holes. 

Working full time as project engineer and programmer for a large company i am familiar with setting up projects and developing not just programs but the full lifecycle of a product. Therefore i began making my plans on what i would imagine a colony sim to look like. And with every idea, with every thought i came closer to the games i played - like most of us do, when they start building something. I was inspired by those classics like Rimworld, Gnomoria and so on.. 

With that evolving plan I also had to make my first decisions on the look and feel of what i was going to create. Top down like Rimworld? Isometric like Gnomoria? Maybe directly going the 3D route? Pixellated? Sprites? Nice and simple drawn graphics like, for example, the Ultima series had? And what about the world? What about... 

So i spent days writing up ideas rather than programming but when i was done i had the basics on what i wanted to create.

An isometrics multi level pixellated colony builder with sprites and animations on a procedural, basically endless terrain..  The game should be sandbox.. but also should have winning conditions, it should get a high complexity but a low bar to start playing and hopefully enjoying.

Or shorter: I wanted to create a good game. What a surprise. 

Now with everything written down i went back to the technical stuff. Constraining myself right at the beginning by choosing the wrong engine or an obscure programming language would have been a death blow to a game later on: We all know that noone likes redoing everything just because an engine has to be changed... well... most of us. I am old enough to remember waiting for Duke Nukem Forever and Daikatana ;) 

Technical Stuff: 

Godot? Unity? Well... i played arround with Unity for ages but never really liked it enough to consider doing something serious with it. Godot is an excellent piece of software. You wouldnt believe how many HMIs in the german concrete industry are now running on GodotC#. But... i like coding. Plain and simple. Also... some things i had in mind are challanging to do with Godot (at least for me). So i went with the obvious path: 

Using https://ebitengine.org/ with my favorite programming language of the decade: GO.

Why using GO? 

Go has a nice syntax, allows creating a lot of stuff quite easily that other languages take way longer build (Ever tried to create a websockets enabled http server with C?). Also.. it is dead fast on compiling, allows cross compiling and has multithredding under its hood - especially useful when simulating a lot of entities..) 

What is Ebitengine? 

A great 2D Engine for Go. It took me maybe a day or two to get into it and start working on Roots.. I can only recommend it everyone to try it. 

In a way using this combination feels as easy as creating a python prototype software and as sturdy and performant as using C++.  In other words: It is just great.

Graphics and AI usage:

I used to create pixel art ages ago.. really... ages. Back in the find days of using Quick- and DarkBasic for games. So... very long ago. And although i can and still do that i tend rather to spend my time writing the game rather than nudging single pixel through multiple frames. That is why i chose to use Pixellab to assist me in creating assets during this early development stages. It makes a huge difference to just use a few minutes for an entire animation sequence rather than hours on it - especially while creating the code to use this animation.  But... despite its usefullness it is inconsistent in quality and style and feelswrong to keep using. That is why i want to phase out AI generated stuff by the end of development. 

Organisatory decisions: 

I am currently creating a kickstarter campaign. Lets be honest. The game is developed while i work 50hrs a week on my dayjob and some more thanks to be self employed. So.. what i need is time off to finishe everything and buy some assets. So.. I'd rather find people who want to support the game in the early stages rather than hope for people buying it in half a year or so. 
That is also why i created my Itch page and keep uploading demos of the current version. Once the kickstarter campaign is running and hopefully concluded with the project being fully backed i am going to start enrolling the game (also) to Steam. I think about releasing a DRM-free version here as well.. but i have not yet decided on doing this. 

With all that.. I'll keep you updated :)

Current state: 

Although i was prpgramming in pretty much every higher level language since the early 90s I have very much switched to PLC programming in the past years. With that change i had to unlearn a lot of stuff i have done in the years before and completely rethink testing and verifying.

Since most people here are not familiar with PLC/RealTime programming, even though hardware like the Arduino and the countless ESP boards might have brought that to hobbyists.. but thanks to the Arduino team this hardware can, and in most circumstances is, programmed like any piece of software for the PC.

Anyway... in real time programming your code has to follow a "flow" from start to finish. You normally dont react to events, you basically have no parallelism and whatever you do the code should be deterministic. That means - if you ever have to stop the execution of the code you have to be able to fully understand how you got to that point and predict how it goes on from there. Therefore a lot of programs for PLCs are built in the simple sceme (Pseudocode)

void main()
{
int[] all_my_variables;
 while(true){
  readallinputs();
  dothelogic();
  writealloutputs();
 }
}

There is very little branching. Most of code is organised into step sequences. Branching is most of time not in use at all.

So..

Why do i write this?

In normal programming people tend to use very little testing. Unit tests are pretty common these days and using languages like my beloved GO make it very easy to use them.. but there is only so much unit testing can do for you. You can check if certain functions return exactly the result you expect for a given set of parameters and while that is sufficient to test that single function your program may still misbehave because the expected result may not be what you need as parameter for the next function and so on.. Dont get me wrong. I love unit testing.. as far as i can tell RoaK has basically no function that is not unit tested but this is not an overall picture.

To those who still read this post.. PLC programming is mostly dont to program physical machines.. and now imagine a large manipulator - a crane - strong enough to lift a few metric tons of steel and concrete while moving 50mm/s and people working close by. You dont want to rely on unit tests only if you could endanger people. if you divide by 0 in a program you end up crashing it. If you divide by 0 on a plc and the plc is crashing you may end up destroying costly equipment and harming real humans. As a nice reminder: The unfortunate and costly fireworks at the first launch auf Ariane5 was basically a variable casting error..

So how can you test a program end-to-end without the fear of doing something very wrong? You simulate it.

For our machines we have simulation tools to fully simulate all sensors and actors and make sure that with any given set varables the code executes the way you want.

Why would that be of interest to game programming?

In a way we can automate quite a lot in our games as well.. we can simulate inputs and see the outcomes on screen. For RoaK i use this extensively. I have a hand full of maps, of scenes i build on the "Green acres" and saved them in a known state. As it is pretty simple to do so on a city builder i have also added a rigged camera that moves along a known path and toggle actions as if i was using my mouse. That way i can precisely see an ingame scene and see if i have introduced game breaking changes. That is why my "PreAlpha" Videos always show basically the same sequence.. just with changing content. Sometimes there are more workbenches, sometimes you will notice lighting changes and so on..

But if i cant make it through this short sequence because some major screwup happens I know something bad has happened in the code.

I know that was a lot of writing for a simple statement on how i test my stuff.. but since this board should not have all too many PLC programmers i wanted to share the reasoning behind my design choices and maybe someone here might find it enlightening and useful that there is this approach.

Some evolution of the same sequence: 

0.1.0:

0.2.0:

0.2.5:

On the Evolution of the brain.. the Gnomes brain.

Before I started to work as programmer I studied paleontology. No joke here.. I was one of those guys who are said to use a toothbrush in the desert to scoop up some old bones.. yet in my case it was a large motorized saw with a blade to cut into stone and mostly very very old trees. 
Anyway.. evolution is still one of my favorite topcs and sometimes a game can be closer to live than you'd expect. 

In this case we can talk about a gnomes brain. 

The proto Gnome, barely "alive" enough to have a single need: hunger has to do nothing more than Eat, find food, sleep and maybe dig into rocks....
Therefore the "Brain" looks quite simple:

As you can see the Protognome has only a very limited set of rules working a single job on demand and otherwise either idle, eat or sleep. A perfect member of society ;) 

A few months later, lets say in the "Hunter & Gatherer" phase of my Gnomes evolution their brain has heavily developed: 

Instead of just fighting for survival we now have several jobs and no longer "rules" but priorities. Survival always has a higher priority than finishing work (yeah.. no longer the perfect member of society..) but if possible work has to be finished first anyway.  Job scheduling is handled outside the brain through the player that can assign certain priorities based on a Gnomes profession:

This way the player can somewhat control the way jobs are handled without meddling with the brain of each gnome seperately. 

Keen eyes may have spotted that, also, i no longer update the brain on each tick but 60x a second. This is a performance imporvement and also allows the scene to fully "settle" before another choice is made. 

Now in the medieval stage where i currently work with them only minor changes came up:

There is the minor refinement of adding a "distance penalty" to jobs. If jobs have the same priority (see, for example the All-Rounder) the closest job is what a Gnome will take. This prevents, for example, hauling jobs that happen dozens of tiles away while mining on the next Tile is marked as a job. And the major change is the "interrupt" system allowing me to "interrupt" whatever a gnome is doing each "brain tick". A sleeping gnome, without interrupts, might be eaten by a wolf or a crafting Gnome wouldnt notice that he is starving to death.. so interrupts are important to keep things somewhat sane.

Well.. let us see where evolution leads the little Gnomes next.

Hi there, 

After spending yesterday with the brain salad surgery of my gnomes i was doing some polishing work today. Sometimes you need to change hard stuff to "feelgood" tasks from time to time. Although it is, i think, too early to polish stuff, it was now good to plan the next things and make the overall look and feel nicer. 

So.. today i spent some time on make the world more "alive". While make things run arround on a grid is simple and having "idle" animations for entities is not bad things can pretty sterile. 

So.. with some image manipulation you can achieve quite a lot.. 

Basically you can slice a sprite and move those slices indipendendly.. this creates the illusion of "wind" if you do that for plants.. and it is quite cheap to achieve (CPU/GPU). 

Please dont mind the black area.. i have no idea what the driver or wayland update changed.. but i cant focus on a single window at the moment.. 

Also... the game already has had some sort of a light/darkness system. I basically share the same system for the "fog of war" and figured it would be easy to add "fire" to the game lighing up areas.. and when there is fire there should be smoke... so...

I render at the places where "fire" happens just some smoke particles (Note: No particle system.. i just draw a fixed sequence of white circles of various transparency values).

Last but not least i was able to finally give the mechanism System a major push by overengineering the whole thing. In the factories i program i have to define circuits, literally and methaphorcally. A circuit can be a PCB with bird seeds and chips on it.. but also dozens of meters long cables running through a plant containing exactly one signal (or network connection) from one source to one machine. At times you have to add junctions, some times you have to bridge over other cables. You have to distribute things and combine signals... and i really cant let go of my dayjob there. 

So at this point i have to decide how far i want to go: Is it ok to do everything that, for example, Gnomoria did... or will i face a possible future that has someone in store that is going to run Doom on my poorly animated mechanisms? 

We will see....