Support multiple hit boxes per Sprite

[bunny-therapist]

Enhancement request:

What should be added/changed?

A sprite should be able to have any number of hit boxes, with one being the default (preserves backwards compatibility). Then when you check for collisions you can input the hit box name as an argument if a non-default hit-box should be used. For example, set_hit_box and check_for_collisions could take a str argument for hitbox name (check for collisions could default to default hitbox if a sprite does not have a hitbox with that name).

Tiled supports multiple hit boxes per object, but when reading Tiled files, arcade currently just discard any additional hit boxes with a warning. If this feature is implemented, support for this Tiled feature could also be added later.

What would it help with?

In games you typically want different hit boxes for e.g. player touching ground/walls and player hitting enemies. (Big hit box for touching solids, small for hitting enemies.)

[bunny-therapist]

Example:
https://lh3.googleusercontent.com/proxy/4bW4iXByJJWJbwXK-yv-aQ466OVlB21_qXif4Q7Ef5xQnM2e1Fr0gyZPT83-tc7F2-e6Qz6-a8j_evitQQ-CU20_yM4fNifeeSiVsF-d5CpuyYIlqkvQAvJcBLf_NKumt9UPszUSBwZrgnEqHNXizqKUDB-n35Qe6XGX

Super Mario 1 hit boxes. Oviously these are not used for the floor, as the hit boxes do not touch it These hit boxes are for player-enemy hit detection. The goomba here has one hit box for standing on the floor and one for hitting mario.

[pvcraven]

I don't see adding support for this in the Sprite class. It is straight-forward for a programmer to add support for this in their own program. Just need to set the hit_box attribute to a new updated hit-box, just like changing the texture.

[bunny-therapist]

It is. But anything can be added by anyone. The question is just if they should or if it should be a basic feature of arcade since there is almost no game in the world which just uses one hit box. At least no platform game.

[einarf]

I think that would at least need to be a subclass of Sprite. We're struggling at the moment to keep the memory usage of sprites down. It can get ugly pretty fast with large tile maps.

The future of sprites could be to split them into types. For example: SimpleSprite offering the basics. A stripped sprite can that can be used in tilemaps. It can even have a cython C class version to reduce the memory usage by 10x+. This can be extended to PlayerSprite or other variants. Those definitely have room for extra features since the number of instances will usually be limited.

[pvcraven]

In my mind we support multiple textures, and multiple hitboxes. You just change the texture and the hit box when you need it modified. We don't have a built-in list for a hit-box in the sprite class, but a subclass could easily add that.

[einarf]

With the spit sprite types right now it might be possible to do something like this. The user can also inherit from the simpler sprite types instead of the massive Sprite class to customize for ther own situation.

[benjamin-kirkbride]

The Community RPG is going to need this pretty much immediately.

[benjamin-kirkbride]

Even something like a boids demo needs this.

[DragonMoffon]

In my opinion, we should make a hitbox-list-like object that can have multiple hitboxes for a single sprite. Then they could be used as 'layers' for collisions. I suspect this would satisfy almost all use cases.

[einarf]

#832 is likely also somewhat related because it adds limitations.