Nacent Breakout-clone in rust, bugs and seeking advice

[JasonKleban]

I'm just messing around, trying to learn more about ergonomic rust, game development, physics engines all at once with Speedy2d and Rapier2d. This is perhaps the start of a Breakout game with a keyboard controlled paddle and so far, two giant Circle pucks. The light_grey track is drawn for ~screenshot clarity but not represented in rapier. The paddle acts reasonably for a few seconds but then the physics go unexpected haywire. In the following short clip there are two runs 1) paddle clips-through the 1 meter wall boundary and more surprisingly 2) the paddle seeming escapes the translation lock.

Screencast.From.2025-11-09.14-23-15.webm

https://github.com/JasonKleban/game (Edit: fixed github visibility to Public)

Simulation Issue 1) could be from extreme numbers, but this happens so soon in this run with large Colliders and supposed-to-be-low speeds!

Simulation Issue 2) is way more puzzling to me. The paddle physics are set to be y-axis locked with dominance:

let paddle_body = RigidBodyBuilder::dynamic()
            .dominance_group(10)
            .ccd_enabled(true)
            .gravity_scale(0.0)
            .linear_damping(0.5)
            .translation(vector![4.0 / 3.0 / 2.0, 0.05])
            .locked_axes(LockedAxes::TRANSLATION_LOCKED_Y & LockedAxes::ROTATION_LOCKED)
            .build();
        let paddle_collider = ColliderBuilder::capsule_x(0.1, 0.025)
            .mass(4.0)
            .restitution(1.2)
            .build();

I have no experience with game development and pretty new at Rust. Is there an existing guide or some guidance to share about a Rusty-way to organize this program's code as it continues toward a Breakout-ish game? Currently, Circle (which captures non-physics attributes like Color) and MyGameWindowHandler seem overly coupled. I think I don't want to try to Object-Orient the code such that Circles register themselves and their associated/wrapped rapier structs, update themselves, draw themselves, etc. But how do we sensibly divide up the responsibilities of the game loop instead of having a gigantic single implementation of, say, WindowHandler.on_draw() and a single tightly-coupled module?

Also, why is Δt/frame rate assumed and constant in rapier?