Modding

[Lurler]

In this topic I would like to start talking about the way the game is implemented as it is directly related to modding.

Well, essentially the game IS a mod for the engine. It uses available API to create the entire game. There is nothing that is hidden from the players.

The entire core.cpk package is a VisualStudio Project with EVERYTHING we have. It is completely open to the players. Every single game system is 100% open-source

If you remember we tried to do something similar with VoidExpanse, but it is not even close. There we had some parts of the game as scripts to allow modding, but ultimately it proved to much hassle, impossible to debug, etc. and in the end VoidExpanse didn't see many big mods. With this, however, it is extremely easy to develop. You just take an empty project (that we will prepare beforehand) and start coding with all the nice things available in Visual Studio. Autocomplete, debugging, live-editing (yes, the game will be running and you can edit the code live), etc. And yes, it is C#, not some crappy Lua or JavaScript We wield the power of real C# here!

You can read a bit more about the engine here: http://wiki.atomictorch.com/Renkei_Engine

Anyway, let's take a look at how the project is structured.


We are using the same notations as in our previous games, so it should be self explanatory. But let's go over everything.
Content - Contains folders for all in-game content. That includes the graphics, music, sounds, etc.
Data - Different data files, such as localization. Well, to be honest for now it is only the localization , but we might include some other things if needed.
LibsGameAPI - This is needed to compile the project. Different DLLs, you don't need to worry about it
Scripts - This folder contains the actual game logic. Everything is here. Everything related to how the game works is here.
UI - Again, should be quite self explanatory. This folder simply contains XAML definitions for different UI elements in the game.
As for files, there are only two that are interesting for us.
header.xml - This is the mod definition file, it is exactly the same as in VoidExpanses. It lists the author, version of the mod and other such things.
AtomicTorch.CBND.CoreMod.sln - this is the actual project file that can be opened in the Visual Studio.

Now let's take a look how certain elements in the game are actually implemented.

Ammo implementation.

There are a few interesting elements here. First - there is no logic in this file. It is only definition for the particular item. In this case it is 10mm ammo. The logic is actually contained in the ProtoItemAmmo file. We have many of these proto files. This allows us to reuse the same logic for many items, rather than creating tons of files with and without logic on the same level of hierarchy.
You can obviously inherit from these proto files for your items. Just to be clear - all that is opensource, so you can take a look what's inside and create your own proto files.
Next, this item also implements an empty interface IAmmoCaliber10 - this essentially means that it can be used with any weapon that accepts 10mm ammo. It allows us to have many-to-many relation between ammo and weapons. There could be many types of ammo (standard, expansive, ammo piercing, etc.) and many weapons that use that ammo.
Okay, let's take a look at the following code now. As you can see, it simply specifies the properties for that specific item. In this case it is an ammo-piercing bullet that deals 15 damage upon hitting the target. And its type of damage is set as impact+kinetic. There are many other properties that can be specified if necessary.

And here is another example. This time for a berry bush.

As you can see it also inherits from the proto class and specifies the necessary properties.
We put testing values there for now, but as you can see it means that the berry bush grows 10 seconds and then bears berries every other 10 seconds from there. Later it will obviously have more realistic values.

[Lurler]

Some new stuff I would like to share.

We changed slightely how the equipment definitions work and here is the current version for the military armor. Not the final version obviously, but I think it's pretty cool.

As you can see - you simply inherit from the proto-equipment class and fill the necessary parameters. Name, description, graphical assets, but most interestingly is the defense parameters. You can specify defense against each type of damage. This should also give you a good idea what kind of game it is, based solely on the damage types
You can also specify different special mechanics (for example exoskeleton might give you more strength), but in this case it doesn't use anything like that, just normal armor.

[Tchey]

I like it :

The game is a mod for the engine.

[Lurler]

Yup, it means we have all the same things available to us as to modders

Anyway, here is some more stuff.


Any serious modder would definitely like to see a good documentation when creating a mod for the game, so we prepared this.
In fact this is THE documentation we use ourselves for development, so again, you will have exactly the same stuff available to you as to us
Since we have several people working on the game at the same time we try to keep this documentation up to date at all times.
In the image above you can see a list of interfaces available in a certain part of the project.
Oh, right. One more thing. Just to be clear, this documentation is automatically generated from the source code, so we don't need to manually edit it. We rebuild it with every new version of the engine and game.


And here is a single article about a particular class. It lists different elements that are available there with short descriptions.
We tried to keep the code such that you don't even need documentation (with all names being self explanatory), but a good documentation could make life much easier for sure

[loudent]

I know that modding isn't a priority right now but just some ideas for thought for down the line:

It would be cool if there was some mechanism where you can "link" privately run servers together (a portal that packages up character info and sends it to another server then logs you in there). It would be interesting to have a sprawling multi-server world each with its own flair but adhering to a core set of principles.

[Lurler]

I know that modding isn't a priority right now but ...

Actually it is a priority! As I mentioned before we have exactly the same tools and API available to us as to modders! So, as we work on the engine and API for our purposes everything we do also translates to modders! As a matter of fact that World Editor (http://forums.atomictorch.com/index.php?topic=910) that I shared yesterday is done entirely as a mod for the game. And this shows perfectly just how much you can do with modding already!
And can I also remind that EVERYTHING in the game is open source, the entire game is! You can open core.cpk file and see all source for for everything in the game.

... just some ideas for thought for down the line:
It would be cool if there was some mechanism where you can "link" privately run servers together (a portal that packages up character info and sends it to another server then logs you in there). It would be interesting to have a sprawling multi-server world each with its own flair but adhering to a core set of principles.

If I'm not mistaken (and don't quote me on this! ) it should be perfectly possible! But ai_enabled may be able to tell for certain if this is possible or not. Although I don't see why it wouldn't if both servers were running that mod. The mod would just have to implement some way to transfer the character data between the servers.

[ai_enabled]

Yes, it will be possible if we implement some server-to-server (or simply HTTP as it allows connecting with practically anything) networking API, plus API to serialize/deserialize any objects to the network stream. We don't really need this for our current and planned features so it will have to wait for some time.

[loudent]

Actually it is a priority! As I mentioned before we have exactly the same tools and API available to us as to modders!

Yes of course. What I meant is that getting modding tools into the hands of the community wasn't a priority (as Weill it shouldn't be).

cheers,
-loudent

[necavi]

I am incredibly happy to see that modding is such a high priority! That was absolutely going to be my first question, I'm very glad to see that it has already been answered pretty well.

I am concerned, however, that this type of modding tends to vastly increase the incompatibilities between mods, I have seen quite a number of games that run in a similar fashion and typically they end up being more or less only allow a single mod to run at a time. How are you guys planning on dealing with that issue, or is that not something you're really concerned about?

I'm quite excited to take a look around and give the modding a go!

Edit: I attempted to load the project into Visual Studio 2015 and it threw out an error that "C:\Users\<My User>\Appdata\Local\CustomProjectSystems\AtomicTorch.GameEngine.ModProject\CustomProject.Default.props" was not found. Am I missing some additional files or something like that?

[Lurler]

I am concerned, however, that this type of modding tends to vastly increase the incompatibilities between mods, I have seen quite a number of games that run in a similar fashion and typically they end up being more or less only allow a single mod to run at a time.

We thought about that from the beginning and designed a system that doesn't require you to mess with the original files that much. The game would automatically detect any new things and make them available in the game. Even if it's something completely new, not just items or such. But sure, if there are two mods that want to completely replace the original source files there might be conflicts, but again, the thing is - you don't really need to do that unless you want to extend the API.

Our primary goal was to have strong typed compilation and all benefits it provides. The game also doesn't store any lists of entities, it uses types to load and process everything at runtime. The simplest example of that would be items and recipes. The engine just searches for the compatible types and automatically adds that into the game.
All of that can easily be added with separate C# Projects as we did with the Core.

As for resource files (images, sound, music, etc.) we use the same system as with VoidExpanse - if the name and path is the same it will replace the original file. So making visual content packs or using new resources in your mods is super easy.

We are also considering other options that have never been done before. One such example would be a system similar to git, where a mod would effectively do a git-diff of files for all C# and XAML files. This way you can directly edit the core and then get a mod pack with only your changes, rather then everything. This mod would modify the core scripts at initialization, while content uses the standard override rules. This would allow you to merge your mod with new versions of the game even if we replace the original files in the game. And that would allow you to merge several mods into a single "modpack" and address any arising compatibility issues there.

But either way, for now we have a very powerful and robust system that allows you to do pretty much anything as long as you are not going to get too crazy with it As a comparison - you can do everything that people do in minecraft and more!

I'm quite excited to take a look around and give the modding a go!

We didn't anticipate that someone would try to do that even before the game is launched, but we are all for it! If you need any help - just let us know

Edit: I attempted to load the project into Visual Studio 2015 and it threw out an error that "C:\Users\<My User>\Appdata\Local\CustomProjectSystems\AtomicTorch.GameEngine.ModProject\CustomProject.Default.props" was not found. Am I missing some additional files or something like that?

You need this custom project file: https://drive.google.com/open?id=0B4-tSq-u4CreNzBKYkwxODUzRTA
Additionally, if you'd like to debug the code you need to open project properties and set "CryoFall_Client.exe" as the target. Note: not the launcher, but the actual executable in the binaries folder.

[necavi]

Thanks! That does make a lot of sense overall! I'm really, really glad to see that modding has clearly been such a primary focus.

I'll probably poke around a fair bit just to get a good idea of how it works but won't really do much modding before it gets further along. I wouldn't want to work on something for a few weeks then see that you guys have released an update that does the same thing before I'm even done!

[ai_enabled]

necavi, you will also need to install our VSIX extension for VS2015 (https://drive.google.com/open?id=0B4-tSq-u4CreQmcxamFmQ05OMHc) to properly open the solution and be able to attach to the game with debugger.

I'll probably poke around a fair bit just to get a good idea of how it works but won't really do much modding before it gets further along.

Please note that you cannot simply add new recipes and items and connect to the server - it will not know about your new files of course. But you can explore the code... and try modding some content! For example, try draw on the textures used for the character face or cloth. You should see the result immediately without restarting the game!

I'm really, really glad to see that modding has clearly been such a primary focus.

A handful of talented developers could make a nice game, but it will never compare with the creative power of millions of people all around the world. And as we still need to make a game, why not make it in a such a way that will open it for the creativity of everyone? And especially if it actually will make writing the gameplay code and content much easier for ourselves?
That's what we do.

Regards!

[ai_enabled]

To be able to build the VS2015 solution and to have Intellisense (autocomplete) you will also need the game API libs - please download there https://drive.google.com/open?id=0B4-tSq-u4CreeVRjOGc4MjZhWWc and place extracted folder LibsGameAPI near inside the Core/Core.cpk folder.
We will include LibsGameAPI with the next game builds.

[necavi]

Thanks! I'd realized that I needed them to really understand what was going on, but I didn't want to bug you guys about it too much until it was actually possible to create a gameplay mod

[Samui]

Opened project in VS 2015 without problems.
I started learning C# so I can do more interesting stuff when "time will come" =)

Also I really interested in your Renkei Engine, especially if it get mobile platforms support.