flame-engine
feat: quad tree broadphase support
Description
Quad tree broadphase support.
Checklist
- [x] The title of my PR starts with a [Conventional Commit] prefix (
fix:,feat:,docs:etc). - [x] I have read the [Contributor Guide] and followed the process outlined for submitting PRs.
- [ ] I have updated/added tests for ALL new/updated/fixed functionality.
- [x] I have updated/added relevant documentation in
docsand added dartdoc comments with///. - [x] I have updated/added relevant examples in
examples.
Breaking Change
- [ ] Yes, this is a breaking change.
- [x] No, this is not a breaking change.
About tests. I see that all excisting collision tests using testCollisionDetectionGame could be reused - at least to ensure that all mechanics works correctly with both systems. It would be fastest way to cover all existing scenarios.
What do you think about this approach @spydon ?
Before I do any commits about this, let me show a small example:
class HasQuadTreeCollidablesGame extends FlameGame
with HasQuadTreeCollisionDetection {}
@isTest
Future<void> testQuadTreeCollisionDetectionGame(
String testName,
Future Function(HasCollisionDetection) testBody,
) {
return testWithGame(
testName,
() {
final game = HasQuadTreeCollidablesGame();
game.initializeCollisionDetection(
mapDimensions: const Rect.fromLTWH(0, 0, 1000, 1000),
);
return game;
},
testBody,
);
}
group('Raycasting', () {
Future raycasting0(HasCollisionDetection game) async {
game.ensureAdd(
PositionComponent(
children: [RectangleHitbox()],
position: Vector2(100, 0),
size: Vector2.all(100),
anchor: Anchor.center,
),
);
await game.ready();
final ray = Ray2(
origin: Vector2.zero(),
direction: Vector2(1, 0),
);
final result = game.collisionDetection.raycast(ray);
expect(result?.hitbox?.parent, game.children.first);
expect(result?.reflectionRay?.origin, closeToVector(Vector2(50, 0)));
expect(result?.reflectionRay?.direction, closeToVector(Vector2(-1, 0)));
}
testCollisionDetectionGame('one hitbox', raycasting0);
testQuadTreeCollisionDetectionGame('one hitbox - QuadTree', raycasting0);
If this approach is acceptable, we should to find appropriate naming convention for test functions. Something like 'raycasting0' might be not a best choice, but in other hand copying something like "ray from bottom-right to top-left within CircleHitbox" into function name is not a best choice too 😉
About tests. I see that all excisting collision tests using
testCollisionDetectionGamecould be reused
That sounds like a good idea!
I wonder if not the whole files could be reused if we just created a list of tests in them that we could pass in the specific game factories to. Then we wouldn't have to do this on a per test basis.
@ASGAlex if you can just fix the merge conflict this PR is ready to be merged! 😍
