Hellsplit: Arena is a constantly evolving product which has already gone through a variety of changes since the first version. Hellsplit: Workbench is a continuously developing instrument as well, functions and possibilities of which will be regularly updated. Due to the reason that Deep Type Games team is quite small, we cannot write a comprehensive documentation on the use of our product.
Instead of this we offer you a timely support and help in solving of concrete issues, and in the future we plan to record a series of video lessons on the use of our SDK. In this document we will try to shortly describe the key concepts which is important to know when creating the mods to our game.
The game Hellsplit: Arena has evolved multiple times throughout its development. It refers not only to the gameplay aspect of the game. The internal structure of the code has been changed many times as well.
One of the most important issues of suchlike games is how to pass damage data from one actor to another. Roughly speaking, when the sword hits the zombie, the zombie needs to be informed about the object that hit him, as well as about its characteristics and impact force. While working on this problem we came to a decision based on Damaged Events.
In brief, the concept of interaction is as follows: when object A damages objects B, it passes a special object of DamageEventBase type which contains all the necessary information about this damage.
Sounds rather simple. But I think you will immediately notice that the damage can be different. There can be the damage from a sword (and the swords themselves can be different), and there can be the damage from a book (at the same time, the book has completely different properties in comparison with the sword). Absolutely right. Due to this reason there are several classes in our game inherited from the DamageEventBase and implementing various damage types.
Let’s return once again to the reason of the necessity of multiple classes of this type. First of all, as mentioned above, each of them contains its own set of parameters peculiar only to the objects which inflicted such a damage. For instance, when hitting with a sword it is necessary to know the weight of the sword, its size, surface type and many other things and when hitting with a book - it is enough to know the hitting speed only.
That is why we divide e.g. HSDamageEventMeleeWeaponHit and HSDamageEventSimpleHit. If you got to the independent passing of the damage to the enemy, start with HSDamageEventSimpleHit as the most simpliest class.
The second reason is the fact that receiving various damage types the enemy can decide how to react on particular damage. Imagine if the damage would not be divided into classes and the impact from bullets/book hit/ hammer hit would be the same? Then perhaps the enemy would simply fall down in each of these cases and the gameplay would be boring and monotonous. But this classification allows us playing with different reactions depending on damage type, which is very convenient.
As already mentioned, the damage system has evolved during the development process until it achieved the current state. Due to this reason, there are still a lot of places in the game containing Legacy code and in particular this applies to the enemies. Therefore, the logics of the enemies is extremely unstable to the modifications now and will be repeatedly changed in the future - for that reason, we do not recommend you to create global mods based on the enemies modifications, as the interaction with them will change in the future. On the other hand you can easily create the whole new types of the enemies and use IHSDamageInterface in them to receive the damage.