Embedded Files
The Project
This is my Unity melee combat system, it uses custom inspectors and scripts to create an easy way for people to implement melee combat with a hit box and hurt box system, this links up animations to an animated mesh and allows someone to add multiple hitboxes to an animation at individual frames on different parents without using the unity animation events system which can is cumbersome and difficult to navigate.
The system was designed in an attempt to be flexible tool fit for many different use cases of melee combat, and is downloaded easily as a unity package.
The tool was made over a limited time period of a month, with part time work. While not as complete as a tool made with more time dedicated, it is functional and has room for expansion.
What The Tool Has
This tool is an attempt to create an easy way of making melee combat inside of a game engine, and more specifically a way to do it in Unity while keeping the animation event system separated from the process of running animation based code inside of Unity.
In doing so I would achieve a way to make melee combat a simpler task for someone using Unity to undertake.
The tool makes tweaking hitboxes for rigged animations incredibly easy. The user interface centralises information relevant to typical melee attack in video games, such as frame data (beginning and end frames), and hitbox size, shape and parent.
The hit box and hurt box system can be easily extended by someone using the tool through virtual functions, and has a whole bunch of inbuilt features like hit stop and knockback with both raw values and automatically calculated ones.
It has a toggleable debug that is separate from the gizmo system to make it easy remove clutter from a users screen without the need to turn off all gizmos.
The custom UI is reactive to whether or not a variables are actually ready to be modified, making it less likely users will break the tool with lighter instruction. The system is also more flexible than a lot of melee systems and could be used for multiple types of games.
In my opinion the system is quite simple to use, getting a basic implementation of the tool can be done in around 10 minutes!
If I Made This Tool Again What Would I Add/Change?
There are a couple of things of note that are improvable in this melee combat tool, there was a limited amount of time for this project and a lot of it went into figuring out work arounds in unity inspector editing rather than implementing fairly standard aspects of melee combat. These are some of the notable things missing that tend to come standard in most Hitbox and Hurtbox melee combat systems:
The ability for hurt boxes and hit boxes to be of different types potentially even user defined types. For example, a hit box with a fire effect, or a hurt box that gets damaged but not knocked back.
A tool to automatically add appropriately sized hurt boxes to a rigged mesh.
An external editing tool rather than doing everything inside of an inspector.
A save function on moves to make it easier to test moves in play mode and bring changes into the prefab/scene.
A more efficient and extensive debug view.
Some Notes On Melee Combat For Nerds
Because I play lots of action and fighting games, I found that I knew a decent amount of what I was getting myself in for in the planning stages of this project, and I knew that the biggest problem for me would be trying to generalise the system.
In retrospect making the system generalised made me run even more problems than I anticipated in terms of scope.
Because there are many different ways a game could require a melee combat system to function, it is commonplace for hitbox and hurt box systems to be specialised for individual games depending on the genre. This is something that I knew heading in but underestimated the complexity of trying to come up with a generalised solution.
For example most fighting games tend to have deliberate angles of trajectory with tweakable size and shape, very specific damage values that tend not to be automatically calculated, and tend to be 2D collision even if models are 3D.
In contrast a third person action title will often do things automatically, trajectory from hits will want to be calculated via the location and trajectory and direction of the motion to maintain the players immersion, the state a hitbox is in could also change dependent on those values (blocking in one direction but not the other is common).
My advice for anyone looking to make a hitbox and hurtbox combat system and what I will be doing in future projects that implement them, is designing the system around the core gameplay more closely to avoid having to make to few decisions on how things should behave and what functions I should support.
If you like learning stuff like this you might like some content my Dev Blog
Google Sites
Report abuse