jumpy

jumpy copied to clipboard

This is an issue intended for discussions around our current situation regarding physics and collision checking.

Currently we use macroquad_platformer for this and it is working as intended. There are a few problems with this, however. Primarily the fact that we have to register a collider (actor) in the CollisionWorld when constructing a PhysicsObject. This creates a divide between the collider used for physics and the collider (get_hitbox on Player, for example) used in all the other settings. There is already a physics implementation for the map format that we use, created in my framework, where I pulled the map implementation from, which includes most of what we need, except gravity (it is designed for top down, not side-scroller).

I am proposing that we pull in this implementation, in stead, as it will make it possible to do collision checks directly on the map instance, in stead of having to keep a separate collision world for all this, where we have to register all movement, etc. The collision part is already there, as calling get_collisions or get_colisions_at will return any collisions with the map, based on the collision settings defined by setting the collisions prop on the Tiled layer in question...

Gravity and all the other things that fall outside of the active collision checks, could be moved to an update method of the PhysicsObject.

As my framework is 100% based on macroquad, it doesn't present any divergence outside of the fact that we drop macroquad_platformer. I use a Collider type that either resolve to a Rect or a Circle but if we choose to adapt this, we will just remove this and use Rect as our basic collider type, as is currently the case...

This issue is not a call for an immediate change, with a following PR, but a place where we can discuss the pros and cons of the solution I propose and, together, come to a conclusion....

Keeping just one collider in one world for everything seems like a good idea. Perhaps it could address issue #135?

Keeping just one collider in one world for everything seems like a good idea. Perhaps it could address issue #135?

It is a very simple implementation so it will be easy to remedy this, in some way, yes.

There was some issues with the map implementation today, when I implemented the triggered effects for weapons, however. I haven't tested this properly, yet, but I suspect it is just due to macroquad_platformer canceling movement, because of collision, before a collision can be registered by the map. I'll need to do a proper test of everything and refactor as needed, before we transition, if we land on going for the collision detection in Map, so this will probably not be done until the item api and the next editor sprint is over, though

After the bevy rewrite we now use a port of macroquad platformer that we migrated to integrate natively with the Bevy ECS. This made it quite convenient and is so far working great.