DEV Community: Antonio

I built a lightweight 2D Web Game Engine in Pure Vanilla JS (BeeEngine v2.8.4)

Antonio — Wed, 30 Sep 2026 20:42:52 +0000

Hi DEV community! 👋

Over the past few months, I've been working on BeeEngine, a lightweight 2D game engine built with pure Vanilla JavaScript and HTML5 Canvas.

My main goal was to create a clean, modular engine without relying on heavy external frameworks or complex build setups. It features a custom built-in visual inspector (BeeLadybug), a State-Graph Animator, and a robust Audio Mixer.

🛠️ Project Structure

Here is how BeeEngine is structured under the hood:

BeeEngine-V2.8/
├── index.html                 # Entry point & Canvas config
├── index.js                   # ESM Barrel (re-exporting BeeEngine.js)
├── main.js                    # Visual Demo (BeeUI: anchor, stack, focus, HUD)
├── BeeEngine.js               # CORE (Core Loop & System Coordinator)
├── index.d.ts                 # Global TypeScript definitions & IntelliSense
└── src/
    ├── audio/                 # BeeAudioMixer (bus, fade, duck, pan 2D)
    ├── core/                  # Entities, Prefabs, Tweens, Timelines, Pooling, Scene Manager
    ├── gameplay/              # Player, Enemy, Platform, Collectibles, Menus
    ├── graphics/              # Layers, Animator, Camera, Tilemaps, Particles
    ├── input/                 # Keyboard, Mouse, Touch & Virtual Joysticks
    ├── ui/                    # BeeUI (Panels, Stacks, Labels, Buttons, Nine-slice)
    ├── physics/               # Spatial Hashing, RigidBody & AABB Collisions
    └── debug/                 # BeeLadybug (Visual Inspector & Hitbox Overlay)

✨ Key Features

Zero External Dependencies: Built with 100% pure Vanilla JS.
Physics & Collision: Integrated Spatial Hash grid for efficient AABB collision detection.
Input System: Built-in support for Keyboard, Mouse, Touch, and Virtual Joysticks.
UI Engine (BeeUI): Flex-like layouts, anchors, focus management, and nine-slice UI rendering.
Visual Debugger (BeeLadybug): Built-in tool for real-time inspection, data tracking, and hitbox rendering.

🎬 Deep Dive: BeeAnimator (State Graph, Not Just Clips)

Most simple engines just play an animation clip. BeeAnimator is a proper State Graph Coordinator. While BeeAnimatedSprite renders the frames, the Animator decides which clip to play and when, handling priorities, hit-locks, and automatic transitions.

The entity.animator ticks inside the entity loop using the simulation's delta time (dt), meaning if the game pauses, the animation lifecycle freezes correctly.

// 1. Create the base animated sprite (The Renderer)
const sprite = gioco.createAnimatedSprite(sheet, {
    animations: {
        idle: { frames:, fps: 4, loop: true },
        run: { frames:, fps: 10, loop: true },
        attack: { frames:, fps: 12, loop: false }
    }
});

// 2. Wrap it in the State Graph Animator
const animator = gioco.createAnimator(sprite);
animator
    .add('idle', { clip: 'idle', initial: true })
    .add('run', { clip: 'run', priority: 1 })
    .add('attack', { clip: 'attack', loop: false, lock: true, priority: 10, exitTo: 'idle' })
    // State Transitions via Predicates
    .when('idle', 'run', (actor) => Math.abs(actor.vx) > 1)
    .when('run', 'idle', (actor) => Math.abs(actor.vx) <= 1)
    .when('*', 'attack', (actor) => actor.wantsAttack)
    .start();

actor.sprite = sprite;
actor.animator = animator;

Core Concepts:

Feature	Mechanics
lock	As long as the clip isn't finished, states with `priority` (\le) current cannot interrupt it (they get queued).
exitTo	Defines where to transition automatically once a one-shot/locked clip finishes.
*when('', to, pred)**	Defines a global transition predicate checkable from any active state.
play(name, { force })	Manual override request; `force: true` breaks active animation locks.

Note: BeeAnimatedSprite.play(name, { restart: true }) and sprite.finished are exposed so the animator knows precisely when an action (like an attack) ends.

🔊 Deep Dive: BeeAudioMixer (Audio Nodes & Bus Hierarchy)

Instead of poorly cloning HTML5 audio nodes (cloneNode), BeeEngine uses a proper audio graph node system via BeeAudioMixer. It handles a full hierarchy: master (\rightarrow) music / sfx / ui / voice. It supports volume control, muting per channel, smooth fading, 2D panning relative to the camera listener, and automatic audio ducking.

The mixer ticks every frame using real-time execution independent of the game simulation pause state.

// Unlock Audio Graph (requires user gesture interaction)
gioco.audio.unlock();

// Play background music with crossfade and custom volume
gioco.audio.music(track, { fade: 0.6, volume: 0.5 });

// Play a 2D localized sound effect spatialized vs the camera listener
gioco.audio.play('hit', { bus: 'sfx', x: 120, y: 300 });

// Procedural beep generation (perfect for web demos without downloading MP3s)
// Triggers automatic music ducking because it runs on the 'voice' bus
gioco.audio.tone({ frequency: 180, duration: 1.1, bus: 'voice' }); 

// Global Bus Controls
gioco.audio.setVolume('sfx', 0.8);
gioco.audio.fade('music', 0.2, 0.4);

Core Concepts:

Feature	Mechanics
bus	Hierarchy chain controller. Muting a parent bus automatically silences all child streams.
duck	Default behavior: Active signals on the `voice` bus automatically duck the `music` bus volume down to `0.35`.
x, y	Automatic distance attenuation and left/right stereo panning relative to the listener position.
tone()	Low-overhead procedural beep generator for quick sound design prototyping.

📦 Try It Out

You can include BeeEngine directly in your project via npm or CDN:

jsDelivr CDN:

<script src="https://jsdelivr.net"></script>

npm:

npm install beeengine

📊 CDN Stats & Package: BeeEngine on jsDelivr

I'd love to hear your thoughts, feedback, or suggestions from fellow web developers and gamedevs! What features would you like to see next?

BeeLadybug — un overlay per il debug DOM in tempo reale

Antonio — Sat, 26 Sep 2026 16:08:34 +0000

Un piccolo overlay in azione per il debug in tempo reale.

Invece di riempire il codice di console.log o stare sempre a smanettare con gli DevTools, ho creato questa piccola utility per tracciare e illuminare gli elementi del DOM e i nodi in tempo reale mentre ci si passa sopra.

Molto comoda per fare controlli al volo mentre si sviluppa, senza appesantire nulla.

Che ne pensate? Vi capita mai di impazzire per tracciare gli elementi a schermo?
Provatelo e fatemi sapere se puo' essere utile."(testato su Chrome/Edge)"

import('https://cdn.jsdelivr.net/npm/bee-ladybug@0.4.0/src/index.js')
  .then(({ BeeLadybugCore, WebDOMAdapter }) => {
    const bee = new BeeLadybugCore();
    new WebDOMAdapter(bee, { root: document.body }).attach();
    window.bee = bee;
  });

🔗 https://www.npmjs.com/package/bee-ladybug

BeeLadybug Ironic: Code Inspection meets Self-Inspection

Antonio — Mon, 21 Sep 2026 18:49:39 +0000

🐞 BeeLadybug Ironic: A Small End-of-Day Ritual for Devs

What if we applied the rubber-duck debugging concept to our end-of-day workflow?

The Core Idea

When you close your code editor after hours of problem-solving, refactoring, or hunting down subtle layout bugs, you don't always need another complex dashboard or analytical tool.

Sometimes, a simple circuit breaker helps you transition out of "dev mode" and step away from the desk.

BeeLadybug Ironic is an experimental project separate from the main bee-ladybug debug tool, combining two main concepts:

Visual Debugging: Inspecting Canvas elements and DOM boundaries under the hood.
Self-Inspection & Irony: A lightweight interactive canvas where you can write down thoughts, log simple notes, or reflect on a session before shutting down the system.

How It Works

Mascot Interface: A small 2D bee-ladybug mascot welcomes you to the canvas session.
Reflection Prompts: Quick interaction nodes to evaluate where you stand:
- "Is this a logic issue or just time for a break?"
- "What's the main blocker left for tomorrow?"
- "Ready to call it a day?"
Canvas Transition: Selecting an option transitions the interface into a clean workspace.
The Dissolve Effect: You type your temporary notes, hit the action button, and watch the text dissolve into a pixel field on screen. Once cleared, it's gone.

Technical Details

Runs Locally: Everything executes inside the browser's RAM during the session. No backend API calls, no databases, no tracking.
JavaScript & Canvas: Built on a minimal 2D rendering loop to keep performance fast and dependency-free.

Feedback & Ideas

This prototype is evolving, and I'd love to hear your thoughts:

Do you use any specific routine or visual break when wrapping up a long coding session?
What kind of canvas particle effect would feel best for clearing text (e.g., pixel dissolve, 8-bit blast, or terminal sweep)?

Feel free to leave a comment below!

"Today I spent 4-5 hours chasing a bug that looked like three different problems. They were all connected: a caching plugin hiding images from Googlebot, a forgotten script blocking the thread, and a wild-goose chase involving PageSpeed warnings about CORS

Antonio — Sun, 20 Sep 2026 09:41:44 +0000

Antonio

Sep 20

How a Caching Plugin and an Analytics Script Silently Destroyed My SEO and Page Speed

#wordpress #webdev #performance #seo

3 min read

How a Caching Plugin and an Analytics Script Silently Destroyed My SEO and Page Speed

Antonio — Sun, 20 Sep 2026 09:18:49 +0000

When running a dynamic WordPress site powered by external iframe feeds (like HTML5 game networks), performance optimization can quickly turn into a maze of contradictory metrics and subtle bugs.

Recently, while auditing PlayCombo, I faced a chain of issues ranging from Googlebot indexing failures to endless PageSpeed warning loops. Here is the breakdown of what went wrong, how each issue was resolved, and — in one case — the trade-off I'm still living with.

1. The "Guest Mode" Trap: Googlebot Couldn't See Images

The Symptom: Google Search Console was failing to index media and rich HTML tags on newly published pages, even though everything looked completely fine when browsing as a logged-in administrator.

The Cause: LiteSpeed Cache was running with Guest Mode enabled. Guest Mode attempts to serve an extremely lightweight, bare-bones HTML page on the very first request from a new IP (including Googlebot). Instead of speeding up indexing, it stripped out essential media elements before JavaScript could hydrate the page for crawler bots.

The Fix (and the trade-off): Disabling Guest Mode restored full HTML — including images — to Googlebot on first contact, and Search Console's live URL test confirmed it: previously hidden images were now visible. But this comes at a cost: every first-time visitor (crawlers included) now receives the full, image-heavy page. On a catalog of 3,000+ games sourced from external feeds, that trade-off is still an open problem I'm actively working to offset — starting with removing unnecessary tracking plugins (see point 2) to claw back some of the lost performance budget.

2. The Ghost Script: Invisible Analytics Bloat

The Symptom: Despite heavy caching, initial execution times and Total Blocking Time (TBT) remained abnormally high.

The Cause: A legacy integration tag for Microsoft Clarity (session recording) was injected directly into the theme header. On a media-heavy site with multiple external embeds, tracking every micro-interaction created massive JS main-thread execution overhead.

The Fix: Removing the redundant tracking script instantly cleared the main thread, lowering execution delay for third-party media assets. Alongside this, a couple of Site Kit plugin components that weren't actually being used were removed too, trimming a bit more dead weight off every page load.

3. The PageSpeed Loop: preconnect vs crossorigin

The Symptom: PageSpeed Insights gave conflicting advice:

"Add preconnect hints for game image origins (img.gamemonetize.com)"

Once added via basic DNS prefetch inputs, it threw:

"Preconnect link was not used. Check crossorigin attribute."

The Cause: Image requests initiated by <img> tags or CSS require CORS handling if requested across origins. Standard DNS prefetch fields in WordPress cache plugins only output <link rel="dns-prefetch"> or a plain <link rel="preconnect">, without the crossorigin attribute. Because the browser prepared a non-CORS connection, it couldn't reuse it for a CORS image fetch — the early connection got discarded entirely, and the "optimization" did nothing.

The Fix: Instead of relying on basic input fields, explicit header tags were injected directly into the document <head>:

<link rel="preconnect" href="https://img.gamemonetize.com" crossorigin>
<link rel="preconnect" href="https://cdn.htmlgames.com" crossorigin>
<link rel="preconnect" href="https://img.gamepix.com" crossorigin>

4. Server Disk Inflation: Softaculous vs Server Backups

The Symptom: cPanel disk space reached critical limits (over 10 GB), threatening site uptime.

The Cause: Softaculous/Installatron was configured to run local daily backups, generating massive .tar.gz compressed archives directly inside the /application_backups/ home directory. Meanwhile, the web host (Netsons) was already performing off-site block backups via JetBackup 5 — the same job was effectively running twice.

The Fix:

Disabled automated local backups inside Softaculous configuration.
Purged accumulated .tar.gz archives via cPanel File Manager.
Left the host's native JetBackup engine to handle automated daily snapshots off-site, without consuming account quota.

Key Takeaways

Don't blindly follow synthetic performance scores. PageSpeed advice can create loops if you don't account for CORS semantics on preconnect.
Audit crawler HTML, not just browser HTML. Features like Guest Mode can optimize first-byte metrics while unintentionally breaking search engine indexing — and the fix isn't always free of cost.
Some fixes are trade-offs, not solutions. Restoring indexability for a 3,000+ page catalog came at the price of page weight for new visitors. That's still a work in progress, not a closed ticket.
Check your backup layer. Make sure software-level installers aren't duplicating host-level snapshot backups.

BeeLadybug 0.4.0 — A Blind, Zero-Dependency Overlay for Debugging Anything on Screen

Antonio — Thu, 17 Sep 2026 18:04:58 +0000

https://beeenginejs.com/wp-content/uploads/2026/09/Screenshot-2026-09-15-194620.png

The problem I kept running into

Every time I built a new game or a new page, I ended up writing the same throwaway debug code: an FPS counter here, a console.log there, a red box drawn around whatever DOM node I was hunting down. It always lived inside the project it was debugging — which meant it broke, or had to be rewritten, the moment I moved to a different project.

So I pulled it out into its own package: BeeLadybug. The core idea is simple and it's the one rule I refuse to break:

The Core is blind. It doesn't know what a "game," a "DOM node," or a "Python process" is. It only knows sendData(type, payload).

Everything that actually understands what it's looking at lives in an Adapter. The Core just stores packets, runs a shared clock, and draws an overlay.

Why "blind" matters

The first version of this tool wasn't blind — it was welded to one specific game engine I was building. The moment I wanted to use it on a plain website, I had to rip out half the code. That coupling is exactly what BeeLadybug was built to avoid. A Core that knows nothing about its subject can sit in front of a <canvas> game, a DOM-heavy site, or a Python backend without a single line of the Core itself changing.

The adapters

Four ship today, each one translating a different world into the same generic packets:

import { BeeLadybugCore, CanvasAdapter, WebDOMAdapter } from 'bee-ladybug';

const bee = new BeeLadybugCore();

// Watching a game's canvas
const canvasAdapter = new CanvasAdapter(bee, { canvas: myCanvas });
canvasAdapter.attach();

// Watching a page's DOM
const domAdapter = new WebDOMAdapter(bee, {
  root: document.body,
  watch: ['.card', 'header', 'footer']
});
domAdapter.attach();

https://beeenginejs.com/wp-content/uploads/2026/09/Immagine-2026-09-15-194536.png
There's also a PythonBridge, which streams telemetry over WebSocket from a Python process — useful if you're inspecting a bot or a simulation running server-side, not just the browser.

What's new in 0.4.0: two purely passive diagnostic modules

The newest additions are two adapters that don't need you to instrument anything by hand — they attach native browser APIs and just watch.

🐜 AntAdapter — DOM mutation rate tracker

It hooks a native MutationObserver and, instead of just logging every change, keeps a 1-second sliding window per node. Cross a mutation-rate threshold (30/sec by default) and it emits a warning naming the offending element:

import { AntAdapter } from 'bee-ladybug';

const ant = new AntAdapter(bee, { root: document.body });
ant.attach();
// → warn: "High Mutation Rate on #cta"

This is the kind of thing that's brutal to notice by eye — some countdown or animation quietly re-rendering way more often than it should — but obvious once something is counting for you.

🕷️ SpiderAdapter — long tasks & slow resources

This one wraps the native PerformanceObserver:

import { SpiderAdapter } from 'bee-ladybug';

const spider = new SpiderAdapter(bee);
spider.attach();
// → telemetry: long task, 85ms
// → warn: slow resource, 640ms

Two honest caveats I'd rather state up front than let you discover the hard way:

The Long Tasks API (entryTypes: ['longtask']) is Chromium-only. Firefox and Safari don't expose it, so SpiderAdapter feature-detects and logs once, gracefully, instead of pretending to work everywhere.
Long task entries almost never carry a real script filename — the attribution field usually just says "window". Don't expect "caused by game.js"; expect a duration and a rough container type.

Both adapters register themselves through a small generic mechanism I added specifically so the Core would stay blind even as the toolbar grows:

core.registerAdapter('ant', { enable, disable, label: 'ANT' });

The overlay renders one toggle button per registered adapter — it has no hardcoded knowledge that "ANT" or "SPIDER" exist. A future fifth adapter needs zero changes to the overlay code.

Trying it without installing anything

If you just want to see it on a page you don't control the build for, paste this into the browser console:

import('https://cdn.jsdelivr.net/npm/bee-ladybug@0.4.0/src/index.js')
  .then(({ BeeLadybugCore, WebDOMAdapter }) => {
    const bee = new BeeLadybugCore();
    new WebDOMAdapter(bee, { root: document.body }).attach();
    window.bee = bee;
  });

No build step, no bundler — it's plain ESM, self-contained, zero runtime dependencies.

What's next

Two ideas are on the table but not yet built:

Motion Trail — a small FIFO buffer of recent (x, y) positions per adapter, drawn with decaying alpha, to visualize movement paths (particularly useful for the Python bridge, where you're watching a remote process's trajectory).
Persistent Bug Trap — a log of caught errors that survives across page reloads (days, not just the session), so you can catch something intermittent, walk away, and come back to it later. Read-only, no runtime mutation — just a log you clear by hand once you've dealt with it.

If you try BeeLadybug on something of your own, I'd genuinely like to hear where it falls over — that's the fastest way this gets better.

antonioprosperi2-svg / BeeLadybug-universal

Lightweight, zero-dependency HUD & telemetry overlay for web apps, game engines, and Python backends. Includes WebSocket bridge and custom AI assistant integration.

BeeLadybug

Universal telemetry and visual inspection overlay.

BeeLadybug is not a Canvas widget. It is a small open-source debugger core that accepts raw packets from any source — Canvas 2D games, DOM pages headless bots, Python processes, AI pipelines — and renders them in one dark console.

Il Core non sa cosa sta monitorando. Riceve solo dati grezzi.

Perché questa struttura

Il file storico BeeLadybug era accoppiato a un engine di gioco (entità, hitbox, ctx.drawOverlay). Quello non scala a un sito HTML o a un modello Python. Per questo il progetto riparte da zero con due strati:

Strato	Responsabilità
`src/core/`	Orologio fittizio, buffer, grafici, overlay cyberpunk
`src/adapters/`	Traduttori. Convertono un mondo specifico in `sendData()`

L'overlay non è disegnato sul Canvas. È un pannello HTML in Shadow DOM: funziona sopra un gioco, sopra una pagina, o da solo in una sandbox.

bee-ladybug/
├── src/
│   ├── index.js                 # API pubblica

…

View on GitHub

https://www.npmjs.com/package/bee-ladybug

🔥 Stop using 500KB heavy telemetry packages for basic logs or canvas tracking. Rebuilding BeeLadybug 🐞: a zero-dep universal visual debugger with a blind Core & Shadow DOM overlay. No lag, no style conflicts 🚀 Check out the full breakdown 👇

Antonio — Sun, 13 Sep 2026 19:52:05 +0000

Antonio

Sep 13

Riscrivere BeeLadybug da zero: dall'engine di gioco al Debugger Universale

#javascript #webdev #opensource #architecture

1 min read

Riscrivere BeeLadybug da zero: dall'engine di gioco al Debugger Universale

Antonio — Sun, 13 Sep 2026 19:40:53 +0000

BeeLadybug 🐞

Universal telemetry and visual inspection overlay.

BeeLadybug non è un semplice widget Canvas: è un debugger open source ultraleggero che riceve pacchetti dati grezzi da qualsiasi sorgente (giochi Canvas 2D, pagine DOM, bot headless, processi Python e pipeline AI) e li visualizza in un'unica console scura in Shadow DOM.

Il Core non sa cosa sta monitorando. Riceve solo dati grezzi.

Perché questa struttura

Il file storico di BeeLadybug era strettamente accoppiato al motore di gioco (entità, hitbox, ctx.drawOverlay). Un approccio che non scala quando si vuole ispezionare un sito HTML o un modello Python. Il progetto è stato quindi ripensato da zero su due livelli distinti:

Strato	Responsabilità
`src/core/`	Orologio fittizio, buffer, grafici, overlay cyberpunk
`src/adapters/`	Traduttori. Convertono un mondo specifico in chiamate `sendData()`

L'overlay non è disegnato sul Canvas: è un pannello HTML isolato in Shadow DOM che funziona sopra un gioco, sopra una pagina web o da solo all'interno di una sandbox.


text
bee-ladybug/
├── src/
│   ├── index.js                 # API pubblica
│   ├── core/
│   │   ├── BeeLadybugCore.js    # stato, clock, sendData
│   │   └── UIOverlay.js         # console scura + sparkline
│   └── adapters/
│       ├── CanvasAdapter.js     # prossimamente: hitbox e giochi
│       ├── WebDOMAdapter.js     # prossimamente: layout HTML
│       └── python/
│           └── PythonBridge.js  # futuro: WebSocket → sendData
├── examples/
│   └── core-sandbox.js          # demo senza adapter
├── index.html
├── package.json
└── README.md

Inside BeeLadybug 🐞: A deep dive into visual debugging, OBB collision tracking, and F2 overlay architecture for the CodePen Challenge! Check out the full Mermaid flowchart and let me know your thoughts 🚀

Antonio — Sun, 13 Sep 2026 18:14:45 +0000

Antonio

Sep 12

Inside BeeLadybug: Visual Logic & Collision Debugging (CodePen Challenge)

#codepenchallenge #gamedev #javascript #webdev

2 min read

Inside BeeLadybug 🐞: A deep dive into visual debugging, OBB collision tracking, and F2 overlay architecture for the CodePen Challenge! Check out the full Mermaid flowchart and let me know your thoughts 🚀

Antonio — Sun, 13 Sep 2026 18:07:43 +0000

Antonio

Sep 12

Inside BeeLadybug: Visual Logic & Collision Debugging (CodePen Challenge)

#codepenchallenge #gamedev #javascript #webdev

2 min read

Inside BeeLadybug: Visual Logic & Collision Debugging (CodePen Challenge)

Antonio — Sat, 12 Sep 2026 20:04:40 +0000

🐞 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 (unscaledDt in 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;

BeeEngine JS

Antonio — Sat, 12 Sep 2026 18:39:10 +0000

Building a Pure CSS 3D Interactive Tower (Zero WebGL Dependencies)

I wanted to display the modular architecture of my open-source 2D game framework, BeeEngine JS, directly on its landing page—without the massive overhead of heavy 3D WebGL libraries.

Instead of loading bulky 3D engines just for a visual widget (which adds unnecessary JavaScript payload and destroys the Total Blocking Time on mobile), I built a fully interactive 3D rotating tower using Pure CSS 3D Transforms driven entirely by the GPU compositor layer.

🚀 Key Highlights

100% Native CSS 3D: Built using perspective, rotateY(), translateZ(), and standard semantic HTML elements.
GPU Accelerated: Layout transformations run off the main thread, keeping Total Blocking Time (TBT) at zero.
Lightweight JS Interaction: Minimal Vanilla JS (ES6) handling touch and mouse drag events to smoothly control rotation without blocking normal clicks.
SEO & Crawler Friendly: Unlike WebGL canvas elements, every card in this tower is a standard <a> link, fully discoverable by search engine crawlers.

🛠️ The Architecture Behind It

The goal of BeeEngine JS is to provide an ultra-lightweight (27.9 kB) and razor-sharp environment for 2D web games. Forcing users to download hundreds of kilobytes of WebGL code just to see the features of a 2D framework felt like a complete technical contradiction.

By offloading the 3D math (rotateY calculation based on the number of cards) directly to the browser's CSS rendering engine, the main thread remains 100% free to handle game logic, asset loading, and smooth scrolling.

🔗 Live Demo

Check out the interactive CodePen demo below:
Check out this Pen I made!