Share this project


Share this project

A simulation-based settlement-building strategy/management game set in a fantasy world, for PC, Mac and Linux.
A simulation-based settlement-building strategy/management game set in a fantasy world, for PC, Mac and Linux.
1,247 backers pledged £21,650 to help bring this project to life.

Recent updates


A55de2d3b1732aa98739b577632993de original.png?ixlib=rb 2.1
8517bcff2513a9933ac565fd74effca0 original.png?ixlib=rb 2.1
Ad59c7becb4efdd445acc2467c44bf3e original.png?ixlib=rb 2.1
398826efad5d7bd5159bc9e131aa18ee original.png?ixlib=rb 2.1
C0075b41b6ccc3d82ea86baf30ec693c original.png?ixlib=rb 2.1
C371fe772dc7de24ee15007ba33a0445 original.png?ixlib=rb 2.1

June 2019 Update - Alpha 2.2 Released

Posted by Rocket Jump Technology (Creator)

An ever-so-slightly late update this month (oh no it's July already!), and we're celebrating that Alpha 2.2 has been released. The main feature in this version is that you can now discover giant mushrooms (they're rare, they prefer to hang out in the larger caverns that you can discover in the middle of the mountainous regions) and harvest them as an alternative to lumber/logs from trees.

For now this is mostly just an unusual colour alternative to the kinds of wood you're used to, but in the future as the economy is added, giant mushrooms are very rare and much-prized by the dwarven community, so this will be a particularly valuable resource to export or craft with. Also, different materials will have different properties - perhaps giant mushrooms are softer/springier than normal wood and you might be able to find a use for this (a better material for a bow, perhaps?).

Alpha 2.2 also includes quite a number of small bug fixes and quality of life improvements. Bugs in systems-driven games like this tend to be darkly amusing and one that I quite liked is that previously, dwarves would jump up out of bed the moment they're starving or critically dehydrated. A change in Alpha 2.1 allows dwarves to sleep at least for a while with a life-threatening unmet need like this. The unintended consequence of this was that dwarves could now die while asleep in bed which they wouldn't do before. As this wasn't noticed during development, it's been possible for dwarves to die while in bed and quite literally stay in that bed forever, decaying away to a skeleton as each dwarf is responsible for getting itself out of bed (i.e. there's no job to go and pull a dead body out of a bed). Instead of the grisly task of removing bodies from beds like that, dwarves now fall out of bed when they die as shown in this dev mode video:

The main changes in Alpha 2.2 are those behind the scenes - I've implemented the artifact-based mod loading and parsing as described in last month's dev update. This massively speeds up the time to add and process new assets that make up the base mod, as well as being a future improvement for modders to make use of.

The other main improvement is that until now, when adding sprites to the game I would manually trim the PNG images down to eliminate unneccessary padding/whitespace from the edges and calculate how this would affect the offset of the sprite being rendered in-game. That was an extremely laborious, time-consuming process which I'm sorry to say I spent quite so long on sometimes. Now that I have a good understanding of that process, I've been able to write a simple automated tool which performs the same job, but taking milliseconds rather than minutes of manual effort! This will also form part of a suite of tools modders will be able to use to make it easier to add assets to the game.

The next milestone, Alpha 3, is the modding release. First I'll be tidying up the existing data structures and mod files so there's better (or at least some) consistency in the data files for modders to expect, as well as a general cleanup of unused or incomplete asset files and data. Part of this includes adding the Kickstarter-backer-specified natural resources to the game! I've only received about half of the possible responses to the email for that reward so please do get in touch if you haven't already and you were a Kickstarter or Backerkit backer who had "Add a natural resource" as one of your rewards.

Otherwise, see you next month and thanks for reading this update!

May 2019 Update - How Modding Works

Posted by Rocket Jump Technology (Creator)

Welcome to the update! I had been hoping to show you giant mushrooms (which can be used as an alternate source of lumber) in this update, but it's still not quite ready, though I don't think it can be far away now.

A giant mushroom in the current mod tools - but how big is it?
A giant mushroom in the current mod tools - but how big is it?

Most of the work accomplished this month has been preparing the way for mod support, which is due to make up almost the entirety of Alpha 3. For this monthly dev update, I'm going to go into some detail on what mods in King under the Mountain actually are and how I expect them to work.

The Basics

One of the design goals of King under the Mountain is that it is data-driven, which is that most of the stuff in the game (i.e. items, terrain, jobs, professions, even some AI decision-making) are not "hard-coded" into the game engine but instead loaded in from data files. That could mean binary data like .wav sound effects, .png sprites for characters, items and furniture or, in most cases, a machine-readable text file which provides data to the game but is also easily understoo-editable by humans. In our case we use JSON as it's a bit shorter and more readable then XML, although you lose the safety net of having a strict structure that you get with XML.

If you want to take a look in the /assets directory wherever King under the Mountain is installed, this is where all the game's data files (except player-specific data like saved games) are stored and loaded when the game is launched. You'll find a large selection of .json files containing all sorts of data for the game, music and sound effects, and perhaps most importantly, spritesheets in the "tilesets" directory. The largest and most important is diffuse-entities.png and here's how it looks as of today:

There's a few points of interest in this image. "Diffuse" refers to the fact there's a matching normal-entities.png with the normal-mapped versions of the same set of sprites. You can think of the diffuse images as the colour version, and the normal is alternatively called bump-mapping to make the lighting system work. "Entities" is the term I'm using for things in the game, currently categorised into items, furniture, humanoids and plants (with animals likely to also be part of this list). You can see that some (mostly the different outfits currently in the game) are coloured, while the rest are in greyscale. This is because a lot of the entities are coloured in "on the fly" by the game engine, usually depending on which material they're made out of - the different materials and which colours they are drawn as is specified in the JSON files.

2D games use spritesheets like this, which are all the images in a single image/texture, so that it can be loaded into the memory of the graphics card once and then accessed many, many times to draw different regions to different parts of the screen. Separately loading each sprite as a new texture, drawing it, unloading it from the graphics card and repeating the whole process would just be too slow in most cases.

The above hopefully explains what the assets used by King under the Mountain are. Most computer games ship with assets exactly like this, and a lot of the time they're compressed and/or obfuscated, meaning they're difficult to modify by the player. Usually this is to prevent cheating (particularly for multiplayer games where the integrity of the game's files will be checked by an anti-cheat tool) or just to help protect the developer's artwork and media from those who would copy and distribute it illegally. Still, that usually doesn't deter some fans, who modified (or "modded") game files to change how a game looks or plays, and its out of this that the modding scene was born.

Processing Assets

Most games now embrace modding and provide guides, tools and engine support for mods, and King under the Mountain will be no exception!

Armed with the above knowledge, you could go into the /assets directory and change things to modify the game, and this would indeed work. Modifying the spritesheets would be awkward  but possible, while the JSON files are relatively easy to manipulate. One or two members of the community have already done this in fact. To share their mods with others though, they need to keep and distribute the changes in the assets directory with others.

This works relatively well for when a single person has modded the game, but what if you wanted to add several mods to the game from different sources? You'd have to keep track of which files each mod changes, and attempt to put them all together without causing any conflicts - mods might want to change the same file, say one of the spritesheets, and at that point you'd have to pick one or the other to apply and lose some of the changes from the other, which might have poor or even disastrous results.

This is where mod support comes in. Alongside the /assets directory, there's also a /mods directory in the game location. Currently this will only contain a single directory, "base", which is effectively the source files for what gets processed into /assets. Looking in the "entities" directory, you'll see JSON files defining what types of entities there are, several .png sprites for each of them, and asset descriptors (more JSON files) which describe how the entity sprites should be used.

The sprites for metal plates alongside their JSON descriptor
The sprites for metal plates alongside their JSON descriptor

The different item types and other entity types are processed, and the image files are combined into the relevant spritesheet - coloured sprites into the diffuse spritesheet and the _NORMALS versions into the normals spritesheet. Similar processing happens for everything else in this base mod directory to produce the contents of the assets directory.

Example of the different file structures
Example of the different file structures

The important point here is that the game's data files, everything under /mods/base is treated as a mod itself. The upcoming work is to then allow for other mods to live alongside this which can be layered "on top" of the base mod to add new assets and behaviour, change existing assets or adjust settings and constant variables used by the game. This also solves the problem that would come from directly modifying the assets directory - multiple mods can be used at once and the mod system defines how they interact with each other - either additively providing more content or replacing the settings of previous mods.

Mod "Artifacts"

Until recently, every time a change was made to the game's base mod - that is, whenever I've been adding more assets to the game - the entire /assets directory was deleted and re-created. It was a quick and dirty solution that was perfectly "good enough" throughout the early stages of development. Now that the entities spritesheet is getting quite large (see above) and complex, this has been taking more and more time, eventually becoming a bit of a drain on gamedev time, just waiting for the assets to be processed between minor changes.

The main progress this month has been designing and implementing a much better solution - mod "artifacts". Simply put, an artifact is a single file or group of related files in the assets directory. Each set of entity type descriptors is one artifact, the entity spritesheets are another artifact, the terrain spritesheets yet another artifact and so on. Now, instead of deleting and recreating the entire assets directory, the mod processor checks for any changes in the "source" files (the files in the mods directory which feed in to each particular artifact) and only recreates the artifact if any changes are detected (by running a quick checksum on the contents of all the input files and checking them against what was last processed.

Diagram of single artifact processing
Diagram of single artifact processing

This also extends perfectly into layering mods on top of each other. As new mods are added to an installation of the game, a mod may only be made up of certain artifacts rather than all of them. The mod processor then knows it only needs to process these artifacts, massively speeding up the process of swapping mods in and out of the game. Here's an example of how a mod which only changes the entity and terrain sprites would be applied:

Example of mod layering
Example of mod layering

And that's how mods work in King under the Mountain! As I continue development of mod support, I'll go into detail on how the mods will be packaged and distributed from modders to the larger playerbase. Of course there will also be much more in-depth guides and documentation covering how to add and change game assets. Most likely a wiki site will be launched soon. I'll also be covering the current plans for code mods, in addition to data files as described above, which will allow for all-new in-game functionality.

If modding isn't your thing, then don't worry! There's still a fairly big update coming as part of Alpha 2, wrapping up a lot of player-requested features and some new content additions. I'd hoped to have this released in May but as always, it's been a very busy month! Finally, if you're interested in modding the game or just want to get involved with the community, the best thing to do would be to join the Discord server. See you next month!

April 2019 Update

Posted by Rocket Jump Technology (Creator)

Alpha 2 is upon us! The main feature is that the placeholder production of metal (which was simply and easily turning raw ore into metal ingots) has been replaced by a more in-depth production chain. Raw, mined metallic ore needs crushing down to remove the useless stone and get to the usable ore. This is then smelted at a bloomery furnace into a "bloom", following how iron was historically produced before modern mass-production. The bloom is then hammered by a smith into usable metal, which can be worked into its final form. This update also introduces fuel in the form of coke (refined from coal) and charcoal (produced at a charcoal clamp using wooden logs).

Alpha 2 also includes the most-requested feature by players - a screen to view and manage all of your dwarves! This was teased in last month's update but it has now been released, head on over to to download Alpha 2 if you already have a copy of the game, or purchase it if not! It's still early days for the user interface (I'm treating the whole thing as a placeholder) but this work solved some of the problems of dealing with the UI (most importantly a way to draw entities like the settlers as interface components) so expect more to follow - perhaps most importantly a screen to manually organise crafting and production so that the player has direct control of what is being created!

Following the "add a natural resource" reward emails which were sent out previously (please do get back to me if you've received one and not responded yet, or if you think you should receive one and don't remember seeing anything), more recently emails have been sent out for the "Add an animal species" and "Design a farmable crop" rewards. In the end there were only 8 of the former and 4 of the latter, with two super-backers covering both! Unlike the "add a natural resource" these will all require custom artwork to be created so I look forward to sharing these in the future.

As it had been so long since the Alpha 1 release, Alpha 2 was actually released early while there was still more content intended for part of this release milestone. First of all, metal plates are to be added as a new intermediate product so that constructing furniture out of metal is a bit more sensible - rather than hammering a few metal ingots together to form an elaborate construction, instead plates will be forged by a blacksmith which are then put together along with other mechanisms to produce some of the machines used by the dwarves (such as the ore crushing station). Expect this to feature more heavily when brewing is added due to the number of metal tanks needed as part of the brewing production chain.

Also on the topic of working with metal - dwarves in King under the Mountain are the only race to know the secrets of producing steel, superior in strength and quality to iron which will be important when different materials have different in-game effects, particularly in combat! Central to this is the crucible furnace, which will be the largest piece of furniture in the game so far, used to convert iron to steel in sizeable quantities.

Long-rumoured to the world of King under the Mountain are giant mushrooms - mushrooms so large, tall and tough that they can be used as an equivalent to trees! A later update will see a visual rework of the game's funghi, but I wanted to have using-giant-mushrooms-as-trees in one of the earlier updates.

With those features added the next major milestone (Alpha 3) will be all about mod support. Modding is an absolutely central pillar to the design of the game and I can't want to see what people are able to come up with once the ability to mod the game is thrown wide open. It's these early days of modding which will shape exactly how mods work and what they look like, so if this is something you're interested in, please get involved (ideally via the Discord server) and help me to add what it is you want to be able to support mods.

March 2019 Update - (Not) Reading from a script

Posted by Rocket Jump Technology (Creator)

It's not released quite yet, but here's a sneak peek at the much-requested Settler Management screen/feature coming in Alpha 2 of King under the Mountain:

Alpha 2 is on the horizon now, potentially including a resource management screen as well as this settler management one. It's taken a lot longer than I'd have liked to be able to go from Alpha 1 to 2 but there's some good news there - I've secured several days in April for development of King under the Mountain and I'm sure we'll see a big jump in progress, and with a pinch of luck, some form of Alpha 2 being released in April.

I forgot to mention that last month saw the start of gathering information for Kickstarter rewards (other than copies of the game), specifically emailing those backers who had one or more natural resources to add to the game. If you think you should have a "pick a natural resource" Kickstarter (or BackerKit pre-order) reward, you should have received an email asking you for the details of this. Try searching for the subject "Claim your pick a resource reward for King under the Mountain" in your inbox or spam folder. It's now over a month since these were sent out but only 47 resources out of a total 169 have been received so far, so please get in touch with me at if you think you should have this and can't find it.

After Alpha 2 is released, the big focus for Alpha 3 will be to enable modding in King under the Mountain. Since the early days of the project, making as much of the game data-driven has been a key goal. This means that things like items, plants, resources and so on are all defined in (JSON format) data files that are loaded and used by the game. The majority of these reference .PNG image files which are also loaded and used to make up what you see when you play the game, or .wav or .ogg audio files for sound effects. Most games combine these "assets" into compressed or obfuscated packages to make the download size of the game smaller but also so they can't be easily modified by users. Instead, King under the Mountain plainly exposes its assets (take a look in /mods/base in the game directory if you're curious) so modders can see how things work to add their own.

This works for adding new things to the game with different values and assets, but doesn't cover adding new functionality to the game, which require the game code to be modified in some way. This month I spent some time investigating this. Initially I was planning to add some kind of scripting engine using a language like Python or Javascript, which would open up the game to small scripts of code to be run. I was worried about the performance of this (although there's quite good options for running snippets of these languages in Java) but also how it would expose the classes and functions used in the core engine for these scripts to make use of. In the end I settled on a different approach, very similar to the one used by Rimworld, where small libraries of additional Java code (the language the game is written in) can be loaded and used by the main game. The main benefit of this is that modders will be able to write code mods that make use of the entire codebase of King under the Mountain, albeit in a controlled manner where certain new classes can be added, rather than just letting a mod change any code within the game.

The way the AI works is heavily inspired by this post by the Starmancer devs, where I have a system of Goals made up of Actions. The Goals are JSON files (look in /mods/base/ai/goals) which are made up of a set of selectors to determine when a settler chooses to select the goal to complete, and a set of Actions which are Java classes used to fulfil a certain, well, action, with a success or failure state. Until now it would only have been possible to add mods implementing new Goals using only the existing Actions. As a test case I had the game load in a new Action from a mod and use this instead, which proved modders will be able to add their own AI steps to the game as well as overall goals. The same can be implemented for basically anything that has a range of different implementations rather than just data values, such as different job types and their effect on the world, and hopefully going as far as new UI screens and views possible in mods. I'm really excited to see what people will be able to come up with in mods and I'll have a lot more to say on this (and guides!) in the near future. I'm sure it'll be an evolving process as some things that I've not really considered might not be possible to mod yet, but I'd be able to open it up as the modding community makes requests.

So it's another relatively short update for the month. Again, I'm very sorry at the lack of tangible progress since Alpha 1 was released but I'm fully committed to breaking through that wall and getting the next major build to you guys soon. If you're already playing the game and haven't joined already, we have a friendly discord server at and if you're just discovering this game for the first time now, you should head on over to and grab a copy of the game while its still in earliest access! Itch purchases will include a Steam key when the game is ready to move on to Steam.

February 2019 Update - The road goes ever onwards

Posted by Rocket Jump Technology (Creator)

February was a quieter month after the hectic buildup (and aftermath) of the Alpha 1 launch. The main part of development was fixing bugs that became apparent with the much bigger playerbase (nearly all fixed now) and re-organising the roadmap based on player feedback. By far the most common piece of feedback is that players are desperately missing a way to keep track of all their dwarves through some kind of management screen so that has been bumped up the priority list to the top!

Until yesterday, the amount of exposure generated by the alpha launch was very disappointing. Very few gaming new sites picked up the story (thanks GamingOnLinux!) and most (but not all) youtubers who covered the game previously haven't picked it up again with the alpha release - I assume because there isn't a huge amount of extra content compared to the pre-alpha builds. The revenue brought in by the launch is very little (averaging around 1 sale per day) which should be expected really, especially without any major sites mentioning the game yet. Oh and many more of those sales than I would have expected include a tip, so thank you very much! Things are looking up a little with an article yesterday on Rock, Paper, Shotgun which I think it a tough but fair preview based on how early in development the game still is.

All in all, it's not the boost to development finances I had hoped for. Still, the way I'm developing the game is prepared for that. The Kickstarter funding allowed me to fully focus on development as well as commission new artwork and sound effects for a few months to get the game to Alpha 1, but that has all been used up now. This month I've had to go back to software development contracting full time which does not leave anywhere near as much time for gamedev unfortunately. This is not a permanent situation though, I'll need to continue this way for a short while as I stretched the budget beyond breaking and need to build up more funds. After that I'm planning to split my time into a healthy balance between gamedev and contract work, which should give some good results.

This does not in any way mean development is stopping, I'm fully committed to bringing this game through to completion. I thought I'd explain why things have been a bit slower this month and how I'm tackling it, as I've always been open and honest about the development process. Making indie games is a super tough business, and only the top 1% of titles break out into being a profitable success. I plan to get there eventually, I think where the game is now is still a bit early to find that breakthrough to a bigger audience, so I'll just keep striving forwards until it gets there!