π BeeLadybug (v2.4.0) β Visual Debugging & System Monitoring
Following up on my previous post about BeeLadybug, I wanted to map out its internal architecture for this week's CodePen Challenge using a clean Mermaid flowchart!
BeeLadybug serves as the primary visual inspector for BeeEngine JS. It lives isolated in src/debug/ and executes its render pass immediately after the game world, overlaying AABB/OBB hitboxes in camera space and system metrics in screen space.
β¨οΈ Input Architecture & Control
- F12 Avoidance: Left untouched to preserve standard browser DevTools workflows.
- Tilde Key (~) Alternative: Avoided due to non-standard layouts on non-US keyboards (such as Italian layouts).
- F2 Toggle: Selected as the clean, standard toggle key for desktop and indie game engine debug panels.
π Screen Overlay Features
-
AABB & OBB Hitbox Tracking: Traverses active scene entities, groups, and child nodes. If an entity contains a
BeeTransform, BeeLadybug calculates and draws oriented bounding boxes (OBB) in real-time.- π’ Green: Active entity, no collision detected.
- π΄ Red: Overlapping/colliding with another bounding box.
- βͺ Gray: Disabled or inactive entity.
-
Engine Metrics: Displays current frame rate (
BeeTime.fps), active entity count vs. total allocation, frame execution time (unscaledDtin ms),timeScale, and simulation state (RUN/FREEZE).
πΉοΈ Quick Controls
| Key | Action Performed |
|---|---|
| F2 | Toggle visual debugger panel |
| F3 | Toggle instant slow-motion (0.25x / 1.0x) |
| F4 | Freeze / Unfreeze simulation loop (BeeTime.pause) |
π‘ Technical Note: The GUI buttons on the screen overlay trigger the exact same methods as physical keyboard shortcuts. Freezing the loop stops delta time (
dt) calculations while maintaining the render loop, allowing pixel-perfect inspection of overlapping hitboxes.
π οΈ Quick Implementation
const game = new BeeEngine('gameCanvas', 800, 600);
game.enableLadybug(); // Enabled on boot; press F2 to hide
game.start();
π Logical Collision & Debug Flowchart
Here is the exact decision workflow executed when BeeLadybug inspects entity bounds during high-throughput canvas operations:
flowchart TD
A[π BeeLadybug Detects Bug] --> B{Is SpatialHash Enabled?}
B -- Yes --> C[π― Locate Colliding Entity ID]
B -- No --> D[β οΈ Fallback: Full Canvas Scan]
C --> E[π Log to BeeLadybug Console]
D --> E
E --> F[π§ Apply Fix & Resume 60 FPS]
%% Custom Cyberpunk Styling %%
classDef bugStyle fill:#ff4757,stroke:#ff6b81,stroke-width:2px,color:#fff;
classDef hashStyle fill:#2ed573,stroke:#2bcbba,stroke-width:2px,color:#fff;
classDef warnStyle fill:#ffa502,stroke:#ff7f50,stroke-width:2px,color:#000;
classDef fixStyle fill:#1e90ff,stroke:#70a1ff,stroke-width:2px,color:#fff;
class A bugStyle;
class C hashStyle;
class D warnStyle;
class F fixStyle;
Top comments (3)
Isolating the inspector in src/debug/ so it doesn't touch the game world's render path is the right instinct β a debug overlay that slows the thing it's debugging is worse than none. I hit the same problem on a completely different stack: driving headless browser agents where you can't see anything, and the "debug view" ends up as an overlay of actions and state on top of the page being driven, always kept as a separate layer that can be disabled without touching the main path.
The F12-avoidance detail is thoughtful too. On my side the equivalent is never hijacking input a human might need mid-run. Small choices like that are what make debugging tools usable in production rather than just in demos.
Thanks for the awesome feedback!
There's nothing worse than a performance profiler that tanks your frame rate, or a debugger that changes the timing behavior of the precise bug you are trying to catch (the classic Heisenbug). Keeping
BeeLadybugcompletely decoupled from the core loopβs production path was non-negotiable for me.That parallel with driving headless browser agents is fascinating. Building an observational overlay without injecting side-effects or breaking human input mid-run sounds like a nightmare, especially when dealing with the asynchronous nature of the DOM. Itβs exactly the same core philosophy: tools must observe, never disrupt.
To bridge this with state inspection, that's exactly why I implemented the simulation freeze (
BeeTime.pause). When frozen, it completely cuts off the delta time (dt) updates for logic and physics, yet the canvas render loop keeps spinning. This allows developers to safely inspect bounding boxes and state layers from a static, pixel-perfect standpoint without halting the execution environment or freezing the browser thread itself.Thanks for noticing the F12 detail too! Standard UX choices are often overlooked, but they make a massive difference in day-to-day production environments.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.