Hitbox ideas for a pony platformer?

[DPBOX 65]

Hello, I'm trying to make a My Little pony platforming game, but one problem I'm facing is hitboxes. This hitbox only applies to objects and enemies, not level geometry and can be any size rectangle down to the pixel. The problem I'm facing is, ponies have a really weird shape, so I'm not sure what the optimal hitbox size and placement should be. Can you guys please draw a rectangle on these images where you think the hit box should be?

[Toastypk 920]

Can a hit region be a combination of two rectangles? Almost like a backwards L, to cover the head and body regions.

[DPBOX 65]

No, it can only be a single rectangle.

[Toastypk 920]

I've played Ponyvania a lot, but I never checked out what hitboxes were like. I suppose it would have to be the same. Like starting right from just behind the tip of her nose, at least.

[DPBOX 65]

I actually just asked Ziggylung, the developer of Ponyvania, what the player character in Ponyvania's hitbox is like on the Ponyvania Discord server. I haven't gotten a response yet.

[StormyVenture 31]

For the sake of simplification, I would suggest you make the hit box enclose every part of the actual pony except manes, tails, and horns. In theory you could even play with excluding part of the pony's outline and any pixels around it that are just accessories/equipment (crown, shoes, etc) if it makes sense once you have a playable game.

With regards to the mane and tail, I feel like it would logically be a glancing blow at best and a total miss at worst. So, consequently it doesn't really benefit you to make the box larger to include them. A direct hit on the horn would probably really suck if ponies were real, but it's such a small area and would add a lot of empty space to the hit box.

Since you can't use a polygon hit box, it's hard to exclude the area/empty space in front of the hooves and under the head or the area above the back and behind the head. Those are probably going to be the most frustrating aspects to the player.

Edited February 20, 2022 by StormyVenture

[HereComesTom 2,232]

Well, I have been working on a pony platformer since 2012 (made from scratch in Java, complete with a level editor), and I ended up making the hitboxes smaller than the ponies themselves.  Let me get a screenshot to show you:

 

So...what I did was/is nose-to-tail, hooves-to-eyes.  It gets a bit weirder when the ponies have saddle-umbrellas and are going through narrow spaces, but I just ignore that, to be honest:

 

 

That's Rarity, wearing her rain-outfit from Return of Harmony Part 1, firing a beam out her horn, with her umbrella clipping up through the solid cardboard boxes above her.  You can tell the gray/green frames are foreground elements that are drawn on top of the characters and their equipped items, and that the cardboard boxes (which act as the tile blocks) are drawn behind the characters and items.

If the clipping got to be too much of a problem, I could probably add foreground elements that are drawn on top of the boxes that hide the fact that the umbrella clips through them.

[Kadae 655]

You generally don't want hitboxes to stretch too far out of the character model, maybe something like this could work well!

[StormyVenture 31]

On 2022-02-20 at 2:41 PM, HereComesTom said:

...

So...what I did was/is nose-to-tail, hooves-to-eyes.  It gets a bit weirder when the ponies have saddle-umbrellas and are going through narrow spaces, but I just ignore that, to be honest:

...

That's Rarity, wearing her rain-outfit from Return of Harmony Part 1, firing a beam out her horn, with her umbrella clipping up through the solid cardboard boxes above her.  You can tell the gray/green frames are foreground elements that are drawn on top of the characters and their equipped items, and that the cardboard boxes (which act as the tile blocks) are drawn behind the characters and items.

If the clipping got to be too much of a problem, I could probably add foreground elements that are drawn on top of the boxes that hide the fact that the umbrella clips through them.

I would argue that instead of trying to kludge away an ugly artifact of the problem, you would be, in fact, better off fixing. One possibility is to make it so the sprite/subsprite switches to a version where the umbrella is tilted out of the way or closed+folded down somehow.

Ultimately, whatt you really want is at least three planes. For example, you could have a background, a foreground, and an in-between plane where you can draw the character. Either that or you might consider faking it with a  z-index system that simply draws things in the right relative order. That is, as opposed to building three separate, independent layers and then compositing them.

[HereComesTom 2,232]

21 hours ago, StormyVenture said:

I would argue that instead of trying to kludge away an ugly artifact of the problem, you would be, in fact, better off fixing. One possibility is to make it so the sprite/subsprite switches to a version where the umbrella is tilted out of the way or closed+folded down somehow.

Ultimately, whatt you really want is at least three planes. For example, you could have a background, a foreground, and an in-between plane where you can draw the character. Either that or you might consider faking it with a  z-index system that simply draws things in the right relative order. That is, as opposed to building three separate, independent layers and then compositing them.

What I ended up doing IIRC was I ended up taking the tiles, drawing them onto the background layer as a static image, and saving that for each room.  Then I draw the player and other game elements on top of that composite background, and then I have a set of foreground widgets (I call cosmetic objects that don't interact with the player "widgets" in my editor) that get drawn on top of the player.

Shoot---I really set myself up to have these kinds of issues when saddle-umbrellas are part of it, didn't I?

The problem with switching versions of the sprite to a folded-up umbrella is that I can't imagine how I'll have that work in the editor---I created a really generic item-drawing system, and I've more or less painted myself into a corner the way I have animations draw when player characters have items equipped; you can attach buffs to items, and then when the player equips or consumes the item (an item can be consumable or equippable but not both), then the buffs attached to the item are applied to the player-character.  Then I create buffs with animations that are basically the clothing your character wears when they have the items equipped.

So if I wanted to have one animation for saddle-umbrellas where they're down if you get into a tight area and another one for where they're up if you're not in a tight area, then I'd need to have some way of (a) telling the game to draw specific animations under specific circumstances, and (b) having the editor specify all of that.

 

...I'm getting off-topic, aren't I?

[Splashee 28,537]

On 2022-01-18 at 3:12 AM, DPBOX said:

No, it can only be a single rectangle.

You are creating this game all by yourself? Then you have to at least think about the simplest approach:

 

For hitbox detection of a shape like this, and modern hardware (anything that has floating point), find the difference between the center of the two objects, and if the distance is less than, or equal to the sum of both the radius of the two objects, an overlap collision has occurred.

Spoiler

I have drawn circles not as pixels, just vague areas, since this approach doesn't deal with exact pixel collision. Not that you can expect any pixel perfect collision with floating point (even if you round, floating point doesn't deal with whole numbers).

Here is the simple pseudo code:

if (((this_center_x - other_center_x) * (this_center_x - other_center_x) + (this_center_y - other_center_y) * (this_center_y - other_center_y)) <= 
    ((this_radius + other_radius) * (this_radius + other_radius)))
{
	// Overlap collision has occurred
}

This is ridiculously fast, super easy to understand. And it works with different sized hitboxes.
It is calculating the dot product (see my blog about dot products) of the vector between the two center points, and is comparing to the sum of the radius of both hitboxes, squared. That way, no need to use that heavy expensive Square Root of Pythagorean Theorem.

 

The downside is, that the dot product is really scaling the further the hitboxes are apart! This is why floating point is necessary or you will run out of precision way too soon. And of course, you can't expect pixel perfect collision detection, not even as a circle.

 

 

Spoiler

If you do it rectangular, and you are using C++, there is an even faster approach and you can then add as many hitboxes per object as you like (as memory allows). It is pixel perfect, always exact, and works on 8 bit hardware.

 

 

[Rikifive 23,481]

If it's mostly for collision with damage sources, you most importantly want to avoid having too much blank space in the hitbox, otherwise players will criticize your game for having an unfair hitbox.

If you only have a single rectangle to work with, focus on including the most critical/obvious parts in the hitbox (body, hooves, closer part of the head), the rest can be, let's say, "forgiving" (tail, mane, further part of the head that would leak too much). In that case it's better to shrink it and try to find balance, while leaning towards player's favor, which is always the better choice, not the other way around.

 

If a player doesn't get hit even when they expected to be, they'll simply continue playing and be like 'omg that was so close'. They won't be interrupted by that.

But if a player gets hit when they were sure to not be, they'll immediately notice it and start criticizing, especially if that hitbox offset will be drastic. You probably do not want to anger your players like this.

 

Therefore, what @StormyVenture has suggested may not be the best approach in sprites of that size.

On 2022-02-20 at 8:13 PM, StormyVenture said:

Since you can't use a polygon hit box, it's hard to exclude the area/empty space in front of the hooves and under the head or the area above the back and behind the head. Those are probably going to be the most frustrating aspects to the player

And this is why, they mentioned this themselves - it indeed can be frustrating for player.

Imagine jumping around trying to dodge projectiles. Luna is extremely vulnerable with such huge hitbox. Let's say you're trying to jump diagonally to squeeze between two projectiles and one of them touches the very upper left corner of the hitbox. Luna gets hit but look how far the projectile was from her. The distance is clearly visible and players will notice this.

Sure it would be more realistic if getting hit in the nose would count - but players would not praise this for too long if they'd have to struggle with unfair hitbox for the rest of the game. The negative aspect of it would surely outshine the positive one, so it's not worth that.

Projectiles usually are more friendly with rectangular hitboxes, so if pony's hitbox becomes too small, one could always make the projectiles a bit bigger to balance things out, making it all more readable to the eye.

 

@Kadae's suggestion is the closest one to what I'd recommend. It is similar to one I've set in my game

 

 

Though it may not be the best example that translates well to your case. The scale in my game is much, much smaller and I wanted to keep the hitbox shared between all animations (ducking being an exception ofc), because it's used for wall collision as well, which was causing bugs (clipping into walls etc.) when these were different. I've been adjusting the hitbox multiple times and this one felt right to me. There are some leaks I mentioned to avoid, but in my case it's just few pixels one won't really notice in a rather choppy low-res environment.

 

It's also important to account how busy your game will be. Are there many projectiles/enemies on screen? Is movement a bit more blocky? Different gameplay mechanics/designs may have different preferences for hitboxes. Sometimes them being precise is important, sometimes it doesn't matter that much.

I'd suggest creating a very hard level that would require player's precision and/or involve lots of combat, and experiment with hitboxes there. If these will be unfair thus annoying, I'm sure you'll quickly notice it yourself. Then, keep adjusting it until you get to the point, where it plays well and feels fair.

 

  

On 2022-02-20 at 8:41 PM, HereComesTom said:

If the clipping got to be too much of a problem, I could probably add foreground elements that are drawn on top of the boxes that hide the fact that the umbrella clips through them.

The clipping isn't an issue in to be honest. It's not a rare sight either, esp in pixel games. Elements that aren't in the character hitbox often tend to clip through walls. To not search far, if you can swing a sword in a pixel game, you most likely can swing it through the wall, with the sword being displayed on top of the solid blocks when doing so.

Basically, there is nothing to "fix" there, it is normal. The umbrella is mostly for cosmetic purposes, making it bounce around when hitting the ceiling would be a nice detail, but not a necessity.

Edited March 2, 2022 by Rikifive

[Splashee 28,537]

@DPBOX Also, avoid changing the size of the hitbox, even if the animation changes. It is much better to have a static hitbox than to change its size during animation. Position is another thing, since it is relative to what the player actually sees. But the position should always reflect the animation frames, and not lag behind the motion. Use whatever is necessary to find out if your hits are lagging behind with a frame (or worse), by any debug techniques you have, such as frame stepping, or slowing down the physics timing, or slow motion recording from an external camera. You don't want the hitbox to activate at a place that is not where Luna is (where the player sees Luna is, at the finale frame).