Urtuk: The Desolation – How to create mods

Urtuk- The Desolation

A simple guide how to create mods for Urtuk.

Some coding experience is required.

To know proof of concept click here

Introduction

If you already tried to look into the files of Urtuk or even tried to create mods,
you might have noticed, that the game directory of the game is pretty….empty.
It only contains your save files, your game settings, and progress as well as a big fat .jar,
so there is nothing to see or edit at the first glance.

People with some coding experience might know, that .jar’s are simply containers for build Java programs (artifacts) and can consist of the compiled code (.class), external libraries (.dll/.so) as well as resources (images, text files, …).

The .jar format itself is actually the same as .zip, so if you want to check these resources, simply open the .jar as zip (Open with 7Zip, WinRar, …) or rename it to .zip.

The resources of Urtuk only consist of images, atlas files (descriptors for how to parse specific images), sound files, and localization files. The for modders important databases and configurations are missing, so, where are they?

The answer is, hardcoded.

Accessing the Game Code

Since all the game data is hardcoded into the game,
we have no other choice besides invading the code of the game to create mods.

To do so, we have to look a bit through it first. This can be done via java decompilers like ,uhm, Java Decompiler[java-decompiler.github.io]. Simply download the decompiler and open the jar of the game with it. The result will look quite similar to how it looks when you opened the jar as zip, but this time the compiled Java classes (.class) will be decompiled and their more or less original Java code can be seen. Please be aware, that decompilers can make mistakes.

Now that you can look at the code, you can start searching for stuff that interests you by using the search function (ctrl + shift + s). The search function is search sensitive, so take care.

As a general hint on how to find specific stuff if you can’t find it,
look for stuff that might use what you’re looking for.

In the following example, we’re looking for the unit data by looking for the champion Amos.

The class that was found contains the complete unit dataset.

Similar queries can be used to find mutators and other stuff.

If you’re looking for specific mechanics, try looking for where they are applied or used.

Creating Mods

Now that you know where the stuff is you want to change, you have to somehow change it.

One option would be trying to recompile the whole game based on the decompiled classed, but trust me, that won’t work without a lot of trouble and the mod would have the same size as the game – to not mention the violation of the copyright.

Another one would be hooking into the running game via tools like Frida, but that’s also quite bothersome and not something normal people can do.

So, what other option is there?

Well, there is a really simple one, and that is using the game as an external library.

You might want to ask, but how, the game is, well, a game?
Yeah, it is, but that doesn’t matter. The only real difference between an executable and a library is, that executables have an entry point, so as to speak, an instruction for the computer to run a specific function if the program is executed as a program. If we load a program as a library, this entry point is simply ignored. This is especially easy for Java and C#, but hell in C/C++ for various reasons.

Anyway,

since we use the game as a library, we remove this entry point, which means that we have to replicate it in our own project. This can be done by simply copying the code of the original main function of the game into the main function of our mod.
The game main can be found in the package kaleta.hex3.desktop.DesktopLauncher.

After this is done, we can start working on our actual modifications.

If what you want to modify is public and static constant, you can apply your changes in your main function before initializing the game, so before initialize your instance of HexGame3.
e.g. editing the HexConstants[github.com]

If what you want to change is something else, it will be a bit trickier to apply your modifications.

You have to follow the route from the game initialization to your destination and create “extensions” of all classes that are used on the way as well as editing the functions that run or initialize the class that contains what you want to change. If you don’t do so, the game will only run its own version and not your modified one.
That sounds like a lot of trouble, and it is to some degree, but not as bad as you might think.
Here is how it has to be done.

1. create a new java class as an extension of the original class[github.com]
2. copy the functions of relevance (call other classes you have to edit, contain what you want to edit)[github.com]
3. replace all usages of the original classes with your own (simple name change) and remove all:

  • {original class name}.this
  • {original class name}.thisx

4. apply your modifications

That’s it, nothing more, nothing less.

After this is done, simply build your project as an artifact and you’re finally free to run your own mod and give it to others as well.

Afterword

If the developers would be willing to, they could mod support without breaking a sweat.

Some simple measures they could take to do so would be:

  • moving files outside of the jar into a separate zips or folder for easier access
  • initializing the databases via json files instead of hard-coding all entries
  • above could also be used to load extra files created by mods, which would overwrite and add entries to said databases

These changes would also make updates faster for the users,
because only the changed files and not the whole game would have to be downloaded after every update.

Apart from this guide, if you want us to cover any other guide related to the game “Urtuk: The Desolation” do lets us know in the comment section. Thanks for reading. Happy Gaming!
Written by: W0lf

Contents

Related Posts

Leave a Comment