Devblog #002 – Shovel Tool + Tools update

Hello, I’ve been expecting you, peasants. My name is Miroslav, you may know me better as Mirzipan, or The Mace Guy™, and I am a programmer for Medieval Engineers. I am going to take this moment to explain our new tool system. At first, I will go briefly through the old system and its shortcomings and then explain which direction we chose for our new tool system. I will also go into more detail with one of the new tools that we are adding for the next major release – the shovel.

The Old

The tools system of old has been with us since the very early days of Medieval Engineers. There, the choice came down to two very different options: flexible omni-tools vs tools with very specific functionality. The winner was the first option, as there were no supporting systems in the game, that would communicate to the player what a tool can and cannot do. So we ended up with a system that allowed any tool to do anything – a hammer could cut down a tree, but very inefficiently.

These omni-tools worked by specifying all the available primary and secondary actions, and valid targets for each of those actions. The tool code would then analyze the current target and choose the action with the highest priority based on the situation. While this seems like a very cool system in theory, there were issues with it in practice. One of our most common complaints was people unintentionally destroying their blocks when their intention was to build the block instead. This was caused by the tool seeing the block as a valid target at the start of the swing, but if the player would move the cursor away from the block during the swing, the tool system would lose the valid target for ‘build’ action and choose ‘attack’ action instead, and that dealt damage to the block. Another common problem would be accidentally digging the ground while trying to cut a tree.

This system also had another shortcoming, which would affect modders. With each new possible action, the tools definition files would grow quite significantly – the hammer had about 200 lines for the tool definition and another 150 lines to specify how the character should display it. Also, each tool contained definitions for what voxel materials it can mine and what the yield should be.

To top it all off, the tools were built to be handled by the underlying Space Engineers weapon system, which provided a benefit of not having to write a completely new system, but did not allow much space for change, since this part of code was shared and changes to it would affect weapon behavior in both games.

Despite the aforementioned drawbacks, the system served its purpose and undoubtedly provided countless hours of fun to the players. But now we have arrived at the point, where we need to say goodbye to it and move on. The game design has evolved, our needs and expectations have too, and that means we needed a new system that will reflect these developments.

The New

For the new system, we have decided to explore a different route. At the end of the day, people really do not use one tool for everything and they might also not known exactly which tool is the absolute best for the task at hand. So the new system is made in a way that makes each tool only do one job. We also came to a conclusion that we want the game to have more unique tools for a variety of jobs (to improve immersion and have more interesting in-game interactions), not just a jack-of-all-trades.

This system and its underlying subsystems were written from scratch, so we could do anything with them. We now have new systems for equipment, tools, combat, stances, landscaping and some other things. The specific tool code was rewritten and that gave us a chance to think about how we can make them feel better when using them. These changes also meant splitting the data that would normally dwell inside one or two very long definitions into smaller, more easily editable chunks that can be modified independently. So if we want to add a new hammer or other tools to the game, it really is just a couple of lines in the definition now.

The equipment system is very simple – we have equipment slots mapped to character bones, and then each tool can specify which slot(s) it wants to occupy. The equipment manager then figures out what can and cannot be equipped simultaneously. Equipment items now also have a built-in durability, so it no longer looks and functions like an afterthought.

The tools system mostly cares about sending the relevant events to equipped tools and making sure the correct tool behavior and player stance is active. Each tool needs to specify which behavior it wants to use and what character stance needs to be active while the tool is equipped. Behaviors have their own separate definitions, that can specify whatever is needed for that behavior to function correctly. For example, the mining behavior needs the mining definition which is a separate definition that specifies what voxel yields what items.

The combat system takes care of dealing damage and blocking, so it only handles tools that use some form of a combat behavior (melee or ranged).

To show the player what a tool can or cannot do at any given moment, we have added icons on the sides of the crosshair. These show what the tool can do and if it cannot do some of its actions, it will also show the reason why it cannot. The icons to the left of the crosshair symbolize the primary action of the tool (LMB), the ones to the right are for the secondary action (RMB) and we also have icons on the bottom that show action related to the interaction key (F).

The Shovel

In order to better demonstrate what the tool system does, I will pick a specific tool as an example. Since the shovel is the newest member in our tools family, and also contains other cool features, I am going to talk about it now.

The basic premise of the shovel is essentially being a tool for terraforming. While it shares a trait with the pickaxe – digging, it also has a couple of unique features on its own. The main reason for adding the shovel was adding voxel material back to the world and having a reliable way of creating flat terrain, whether is it aligned to gravity or not. It took us a couple of iterations until we were happy with the shovel. One of the latest saw the addition of the landscaping system, where you can place landscaping stakes in the voxels or blocks and connect them with a rope. Once the ropes form a triangle or a rectangle, the landscaping system calculates the plane between the stakes and, once the player is ready to use the shovel, it will only remove voxels that are above the plane and add voxels below it, thus ensuring a terrain that is almost perfectly flush with the plane defined by the stakes.

There are however also many reasons why either of the operations (adding or removing) can go wrong, and we needed a way of clearly communicating that to the players. The logic of the shovel checks for them and then we display it next to the crosshair. We need to clearly show when player is standing in the area he wants to add voxels to if there is not enough material to add, if the terrain he is trying to mine is not minable with the current tool, etc.

In conclusion, it took us some time to rethink tools and we think you are going to be happy with the result. The tools are now refreshed, feel a lot more responsive, work more reliably, and have a better way of communicating what they can be used for. We hope to keep expanding the systems that we are introducing with the new major update and we are sure the modders and players will have a lot of fun with them.