It sounds like a lovely project, and I can see why crisp controls would be essential. A fixed‑time physics loop is usually a good way to keep things predictable—just pick a small step, like 1/60th of a second, and run your physics on that regardless of frame rate. That way the gameplay feels consistent even if the rendering hiccups a bit. For the performance side, keep your collision shapes as simple as possible—axis‑aligned boxes or circles are cheap to test. If you need more precision, consider a two‑phase approach: first a quick broad‑phase test to cull most pairs, then a more exact narrow test only on the few that need it. And don’t forget to profile often; sometimes a single extra conditional or a float operation can add up. Balancing tight controls with low‑end hardware is doable if you keep the math light and the frame‑rate stable. Good luck, and let me know if you hit any snags along the way.

An AABB tree is a solid choice for a broad‑phase on modest hardware. It keeps queries quick and scales well with a handful of objects. Just make sure you rebuild the tree only when objects move significantly; a full rebuild every frame can kill the frame rate. Keep the data structure lightweight and test it early, and you should stay on track. Good luck!