▶
May 2019 Update - How Modding Works
One of the design goals ofKing under the Mountainis that it isdata-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 its 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 Mountainis installed, this is where all the games data files (except player-specific data like saved games) are stored and loaded when the game is launched. Youll 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 heres how it looks as of today:
Theres a few points of interest in this image. Diffuse refers to the fact theres 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 Im 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 theyre 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 theyre compressed and/or obfuscated, meaning theyre difficult to modify by the player. Usually this is to prevent cheating (particularly for multiplayer games where the integrity of the games files will be checked by an anti-cheat tool) or just to help protect the developers artwork and media from those who would copy and distribute it illegally. Still, that usually doesnt 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.
Most games now embrace modding and provide guides, tools and engine support for mods, andKing 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? Youd 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 youd 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, theres 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, youll 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 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 The important point here is that the games 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.
Until recently, every time a change was made to the games base mod that is, whenever Ive 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 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. Heres an example of how a mod which only changes the entity and terrain sprites would be applied:
Example of mod layering And thats how mods work inKing under the Mountain! As I continue development of mod support, Ill 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. Ill 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 isnt your thing, then dont worry! Theres still a fairly big update coming as part of Alpha 2, wrapping up a lot of player-requested features and some new content additions. Id hoped to have this released in May but as always, its been a very busy month! Finally, if youre 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!
[ 2019-05-31 08:23:28 CET ] [ Original post ]
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 its still not quite ready, though I dont think it can be far away now.
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, Im going to go into some detail on what mods inKing under the Mountain actually are and how I expect them to work.
The Basics
One of the design goals ofKing under the Mountainis that it isdata-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 its 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 Mountainis installed, this is where all the games data files (except player-specific data like saved games) are stored and loaded when the game is launched. Youll 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 heres how it looks as of today:
Theres a few points of interest in this image. Diffuse refers to the fact theres 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 Im 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 theyre 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 theyre compressed and/or obfuscated, meaning theyre difficult to modify by the player. Usually this is to prevent cheating (particularly for multiplayer games where the integrity of the games files will be checked by an anti-cheat tool) or just to help protect the developers artwork and media from those who would copy and distribute it illegally. Still, that usually doesnt 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, andKing 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? Youd 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 youd 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, theres 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, youll 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 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 The important point here is that the games 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 games base mod that is, whenever Ive 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 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. Heres an example of how a mod which only changes the entity and terrain sprites would be applied:
Example of mod layering And thats how mods work inKing under the Mountain! As I continue development of mod support, Ill 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. Ill 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 isnt your thing, then dont worry! Theres still a fairly big update coming as part of Alpha 2, wrapping up a lot of player-requested features and some new content additions. Id hoped to have this released in May but as always, its been a very busy month! Finally, if youre 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!
[ 2019-05-31 08:23:28 CET ] [ Original post ]
King under the Mountain
Rocket Jump Technology
Developer
Rocket Jump Technology
Publisher
2021-11-24
Release
Game News Posts:
58
🎹🖱️Keyboard + Mouse
Mixed
(129 reviews)
Public Linux Depots:
- King under the Mountain Linux [712.99 M]
King under the Mountain is a simulation-based settlement-building strategy game set in a fantasy world.
The game is based around these central pillars:
The game is based around these central pillars:
- A simulated world – The game world is built on a series of interlocking systems which combine together to simulate a living, breathing world. As night changes to day, trees and plants will grow (or not) based on sunlight and rainfall. The local environment and changing seasons have effects on the native flora and fauna. Your settlers and other characters have their own personal social and physical needs that you’ll have to fulfil to keep them happy (or at least stop them from breaking and going insane!)
- Procedural generation – Every map is randomly generated from an initial seed (a large number) so that no two maps will ever be the same – unless you choose to use the same seed! The art assets for the game have been created in such a way that they can be drawn by the game engine for near limitless variation in colour – so every tree, plant and character will have their own unique combination of colours and appearance.
- Peaceful expansion – It’s an important design goal that it’s possible to play the entire game without getting into armed conflict with other factions (if you choose to). Although weapons and combat can be significant parts of gameplay, we wanted to make sure you can peacefully build up a fully-functioning town to have the satisfaction of sitting back and watching your settlers go about their business in an “art farm” style of play.
- Multiple ways to play – As well as different ways to build and grow your settlement (do you focus on mining? farming? crafting? buying and selling goods?), in King under the Mountain you can play as several different races and factions each with their own unique gameplay elements. You could build a dwarven fortress dug deep into the side of a mountain, a town of humans at an important river crossing, or a tribe of orcs hunting and raiding others. More than just different races to play as, we want to introduce completely new play styles as unusual factions – perhaps a lone wizard building their secret lair with golems they have constructed, an evil necromancer raising an army of the dead, a dragon amassing a hoard of gold in a giant cave system, or even an invasion of demons attacking the material world.
- Player-driven content – Have you ever spent hours in a creative game building something, only for it to sit hidden away on your computer? In King under the Mountain, players can opt-in to automatically upload their settlements for other players to visit. This drives the basis of the adventure mode – you put together a party of champions from your settlement’s population, and go off on an adventure to explore another player’s creation. This mode will involve turn-based tactical combat as you explore and battle through another player’s fortress, claiming rare resources that may be difficult or impossible to acquire otherwise. It’s important to note that nothing will be lost by either player in this encounter – you don’t actually “attack” the other player, only a copy of their settlement, and there are benefits to be gained by both parties.
- Mod friendly engine – Another big design goal is that everything you see or read in the game (and the variables behind them) are fully open to modification. In fact, the base game is built as an engine with one base mod applied to it (which modders can look at to see how things work).
MINIMAL SETUP
- Processor: Intel Core2 Duo 2.4Ghz or HigherMemory: 4 GB RAM
- Memory: 4 GB RAM
- Graphics: Intel HD Graphics 3000
- Storage: 500 MB available space
GAMEBILLET
[ 6140 ]
GAMERSGATE
[ 1688 ]
FANATICAL BUNDLES
HUMBLE BUNDLES
by buying games/dlcs from affiliate links you are supporting tuxDB