King under the Mountain

September 2019 Update
over 4 years ago – Tue, Oct 01, 2019 at 02:49:13 AM

Welcome to the September update! A bit of a short one this month because A) August was late so it's not been quite as long since the last update, and B) it's been one of those months where there isn't any particularly visual or even interesting progress! So what has been happening? The main body of work has been adding new resources to the game - those chosen by Kickstarter backers as part of their rewards. Although there was an email survey sent out several months ago, only around 50% of backers eligible for this reward have responded, so if you're in the other half who have not got back to me yet, search your email inbox for "Claim your pick a resource reward for King under the Mountain" and get that response in soon to avoid missing out!

Past that, I'm still laying the (huge piles of) groundwork for mod support. It's the kind of task that requires lot of fairly dull legwork until the big bang at the end when everything comes together.

In other news, this month saw the release of Overland (at least on consoles) which is a game I've enjoyed following the progress of although I've not yet found the time to play the thing. I mention this because there were several news stories around the fact that it includes the OpenDyslexic font as an option to replace the game's default font, and coming off the back of last month's update all about fonts it really stood out to me.

Until these news articles appeared I had no idea that there was such a thing as a font that can be more legible to people who suffer with dyslexia and it quite rightly garnered some praise. Having just swapped out the font in King under the Mountain, it occurred to me that this will make a perfect test case for an example mod that could come supplied with the base game.

So when mod support does finally drop, you can look forward to this as an example of a simple mod coming bundled with the game, with the bonus of including the OpenDyslexic font for those who prefer it!

Finally there's some very good news on the horizon - I'm in a position where I'm going to be able to change from trying to fit game development around a full-time 5-days-a-week day job, and instead I'm going to move to a 4-day working week, simply cutting down on the contract work that keeps the lights on to be able to dedicate a full day a week to development of King under the Mountain. Progress has been pretty slow for the last few months, which I'm deeply sorry for and is a source of much personal frustration. Fortunately, you can expect to see things kick up a notch in the near future and bring us closer to release!

See you next month!

August 2019 Update
over 4 years ago – Fri, Sep 13, 2019 at 12:39:21 AM

Welcome to the (late) August update for King under the Mountain! Apologies for the lateness of this, August was a crazily busy month personally, but I thought it still worth putting out a delayed dev update rather than nothing at all until the end of September.

The good news is that tooltips for nearly everything in the game have now all been implemented (thousands of words in total!) and there's a new alpha build (Alpha 2.6) available on the Itch.io page for all current and future owners to get hold of with these tooltips in. As well as providing some super useful information to the player (especially to explain what a pillar actually does), this is also the start of background lore in the world of King under the Mountain with references to the magic system and the world at large.

Now that there's larger sections of text in the game, it really started to highlight the issues with the font currently in use. King under the Mountain is built using LibGDX, a gamedev application framework that works as a fairly high level API over graphics (OpenGL) and sound (OpenAL) and other things such as input devices, but it is not a full game engine like Unity or Unreal. Instead, for example, it gives you commands to load images from a file as a texture, or draw those textures to the screen, or play a sound from an audio file. Everything on top of that is written by game developers so you don't see as much similarity as you do with some games using Unity - not that that's a good or bad thing! Slay the Spire is an amazing game also written in LibGDX, and it plays very differently to King under the Mountain! When it comes to text drawn on screen, LibGDX works with glyphs in a sprite sheet that it then renders to the screen, in exactly the same way other images are drawn to the screen from spritesheets. If you don't supply your own font image, you get the LibGDX default which is Arial in 15 point and looks like this:

Early on I decided I didn't want the absolute default to at least differentiate the game from other basic LibGDX projects, so I decided to use Google's Roboto font, mostly because it's designed to be clear and readable, but more importantly that it was also released under a permissive license - most fonts have restrictions around their licensing.

However, armed with the Roboto font file, it needed turning into a spritesheet of glyphs similar to the above. One of the several tools LibGDX provides is a tool called Hiero which performs this task. Running that with the Roboto font file produces the following (actually done for several different font sizes):

Note the greatly expanded set of characters to the above, this is to include cyrllic characters to support languages such as Russian.

That was all fine for a while, but it became apparent that the spacing around some letters (the "kerning") was a bit off, leading to weird gaps in some blocks of text as you can see here:

It's subtle, but the letter "e" tends to not have enough space around it, while the "a" has too much space in most cases. This has really bothered me for a long time and makes the game feel lower quality in my opinion. I put this down to a quirk of either the Heiro tool and/or the Roboto font and decided I'd replace it at some point in the future, because there was another problem I wanted to tackle...

Creating a spritesheet of glyphs is fine for the number of characters shown above, but as someone who knows a little Japanese, I really wanted to be able to include the main East Asian languages - Japanese, Korean and Chinese. The Korean language with only 24 characters in Hangul would be fine to add, but Chinese with potentially thousands of characters, and Japanese also using these alongside hiragana and katakana would potentially be too much to include depending on the size of the font and the max texture size allowed on any given graphics card. As an aside, games in 2019 and onwards can probably safely rely on a max texture size of 4096px in both dimensions or even 8192px, depending on how old the hardware that a game wants to support is, so this may be a non-issue by the time of release.

This problem of supporting East Asian languages in LibGDX is often discussed with several possible solutions. Most rely on the fact that there is an extension to LibGDX (gdx-freetype) that generates font bitmaps on the fly from font files, rather than the developer providing a pre-generated bitmap image like the above. From there you can either just generate the snippets of text that you need at any given time, or perhaps generate a spritesheet with all the characters your game is ever going to use but crucially not the entire set of Chinese characters that exist.

While I was improving the tooltips from what you can see in last month's video (for example, improving the way they break over multiple lines and tidying up whitespace around them), I thought it was a good time to finally try to improve the game's font too, now that there were larger sections of text which was really highlighting the kerning problem. Coupled with the desire to get East Asian fonts working, I switched from Google's Roboto font to Google's Noto font family as the latter aims to cover all unicode characters. Having added quite a large body of text to the game's translation files, I figured I could calculate all the unique characters across every language and generate a font bitmap from these using the gdx-freetype extension to get closer to using the actual font rather than the pre-generated bitmap from Hiero.

In something of a happy accident, this led to a much clearer looking font with massively improved kerning:

Look how smooth the kerning and font itself is in "dwarven woodcutter" now! The light blue also denotes that you can hover over it for a tooltip, actually separate tooltips for "dwarven" and "woodcutter".

It doesn't look like much has changed in the UI but adding tooltips was actually a massive change to the way all text is handled in the game, and the main reason this took so long to get done alongside the large amount of words that needed adding.  Instead of simple strings of characters, every section of text is now broken into sections which can have their own independent tooltips, which is what we see here for the dwarf's description text. Those tooltips themselves draw more of this text which can have further tooltips, and so on from there. It also handles and inserts line breaks which is an incredibly basic feature of displaying text but something that I had to build on top of what LibGDX already does! I'm quite proud that the tooltip is neatly tied into different classes of each word that can be translated and replaced into other text, for example the noun, adjective and plural of "dwarf", "dwarven" and "dwarves" would all share the same tooltip, and this tooltip would be applied to any text where this "single" word has been replaced.

This also means that with a slight swap of the default Noto font to one of the Noto font files that includes Chinese and Japanese, I was able to prove that, finally, these languages can work in the game (despite LibGDX making it slightly difficult)!

Now that all of this is accomplished, and the tooltips are in place, the game is in a good place to be opened up to supporting other languages. Alpha 3 is all about modding practically everything in the game, but I'm going to focus on translation support initially as there's been quite a bit of interest and offers of help from the community with translations.

This month marks one year since the Kickstarter campaign was completed successfully, and while I'm sometimes frustrated by what feels like slow progress month-to-month, the game has developed massively since the pre-alpha that was available alongside the Kickstarter, right through to being released in Early Access on Itch.io and now heading towards a more polished, fully-featured Steam Early Access release! On that front, I've recently updated the Steam store page to be marked as "coming soon" in 2020 rather than 2019. I'm very sorry to push back any dates that have already been written down like this. The roadmap still has quite a way to go before I think the game is ready for the Steam audience, but I'm fully committed to getting it there in 2020 rather than any further delays!

And with that I'll leave for a few more weeks until the September update, where I'll get into more detail on how translations are actually going to work, and if you want to, how you can get involved and help out with them!

July 2019 Update
over 4 years ago – Fri, Aug 02, 2019 at 03:11:14 AM

 Welcome to the monthly update! With Alpha 2 effectively out of the way (though as always there's some small bugs still to look into), the focus now is on Alpha 3, which means mod support! As a precursor to this though, I've been working on a tooltip system. I think this is going to really improve the new player experience by explaining how things work which is a bit of a sticking point without a tutorial (I'd rather add a tutorial later in development when more of the base gameplay is in place). It's also the first time we're getting some background fluff added to the game! You can see it in action here:

A tutorial is often requested as the game is not as easy to understand as it could be. I'm hoping tooltips on practically everything will work as a bit of a sticking plaster until there actually is a tutorial. I decided to get the tooltip system done now as it is massively increasing the amount of text in the game which leads into... multi-language support (AKA internationalisation).

The first big feature I want to enable through modding is to add translations to the game. While King under the Mountain is in development, it doesn't make sense to get a translation company to translate all the text in the game as it is constantly being added to - as soon as a set of translations was finished it would be incomplete in the next update and not usable by any players who don't read English. I think the best approach, for now at least, is to support and encourage translation mods while the game is in development, and potentially pull these and/or "professional" translations into the base game (not as a mod) once it hits version 1.0 (i.e. after beta).  The game can even warn you if a translation is incomplete for the version you are playing - it's a problem that needs addressing if not solving while development is active.

To this end, I'm going to be creating tools to help the community with translation mods - probably a small command line executable which initialises or updates a spreadsheet to be filled in with translated text, even including computer-generated translation text as a start pointing. Translations provided by a computer are often poor because they're missing enough context to know exactly how something should be translated, but having them as a base to work on top of should make things easier.

I'm also looking at swapping out the font currently used in the game (Google's Roboto), or perhaps even the entire UI skin, as the kerning (the spacing between letters) is terrible with the current font sprites that have been generated. As with everything else, this will be open to modders to change and improve, so I'm hoping that one day someone comes up with a usable font and set of UI widgets that blows everything else out of the water! Part of the problem is that fonts often have restrictive licensing considerations so it's not quite as simple as deciding "that font looks good, lets use that one", as well as generating a spritesheet for the font which is what LibGDX uses rather than rendering text directly from font files.

If you'd like to help out the early community with translation support into practically any language (I'm aiming to support languages with a large number of characters like Japanese, Chinese and Korean, but I will probably not be able to support right-to-left languages like Arabic) then please head on over to the discord server and the newly created #translations channel where I'll be organising things in the not too distant future!

June 2019 Update - Alpha 2.2 Released
almost 5 years ago – Tue, Jul 02, 2019 at 02:34:29 AM

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
almost 5 years ago – Thu, May 30, 2019 at 01:31:50 PM

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.

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 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.

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.

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:

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!