This issue is mentioned as a bullet point in #68 and i'm opening it here for better isolation.
As the collision solution implemented in the project currently is not as much escalable, i'm taking a shot on it. Talking with @Stephcraft over Discord, he gave me advice on the desired implementation, using a PhysicsEngine singleton to register and handle every collision check for every non-static Collider object. The reached design is as follows:
- Creation of a new class, PhysicsEngine, as a singleton with read-only calls across the project, with the instance that can be stored in SideScroller for update() calls.
- Creation of a Collider abstract class which stores some rudimentary shape data, like position and rotation, bit-masking for quick collision detection, collision data, and some common collision methods. During initialization, it will register itself into the PhysicsEngine singleton, and un-register during destruction.
- The collision calculations would be made inside each interested collider, as there could be many different collider shapes and collision logic depending of the concrete implementations.
- Each class interested in having collision detection would need to store a concrete Collider object or list of objects, and move it along with them (as there is no common transform to move it automatically).
- Switching the commonly used collision logic of non-static objects into these classes, and delegating the pre-calculation of collision data to the PhysicsEngine class, such as each interested class that stores a concrete Collider class can quickly access to the collision information stored in each of them (All colliders colliding and collision normals).
- The PhysicsEngine will do some pre-calculations for each shape defining some grid-based bounding for quick collision detection (filtering the Colliders by distance). These bounds would be stored inside the Collider and recalculated each time it moves inside or outside a cell, to avoid unnecesary processing.
- Tile-based collision data would be supported as it is now implemented, so it wouldn't be necessary to define a new Collider for each tile present in the scene.
Things left out from this refactor, left pending of implementation:
- Other collider shapes beyond the standard RectCollider.
- Collider shape truncation, so it isn't necessary to calculate for each of its bounds.
- (Possibly) collision detection for rotated shapes.
Please, do tell me if i'm missing something or any suggestion, i'll be working on it shortly.
This issue is mentioned as a bullet point in #68 and i'm opening it here for better isolation.
As the collision solution implemented in the project currently is not as much escalable, i'm taking a shot on it. Talking with @Stephcraft over Discord, he gave me advice on the desired implementation, using a PhysicsEngine singleton to register and handle every collision check for every non-static Collider object. The reached design is as follows:
Things left out from this refactor, left pending of implementation:
Please, do tell me if i'm missing something or any suggestion, i'll be working on it shortly.