$100 - FlxG.collide with simple object "mass" for HaxeFlixel

[chosencharacters]

[This is a HaxeFlixel bounty]

Currently when two objects collide in HaxeFlixel, unless one is immovable, will act as if they are the same impact on eachother. This means a pebble can push a boulder as hard as the other way around. You can usually design around this problem, but here is a case that wouldn't.

Consider the Enemy which stands on the ground, has a force of gravity upon it, and moves side to side, but can be stood upon by the Player. The Enemy cannot be immovable because then they would fall through the floor. However, if the player stands on it, they will slip off as collisonXDrag won't apply. The result is something akin to this. (Note: In this situation, there's a admittedly poorly written function trying to keep the player on the enemy, but oh well.)

Now, since this is really only a subset of the problem, we might as well beat two birds with one stone and have a mass system. With 10 being default mass, any point below or above will divide the effect of their collision by 10% or multiply by 10%. So if you have A pushing B, with A having mass of 10 and B having a mass of 12, then reduce/increase the effect by 20% depending on who's applying force. Yes, this isn't how mass really works, but it's a good way to do it for 2D games, so it'll do HOWEVER if you take this bounty and have a better proposal, I'm 100% open to conversation.

So, a deliverable for this would be a game world that has:

• A player character with mass of 10
• An enemy with mass of 20
• A box that has mass of 15 that can be pushed around
• A box that has mass of 5 that can be pushed around
• The player can stand on the enemy (and boxes, in extension) and move with it

This is highly unlikely to be added to HaxeFlixel proper (though we can try!,) so we may have to have FlxG.massCollide be a Utility function that has objects "self report" their mass to ensure compatibility with any project (like for example, Renaine, which has its own FlxSpriteExt where a mass field could easily be added without modifying FlxSprite.)

[Geokureli]

FlxObjects already have a mass field, but they are currently only used for elasticity, IIRC. adding in a feature like this to flixel makes a lot of sense, imo, but modifying FlxObject.separate could cause problems for existing games

[Geokureli]

I notice in your demo the enemy slows down when you're on top of it. Is this an effect you want covered by the mass collision? If so, can you explain how you imagine this behaving? If not I've just about got all the bullet points covered.

WIP:
https://gist.github.com/Geokureli/070adf01f764a154d0a075f00d957945

Note:this is under an hour of work, all this does is allow 1 object to ride a non-immovable object, I'm still fixing some of flixel's mass handling.

Default mass is 1.0.
Issues:

• If a heavy object (mass: 2) is pushed into a light object(mass:~0.5) they continually increase each others velocity, shooting off the screen at high speeds. I have a simple fix in mind for this
• when a mass:1 object stands on a very light object (mass: ~1/6) they don't even stand on top of it. I assume that, in my test case I assume I was pushing the crate all the way into the floor, and the subsequent tilemap collision was pushing it back up. this seems like a difficult broad-phase issue, should probably just avoid it, right?

I do think I could get all of these changes in flixel, the mass glitch definitely needs to be fixed and I think collisonXDrag should be an enum rather than a bool, with possible values of NONE, ALL, IMMOVABLE, HEAVIER. but an engine PR can wait.

[Geokureli]

Here's the standalone class if they don't approve the PR. https://gist.github.com/Geokureli/69789154a653dc90ac2c719a9c284963

This fixes both issues I mentioned above, and allows objects to ride non-immovable objects. this doesn't slow mounted object's x velocity based on the rider's mass. I figured that would be something checked on the object's update loop or something.

Lastly, while it's harder to push heavier objects, the effect is only really dramatic at the beginning, it may be necessary to make the effect more obvious by using it alongside the drag or maxVelocity feature. Let me know if I missed anything, or if you need some ad-hoc fixes for these differences