The built in collision detection + ray cast features I think would work if every bullet had a script, but it would be much better to use a manager. But then ray casts can’t provide enough information about collision. physics.ray_cast / ray_cast_response has a 0-255 size limit, which is not enough for bullet hell games.
Using ray casts is necessary for bullet tunneling between frames.
I’d like to use built in collision. But I’m thinking of making my own broad phase with spatial partitioning.
I think it will require using Tiled to build tilemaps for display, then export as .lua so that DefBullet can have easy access to tile collision information and take advantage of broad phase spatial partitioning. Then would want to use Tiled for placing doodads and other layered stuff as well in levels.
Box2D has features for bullet tunneling too but I don’t think they are enabled in Defold at the moment.
I’m not an expert either so we can all learn some new things!
With spatial partitioning you can more quickly exclude objects from needing to do more expensive calculations. @ChaosYu mentions quadtrees which are like a dynamically recursively sub-divided trees which can be more efficient than a simple grid.
Broad phase is contrasted with narrow phase. With broad phase we can more quickly exclude objects which for sure don’t collide, and then in narrow phase do the expensive calculations on the rest which don’t have certainty.
With spacial partitioning you divide world into grid cells. You place bodies into cells, and they can be in multiple cells. Then you can simply check if objects are within the same cells to see if they could possibly collide.
I’ll test a few methods over time and use what works. If one method is good enough I’ll stick with it. I also want to test making a C NE vs Lua code and see if it can make a meaningful difference or not be worth it if overhead is too large. For my game I can imagine 250+ bullets and other collideables within the game world going on at once, but not thousands like touhou bullet hell games have.
Currently making version which uses built in collision detection. Using raycasts for the distance a bullet travels a frame to compensate for bullet tunneling. There is an issue with raycasts within a body not registering, but I think it can be avoided by making the raycast a little longer and start a little behind should make the small chance of that happening not happen?
Will improve this a bit with different bullet types and then release a version with this setup. Then it can be profiled against with non-built in collision detection methods. This version also uses a script per bullet as there is a 255 id limit with a manager. Could maybe have multiple managers dynamically used though to get over that limit and not need to use a script per bullet.
For bullets which do not move faster than their hitbox size per frame normal collision shapes can be used. The fast moving bullets are almost hitscan but true hitscan can be made too like for laser weapons.
Also noticed a bug with super fast moving game objects sometimes losing their collision shapes!?
Bullet hell games can have many bullets on screen at once depending on how insane they are. There is also the performance hit with all of the extra scripts. We’ll see soon how different performance is with and without…
I had debug physics on and was moving an object around the scene very fast and sometimes the collision shape would no longer draw like it was deleted. It was reproducible and can probably make a sample where it happens.
Also I have another question: Is the raycasting necessary, or could we use the “bullet” option on the collision object (it’s been 6 years since this thread last updated - maybe that changed?).
You would need to test that with the collision objects. The 2D raycasting is just to prevent fast moving bullets from skipping over something they should hit. Possibly the bullet option on collision objects would be able to do this too.
