Multiple hitbox support should really be added at some point.

[Jeru Sanders]

I just made a game for a jam using HaxeFlixel and I ran into an interesting problem.

To start here's an image of my game.

The Wizard is the player character. The problem is that I need to make his hitbox small and move the offset down to get the collision I want with the tilemap. So basically the bottom half of the wizard is where his hitbox is.

But there's a chest there on the left that I want the player to be able to push around, it works, but with only the bottom half the player, and it looks odd. From what I understand the only solution to this is to make rectangle checks then manually change the velocity's of objects, but that's strenuous and there's a good chance it would break other physics interactions. 

The general solution is to make multiple invisible sprites and manage them with meta-groups. But firstly that wouldn't work if you want to use collide() rather than just overlap().

And secondly, that's a pretty poor solution in general, it feel really hacky like the old Flixel and meta-groups in general. Wasted updates, wasted rendered transparency.

I think the collision system needs a real over-haul. Proper multi-hitbox support, collision filtering, FlxG.serperate() should work better.

What do you guys think?

Also link to my game if you're interested. Has randomly generated dungeons and auto-tiling, all self written. www.newgrounds.com/portal/view/642575

[Gama11]

You're absolutely right, flixel collisions are extremely basic and limited (to avoid the word "shitty"). Currently, the best way around that is to use Nape, which is super solid when it comes to collisions. A lot of people are doing exactly that, but of course not every game needs a full-blown physics engine just to realize collisions.

Sidenote, if you want a second hitbox, you can use a FlxObject (which has all the necessary physics for collisions) for that if you're concerned about the overhead of a FlxSprite (which would be pretty minimal). And instead of using groups you could use simply synchronize the velocity values of the hitbox within Player#update().

Nice game btw,I guess implementing flash gamepad support was worth it. :D A few thoughts:

- You should hide the mouse cursor, it being visible implies that there are mouse controls, which there are not - confused me at first

- Player movement seems a bit jittery, maybe pixelPerfectRender = false; helps? Unless you're not a fan of subpixel rendering.

- The player sprite is not really a good indicator of the shot direction, which can be confusing, especially when shooting up.

- In general, shot direction being tied to movement direction feels frustrating. This would work much better as a twin-stick-shooter where both are independant.

[Jeru Sanders]

Nape would work but created huge overhead, especially in tilemaps, it's not common to 50-100 collectible objects on one level. That wouldn't fly in Flash or weaker Android target.

And about the game, yeah twin sticks would of been nice but it was a jam and there's keyboard ghosting and I wanted to have two players on one keyboard, it wasn't amazingly designed.