Kojiki54% Dev Logs Miko Sramek A game by Atomic Space Frogs A Starting Point. Hitboxes! What are they, and why do they matter? Have you ever been playing a game where an attack goes straight over your head, yet still somehow damages you? That might be a case of bad hitboxes. While hitboxes are more on the technical side of games, they play a big role in how the player experiences the game. Hitboxes in general: Games handle hitboxes in different ways. Some are more complex than others. Some 3D, some 2D. It all depends on what the game needs, and how precise collision has to be. Symphony of the Night A single hitbox is typically seen in 2D games where the player takes up a fairly standard space. Whereas the enemy has multiple segments, meaning more hitboxes are required to have hitting it make sense. In Counter Strike 1.6, the hitboxes are fairly simple, but there’s a box for each major segment of the player model. While this may seem too complex, it is required because the player is shooting at an enemy. Being able to accurately hit the player is part of the challenge. Getting headshots is something fun and rewarding. If the enemy just had a big hitbox, that aspect of the game wouldn’t exist, and getting hit would feel unfair or confusing. This is the main reason to have good hitboxes. Not only does it show lack of technical refinement of the game, it also leads players to feel cheated and frustrated. It is one thing to make a mechanic hard for a player to deal with, but to have hitboxes that don’t accurately represent it, takes away from it feeling hard. It makes it feel like luck, and unless you’re gambling, luck isn’t very rewarding. Dark Souls 2 An example of poor hitboxes: (Video by daSchoof) ​ ​ Hitboxes in fighting games: One of the most important aspects of a fighting game is that the fighting is fun. If at any point the fighting feels stiff or unresponsive, the fun starts to not exist. This is where hitboxes come in. As a player, if you were to clearly make contact with a punch, but the enemy wasn’t hurt, or the enemy clearly missed yet you still took damage, it starts to feel arbitrary and unresponsive. Blazblue – Hakumen Having accurate and consistent hitboxes can make or break a fighting game. The goal being that when a player is hit, they feel like it was their fault, not the games. That they’re the ones who need to improve their spacing and timing. If at any point the player feels like the game is in the wrong, any motivation to improve will be gone. Why would they want to improve if in the end it doesn’t matter and they’ll still lose to luck or unclear hitboxes. However, having simple, yet efficient hitboxes can lead to really satisfying gameplay, such as using a move to dodge an attack and getting in one of your own. Marvel vs. Capcom Origins – Wolverine Types of hitboxes: Almost no fighting game handles the the size and placement of hitboxes the same way. The developers have their own ideas of what makes an ideal hitbox, and what comes across as fair. However, the types of hitboxes seems to be fairly consistent. ​ ​ Skullgirls – Squigly Here’s what I’ve come to find: ● Hurt box ○ If an attack hits this you’ll get hurt ○ Usually depicted as green or yellow ● Damage box ○ Shows your attack range ○ Has to connect with a hurt box to damage opponent ○ Usually depicted as red ● Throw box ○ A hurt box, but for throws ○ If a grab box hits this, you’ll get thrown ○ Usually depicted as blue ● Grab box ○ Shows your grab range ○ Has to connect with a throw box to work ○ Usually depicted as solid blue ● Block box ○ Seen in Street Fighter ○ A bigger box that accompanies a damage box ○ Causes opponent to enter a blocking animation ○ Usually depicted as yellow ● Invincibility box ○ Is the same as a hurt box, but depicts that the character cannot get hurt ○ Usually is either white, or is actually invisible ● Projectile box ○ Like a damage box, but can be destroyed by other projectiles ○ Usually orange ● Special/unique box ○ Seen in Street Fighter V ○ Depicts special moves, such as wind, or a poison fog ○ Varies depending on characters ○ Usually textured purple While fighting games span from 2D to 3D, most of the hitboxes are 2D boxes. While Guilty Gear does use 3D models, it tries to attain a 2D look using shaders and animation techniques. Not only does having 2D hitboxes save on collision checks, it also is probably able to match the look of the game. Guilty Gear – Millia Rage How I plan to handle hitboxes: Unity Rects! Using these will allow for easy collision testing, using the built in Rect.Overlap function, eg. Hurtbox.Overlap(enemyHitBox); This function is quite cheap to use, so cycling through all of the enemies hitboxes won’t strain the system much. Having Unity Gizmos to visualize the hitboxes allows for the to be tweaked and matched up with attack animations and player movements. Having hitboxes that accurately represent attacks and players is the biggest key to having a good fighting game. Finding the perfect balance of size, position, and count for hitboxes is what will make the action feel responsive and fun to play. The next step is finding a good way to save these hitboxes and allow artists to easily adjust and assign hitboxes to their animations. Creating a tool: the tech and design process. More Hitboxes! A light attack animation. Initial Ideas What is this tool used for? The use is to easily create, manage, and adjust hitboxes for our fighting game Re:mminent. This tool has to be easy to use, and ideally all self-contained. Making changes to hitbox data cannot be a hard or painful to do. Hitbox information When testing to see if the game feels good, the hitboxes play a large part of that. Being able to change them on the fly, with minute details is super important. Especially for designers that don’t want to delve into code. Who will be using it? Keeping the user in mind while creating this was important, however, that user is most likely to be me. However, the technical artist on the team should also be able to use it. Designing it to be friendly to them is as important as having it even work in the first place. What exactly does it need to have? So far the tool has: ● Showing / Hiding Hitboxes ● Locking of Hitboxes ● Playing and Mimicking of Asset animations ● A timeline that can be scrubbed through ● A list of the hitboxes that belong to the current state ● The ability to ○ Add, ○ Delete, ○ Duplicate Hitboxes ● Fine tuning of individual hitboxes ● Free movement of hitboxes within the preview At this point without actively using the tool, I cannot think of what it still needs for designer use. Right now all that can be done is streamlining the use of it, and optimizing how it works. What may be in the future is utilizing Unity’s ReorderableList along with better visualization of the timeline to further increase the usability for other designers. The Creation The Unity Editor Every aspect of the tool is made using Unity’s Editor API, and is a EditorWindow class. The window itself is divided into four main areas: basic info / options, the asset preview, the timeline and the hitbox information. Creating areas with Rects, and Unity’s GUILayout.BeginHorizontal(); and EndHorizontal(); allows for easy subdivision of the window. Tackling the Unity Editor beast requires a different type of thinking, as everything happens multiple times per update, so loops are different and things exist in a strange Unity space. When used well it’s extremely powerful though! Custom Assets The main thing this tool is working off of is the creation and adjustment of custom assets. These custom assets then are used within the player controller during runtime. The base of these assets are what I refer to as states (as in different player states, ie. moving, punching, blocking) and these states then contain individual hitboxes. The lightAttack state This process is fairly easy to handle, and being able to place hitbox assets within another asset makes organizing the project much easier. Currently, the code used for this is as simple as: But there is a way to hide these assets, so that within the project view, a user can only see the top most asset. This would allow me to control what information a designer can change within these assets. The tool would be the only way to engage with the hitboxes and could stop any possible corruption. The Elusive Asset Viewer Asset animation within the tool The main issue with creating these kinds of tools is that Unity’s documentation is not the most complete or helpful. One such example is what is displayed above – Unity’s PreviewRenderUtility. Luckily, with the help of a mentor, this viewer became possible. Using their advice, and the example shown here, I was able to implement this feature for ​ ​ the tool. With a couple tweaks to the camera position and scaling, and getting the mesh from the SkinnedMeshRenderer through the .BakeMesh() function, the mesh within the preview successfully mimicked the in-scene model. Getting the in-scene model for the asset preview The scaling of the camera was the trickiest part, as it had to match with the size of the hitboxes to accurately represent what was going on in the actual scene.