Thank you. This is exactly the kind of system information I needed, especially knowing that the major drop happens when three BAEs collide. If you’re able to share the recording, that would also be useful, but no pressure.
To clarify one point, I’m not literally building an engine entirely from scratch. The game is built on Phaser and Three.js, with custom systems connecting rendering, physics, combat, and the rest of the game. It is still an unconventional stack with plenty of opportunities for me to hurt myself, as demonstrated here.
The broader goal is to combine real physics-driven interactions with an arcade feel. One of the major roadmap features is the ability to shape and sculpt individual BAE parts, somewhat like Spore. Those shapes are intended to affect how the BAE handles, collides, distributes its mass, and behaves in the arena, so the physics become part of the actual build strategy rather than visual decoration.
I have seriously considered using a conventional game engine, and I may still rebuild the game in Godot once the design has earned that investment. Right now, I’m approaching this as product development as much as traditional game development. My priority is to validate the core idea, test its variables with real players, and iterate on feedback as quickly and cheaply as possible.
If the concept proves itself, I can approach a Godot rebuild with the combat rules, game feel, progression, content structure, and technical requirements already understood. That would still be a significant rebuild, not a simple port, but it would be a much more informed one than committing to production architecture before knowing whether the game deserves it.
Thanks again for the detailed follow-up and for giving the game a fair chance!