DEV Community: Kehinde Owolabi

From Buggy Prototype to Polished Arcade: How I Upgraded Three Browser Games

Kehinde Owolabi — Wed, 14 Oct 2026 12:58:25 +0000

From Buggy Prototype to Polished Arcade: How I Upgraded Three Browser Games

Over the past few days I've been deep in the trenches refactoring and rebuilding three browser games built on a lightweight 2D/3D canvas engine. What started as "fix a few bugs" turned into a full-blown feature overhaul across a platformer, a racer, and an FPS.

Here's what actually changed, why, and what I learned.

The Starting Point

Three games, all built on the same homegrown engine:

Neon Caverns: Seasons — a platformer with 20 levels and a coin economy
Death Boost: Seasons — a pseudo-3D arcade racer
Riftfire (formerly Raycast FPS) — a raycast shooter

The initial request was simple: "there are bugs." But as I dug in, the real issues were architectural — not just a few typos.

Neon Caverns: Seasons

The Bugs

Two silent killers were ruining the game:

1. Tile mutations across restarts. The engine's tilemap constructor mutated a shared array every time a level loaded. After one restart, every tile lookup broke. Players saw invisible walls.

2. The pause button drifted off screen. It was added as a world-space entity, so it scrolled away with the camera instead of staying pinned to the HUD.

The Overhaul

4 seasons × 12 levels = 48 unique stages, each procedurally generated but deterministic per run.
Ramping difficulty curve — enemy HP, speed, accuracy, and map density all scale with a single normalized value from 0 to 1.
Full procedural audio — every sound effect and music track is synthesized live via the Web Audio API. No external files, no downloads.
Persistent coins and upgrades — health, speed, jump, magnet range, shield tiers, all saved to localStorage.
Star ratings per level (1–3 stars based on health, time, and coin collection).
Season unlock chaining — clear all 12 levels of a season to open the next one.

Death Boost: Seasons

The Bugs

This game had a list:

Invisible hazards were killing players
Cars were colliding from behind the player
Traffic recycled to a moving target, causing pile-ups
Menu clicks silently failed when audio init threw
Sprites rendered ~1000× too small to be visible

The Overhaul

4× wider road — from 2000 to 3400 units wide, 5 lanes instead of 3.
60% fewer obstacles, 50% less traffic, longer spacing between hazards.
12 tracks total with lap counts from 1 to 3.
Bug fixes: signed z-window for hazard collisions, cooldowns on repeated hits, sprite scale corrected to match world geometry, audio failures no longer swallow input.
Always-visible pause button — now pinned to screen coordinates instead of world space.
Per-level difficulty display — cars show their speed, health, and boost stats as animated bars.

Riftfire

The Overhaul

What was originally a 5-map raycast FPS became:

12 seasons × 30 levels = 360 stages, all procedurally generated with seeded randomness.
Difficulty ramp — enemy HP, damage, accuracy, speed, and fire rate all scale from easy (level 1) to brutal (level 360).
Procedural audio — every gunshot has its own synthesized waveform. Rifle, pistol, shotgun, sniper, minigun — all distinct, all generated at runtime.
Adaptive music — four different musical scales that switch based on the current level's difficulty.
Weapons shop, ranks, and coin economy — buy new weapons, earn XP, climb 10 ranks.
Mobile touch support — analog joystick for movement, drag-to-aim for firing.

The Common Threads

Across all three games, the same principles showed up again and again:

1. Separate World Space from Screen Space

The pause button bug and the sprite scale bug both came from mixing world coordinates with screen coordinates. Anything that should stay fixed on the HUD must be drawn after the camera transform is popped.

2. Never Trust Global Mutable State

The tilemap bug was caused by an engine-level array.unshift() that silently mutated data shared between level loads. Whenever possible, rebuild state fresh at scene boundaries.

3. Procedural Content Is Cheap and Endless

All three games now generate their content at runtime. This means:

No asset loading delays
No missing-file errors
No copyright issues
No download size

Web Audio can synthesize a gunshot, a jump sound, or a full musical theme in a few lines of code.

4. Input Handling Must Be Defensive

The click-swallowing bug in Death Boost happened because initAudio() threw an exception and aborted the event listener before pendingClick was ever set. Always set state before calling anything that might throw.

5. Difficulty Should Be a Single Scalar

Rather than tweaking 20 numbers per level, each game derives all difficulty factors from one normalized value:

difficulty = (globalLevel / totalLevels) ^ 0.85

That one number then scales enemy HP, count, speed, accuracy, and map density. It's clean, tunable, and easy to reason about.

What I'd Do Differently

If I started over:

Version control from day one. This was all done in single monolithic files.
Write tests for input flow. The click bug was caught by a human, not a test.
Separate rendering from state. Several bugs came from render functions that also mutated game state.
Build a small dev console — a way to jump to any level, tweak difficulty, and inspect state.

Final Numbers

Game	Levels	Audio	Notable Feature
Neon Caverns: Seasons	48	100% procedural	Season unlock chains
Death Boost: Seasons	12 tracks	100% procedural	Multi-lap enduros
Riftfire	360	100% procedural	Adaptive music scales

All three ship as single HTML files, no external assets, and run in any modern browser.

Closing Thoughts

The best thing about browser games is how fast the iteration loop can be. Change a number, refresh the page, feel the difference. The worst thing is how quickly small architectural mistakes compound into invisible bugs.

The three games above went from "playable but broken" to "actually fun" by fixing a handful of fundamental issues and then building outward. Every new feature is now cheap to add because the foundation is solid.

If you're building a browser game and something feels off, it's almost never "just one bug." It's usually a small design decision that ignored a boundary between two systems. Find the boundary. Fix the boundary. The rest follows.

Limn Engine Is Getting a Performance Plugin That Might Change How You Think About Browser Games

Kehinde Owolabi — Wed, 07 Oct 2026 20:58:37 +0000

Limn Engine Is Getting a Performance Plugin That Might Change How You Think About Browser Games

The engine used to cap at 60. Now the display is the only limit.

If you've ever built a browser game, you know the feeling. It runs at a smooth 60fps on your laptop. You send it to a friend. Their phone chokes. Their older Android tablet chokes harder. The frame counter drops from 60 to 45, then 30, then stutters at 18 while particles flicker and input feels like it's arriving by mail.

This is the universal tax of browser game development. Weak hardware. Inconsistent frame pacing. Frustration that has nothing to do with your code and everything to do with how the browser schedules rendering.

Limn Engine has a fix coming. And it's not a rewrite. It's not a new engine. It's a plugin — one extra <script> tag, no configuration, no code changes.

What Limn Already Gets Right

Limn Engine was built on a simple philosophy: common outcomes should be functions. No build tools. No npm install. No config files. One script tag, one Display instance, and you're making a game.

That philosophy has already produced:

A dual-canvas architecture that caches static scenes
A move utility that turns boilerplate into one-liners
A built-in audio system with volume buses
Particles, sprites, tilemaps, and camera shake — all in one file

But even with all of that, Limn is still bound by the same browser limits that every other Canvas 2D engine is bound by. Weak devices drop frames. High-refresh panels don't always get used. Frame pacing wobbles.

The upcoming plugin changes that.

"60fps Is the Ceiling"

That's what we were told. On low-end devices, 60 frames per second is the natural limit of what the browser can deliver. The display refreshes at 60Hz. RAF fires 60 times a second. The math closes. There's nothing above it.

It's a fair objection. On a 60Hz panel, 60 visible frames per second really is the physical limit — no engine can show more than the screen refreshes. But "the display caps at 60" and "the engine caps at 60" are two different claims. One is hardware. The other is a design choice.

For most engines, on most hardware, the ceiling holds — but only because nobody has bothered to push past it.

"Beyond the ceiling there is the sky. Beyond the sky there is infinite space."

We're not claiming we've broken physics. We're claiming that the ceiling people keep pointing to is lower than it needs to be — and that once you stop assuming it's fixed, there's a lot of room above it.

What's Coming

A drop-in performance plugin for Limn Engine that:

Raises the engine's internal tick rate so the display is no longer waiting on the engine
Matches GPU engine frame-rate consistency on small to medium 2D scenes
Works across device classes — desktop, mid-range Android, low-end Android
Requires zero configuration — one script tag, auto-activates
Falls back gracefully if the device can't support it
Doesn't change a single line of your game code

If your Limn game runs today, it'll run with the plugin. Faster. Smoother. On hardware you might have given up on.

Why This Matters

For solo developers

You don't have a QA team. You don't have a device lab. You have your laptop and a vague hope that your game runs on whatever your players own. The plugin closes that gap. What you see on your machine is closer to what your players will see on theirs.

For game jams

Game jams are won and lost on first impressions. A game that stutters on a judge's phone doesn't get a second look. A game that hits a stable frame rate on a budget Android gets remembered. The plugin turns "technically works" into "feels great."

For web games as a medium

Browser games have always lived in the shadow of native. Not because browsers can't do great games — they can — but because the feel has often been second-rate on low-end hardware. If this plugin does what it's designed to do, that gap narrows. Not on flagship phones. On everyone's phones.

For Limn's philosophy

The plugin preserves what makes Limn worth using. It doesn't ask you to restructure your code. It doesn't require a build step. It doesn't add a dependency. It's an enhancement — one script tag that makes existing games smoother without changing how they're written.

What We're Not Claiming

We're not saying this replaces Unity, Godot, or a "real" game engine. Different tools, different problems.

We're not saying it's free performance. The plugin uses real resources. It's engineered, not magic.

What we are saying is this: for the class of 2D games Limn is built for — platformers, puzzle games, RPGs, retro-style action games, game jam entries, learning projects — the plugin brings frame-rate consistency that previously required a much heavier engine.

What This Actually Changes

The frame rate you see is bounded by your display — a 60Hz panel shows 60, a 120Hz panel shows up to 120. That's hardware, not software. No engine can change it.

What the plugin changes is the engine's internal rate. Instead of ticking once per display refresh, the engine produces state at twice that rate and hands the freshest frame to the display at the moment it refreshes. On a 60Hz panel, the frame you see was computed half a frame ago instead of a full frame ago. On a 120Hz panel, the display actually receives 120 distinct frames per second.

The result:

Lower input latency — your input is sampled at twice the panel rate, even on a 60Hz screen
Smoother motion — physics and animation update at twice the tick rate, so nothing is skipped
Higher visible frame rate on capable displays — up to the panel's native maximum

To be clear: the plugin does not produce more frames than your display can present. A 60Hz panel receives 60 refreshes per second, and that's what gets shown. A 120Hz panel receives up to 120. The plugin does not duplicate, interpolate, or fake frames — the number on your frame counter corresponds to real displayed refreshes.

This isn't double rendering. It isn't frame interpolation. It isn't an upscaling illusion. And it doesn't cost more CPU — the plugin is designed to use fewer resources than a naive render loop, which is exactly why it helps on low-end devices. It raises the floor. The display is the ceiling, and only the display.

The Numbers We're Targeting

We'll publish real benchmarks when the plugin ships. For now, here's what we're aiming for across device classes:

Device	Current typical Canvas 2D	Target with plugin
Desktop	60fps stable	60fps stable (parity)
Flagship phone	60fps, occasional jitter	60–120fps stable
Mid-range Android	30–45fps with stutter	60fps stable
Low-end Android	10–20fps unplayable	60fps stable
High-refresh panels	Limited by main loop	Full refresh rate unlocked

We'll measure 1% lows and 99th-percentile frame times, not just averages — because averages lie, and stutter is what players actually feel.

How to Try It

Soon. The plugin is in development. When it's ready:

Add one <script> tag to your page after epic.js
That's it
Your existing Limn game gets faster automatically

If it doesn't work on your device, the plugin detects that and quietly steps aside. Your game still runs exactly as it did before. Zero risk.

Follow the Limn project for updates — the release will be announced the day it's ready.

What's Next

We'll publish:

The benchmark scene — open source, so anyone can reproduce our numbers
Before/after comparisons — on real devices, not throttled DevTools
A technical writeup — explaining the approach at a level that's useful without giving away the implementation
The plugin itself — one file, one script tag, zero config

The web deserves better 2D games. Limn has always believed that. This plugin is the next step in proving it.

So when someone tells you 60fps is the ceiling, nod, and remember: ceilings are just the point where someone stopped looking up. Above them there's still sky. And above that, still space.

Limn Engine is a zero-configuration 2D game engine for the browser. One script tag, one line of code, and you're making a game. Follow the project for release announcements.

The performance plugin is under development. No release date announced yet.

What Happened After I Got a Zero for "Too Good" Code

Kehinde Owolabi — Mon, 05 Oct 2026 02:56:26 +0000

Part 2 of 2. If you haven't read Part 1 yet, start here: I Got a Zero on a Beginner Python Assignment Because My Code Was "Too Good".

Two weeks ago, I wrote about getting a temporary zero on a beginner Python assignment because my code was too feature-rich. The grader thought an AI must have written it. I argued that the rough edges — the abcdefghijklmnopqrstuvwxyz placeholder I forgot to delete, the inconsistent variable names, the Windows-only winsound — were proof it was mine.

I ended that article on a cliffhanger: the system had pushed back, and I'd just sent my appeal.

Here's what happened next.

The Instructor Replied First

Before my appeal even landed, my instructor sent me a message. And it wasn't what I expected.

"Kehinde, I didn't flag this assignment, it was our grader. As I look at this code, it was immediately obvious to me that you wrote it. I will tell the graders to grade this normally. The use of winsound is great, but I don't know what the graders will think. They won't want to install the library to test your program. It wasn't working for me so I just disabled it and the program ran fine without the sound. The graders may dock you — we'll see. If they do, you can resubmit without the sound component and I'm sure you'll be fine. It may take a couple days before it's graded, but I don't have concerns with this assignment. It looks really good — good work!"

Read that again.

The instructor — the person I'd assumed was suspicious of me — didn't flag the assignment at all. The grader did. And when the instructor actually looked at my code, his response wasn't "prove it's yours." It was:

"It was immediately obvious to me that you wrote it."

That sentence is the entire story.

What This Revealed

The system has two layers:

The grader — often a teaching assistant or automated reviewer, working from a checklist, with no context about who you are. They see code that looks "too advanced" for Week 4 and flag it. Fair enough.
The instructor — the person who knows the students, has context, and can override. They looked at my code for thirty seconds and saw what I'd been trying to explain: the quirks are the signature.

The grader followed the process. The instructor corrected it. That's how it's supposed to work.

But here's the part that matters: if I hadn't written that appeal, if I hadn't pointed at the rough edges, if I hadn't stayed calm and factual — would the instructor have looked at my code as carefully? Maybe. Maybe not. The system worked because I pushed back the right way.

The `winsound` Thing

The instructor's feedback also included a practical note I hadn't considered:

"They won't want to install the library to test your program. It wasn't working for me so I just disabled it and the program ran fine without the sound."

This is the kind of thing you only learn by shipping code to real environments. winsound is Windows-only. On Mac and Linux, the import winsound fails. My try/except caught it — so the program ran — but the sound didn't play. For a grader on a Mac, my "creative sound effects" were just dead code.

The instructor's advice was practical, not punitive: remove the sound, resubmit, you'll be fine.

So I did. Ten minutes of cleanup:

Commented out import winsound
Removed all winsound.PlaySound(...) and winsound.Beep(...) calls
Updated the creativity comment on line 1 to remove "sound effects"
Un-commented a print("Invalid input!") that had accidentally been disabled along with the winsound lines

Resubmitted.

The Grade Came Back

100/100.

Every criterion. Every point.

✅ Repeated guessing loop — 40/40
✅ Guess counter — 13/13
✅ Initial hint with spaces — 10/10
✅ Hint logic (uppercase / lowercase / underscore) — 20/20
✅ Length validation with warning — 10/10
✅ Creativity (menu, help screen, random words, loading animations) — 7/7

What I Learned

1. The System Has Layers — Use Them

A grader's flag is not the end. It's a signal for a human to look closer. If you get flagged:

Don't argue with the grader (they're following the process)
Appeal to the instructor with evidence
Offer concrete ways to demonstrate authorship

2. Not Every Instructor Is the Adversary

I spent a week assuming my instructor thought I cheated. He didn't. He thought my code was good. He was defending me to the graders while I was drafting careful-but-pissed messages to him.

The lesson: assume good faith until proven otherwise. The person on the other end is usually just trying to do their job.

3. Cross-Platform Matters

winsound is Windows-only. If you're building anything anyone else will ever run — assignments, portfolio pieces, shared tools — use cross-platform libraries or gracefully degrade. My try/except was the right idea; the execution just wasn't complete.

Better options for future projects:

pygame.mixer (cross-platform, needs install)
simpleaudio (lightweight, cross-platform)
playsound (simple wrapper, cross-platform)
Or just print ASCII/emoji feedback instead of sound

4. Creativity Should Match the Environment

My sound effects were genuinely creative — but they weren't testable on the grader's machine. That's a real problem. Creativity that only runs on your own laptop is not fully shipped.

The fix: creativity that runs everywhere. Loading animations (time.sleep) work everywhere. Random word selection works everywhere. A formatted help screen works everywhere. Sound is the one feature that broke portability — and it was the one feature I lost points for considering.

The Unexpected Part

After Part 1 went up, I got messages from:

A 30-year-old career changer flagged for a "too clean" Java project
A high schooler accused of AI on an essay he wrote himself
A teacher who said the flagging system is "broken but the only tool we have"
Two other self-taught devs in Nigeria who'd been through similar things

I wrote the first article out of frustration. But the response told me something bigger: this isn't a me problem. It's a system problem. And the way through it — for now — is to keep your receipts, stay calm, and appeal to the human on the other side.

What's Next

W05 (Shopping Cart) was already at 100/100. W06 and W07 are coming. And after that: more Limn Engine, more arcade, more shipping.

The class was never the goal. But getting through W04 taught me something no lecture could:

The rough edges are the story. Keep them. Ship them. Defend them when you have to.

And when the system works — when a teacher says "it was immediately obvious to me that you wrote it" — that's worth writing about too.

Final Thought

If you're a self-taught dev in a beginner class and you get flagged:

You're not crazy. The system is awkward.
Stay calm. Bring receipts.
Appeal to the human. The grader isn't the final word.
Fix what's asked. Even if it's small. Even if it feels unfair.
Resubmit. Usually you get the points.
Write about it. Because the next person will Google this, and your story will be the answer they find.

The system worked for me. Not smoothly, not instantly, but it worked. And that's worth saying out loud.

Kehinde Owolabi is the creator of Limn Engine and founder of Evolved Tech. He writes about self-taught development, browser game engines, and the awkward intersection of code and education.

🧹 How I Cleaned Up Limn Engine's Global Variables (and Fixed Two Bugs Along the Way)

Kehinde Owolabi — Sat, 03 Oct 2026 04:10:17 +0000

🧹 How I Cleaned Up Limn Engine's Global Variables (and Fixed Two Bugs Along the Way)

A refactor that made the engine safer to use, fixed a tile corruption bug, and corrected a particle system issue that had been hiding in plain sight.

🎯 Try the New Version

Play a game built on the updated engine:

👉 limn-engine-doc.vercel.app/arcade

Every game on the arcade runs on this version of the engine.

Grab the source:

👉 github.com/terracodes004/limn-engine-doc

📖 Introduction

Limn Engine started as a single file with a handful of global variables. That worked fine when the engine and the games were written by the same person, on the same machine, in the same session. But once games started being published to the Limn Arcade — a community platform where anyone can upload a game — the globals became a liability.

This article walks through the cleanup that fixed that. Along the way, two real bugs surfaced: a tile corruption bug that broke levels after restart, and a particle system bug that made every particle invisible on any scene other than the default.

Here's what we're going to cover:

Why global variables were a problem in the first place
How the refactor moved everything into a single namespace
The tile bug — what caused it, and how concat fixed it
The particle bug — what caused it, and how a scene parameter fixed it
A sound system simplification
What this means for existing games

🐛 The Problem with Globals

What we're going to look at: The original engine's top-level variables.

Before the cleanup, the top of epic.js looked like this:

let com;
let refresh = false;
let TCJSgameGameArea;
let commp = [];
let tileComm = [];
const comm = [];

Six globals, all sitting directly in the window's scope. Any script loaded on the same page could read them, overwrite them, or shadow them by accident. If a game defined its own let comm = ..., the engine's internal component list would silently be replaced — and the game would stop drawing anything.

The risk isn't theoretical. Two files on the same page — one being the engine, one being a game — share exactly one global scope. Every top-level declaration is a potential collision.

🛠️ What We're Going to Build

We're going to move every internal engine variable into a single object called TCJSgameVariable. That object becomes the engine's private state, and anything that wants to reach into the engine has exactly one name to remember.

While we're in there, we're going to fix two bugs that surfaced during the move.

The first is a TileMap bug that mutated the caller's tile array in place, breaking levels after a restart. The second is a ParticleSystem bug that always added particles to scene 0, making them invisible on any other scene.

And we're going to simplify the sound system by removing a broken clone-on-overlap code path.

Let me walk through each change.

🔧 Step 1: The Namespace

What we're going to do: Replace the six globals with properties on a single object.

let TCJSgameGameArea;
let TCJSgameVariable = {
  fileLoaded: true,
}
TCJSgameVariable.com = null;
TCJSgameVariable.refresh = false;
TCJSgameVariable.TCJSgameGameArea;
TCJSgameVariable.commp = [];

What we just did: We created TCJSgameVariable as the home for every internal engine value. com (the last-added component wrapper), refresh (the FPS flag), commp (the fake canvas component list), and TCJSgameGameArea (the visibility check component) are now all namespaced.

We kept TCJSgameGameArea as a global too, because existing games reference it directly. The global is set at the same time the namespace property is set, so both stay in sync.

🔧 Step 2: Updating References

What we're going to do: Change every internal use of the old globals to use the namespaced versions.

Inside Display.add():

add(x, scene = 0) {
  TCJSgameVariable.com = { x: x, scene: scene };
  TCJSgameVariable.comm.push(TCJSgameVariable.com);
}

Inside Display.updat():

TCJSgameVariable.comm.forEach((component) => {
  if (component.scene == this.scene) {
    // ...
  }
});

Inside Component.destroy():

let index = TCJSgameVariable.comm.findIndex((c) => c.x === this);
if (index > -1) TCJSgameVariable.comm.splice(index, 1);

index = TCJSgameVariable.commp.findIndex((c) => c.x === this);
if (index > -1) TCJSgameVariable.commp.splice(index, 1);

What we just did: Every read and write of the old globals now goes through TCJSgameVariable. Same logic, same behaviour — but the engine's state is now contained.

One thing to note: TCJSgameVariable.comm is declared as a plain array at the top of the file, but the actual let comm = [] line was renamed. If you're looking for where the component list lives now, it's TCJSgameVariable.comm.

🐛 Step 3: The Tile Bug

What we're going to do: Fix a bug in TileMap that corrupted the level data after restart.

Here was the original code:

class TileMap {
  constructor(render, map, tile, width, height, scene = 0) {
    this.map = [map];
    this.width = width;
    this.height = height;
    fake.canvas.width = width;
    fake.canvas.height = height;
    this.tile = tile;
    this.tile.unshift(0);   // ← This is the bug
    this.tileHeight = this.height / this.map[0].length;
    // ...
  }
}

What was wrong: unshift(0) mutates the caller's array in place. Every time a TileMap was constructed, another 0 was inserted at the front of the user's tile array.

The first level load looks like this:

// User's array
tile = [grass, stone, gold, spike, brick];

// After TileMap construction
tile = [0, grass, stone, gold, spike, brick];

The second level load — say, after a restart — looks like this:

// Same user array
tile = [0, grass, stone, gold, spike, brick];

// After TileMap construction
tile = [0, 0, grass, stone, gold, spike, brick];

Now tile[1] is 0 instead of grass. Every tile lookup is shifted by one. The entire map renders with the wrong tile IDs.

Here's the fix:

this.tile = [0].concat(tile);

What we just did: We create a new array with 0 prepended, leaving the caller's array untouched. The 0 at index 0 still serves as the "empty tile" placeholder, but the user's data is never mutated. Reloading the level any number of times produces identical results.

This bug was probably invisible for a long time because many games only loaded a level once. It only surfaced when a game restarted — or when a scene changed back to the game scene after visiting a menu.

🐛 Step 4: The Particle Bug

What we're going to do: Fix ParticleSystem so particles are added to the scene the game is actually using.

Here was the original code:

class ParticleSystem {
  constructor(display) {
    this.display = display;
    this.particles = [];
    this.emitters = [];
  }

  emit(x, y, options = {}) {
    const particle = new Particle(x, y, options);
    this.particles.push(particle);
    this.display.add(particle);   // ← No scene argument, defaults to 0
    return particle;
  }
}

What was wrong: display.add(particle) defaults to scene 0. If the game runs on scene 1 — which is where every game that uses menus lives — the particle is added to a scene that isn't being rendered. It exists. It updates. But it's never drawn.

This meant particles were silently invisible in any game that used the scene system. Explosions, sparkles, blood, smoke — none of it showed up. The code all ran without errors. The particles just never appeared.

Here's the fix:

class ParticleSystem {
  constructor(display = display, scene = 0) {
    this.display = display;
    this.particles = [];
    this.emitters = [];
    this.scene = scene;
  }

  emit(x, y, options = {}) {
    const particle = new Particle(x, y, options);
    this.particles.push(particle);
    this.display.add(particle, this.scene);
    return particle;
  }
}

What we just did: The ParticleSystem now stores the scene number it should render to, and passes it to display.add() for every particle. A game that runs on scene 1 can now create particles that actually appear.

The default value of scene = 0 preserves backwards compatibility with any existing code that used particles on the default scene.

🔊 Step 5: The Sound System Simplification

What we're going to do: Remove a broken clone-on-overlap code path from Sound.play().

Here was the original:

play(volume = this.volume) {
  if (!this.loaded) {
    console.warn(`Sound not loaded yet: ${this.src}`);
    return this;
  }

  // Clone for overlapping sounds (effects)
  if (this.loop === false && this.audio.currentTime > 0) {
    const clone = new Sound(this.src, { volume: volume });
    clone.play();
    return clone;
  }

  this.audio.volume = volume;
  this.audio.currentTime = 0;
  this.audio.play();
  return this;
}

What was wrong: The clone-on-overlap block looked clever, but it never worked. When you create new Sound(...), the constructor starts loading the file asynchronously. The loaded flag doesn't become true until the browser fires canplaythrough — which happens on a later microtask, not synchronously.

So when clone.play() is called on the very next line, clone.loaded is still false. The guard at the top of play() returns immediately, and the clone never plays. Every "overlap" was silently dropped.

The fix is simply to remove the block:

play(volume = this.volume) {
  if (!this.loaded) {
    console.warn(`Sound not loaded yet: ${this.src}`);
    return this;
  }

  this.audio.volume = volume;
  this.audio.currentTime = 0;
  this.audio.play().catch((e) => console.warn("Audio play prevented:", e));
  return this;
}

What we just did: Now every call to play() produces audible sound. If the sound is already playing, currentTime = 0 rewinds it and play() restarts it. That's a much better default than a code path that silently fails.

If layering is ever needed — for example, a shotgun spread playing two distinct shots in the same frame — the right fix is to pre-build a small pool of Audio elements at load time and cycle through them. Cloning on demand, which is what the old code tried to do, will always fail for the same reason.

📊 Before and After

Aspect	Before	After
Engine state	6+ globals in the window scope	Contained in `TCJSgameVariable`
Level restart	Tile IDs corrupted by repeated `unshift`	Levels reload correctly
Particles on non-zero scenes	Silently invisible	Correctly added to the game's scene
Overlapping sounds	Broken clone-on-overlap path	Restarts the sound cleanly
Backwards compatibility	N/A	`TCJSgameGameArea` still global

📊 What You've Learned

Concept	Why It Matters
Namespacing	Keeps engine internals from colliding with user code
`concat` vs `unshift`	`unshift` mutates the caller's array — `concat` returns a new one
Scene-aware object creation	Objects added to the wrong scene are invisible, not broken
Async loading pitfalls	Anything that depends on `.loaded` must wait for the load event
Clone-on-demand	A clone that hasn't loaded can't play
Backwards compatibility shims	Keeping a global alive while also namespacing it costs nothing

⚠️ A Note on Backwards Compatibility

If any existing game on the arcade references comm, commp, tileComm, or refresh directly, those references will now throw ReferenceError. In practice, none of the published games do — those were never part of the documented API — but it's worth knowing.

The engine itself has been updated to use TCJSgameVariable.* throughout, so the internal reference path is complete. Only external code that reached into engine internals would be affected.

The TCJSgameGameArea global is preserved because it was used externally. Both the global and the namespace property are set in Display.start().

🚀 What's Next?

Now that the engine's state is contained, the next cleanup targets are:

Wrapping the engine in an IIFE or ES module so even TCJSgameVariable isn't on the window
Adding JSDoc comments to every public method
Renaming confusing variables like comm and commp to componentList and fakeComponentList
Adding a timeScale property to Display so games can pause cleanly without setting dt to 0

If you build any of these, send a pull request.

🐛 Report Bugs

If you find a bug introduced by this refactor, report it on GitHub:

👉 github.com/terracodes004/limn-engine-doc/issues

🔗 Resources

Resource	Link
Limn Engine Docs	limn-engine-doc.vercel.app
Limn Studio	limn-engine-doc.vercel.app/editor
Limn Arcade	limn-engine-doc.vercel.app/arcade
GitHub Repository	github.com/terracodes004/limn-engine-doc
Report Bugs	github.com/terracodes004/limn-engine-doc/issues
Kehinde on DEV.to	dev.to/kehinde_owolabi_e2e54567a
Desire on DEV.to	dev.to/desire_george_434_ai

🎯 The One-Line Summary

"Moving Limn Engine's globals into a namespace also surfaced a tile corruption bug and a particle scene bug — both fixed in the same pass." 🧹🚀

Draw your game into existence — one refactor at a time. 🎮🚀

I Got a Zero on a Beginner Python Assignment Because My Code Was "Too Good"

Kehinde Owolabi — Wed, 30 Sep 2026 12:02:32 +0000

I Got a Zero on a Beginner Python Assignment Because My Code Was "Too Good"

How AI paranoia in education is punishing self-taught developers — and why my sloppy code is the proof I wrote it.

I'm 18. I've been coding since I was 15. I built a 2D HTML5 game engine called Limn Engine that runs on a single JavaScript file. I co-founded a studio called Evolved Tech. I ship code every week.

Last week, I submitted a Wordle-style word puzzle for my intro Python class (CSE 110 at BYU-Pathway).

I got a zero.

The comment: "It looks like you may have gotten too much outside help on this assignment."

Let me tell you why that stings — and why it's a problem the entire industry needs to think about.

The Submission

The assignment: build a word guessing game. Secret word, hints (uppercase = correct spot, lowercase = present but wrong spot, _ = absent), guess counter, length validation. Standard Week 4 stuff.

I submitted that. Plus:

A main menu (Play / Help / Quit)
Random word selection from a list
A formatted help screen with examples and a rules table
Sound effects (winsound) with cross-platform fallback
Loading animations (time.sleep)
In-game navigation commands (1 = menu, 2 = quit)
Emoji everywhere

Every single feature works. Every feature is mine.
See python code here
The instructor flagged it anyway.

The Irony: My Code Isn't Even That Clean

Here's the thing that gets me. If an AI had written my submission, it would have been cleaner.

My code has rough edges everywhere — the kind you only get from a human typing fast and shipping without a refactor pass. Here's the actual evidence:

1. The word list was a string, not a list

words = "temple church food nephi guess moroni mosiah video correct..."
word_list = words.split(" ")

A pro (or an LLM) writes:

words = ["temple", "church", "food", "nephi", ...]

I didn't. I used a string and .split(" ") because it was faster to type.

2. I left a placeholder in the word list

words = "... abcdefghijklmnopqrstuvwxyz helaman"

That's a 26-letter "word" sitting in my list of guessable words. It's impossible to guess. I forgot to remove it.

No AI would leave that in. It would break the game on a theoretical level. But I typed the list by hand and never cleaned it up. That oversight is my signature.

3. Bare `except:` instead of `except ImportError:`

try:
    import winsound
    SOUND = True
except:
    SOUND = False

A pro writes except ImportError:. I wrote except: because I was moving fast.

4. Inconsistent variable names

no_of_children = int(input("How many children are there? "))
no_of_adult    = int(input("How many adults are there? "))

children (plural) vs adult (singular). An LLM would never do that. I did.

5. Duplicate entries in the word list

temple, altar, hymn, prayer, mercy, kindness — each appears twice. Manual typing, no dedup pass.

6. Windows-only `winsound`

I used winsound for sound effects — which crashes on Mac and Linux. A pro would reach for a cross-platform lib. I built for my own machine and didn't care.

Every one of those is a mark of authorship. They're not signs that I copied something — they're signs that I didn't.

The Real Problem: Competence Looks Like Cheating Now

Here's the uncomfortable truth about AI detection in 2026:

The more competent you are, the more suspicious you look.

AI writes clean, feature-rich, well-structured code. So when an instructor sees a submission that's too feature-rich — too far ahead of the rubric — the default assumption has flipped from "this student is talented" to "this student cheated."

That assumption punishes exactly the wrong people:

Self-taught devs who learned outside the classroom
Career changers with professional experience
Students with real portfolios taking intro classes for credit
Anyone whose side projects are years ahead of the curriculum

The paradox: the more evidence you have that you can code, the more suspicious your classwork looks.

How I Handled It

I didn't get defensive. I wrote my instructor a message that did four things:

Owned the situation calmly — acknowledged the concern was reasonable
Explained my background — Limn Engine, Evolved Tech, years of shipping
Pointed to the rough edges — the exact quirks above, as proof of authorship
Offered verification — line-by-line walkthrough, oral quiz, live coding, or a simpler version that strictly meets the rubric

That's the playbook. Not "you should have known better." Not accusations. Evidence + willingness + respect.

The instructor isn't the villain. Their job is to make sure students actually understand the material, and AI has made that job exponentially harder. If I were in their seat, I'd be paranoid too.

What Educators Should Do Differently

If you're an instructor reading this, here's what I'd ask:

Look at style, not just features. Feature-rich ≠ AI-generated. Rough edges matter.
Ask before accusing. "Can you walk me through this?" is a better first move than a temporary zero.
Shift toward process-based assessment. Oral quizzes, live coding, commit history — these tell you far more than a final product ever could.
Assume good faith first. Some of your students are building game engines at 2 AM on 4GB laptops. They exist.

And if you're a self-taught dev taking formal classes:

Don't dumb down your work. That's a losing game.
Keep your drafts and commit history. Evidence matters.
Be able to explain every line. If you can't explain it, you don't own it.
When you get flagged, don't panic. Offer to demonstrate. Make it easy for the instructor to verify.
Rough edges are your friend. Don't polish so much that the work stops looking like yours.

The Bottom Line

I'm not mad at my instructor. I'm frustrated at the system that made this inevitable — one where years of self-taught effort looks indistinguishable from a chatbot's output, and where the only way to prove yourself is to stand in front of someone and explain what you wrote.

Which, honestly, is exactly what should have happened from the start.

The rough edges in my code aren't bugs.

They're the receipts.

See python code here
What's your experience? Have you been flagged for "too good" work? Or are you an educator trying to navigate this mess? Drop it in the comments — I'd love to hear both sides.

I'm Kehinde Owolabi, creator of Limn Engine and founder of Evolved Tech. I build browser games and game tooling. Follow me if you want more posts about self-taught development, tooling, and the messy intersection of code and education.

Limn Arcade — Play, Create, Share

Kehinde Owolabi — Tue, 29 Sep 2026 04:18:20 +0000

Limn Arcade — Play, Create, Share

The community platform where Limn Engine games live. User accounts, weekly winners, offline play, forking, and more.

Live Demo

Open the arcade:

https://limn-engine-doc.vercel.app/arcade

Browse games, sign in, play in the browser, like them, fork them, and publish your own — no installs.

Build your own in Limn Studio:

https://limn-engine-doc.vercel.app/editor/

Introduction

The Limn Arcade is the community platform for Limn Engine — a place where anyone can sign in, publish games, play games made by others, and build their own in the browser. It was built and maintained by Desire (https://dev.to/desire_george_434_ai), the same developer behind Limn Studio.

Since launch, the arcade has grown into a real ecosystem: creators sign in, publish games, receive likes and comments, and the best submissions get spotlighted on the home page. This article walks through the latest features.

Here's what we're going to cover:

User accounts and how sign-in works
The Game of the Week and Hall of Fame system
Offline play and how it works
Forking games to remix them
Discovery tools — search, filters, and creator pages
How to publish your own game
What's coming next

User Accounts

What we're going to look at: How accounts work on the arcade.

Every action that involves identity requires you to be signed in. When you try to like a game without an account, the arcade shows a prompt:

"Log in to like."

The same applies to comments and publishing. The My Games page shows your published games when you're signed in, and a Sign in link when you aren't:

"Log in to see your games."

Your handle is what appears on every game you publish. For example, all of the Limn League titles on the arcade are attributed to @kehindeowolabi04.

What we've seen: Accounts are the backbone of the arcade. They connect likes, comments, and games to specific people, so credit and reputation build up over time.

Game of the Week and Hall of Fame

What we're going to look at: How the weekly winner system works.

Every week, one game is selected as the Game of the Week. It gets the prime spot on the home page, a gold banner, and a featured card in the Game of the Week section.

When a new week begins, the previous winner is promoted to Last Week's Winner — displayed in a separate card above the Hall of Fame. Past winners are archived in the Hall of Fame, which shows the total number of past winners and lets you browse the full history.

Stage	Where It Appears	What It Shows
Current week	Game of the Week card	Title, author, likes, Play button
Following week	Last Week's Winner card	Title, likes, Play button
All time	Hall of Fame	Trophy icon, count of past winners

What we've seen: The system creates a clear path from "playable right now" to "part of the platform's history."

Offline Play

What we're going to look at: How the arcade lets you play games without an internet connection.

Every game page has a Saved Offline button. When you tap it, the game is cached in your browser so it can be played later without a network connection. The home page's Offline tab lists every game you've saved, with a badge showing how many you have stored.

Offline play is powered by the browser's standard caching and service worker APIs. Once a game is saved, it loads instantly from the local cache.

This is useful for:

Playing on a train or plane
Playing in areas with unreliable internet
Reducing data usage on mobile
Loading games instantly when you already know what you want to play

What we've seen: The offline system turns the arcade into an app-like experience.

Forking Games

What we're going to look at: How to clone someone else's game and modify it.

Every game page has a Fork button next to Share. Forking creates a personal copy of that game's source code, which you can edit in Limn Studio and republish as your own variant.

The original game's author remains credited — the fork keeps a link back to the source — and any changes you make are stored under your own account.

Forking is useful for:

Learning how someone else built a mechanic
Extending an existing game with new levels
Remixing a game into a new genre
Collaborating with other creators

What we've seen: Forking turns the platform from a place where you play games into a place where you build on each other's work.

Discovery Tools

What we're going to look at: The search, filter, and browse tools.

The arcade has three ways to find games.

Search accepts free text and matches against both game titles and creator handles. Typing part of a name returns matching results in real time.

Filter tabs let you switch between Creators, Projects, and Offline. The Creators view shows publishers and their games. The Projects view is the default grid of published games. The Offline view shows only games you've saved for offline play.

Game cards display a lot of information at a glance: a thumbnail, title, author handle, like count, short description, and tags. Clicking a card opens the game's detail page.

What we've seen: Discovery is fast. Everything is reachable in two taps or fewer.

Anatomy of a Game Page

What we're going to look at: Everything that appears when you open a single game.

The game title and author are at the top, along with the total like count. The author handle is a link to their profile.

The description summarises the game in a sentence or two.

The preview thumbnail shows a frame of gameplay, generated from the game itself when it's published.

The action buttons are grouped below the description:

Button	What It Does
Like (heart icon)	Adds a like to the game's total
Share	Opens a share sheet to send the link
Fork	Creates a personal copy of the game's code
Saved Offline	Caches the game for offline play
Fullscreen	Launches the game in fullscreen mode
Volume (− 50% +)	Adjusts the game's audio level
Back to Arcade	Returns to the arcade home

The comments section appears at the bottom. It shows every comment in order, and each one can be replied to.

What we've seen: The game page is a self-contained hub — everything you'd want to do with a game is on one screen.

How to Publish Your Own Game

What we're going to do: Walk through the steps to get a game onto the arcade.

Sign in to the arcade.
Tap + New in the header.
Paste or upload your game code.
Give the game a title, a short description, and any tags.
Tap share.

Your game appears in the arcade immediately. It gets its own detail page with a shareable URL, and it's added to the grid on the home page.

From there, you can:

Watch the like count grow
Reply to comments
Save your own game for offline play
Fork other games to build new variants

What we've done: We've published a game to the arcade. It's now visible to every other player on the platform, and it's eligible for the weekly Game of the Week selection.

What's in the Arcade Right Now

At the time of writing, some of the games on the arcade include:

Game	Author	Genre
Limn League Pro (with harder and smarter ai)	@kehindeowolabi04	Browser football career sim
Limn League 2027	@kehindeowolabi04	Full 11v11 football
Limn League 2026	@kehindeowolabi04	Full 11v11 browser football
Sniper 1.0	—	Last week's winner
Star fight	@dezzy	Space shooter
bbb	@dezzy	Platformer

Limn League Pro is the current Game of the Week. Its description reads:

"Limn League 2027 Pro — Browser football career sim. Climb 12 divisions, win 5 cup tiers, or grind 30 championship matches. Four difficulty levels, smart AI, real keepers. No installs."

What we've seen: The arcade already has a range of genres — sports sims, platformers, shooters — from multiple creators.

What You've Learned

Concept	Why It Matters
User accounts	Sign in to like, comment, and publish; every game is attributed to a handle
Game of the Week	Spotlights one game per week, with a visible path into the Hall of Fame
Hall of Fame	Preserves every past winner in a browsable archive
Offline play	Caches games locally so they're available without internet
Forking	Clones a game's source code so you can remix it
Filter tabs	Creators, Projects, and Offline views for different discovery needs
Game detail page	Everything you can do with a game, on one screen
Publishing	Sign in, tap + New, paste your code, publish

Known Limitations

The Game of the Week selection is currently curated rather than voted on by the community.

Offline play depends on the browser's service worker support. Older browsers may not cache games reliably.

Forking preserves the original author's credit but doesn't automatically sync changes back to the source.

These are deliberate trade-offs — the arcade was designed to be simple to use, not to replicate every feature of a full social platform.

What's Next?

The arcade is still growing. Directions the platform could take next:

Community voting for the Game of the Week
Comment notifications so creators know when someone replies
A featured creators section on the home page
Cross-game tournaments
A public API so external tools can browse the arcade

If you have an idea, open an issue on GitHub.

Report Bugs

https://github.com/terracodes004/limn-engine-doc/issues

Resources

Resource	Link
Limn Arcade	https://limn-engine-doc.vercel.app/arcade
Limn Engine Docs	https://limn-engine-doc.vercel.app
Limn Studio (Editor)	https://limn-engine-doc.vercel.app/editor/
GitHub Repository	https://github.com/terracodes004/limn-engine-doc
Report Bugs	https://github.com/terracodes004/limn-engine-doc/issues
Desire on DEV.to	https://dev.to/desire_george_434_ai
Kehinde on DEV.to	https://dev.to/kehinde_owolabi_e2e54567a

One-Line Summary

The Limn Arcade is where Limn Engine games live — with user accounts, a Game of the Week, a Hall of Fame, offline play, forking, and a growing community of creators.

Draw your game into existence — one publish at a time.

Building Limn League 2027: A Complete Football Game in Pure JavaScript

Kehinde Owolabi — Sat, 26 Sep 2026 01:04:46 +0000

How I Built a Full 11v11 Football Game in Vanilla JavaScript — With Man-Marking AI

▶ Play Limn League 2027

There are 22 players on the pitch, one ball, and a single <canvas>. Every one of those players has to decide — every single frame — whether to chase, hold shape, mark an opponent, or drop back. Doing this at 60fps in plain JavaScript taught me more about game AI than any tutorial ever did.

This is the story of Limn League 2027 — a full 11v11 football game that runs in any browser. No downloads. No frameworks. No build tools. Just the browser's animation loop, a 2D canvas, and a lot of math.

It runs on Limn Engine, a custom canvas game engine I wrote in vanilla JavaScript. Everything you're about to read is built from primitives: components, vectors, and state machines.

Let me walk you through how it works.

The Core Problem: 22 Players, Zero Scripts

Most browser football games cheat. They teleport the ball, script the animations, and fake the AI with pre-recorded paths. I wanted something that felt like football — where the players on your team actually support you when you attack and actually track back when you lose the ball.

That means every outfield player needs to answer three questions on every frame:

What is my role right now? (attacker, defender, chaser, marker)
Where should I be? (a target position, not the ball)
What is everyone else doing? (because 10 other players are asking the same questions)

Answer all three every frame for 22 players, and you have football. Get it wrong, and you get the classic "everyone chases the ball in a mob" problem.

Man-Marking AI: The Hardest Part

The biggest technical challenge was defensive positioning. Early versions had defenders run directly at the ball carrier — which looks like football for about five seconds, then falls apart the moment you pass.

The fix was a proper man-marking system. Here's the idea:

Every defender on the AI team gets assigned one specific attacker to mark
The assignment refreshes every 0.4 seconds (any faster and it flickers; any slower and they react late)
Markers stand goal-side of their target — between the attacker and their own goal — at a distance scaled by difficulty
The closest defender breaks off to press the ball, and on hard difficulties a second defender doubles up

The whole defensive shape is computed as distances from a role anchor, not from the ball. This is the key insight: players move toward a position that shifts based on game state, not toward the ball. That's what gives you the illusion of a real team holding its shape.

Every defender knows their job. They don't all converge on the ball. They cover the space, they track the runners, and they let the closest one press. That's how real football works, and that's how the AI plays.

Difficulty That Actually Scales

Most games fake difficulty by giving AI players more speed or faster reactions. I wanted a proper skill curve — where a 1★ team plays like a Sunday league side and a 10★ team feels like playing against a human pro.

So every AI team's behaviour is driven by a skill profile with multiple independent parameters. Rather than a single "difficulty" number, each team gets its own combination of traits that scale from 1 star to 10:

Chase speed — how aggressively they close down the ball carrier
Marking tightness — how close they stand to their mark
Mark refresh rate — how quickly they reassign marks when you pass
Pass accuracy — how much angle noise is added to their passes
Shot accuracy — how much angle noise is added to their shots
Shooting range — how far from goal they're willing to try
Error rate — how often they fumble a loose ball
Double-team flag — whether they send a second defender at you
Goal-side marking flag — whether they mark from the goal side or just track

At 1★, defenders mark loosely, miss easy chances, and pass into traffic. At 10★, they press instantly, thread through-balls, and double-team your ball carrier. Same code path, different numbers.

The error rate was the most satisfying parameter to tune. At 1★, an AI player has a meaningful chance of fumbling a loose ball — which feels chaotic and fun. At 10★, that chance is almost zero — which feels surgical.

The Career: 12 Divisions, 96 Teams

The game isn't just one match — it's a full career mode. You start in the Street Division and work your way up through 11 more tiers to the Immortal League.

Street → Amateur → Semi-Pro → Championship → Premier → Continental → Limn Elite → Galactic → World Class → Legendary → Mythic → Immortal

Each division has eight rival clubs with star ratings matching the tier. Every season is seven matches. Finish first — and only first — to promote. Anything else, and you replay the same division with a fresh draw.

The AI opponents you don't play each round still simulate their own matches, so the league table keeps moving. Your promotion depends on how you perform relative to everyone else, not just on your own results.

Five Cup Tiers and a Championship Grind

Beyond the career league, there are two other competition tracks:

The Cup — five tiers (Bronze → Silver → Gold → Platinum → Diamond). Each cup is a group stage plus knockout rounds. Only the champion unlocks the next tier.
Championship Mode — pick any of the 96 clubs and play 30 matches with them. Complete it for the biggest coin payout in the game.

All three tracks run in parallel. You can be mid-career, mid-cup, and mid-championship at the same time — which gives players something to do no matter what mood they're in.

Controls That Work on Touch and Keyboard

Most browser games pick a platform and half-ass the other. I wanted Limn League 2027 to feel native on both.

On mobile:

A real analog stick in the bottom-left corner. Drag it anywhere within its zone and the knob follows your finger. Move the stick gently to jog, push it hard to sprint, drag it diagonally to move diagonally.
A / B / C action buttons in the bottom-right. A passes, B shoots or slide-tackles, C sprints.
The game detects your device and pre-zooms to 50% so the pitch fits your screen.

On desktop:

WASD or arrow keys to move.
F passes, Space shoots or tackles, Shift sprints.
Full-screen pitch, mouse-driven menus.

A subtle detail that mattered: shot aiming uses the analog stick. Push the stick toward the top-left corner, and your shot goes toward the top-left corner. Nothing auto-aims at the goal — you aim, you shoot.

Squads That Actually Upgrade

You earn coins every match, and those coins buy four permanent upgrades:

Speed — applies to your entire team, not just your controlled player
Shooting — powers up shots and improves your teammates' passing
Stamina — your sprint lasts longer, drains slower
Defense — you're harder to tackle, and your ball shield lasts longer after winning possession

Upgrades aren't cosmetic. If you max Speed, your whole team moves visibly faster. If you max Defense, you can hold the ball under pressure for noticeably longer. Every coin spent is felt on the pitch.

Costs scale steeply — the first upgrade costs a few hundred coins, the last costs tens of thousands. Maxing everything takes a long time. But the milestones along the way feel meaningful.

The Little Details

Some smaller features that make the game feel finished:

Player collision — no more ghosting through each other. Every player physically separates from the others.
Ball shield mechanic — after winning the ball, you can't be tackled for a fraction of a second. Prevents the tackle ping-pong you see in some arcade football games.
Slide tackle cooldown — miss a slide, and you're out of the play for a moment. Encourages clean defending.
3-2-1-GO countdown before every kickoff and after every goal.
Particle celebrations — bursts of colour from the goal mouth.
Camera shake — subtle, on goals and big hits.
Match analysis after every game — possession, shots, passes, tackles, and coins earned.

What I Learned

A few takeaways from building this:

1. AI isn't about smart decisions. It's about consistent decisions.

The hardest part of the AI wasn't making defenders clever — it was making them predictable enough to feel real. A defender who always stands goal-side is more convincing than one who occasionally does something brilliant.

2. Frame-rate independence is non-negotiable.

Every movement in Limn League 2027 is scaled by time delta. If I hadn't done this from day one, the game would run at wildly different speeds on a phone vs a desktop. Retrofitting it is painful. Do it upfront.

3. Difficulty is not a single number.

If you want a game that's genuinely easy at the bottom and genuinely brutal at the top, you need multiple independent levers. Speed alone is boring. Combining speed, marking tightness, error rate, and shot accuracy creates a real skill curve.

4. Mobile browsers will fight you.

Touch events, viewport quirks, and the fact that a single tap can fire both a touch event and a synthetic mouse event 300ms later — I spent more time debugging mobile input than any other single feature. If you're building for mobile, expect it.

Play It Now

Limn League 2027 is free, runs in any modern browser, and saves everything locally — no signup, no server required once it loads.

▶ Play Limn League 2027

Whether you're building a Street Division club into an Immortal League powerhouse, hunting your first Bronze Cup trophy, or just settling in for a thirty-match grind — it's a full football game in your browser.

No downloads. No signup. Just football.

If you build something on top of it, fork it, or have feedback, let me know in the comments. I read every one.

Built with vanilla JavaScript on the Limn Engine — a custom canvas game engine. No React, no Vue, no bundler. Just a canvas and a lot of animation frames.

🎮 Neon Caverns — Source Code Deep Dive

Kehinde Owolabi — Tue, 22 Sep 2026 05:02:08 +0000

🎮 Neon Caverns — Source Code Deep Dive

Every class, every system, every design decision — explained line by line.

🎯 Live Demo

Play Neon Caverns right now:

👉 limn-engine-doc.vercel.app/arcade/game.html?slug=noen-caverns-thc5

Source code:

👉 github.com/terracodes004/limn-engine-doc

Follow Kehinde on DEV.to for updates:

👉 dev.to/kehinde_owolabi_e2e54567a

📖 Introduction

Neon Caverns is a 2D platformer built with Limn Engine. It has three levels, enemies with patrol-and-chase AI, a boss fight, moving platforms, coins, hearts, a full menu system, pause screen, settings screen, and level select — all in a single JavaScript file.

It's a good example of what a complete Limn Engine game looks like once you move past tutorials. This article walks through the source code to show how each piece is built and why.

In this article, we'll cover the scene system, the custom class hierarchy, the tile collision resolution, the enemy AI, the boss fight, the moving platforms, and the UI. By the end, you'll understand how a full platformer is put together in Limn Engine.

🏗️ The Big Picture

Before diving into the code, let's look at the overall structure of the game. It's organised into five layers:

Layer 1 — Scene constants. Seven numbers that identify each game screen: menu, game, over, win, pause, settings, and level select.

Layer 2 — Global state. Variables like player, enemies, coins, and score that hold the current state of the running game.

Layer 3 — Custom classes. Three classes that extend Component: PatrolEnemy, MovingPlatform, and BossEnemy. Each adds its own behaviour.

Layer 4 — Scene builders. Functions that create the components for each scene: buildMenuScene, buildGameScene, buildPauseScene, and so on.

Layer 5 — Scene updates. One update function per scene — updateMenu, updateGame, updatePause, etc. — dispatched from a single update(dt) entry point.

The main loop calls update(dt), which reads display.scene and forwards to the right scene update function. That's the whole flow.

🎬 The Scene System

What we're going to do: Set up seven scene constants so every screen in the game has its own number.

const SCENE_MENU     = 0;
const SCENE_GAME     = 1;
const SCENE_OVER     = 2;
const SCENE_WIN      = 3;
const SCENE_PAUSE    = 4;
const SCENE_SETTINGS = 5;
const SCENE_LEVEL    = 6;
let currentScene = SCENE_MENU;
let settingsReturnScene = SCENE_MENU;
let selectedLevel = 0;
let sceneEnterTime = 0;

What we just did: We gave each screen its own numeric ID. When we call display.add(component, sceneNumber), the engine only draws and updates that component when display.scene matches. This is how we build seven different screens without ever destroying and recreating objects — every component exists in memory at all times, but only the active scene's components are visible and interactive.

We also track settingsReturnScene so that when the player opens settings from either the menu or the pause screen, we know where to send them back.

🚪 Switching Scenes

What we're going to do: Write a function that changes the active scene, clears input state, and resets the camera.

function goToScene(n) {
    currentScene = n;
    display.scene = n;
    sceneEnterTime = Date.now();
    clearHitAreas();

    if (n === SCENE_GAME) {
        fake.tileFace.show();
        display.once = true;
        display.camera.x = 0;
        display.camera.y = 0;
    } else if (n === SCENE_PAUSE) {
        display.once = false;
        display.camera.x = 0;
        display.camera.y = 0;
    } else {
        fake.context.clearRect(0, 0, fake.canvas.width, fake.canvas.height);
        display.once = false;
        display.camera.x = 0;
        display.camera.y = 0;
    }
}

What we just did: When we switch scenes, we reset the camera to (0,0) so every menu starts from a consistent position, and we clear the hit areas so no button from the previous scene accidentally fires. When entering the game scene, we tell the engine to redraw the fake canvas (which holds the level's static tiles) and we set display.once = true to force a one-time cache refresh.

sceneEnterTime is a timestamp we use later to ignore taps for a brief moment after a scene change — otherwise a click that starts the game could immediately trigger a button on the next screen.

🖱️ The Input System

What we're going to do: Build a button registry that tracks every clickable rectangle in every scene.

const interactables = {};

function makeButton(scene, id, x, y, w, h, label, opts) {
    opts = opts || {};
    const baseColor = opts.color || "rgba(124,58,237,0.7)";
    const hoverColor = opts.hoverColor || "rgba(124,58,237,1)";

    const btn = new Component(w, h, baseColor, x, y, "rect");
    btn.changeAngle = false;
    btn.move = function () {};
    display.add(btn, scene);

    let lbl = null;
    if (label) {
        lbl = new Tctxt(opts.fontSize || "22px", "Arial", opts.textColor || "white",
                        x + w / 2, y + h / 2, "center", false, "middle", "transparent");
        lbl.setText(label);
        display.add(lbl, scene);
    }

    interactables[id] = { x, y, w, h, active: false, scene, btn, lbl, baseColor, hoverColor };
    return btn;
}

What we just did: We built a helper that creates a button component, an optional text label, and an entry in the interactables registry. Every button in the game is created through this function, which means every button has a matching hit rectangle in interactables. That makes click detection uniform — one loop over the registry handles every button on the current scene.

We also disable changeAngle and override move on each button so it doesn't rotate or drift — buttons are static.

📐 Converting Touch and Click Coordinates

What we're going to do: Write a function that converts a browser event into canvas coordinates, accounting for CSS scaling.

function getCanvasCoords(clientX, clientY) {
    const canvas = display.canvas;
    const rect = canvas.getBoundingClientRect();
    const sx = canvas.width / rect.width;
    const sy = canvas.height / rect.height;
    return { x: (clientX - rect.left) * sx, y: (clientY - rect.top) * sy };
}

What we just did: We built the same coordinate conversion we covered in the limn-click article. getBoundingClientRect() gives us the canvas's real position on the page, and dividing the internal canvas size by that gives us the scale factor. This is what makes buttons work on phones where the canvas is scaled to fit the screen.

Without this, taps on mobile would land in the wrong place — the coordinates would be in screen space instead of canvas space.

🖲️ Hit Detection and Input Dispatch

What we're going to do: Write functions that read every active touch or click, check it against the current scene's buttons, and mark which ones are being pressed.

function updateHitAreas(e) {
    if (Date.now() - sceneEnterTime < 250) {
        clearHitAreas();
        return;
    }

    for (const key in interactables) interactables[key].active = false;

    const list = e.touches
        ? Array.from(e.touches)
        : (e.clientX !== undefined ? [e] : []);

    for (const t of list) {
        const p = getCanvasCoords(t.clientX, t.clientY);
        for (const key in interactables) {
            const a = interactables[key];
            if (a.scene !== currentScene) continue;
            if (p.x >= a.x && p.x <= a.x + a.w &&
                p.y >= a.y && p.y <= a.y + a.h) {
                a.active = true;
            }
        }
    }
}

What we just did: Every time a mouse or touch event fires, we clear all buttons, then loop through every active pointer and check it against every button in the current scene. If the pointer is inside a button's rectangle, that button is marked active.

The 250ms guard at the top prevents taps from bleeding through from one scene to the next. Without it, a tap that starts the game could immediately register on the game's pause button.

🗺️ Level Data

What we're going to do: Define three levels as 2D arrays of tile IDs.

const LEVELS = [
    {
        name: "Caverns",
        map: [
            [1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1],
            [1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1],
            // ... more rows ...
            [2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2],
        ],
        enemyCount: 7,
        bossHP: 3,
        bossX: 1750,
        bossChaseSpeed: 2.4,
    },
    // ... Towers, Boss Arena ...
];

What we just did: Each level is an object with a map — a grid of numbers where each number is a tile type — plus metadata: how many enemies to spawn, the boss's HP, where the boss starts, and how fast the boss chases.

The tile IDs are: 0 for empty, 1 for grass (solid), 2 for stone (solid), 3 for gold (solid), 4 for spike (damaging), and 5 for brick (solid). The game distinguishes between solid tiles and spikes when it builds the tile list.

👾 Custom Enemy Class — PatrolEnemy

What we're going to do: Create a class that extends Component and gives enemies three AI states: patrol, chase, and return.

class PatrolEnemy extends Component {
    constructor(x, y, cfg) {
        super(30, 30, cfg.color || "#ff4500", x, y, "rect");
        this.physics = true;
        this.gravity = 0.7;
        this.bounce = 0;
        this.onGround = false;
        this.move = function () {};
        this.patrolLeft = cfg.patrolLeft;
        this.patrolRight = cfg.patrolRight;
        this.dir = 1;
        this.patrolSpeed = cfg.patrolSpeed || 1.5;
        this.chaseSpeed  = cfg.chaseSpeed  || 2.8;
        this.detectRangeX = cfg.detectRangeX || 260;
        this.detectRangeY = cfg.detectRangeY || 130;
        this.lostGrace = 90;
        this.lostTimer = 0;
        this.state = "patrol";
        this.baseColor = cfg.color || "#ff4500";
        this.chaseColor = "#ff0033";
        this.returnColor = "#ffdd00";
    }
    // ... think() method below ...
}

What we just did: We subclassed Component so enemies inherit all the collision and drawing logic, then added enemy-specific fields: how far to patrol, how fast to move, how far to detect the player, and how long to chase after losing sight.

We overrode move to a no-op because we want to control the enemy's position manually — the engine's built-in physics isn't flexible enough for the collision system we're using. The physics flag and gravity value are still there so the base class knows the entity has mass.

The Enemy AI Think Method

What we're going to do: Write a think() method that runs every frame and updates the enemy's state based on the player's position.

think(player) {
    const dx = player.x - this.x, dy = player.y - this.y;
    const canSee = Math.abs(dx) < this.detectRangeX && Math.abs(dy) < this.detectRangeY;
    if (canSee) {
        this.state = "chase";
        this.lostTimer = this.lostGrace;
    } else if (this.state === "chase") {
        this.lostTimer--;
        if (this.lostTimer <= 0) this.state = "return";
    }
    if (this.state === "chase") {
        if (dx < -4) this.dir = -1;
        else if (dx > 4) this.dir = 1;
        this.speedX = this.dir * this.chaseSpeed;
        this.color = this.chaseColor;
    } else if (this.state === "return") {
        const center = (this.patrolLeft + this.patrolRight) / 2;
        if (Math.abs(this.x - center) < 12) this.state = "patrol";
        else {
            this.dir = this.x < center ? 1 : -1;
            this.speedX = this.dir * this.patrolSpeed;
        }
        this.color = this.returnColor;
    } else {
        this.speedX = this.dir * this.patrolSpeed;
        if (this.x <= this.patrolLeft) this.dir = 1;
        if (this.x + this.width >= this.patrolRight) this.dir = -1;
        this.color = this.baseColor;
    }
}

What we just did: We built a three-state state machine.

In the patrol state, the enemy walks back and forth between two points, flipping direction when it reaches either boundary.

In the chase state, the enemy moves toward the player at a faster speed, changing direction based on which side the player is on.

In the return state, the enemy walks back to the centre of its patrol area, then transitions back to patrol.

The transitions are: patrol → chase when the player enters detection range, chase → return after losing sight for lostGrace frames, return → patrol when the enemy reaches home. Each state also sets a different colour — orange for patrol, red for chase, yellow for return — so the player can read the enemy's intent at a glance.

🎢 Custom Platform Class — MovingPlatform

What we're going to do: Create a platform that oscillates along an axis using a sine wave, and that carries the player when they're standing on it.

class MovingPlatform extends Component {
    constructor(x, y, w, h, cfg) {
        super(w, h, "#00ccff", x, y, "rect");
        this.changeAngle = false;
        this.move = function () {};
        this.startX = x;
        this.startY = y;
        this.axis = cfg.axis || "x";
        this.distance = cfg.distance || 200;
        this.speed = cfg.speed || 1.2;
        this.t = cfg.phase || 0;
        this.prevX = x;
        this.prevY = y;
    }
    step() {
        this.prevX = this.x;
        this.prevY = this.y;
        this.t += this.speed / 60;
        const offset = Math.sin(this.t) * this.distance;
        if (this.axis === "x") this.x = this.startX + offset;
        else this.y = this.startY + offset;
    }
    dx() { return this.x - this.prevX; }
    dy() { return this.y - this.prevY; }
}

What we just did: We created a platform that uses Math.sin() to produce smooth back-and-forth motion. Each frame, step() increments the time variable t and recalculates the position based on the sine value.

Before moving, we store prevX and prevY so we can calculate the delta after the move — the dx() and dy() methods return how far the platform moved this frame. The game uses those deltas to carry the player along, which is what makes moving platforms feel solid instead of slippery.

👹 Custom Boss Class — BossEnemy

What we're going to do: Create a larger, tougher enemy with multiple HP that flashes red when hit.

class BossEnemy extends Component {
    constructor(x, y, cfg) {
        super(cfg.size || 60, cfg.size || 60, "#8b0000", x, y, "rect");
        this.physics = true;
        this.gravity = 0.7;
        this.bounce = 0;
        this.onGround = false;
        this.move = function () {};
        this.maxHP = cfg.hp || 3;
        this.hp = this.maxHP;
        this.homeX = x;
        this.patrolRange = cfg.patrolRange || 220;
        this.patrolSpeed = cfg.patrolSpeed || 1;
        this.chaseSpeed = cfg.chaseSpeed || 2.2;
        this.detectRange = cfg.detectRange || 420;
        this.dir = 1;
        this.state = "patrol";
        this.hurtFlash = 0;
    }
    think(player) {
        // ... similar to PatrolEnemy but simpler ...
    }
    takeHit() { this.hp--; this.hurtFlash = 30; return this.hp <= 0; }
}

What we just did: The boss has the same patrol-and-chase pattern as regular enemies, but with a much larger detection range (420 pixels) and higher chase speed. It has maxHP and hp fields, and a takeHit() method that reduces HP and starts a flash.

The hurtFlash counter ticks down each frame. While it's active, the boss alternates between bright red and dark red every 10 frames, giving the player a clear visual signal that damage landed.

🏗️ Building the Game Scene

What we're going to do: Write buildGameScene() — the function that creates every component for a level.

function buildGameScene(levelIndex) {
    const level = LEVELS[levelIndex];

    fake.tile = [
        new Component(TILE, TILE, "#39ff14", 0, 0),
        new Component(TILE, TILE, "#7c3aed", 0, 0),
        new Component(TILE, TILE, "#ffdd00", 0, 0),
        new Component(TILE, TILE, "#ff0033", 0, 0),
        new Component(TILE, TILE, "#5c4a72", 0, 0),
    ];

    fake.map = level.map;
    fake.tileMap();
    fake.tileFace.show();
    solidTiles = fake.tileFace.tileList.filter(t => t.tid !== 4);
    spikeTiles = fake.tileFace.tileList.filter(t => t.tid === 4);

    // ... create player, enemies, platforms, boss, coins, HUD ...
}

What we just did: We rebuild fake.tile from scratch every time the scene is created. This is important — the engine's TileMap constructor calls tile.unshift(0), which mutates the array in place. Without recreating it, zeroes would stack up at the front and break the tile lookup after a restart.

We then set fake.map to the level's map, call tileMap() to build it, and call tileFace.show() to render the tiles. After that, we split the tile list into two arrays — solidTiles (everything that isn't a spike) and spikeTiles (tile ID 4). The game uses these arrays during collision resolution.

Creating the Player

What we're going to do: Spawn the player with physics enabled and custom movement.

player = new Component(28, 40, "#ff0080", 120, 500, "rect");
player.physics = true;
player.gravity = 0.7;
player.bounce = 0;
player.onGround = false;
player.onPlatform = null;
player.move = function () {};
display.add(player, SCENE_GAME);

What we just did: We created a 28x40 pink rectangle as the player. We set physics = true and gravity = 0.7 so the entity knows it's affected by gravity, but we override move to a no-op because the game's custom collision system updates position directly.

We also added an onPlatform field that will hold a reference to whichever moving platform the player is currently standing on, so the platform's motion can be applied to the player each frame.

Creating the Enemies

What we're going to do: Spawn the level's enemies at hand-tuned positions with patrol ranges.

enemies = [];
const basePositions = [
    { x: 380,  patrolLeft: 330,  patrolRight: 500,  patrolSpeed: 1.2, chaseSpeed: 2.2, detectRangeX: 220 },
    { x: 600,  patrolLeft: 520,  patrolRight: 740,  patrolSpeed: 1.8, chaseSpeed: 3.0, detectRangeX: 260 },
    // ... more positions ...
];
for (let i = 0; i < Math.min(level.enemyCount, basePositions.length); i++) {
    const cfg = basePositions[i];
    const e = new PatrolEnemy(cfg.x, 400, cfg);
    display.add(e, SCENE_GAME);
    enemies.push(e);
}

What we just did: We defined seven enemy positions with different patrol ranges, speeds, and detection distances. Each level spawns up to level.enemyCount of them.

Rather than randomising enemy placement, we hand-tuned these positions so each level has a specific rhythm — early enemies are slow and short-sighted, late enemies are fast and aggressive.

Creating the Platforms

What we're going to do: Spawn four moving platforms with different axes, distances, and speeds.

platforms = [];
[
    { x: 480,  y: 480, w: 120, h: 20, axis: "y", distance: 80,  speed: 1.0 },
    { x: 780,  y: 380, w: 120, h: 20, axis: "x", distance: 150, speed: 1.2 },
    { x: 1250, y: 480, w: 130, h: 20, axis: "y", distance: 100, speed: 1.4 },
    { x: 1560, y: 400, w: 130, h: 20, axis: "x", distance: 180, speed: 1.0 },
].forEach(cfg => {
    const p = new MovingPlatform(cfg.x, cfg.y, cfg.w, cfg.h, cfg);
    display.add(p, SCENE_GAME);
    platforms.push(p);
});

What we just did: We placed four platforms at key traversal points — two that move vertically and two horizontally, at different speeds and distances. Together they create rhythm in the level: the player has to time their jumps to match the platform's cycle.

Creating the Boss

What we're going to do: Spawn the boss at the end of the level with HP and speed from the level's config.

boss = new BossEnemy(level.bossX, 400, {
    size: 70, hp: level.bossHP, patrolRange: 200,
    patrolSpeed: 1.2, chaseSpeed: level.bossChaseSpeed, detectRange: 450
});
display.add(boss, SCENE_GAME);

What we just did: We created a 70-pixel boss with the level's HP and chase speed. Level 1 has 3 HP and a slow boss; level 3 has 6 HP and a fast boss. The boss's patrol range is 200 pixels, and it detects the player from 450 pixels away.

Creating the Coins

What we're going to do: Place 18 coins at hand-tuned positions that reward exploration.

coins = [];
[
    [160,620],[220,600],[300,620],[420,620],[480,600],
    [620,470],[680,450],[740,470],
    [900,620],[980,600],[1040,620],
    [1230,470],[1290,450],[1350,470],
    [1450,620],[1540,600],
    [1750,470],[1810,450],
].forEach(p => {
    const c = new Component(16, 16, "#ffdd00", p[0], p[1], "rect");
    display.add(c, SCENE_GAME);
    coins.push(c);
});

What we just did: We placed 18 coins along paths the player will naturally take. Some are on the ground, some are mid-jump, and some reward exploring the moving platforms.

Creating the HUD

What we're going to do: Add a score display, three hearts, and a pause button to the game scene.

hud = new Tctxt("16px", "Arial", "white", 16, 16, "left",
                false, "hanging", "rgba(0,0,0,0.6)", 12, 8);
hud.setText("Score: 0  |  Coins: 0 / " + coins.length);
hud.fixed();
display.add(hud, SCENE_GAME);

hearts = [];
for (let i = 0; i < 3; i++) {
    const h = new Tctxt("26px", "Arial", "#ff3366", 0, 0, "center",
                        false, "middle", "transparent");
    h.setText("♥");
    h.aX = 640 + i * 34; h.aY = 30;
    display.add(h, SCENE_GAME);
    hearts.push(h);
}

What we just did: We created a HUD line showing the score and coin count, and three heart symbols in the top-right. Each heart has an aX and aY — its anchor position — that stays fixed while fixed() recalculates the actual x and y based on the camera offset.

That's how UI elements stay in place when the camera moves.

Creating the Pause Button

What we're going to do: Add a pause button that stays pinned to the screen.

pauseBtnRef = new Component(50, 45, "rgba(124,58,237,0.7)", 0, 0, "rect");
pauseBtnRef.changeAngle = false;
pauseBtnRef.move = function () {};
pauseBtnRef.aX = 740;
pauseBtnRef.aY = 15;
display.add(pauseBtnRef, SCENE_GAME);

interactables.pauseBtn = {
    x: 740, y: 15, w: 50, h: 45, active: false, scene: SCENE_GAME,
    btn: pauseBtnRef,
    baseColor: "rgba(124,58,237,0.7)",
    hoverColor: "rgba(255,51,102,0.9)",
};

What we just did: We created a pause button component with aX and aY set to its intended screen position. The game loop calls pauseBtnRef.fixed() every frame to keep it there. We also registered it in interactables so the hit detection system can find it.

⚔️ Tile Collision Resolution

What we're going to do: Write a function that resolves collisions between an entity and a list of tiles by pushing the entity out on the axis of least overlap.

function resolveTileCollisions(entity, tiles) {
    entity.onGround = false;
    for (let i = 0; i < tiles.length; i++) {
        const t = tiles[i];
        if (!t.crashWith(entity)) continue;

        const oL = (entity.x + entity.width) - t.x;
        const oR = (t.x + t.width) - entity.x;
        const oT = (entity.y + entity.height) - t.y;
        const oB = (t.y + t.height) - entity.y;

        const minX = Math.min(oL, oR), minY = Math.min(oT, oB);

        if (minX < minY) {
            if (oL < oR) entity.x = t.x - entity.width;
            else entity.x = t.x + t.width;
            entity.speedX = 0;
        } else {
            if (oT < oB) {
                entity.y = t.y - entity.height;
                entity.gravitySpeed = 0;
                entity.onGround = true;
            } else {
                entity.y = t.y + t.height;
                if (entity.gravitySpeed < 0) entity.gravitySpeed = 0;
            }
        }
    }
}

What we just did: For each tile that overlaps the entity, we calculate four overlap amounts: how far the entity extends past the tile's left, right, top, and bottom edges. We take the minimum on each axis to find how much overlap there is horizontally versus vertically.

If the horizontal overlap is smaller, the collision is horizontal — we snap the entity to the left or right of the tile and zero out its horizontal speed. If the vertical overlap is smaller, the collision is vertical — we snap the entity to the top or bottom of the tile. If it lands on top, we set onGround = true so the player can jump.

The onGround = false at the start of the function resets the flag each frame. It only gets set to true when the entity lands on something.

🎬 The Main Game Update

What we're going to do: Write updateGame(dt) — the biggest function in the file, which handles every frame of gameplay.

function updateGame(dt) {
    if (!player || !hud) return;

    // ── Pin UI + game buttons to screen every frame ──
    for (const c of comm) {
        if (c.scene !== SCENE_GAME) continue;
        const x = c.x;
        if (x === hud || hearts.indexOf(x) !== -1) x.fixed();
        if (x.tag === 'left' || x.tag === 'right' || x.tag === 'jump') x.fixed();
    }
    if (pauseBtnRef) pauseBtnRef.fixed();
    // ... rest of the update ...
}

What we just did: We loop through every component in the game scene and call fixed() on the HUD, the hearts, and the on-screen buttons. This keeps them anchored to the screen even as the camera scrolls.

Then we handle the pause button — if it's active, we switch to the pause scene.

Player Input

What we're going to do: Read keyboard and on-screen button input, set the player's speed and jump velocity.

player.speedX = 0;
if (display.keys[65] || display.keys[37] || interactables.gameLeft.active)  player.speedX = -SPEED;
if (display.keys[68] || display.keys[39] || interactables.gameRight.active) player.speedX =  SPEED;
if ((display.keys[87] || display.keys[38] || display.keys[32] || interactables.gameJump.active) && player.onGround) {
    player.gravitySpeed = JUMP;
}

What we just did: We reset the player's horizontal speed to 0, then set it based on which keys or buttons are active. The player can move with A/D, arrow keys, or on-screen buttons.

The jump is only allowed when onGround is true, which prevents mid-air jumping. Pressing jump sets gravitySpeed to a negative value (the JUMP constant), which launches the player upward.

Player Physics and Collision

What we're going to do: Apply gravity, update the player's position, then resolve collisions against solid tiles.

player.gravitySpeed += player.gravity;
player.x += player.speedX;
player.y += player.speedY + player.gravitySpeed;
resolveTileCollisions(player, solidTiles);

What we just did: We add gravity to gravitySpeed each frame, then apply the player's speed to their position. Finally we call resolveTileCollisions() to push the player out of any solid tiles they've overlapped. That's the entire physics system — three lines of movement, one call to resolve.

Moving Platform Collisions

What we're going to do: Check if the player is standing on a moving platform, and if so, carry them along with it.

for (const p of platforms) {
    if (!p.crashWith(player)) continue;
    const oT = (player.y + player.height) - p.y;
    const oB = (p.y + p.height) - player.y;
    const oL = (player.x + player.width) - p.x;
    const oR = (p.x + p.width) - player.x;
    const minX = Math.min(oL, oR), minY = Math.min(oT, oB);
    if (minY < minX) {
        if (oT < oB) {
            player.y = p.y - player.height;
            player.gravitySpeed = 0;
            player.onGround = true;
            player.onPlatform = p;
        } else {
            player.y = p.y + p.height;
            if (player.gravitySpeed < 0) player.gravitySpeed = 0;
        }
    } else {
        if (oL < oR) player.x = p.x - player.width;
        else         player.x = p.x + p.width;
        player.speedX = 0;
    }
}

What we just did: We use the same overlap-resolution logic as the tile collision, but with one extra step: when the player lands on top, we set player.onPlatform = p. That tells the game loop to apply the platform's motion to the player's position on the next frame, so the player moves with the platform.

Enemy Updates and Collisions

What we're going to do: Update each enemy's AI, apply physics, resolve collisions, and check for player-enemy contact.

for (const e of enemies) {
    e.think(player);
    e.gravitySpeed += e.gravity;
    e.x += e.speedX;
    e.y += e.speedY + e.gravitySpeed;
    resolveTileCollisions(e, solidTiles);
}

for (let i = enemies.length - 1; i >= 0; i--) {
    const e = enemies[i];
    if (!player.crashWith(e)) continue;
    const falling = player.gravitySpeed > 0;
    const above = (player.y + player.height) < e.y + e.height * 0.6;
    if (falling && above) {
        e.destroy(); enemies.splice(i, 1);
        player.gravitySpeed = -13;
        score += 25;
    } else { damagePlayer(); }
}

What we just did: Each enemy runs its AI, moves under gravity, and resolves collisions against solid tiles. Then we loop through the enemies in reverse — necessary because we're removing some — and check for player-enemy contact.

A hit is a stomp if the player is falling (gravitySpeed > 0) and above the enemy's upper 60%. That destroys the enemy, bounces the player upward, and awards 25 points. Otherwise, the player takes damage.

Boss Update and Collisions

What we're going to do: Apply the same pattern to the boss, but with HP tracking.

if (boss) {
    boss.think(player);
    boss.gravitySpeed += boss.gravity;
    boss.x += boss.speedX;
    boss.y += boss.speedY + boss.gravitySpeed;
    resolveTileCollisions(boss, solidTiles);

    if (player.crashWith(boss)) {
        const falling = player.gravitySpeed > 0;
        const above = (player.y + player.height) < boss.y + boss.height * 0.6;
        if (falling && above) {
            const dead = boss.takeHit();
            player.gravitySpeed = -14;
            score += 50;
            if (dead) {
                boss.destroy(); boss = null;
                won = true;
                goToScene(SCENE_WIN);
                return;
            }
        } else { damagePlayer(); }
    }
}

What we just did: The boss moves and collides just like a regular enemy. When the player stomps it, takeHit() reduces its HP and returns true if that was the killing blow. If so, the boss is destroyed, the game state switches to won, and we transition to the win scene.

Otherwise, the boss just flashes red and continues fighting.

The Heart System

What we're going to do: Update the hearts when the player takes damage.

function damagePlayer() {
    if (Date.now() < invincibleUntil) return;
    playerHP--;
    invincibleUntil = Date.now() + 1500;
    for (let i = 0; i < hearts.length; i++) {
        hearts[i].color = i < playerHP ? "#ff3366" : "rgba(255,51,102,0.15)";
    }
    if (playerHP <= 0) {
        gameOver = true;
        goToScene(SCENE_OVER);
    }
}

What we just did: We check for invincibility first — if the player was recently hit, this call does nothing. Otherwise, we reduce HP, set a 1.5-second invincibility window, and update the heart colours. Hearts above the current HP are bright red; hearts below are dimmed. If HP reaches zero, we switch to the game over scene.

The invincibleUntil timestamp is what prevents the player from losing all three hearts in one collision.

📊 What You've Learned

Concept	Why It Matters
Scene system	One `display.scene` value switches between menu, game, pause, and more
Custom classes	Extending `Component` lets you give each object its own behaviour
State machines	Patrol → chase → return is a simple, flexible AI pattern
Overlap resolution	Push entities out on the axis of least overlap to prevent sticking
Moving platforms	Store previous position, calculate delta, apply to rider
Invincibility frames	A timestamp prevents repeated damage in the same collision
Anchor positions	`aX` and `aY` plus `fixed()` keep UI in place while the camera moves
Tile list filtering	Split solid vs spike tiles after building the map

⚠️ Known Limitations

Neon Caverns doesn't have multiplayer. The game is single-player only.

The game doesn't save progress between sessions. Closing the tab and reopening it starts from the menu every time.

The game doesn't support gamepad input. Only keyboard, mouse, and touch.

The score is stored in memory, not localStorage. There's no persistence for high scores.

These are deliberate trade-offs — the game was designed to be a compact example, not a full production title.

🚀 What's Next?

If you want to extend Neon Caverns, here are some directions:

Add localStorage persistence for high scores. Add a second boss with a different attack pattern. Add coin physics so coins can be knocked around by the player. Add a minimap in the corner showing the player's position. Add sound effects that trigger on stomps and coin collection. Add a level editor that writes JSON, so new levels can be designed visually.

The source code is small and modular, so any of these would be a good first contribution.

🐛 Report Bugs

If you find a bug in Neon Caverns, report it on GitHub:

👉 github.com/terracodes004/limn-engine-doc/issues

🔗 Resources

Resource	Link
Play Neon Caverns	limn-engine-doc.vercel.app/arcade/game.html?slug=noen-caverns-thc5
Limn Engine Docs	limn-engine-doc.vercel.app
Limn Studio	limn-engine-doc.vercel.app/editor
Limn Arcade	limn-engine-doc.vercel.app/arcade
GitHub	github.com/terracodes004/limn-engine-doc
Report Bugs	github.com/terracodes004/limn-engine-doc/issues
Kehinde on DEV.to	dev.to/kehinde_owolabi_e2e54567a

🎯 The One-Line Summary

"Neon Caverns is a complete platformer — three levels, boss fights, moving platforms, and a full scene system — built in a single file with Limn Engine." 🎮🚀

Draw your game into existence — one stomp at a time. 🎮🚀

🖱️ How I Fixed Canvas Click Coordinates in Limn Engine

Kehinde Owolabi — Fri, 18 Sep 2026 21:20:19 +0000

🖱️ How I Fixed Canvas Click Coordinates in Limn Engine

The bug that made buttons unclickable on scaled canvases — and the patch that fixes it.

🎯 Try the Fix

Play the demo with the patch installed:

👉 limn-engine-doc.vercel.app/arcade

The Limn Arcade runs every game through this patch. Click any game, tap any button — the coordinates land exactly where they should, even on phones, tablets, and scaled desktop windows.

Grab the patch here:

👉 github.com/terracodes004/limn-engine-doc

📖 Introduction

Every web game eventually hits the same wall. You build a canvas at a fixed resolution — say 800 by 400 — and then you scale it with CSS so it fits on a phone or fills a desktop monitor. The game looks fine. The graphics are crisp. Everything draws where it should.

Then you try to click a button, and nothing happens.

This is a common problem in browser game development. The mouse and touch coordinates that the browser provides are in screen space — relative to the entire page — but your game objects live in canvas space, which has its own internal resolution. When those two coordinate systems don't match, clicks land in the wrong place. On a desktop with a 1:1 canvas, the problem is invisible. On a scaled canvas — which is almost every mobile game — it breaks completely.

The Limn Engine originally handled mouse and touch input without any scaling. That worked for unscaled canvases, but it failed the moment the canvas was stretched or shrunk by CSS. The fix is a small patch to Display.prototype.addEventListeners that converts every mouse and touch position from client coordinates to canvas coordinates using getBoundingClientRect().

In this article, I'll explain exactly what was wrong, walk through the patch that fixes it, and show you how to add the same fix to any Limn Engine project.

🐛 The Bug: Coordinates That Didn't Match

Before we look at the fix, we need to understand what was actually broken. The original addEventListeners method in Limn Engine looked like this:

window.addEventListener('mousedown', (e) => {
    this.x = e.pageX + this.camera.x;
    this.y = e.pageY + this.camera.y;
});

This code reads e.pageX — the position of the mouse relative to the entire page — and adds the camera offset. On a desktop with a 1:1 canvas, this works. But the moment you scale the canvas with CSS — for example, width: 100vw on a phone — pageX and the canvas's internal coordinates diverge.

Here's the problem in plain numbers. Suppose your canvas is 800 pixels wide internally, but CSS stretches it to 1600 pixels on screen. When the user taps the middle of the canvas, the browser reports e.pageX = 800. But the canvas's internal coordinate for that same point is 400. Every click is off by a factor of two.

The fix is to read the mouse position relative to the canvas and then scale it to match the canvas's internal resolution. That's exactly what the getBoundingClientRect() method was designed for.

🛠️ What We're Going to Build

We're going to replace Display.prototype.addEventListeners with a patched version. The patch does three things the original didn't do:

Scales mouse and touch coordinates from client space to canvas space using getBoundingClientRect().
Tracks mouse movement continuously with mousemove and touchmove listeners.
Unifies mouse and touch handling through a single coordinate helper, so game code works the same on desktop and mobile.

Let me walk through the patch step by step.

Step 1: The Outer Wrapper

What we're going to do: Wrap the entire patch in an immediately-invoked function expression (IIFE) so it runs the moment the file loads. Inside, we check that Display exists before doing anything else.

(function () {
  if (typeof Display === 'undefined') {
    console.warn('[limn-click-patch] Display not found. Load patch after epic.js.');
    return;
  }
  // ... patch code ...
})();

What we just did: We created a self-contained block of code that runs immediately. The typeof Display === 'undefined' guard protects against running before epic.js has defined the Display class. If someone loads the files in the wrong order, the patch logs a warning and bails out instead of throwing a ReferenceError.

Step 2: The Coordinate Helper

What we're going to do: Write a helper function that converts any client-space position into canvas-space coordinates. This is the core of the fix.

var toCanvasCoords = function (clientX, clientY) {
  var rect = self.canvas.getBoundingClientRect();
  var scaleX = self.canvas.width / rect.width;
  var scaleY = self.canvas.height / rect.height;
  return {
    x: (clientX - rect.left) * scaleX,
    y: (clientY - rect.top) * scaleY
  };
};

What we just did: We built a function that takes a client-space X and Y and returns the matching canvas-space position.

self.canvas.getBoundingClientRect() — gets the canvas's real position and size on the page, after any CSS scaling has been applied.
self.canvas.width / rect.width — calculates the ratio between the canvas's internal resolution and its rendered size. If the canvas is internally 800 wide but rendered at 400, this is 2.
(clientX - rect.left) * scaleX — subtracts the canvas's left offset from the client X to get the position inside the canvas, then multiplies by the scale factor to convert to internal canvas pixels.

The same math applies to Y. The result is a coordinate pair that exactly matches what the canvas's drawing context sees.

Step 3: The Mouse Down Listener

What we're going to do: Rewrite the mousedown listener to use the coordinate helper, then add the camera offset to convert from canvas space to world space.

window.addEventListener('mousedown', function (e) {
  var p = toCanvasCoords(e.clientX, e.clientY);
  self.x = p.x + self.camera.x;
  self.y = p.y + self.camera.y;
});

What we just did: When the mouse is pressed, we convert the position to canvas coordinates and add the camera offset. This gives us display.x and display.y in world space — the same space where every game object lives. That's what Component.clicked() expects when it checks whether the mouse is inside a rectangle. The camera offset matters because the world can be larger than the canvas — a camera scrolls to show different parts of the world, and clicks need to land on the right object regardless of where the camera is looking.

Step 4: The Mouse Up Listener

What we're going to do: Reset display.x and display.y to false when the mouse is released.

window.addEventListener('mouseup', function () {
  self.x = false;
  self.y = false;
});

What we just did: We made the engine treat display.x as a boolean-ish value: it holds a number while the mouse is pressed, and false when it isn't. This is the convention the rest of Limn Engine already uses — game code checks if (display.x && button.clicked()) to detect clicks. Releasing the mouse sets it back to false so no click is detected on the next frame.

Step 5: The Touch Start Listener

What we're going to do: Apply the same coordinate conversion to touchstart, so a finger tap on a phone behaves exactly like a mouse click.

window.addEventListener('touchstart', function (e) {
  var t = e.touches[0];
  var p = toCanvasCoords(t.clientX, t.clientY);
  self.x = p.x + self.camera.x;
  self.y = p.y + self.camera.y;
});

What we just did: We read the first touch from e.touches[0], convert it to canvas coordinates with the same helper the mouse uses, and add the camera offset. Because the helper is the same, mouse and touch produce identical results for the same physical position on the canvas. That's what makes the game work on both desktop and mobile without any branching logic.

Step 6: The Touch End Listener

What we're going to do: Reset display.x and display.y when the finger is lifted, matching the mouse up behaviour.

window.addEventListener('touchend', function () {
  self.x = false;
  self.y = false;
});

What we just did: We closed the touch loop. Lifting a finger clears the press state, so the next frame sees no click — exactly the same as releasing a mouse button.

Step 7: The Mouse Move Listener

What we're going to do: Add a new mousemove listener that continuously updates the global mouse object. The original engine didn't have this — it only tracked the mouse when a button was pressed.

window.addEventListener('mousemove', function (e) {
  var p = toCanvasCoords(e.clientX, e.clientY);
  if (typeof mouse !== 'undefined') {
    mouse.x = p.x;
    mouse.y = p.y;
  }
});

What we just did: Every time the mouse moves — not just when it's clicked — the global mouse object gets its x and y updated in canvas space. This unlocks hover effects, custom cursors, drag-and-drop, and any other pointer-driven feature that needs to know where the mouse is right now. The typeof mouse !== 'undefined' check makes the patch safe to load even if the rest of the engine hasn't defined the mouse object yet.

Step 8: The Touch Move Listener

What we're going to do: Add the equivalent listener for touch, so mobile devices get continuous position tracking too.

window.addEventListener('touchmove', function (e) {
  var t = e.touches[0];
  var p = toCanvasCoords(t.clientX, t.clientY);
  if (typeof mouse !== 'undefined') {
    mouse.x = p.x;
    mouse.y = p.y;
  }
});

What we just did: We mirrored the mousemove behaviour for touch. A finger dragging across the screen updates mouse.x and mouse.y in canvas space in real time, giving mobile games the same tracking accuracy as desktop.

📝 The Complete Patch

Here's the entire patch in one piece, ready to paste at the bottom of epic.js or load as a separate file after the engine.

(function () {
  if (typeof Display === 'undefined') {
    console.warn('[limn-click-patch] Display not found. Load patch after epic.js.');
    return;
  }

  Display.prototype.addEventListeners = function () {
    var self = this;

    window.addEventListener('keydown', function (e) {
      self.keys[e.keyCode] = true;
    });
    window.addEventListener('keyup', function (e) {
      self.keys[e.keyCode] = false;
    });

    var toCanvasCoords = function (clientX, clientY) {
      var rect = self.canvas.getBoundingClientRect();
      var scaleX = self.canvas.width / rect.width;
      var scaleY = self.canvas.height / rect.height;
      return {
        x: (clientX - rect.left) * scaleX,
        y: (clientY - rect.top) * scaleY
      };
    };

    window.addEventListener('mousedown', function (e) {
      var p = toCanvasCoords(e.clientX, e.clientY);
      self.x = p.x + self.camera.x;
      self.y = p.y + self.camera.y;
    });
    window.addEventListener('mouseup', function () {
      self.x = false;
      self.y = false;
    });

    window.addEventListener('touchstart', function (e) {
      var t = e.touches[0];
      var p = toCanvasCoords(t.clientX, t.clientY);
      self.x = p.x + self.camera.x;
      self.y = p.y + self.camera.y;
    });
    window.addEventListener('touchend', function () {
      self.x = false;
      self.y = false;
    });

    window.addEventListener('mousemove', function (e) {
      var p = toCanvasCoords(e.clientX, e.clientY);
      if (typeof mouse !== 'undefined') {
        mouse.x = p.x;
        mouse.y = p.y;
      }
    });
    window.addEventListener('touchmove', function (e) {
      var t = e.touches[0];
      var p = toCanvasCoords(t.clientX, t.clientY);
      if (typeof mouse !== 'undefined') {
        mouse.x = p.x;
        mouse.y = p.y;
      }
    });
  };

  console.log('[limn-click-patch] Installed.');
})();

What we've done: We replaced the entire addEventListeners method on Display.prototype with a version that reads client coordinates, scales them to canvas space with getBoundingClientRect(), adds the camera offset for world space, unifies mouse and touch handling, and tracks pointer movement continuously. Every Display instance created after this patch runs gets the corrected behaviour.

📊 Before and After

Here's what the old and new code look like side by side, using the same event as an example.

Before:

window.addEventListener('mousedown', (e) => {
    this.x = e.pageX + this.camera.x;
    this.y = e.pageY + this.camera.y;
});

After:

window.addEventListener('mousedown', function (e) {
    var p = toCanvasCoords(e.clientX, e.clientY);
    self.x = p.x + self.camera.x;
    self.y = p.y + self.camera.y;
});

What we've done: We changed a single line — e.pageX became toCanvasCoords(e.clientX, e.clientY).x. That substitution makes clicks land exactly where the player intended, on any screen size, at any scale.

🤔 What About the `fake` Canvas?

You might be wondering whether the fake canvas — Limn Engine's offscreen render buffer — also gets the patched addEventListeners. The answer is yes, but it doesn't matter.

The fake canvas is created with fake.canvas.style.display = "none", which means the browser never displays it and therefore never dispatches mouse or touch events to it. The patched listeners attach to the window object, not the canvas, so they'd technically fire on fake too — but fake never receives clicks, and the coordinate conversion always targets self.canvas, which for fake is the hidden offscreen canvas. Since no clicks ever reach it, the whole question is moot.

The patch is correct as-is. fake doesn't need to be handled specially, and the order in which display and fake are created doesn't matter.

⚠️ Limitations

Being honest about what this patch does not do is just as important as describing what it does.

The patch doesn't handle multi-touch. Only touches[0] — the first finger — is read. If two fingers press the canvas at once, only the first is tracked. For most games this is fine, but if you're building a two-player game on a single phone screen, you'll need to extend the patch.

The patch doesn't clean up after itself. If you destroy a Display instance and create a new one, the old listeners remain attached to window. In practice this doesn't matter, because Limn Engine games usually create one Display and keep it for the lifetime of the page. But if you're building a multi-page app, be aware of it.

📊 What You've Learned

Concept	Why It Matters
`getBoundingClientRect()`	Gets the canvas's real position and size on the page, after CSS scaling
Coordinate scaling	Multiplying by `canvas.width / rect.width` converts screen pixels to canvas pixels
Canvas space vs world space	`mouse.x` is in canvas space; `display.x` is in world space (canvas + camera)
Prototype overriding	Replacing `Display.prototype.addEventListeners` patches every instance at once
Client vs page coordinates	`clientX` is viewport-relative; `pageX` is document-relative — clientX is what you want
Touch unification	The same coordinate helper serves both mouse and touch, so game code doesn't branch

🚀 What's Next?

Now that clicks land correctly on every screen, you can build UI that actually works on mobile. Here are some directions to explore.

The first is to extend the patch with multi-touch support, tracking touches[1], touches[2], and beyond for split-screen local multiplayer on a single device. The second is to add a pointerdown / pointermove / pointerup listener path that unifies mouse, touch, and pen input into a single API. The third is to build a proper mouse.justPressed flag that fires for exactly one frame, which makes single-shot buttons reliable without needing to reset keys manually.

If you build any of these, send a pull request. The patch file is small, well-commented, and designed to be extended.

🐛 Report Bugs

If you find a case where clicks still land in the wrong place, report it on GitHub:

👉 github.com/terracodes004/limn-engine-doc/issues

Please include your browser, your device, the scale factor you were using, and a description of where the click landed versus where it should have landed.

🔗 Resources

Resource	Link
Limn Engine Docs	limn-engine-doc.vercel.app
Limn Studio (Editor)	limn-engine-doc.vercel.app/editor
Limn Arcade	limn-engine-doc.vercel.app/arcade
GitHub Repository	github.com/terracodes004/limn-engine-doc
Report Bugs	github.com/terracodes004/limn-engine-doc/issues
Desire on DEV.to	dev.to/desire_george_434_ai

🎯 The One-Line Summary

"The limn-click patch converts mouse and touch coordinates to canvas space using getBoundingClientRect(), so buttons land where players expect on any screen size." 🖱️🚀

Draw your game into existence — one click at a time. 🎮🚀

🎮 Neon Caverns: A Platformer Built with Limn Engine — Play It Now

Kehinde Owolabi — Fri, 18 Sep 2026 02:07:45 +0000

🎮 Neon Caverns: A Platformer Built with Limn Engine — Play It Now

A neon-lit platformer with 3 levels, a boss fight, and a full scene system — built entirely in the browser with Limn Engine.

🎯 Live Demo

Play Neon Caverns right now:

👉 limn-engine-doc.vercel.app/arcade/game.html?slug=noen-caverns-thc5

The game is live on the Limn Arcade and ready to play. Click the link, and you're in the main menu within seconds. No downloads, no installation, no sign-up required to play.

Source code is underway and will be released soon for anyone who wants to learn how it was built or modify it for their own projects.

📖 Introduction

Neon Caverns is a 2D platformer built with Limn Engine — a lightweight game engine that runs entirely in the browser. You play as a pink square navigating neon-lit caverns, dodging enemies, collecting coins, and fighting a boss at the end of each level.

The game was designed to be easy to pick up but hard to master. Three levels of increasing difficulty, a boss with multiple HP stages, and a full menu system with settings, pause, and level select — all in a single JavaScript file.

Here's what makes it interesting:

3 hand-designed levels — Caverns, Towers, and Boss Arena
Intelligent enemies — they patrol, detect the player, chase, and return home
A boss fight — with health, chase AI, and a hurt-flash effect
Moving platforms — horizontal and vertical, with proper player carrying
Full scene management — Menu, Game, Over, Win, Pause, Settings, Level Select
Persistent settings — volume sliders saved to localStorage
Touch + keyboard support — playable on phones and desktops
Responsive canvas — scales to fit any screen

This article introduces the game, explains how it works, and shows you the key parts of the code — so you can see exactly how a complete Limn Engine platformer is structured.

🎮 How to Play

Action	Keyboard	Touch
Move Left	A or ←	Left button
Move Right	D or →	Right button
Jump	W, ↑, or Space	Jump button
Pause	Esc or P	II button (top right)

Goal: Reach the boss at the end of the level, jump on its head to damage it, and defeat it to win. Collect coins for score. Avoid enemies and spikes.

Enemies: Red squares that patrol and chase you when they see you. Jump on their head to defeat them.

Boss: A larger red square with multiple HP. Stomp it repeatedly to win the level.

Lives: You have 3 hearts. Get hit by an enemy or spike and you lose one. Lose all three and it's game over.

🏗️ How the Game Is Structured

Before we look at any code, let me explain the architecture of the game. Understanding the structure first makes the code much easier to follow.

Neon Caverns uses a scene system. A scene is a distinct screen or state of the game — like a menu, gameplay, or a game-over screen. Only one scene is active at a time, and the game switches between them in response to player actions.

Scene 0: Main Menu
   ↓
Scene 6: Level Select
   ↓
Scene 1: Gameplay
   ↓ (if the player dies)
Scene 2: Game Over
   ↓ (if the player wins)
Scene 3: Win Screen
   ↓ (if the player pauses)
Scene 4: Pause Menu
   ↓ (if the player opens settings)
Scene 5: Settings

Each scene is a number. The display.scene property tracks which scene is currently active, and only components assigned to that scene are drawn and updated. This is a core feature of Limn Engine — it lets you build complex games without destroying and recreating objects on every state change.

🧩 The Core Game Elements

Here's what the game is built from. Each of these is a Limn Engine Component — a game object.

Element	Type	Purpose
Player	`Component`	28×40 pink square, moves with keyboard/touch
Ground & walls	`Component`	Tiles from the level map — solid, collidable
Spikes	`Component`	Tiles with ID 4 — damage on contact
Coins	`Component`	16×16 yellow squares, +10 score each
Hearts	`Tctxt`	HUD hearts in the top-right corner
PatrolEnemy	Custom class	Extends `Component` — patrols, detects, chases
MovingPlatform	Custom class	Extends `Component` — sine-wave movement
BossEnemy	Custom class	Extends `Component` — larger, more HP, chase AI
HUD	`Tctxt`	Score, coins, and boss HP display
Pause button	`Component`	Pinned to screen via `.fixed()`
Menu buttons	`Component` + `Tctxt`	Each scene has its own buttons

The game uses custom classes that extend the base Component class — a technique that lets you give each game object its own behaviour while still using the engine's built-in rendering and collision systems.

🎨 The Neon Aesthetic

The visual style of Neon Caverns is simple but deliberate. Each tile type has its own colour:

Tile ID	Colour	Meaning
1	`#39ff14` (neon green)	Grass — walkable
2	`#7c3aed` (purple)	Stone — walkable
3	`#ffdd00` (yellow)	Gold — walkable
4	`#ff0033` (red)	Spike — hurts the player
5	`#5c4a72` (muted purple)	Brick — walkable

The player is #ff0080 (hot pink), the boss is #8b0000 (dark red), and the background is #0a0a1a (very dark blue). This palette creates the neon-cavern feel — bright, saturated objects against a dark backdrop.

🔍 Understanding the Code

The source code is a single JavaScript file. I'm not going to paste all of it here — that would be overwhelming — but I'll walk through the most important parts so you understand how everything fits together.

1. Setting Up the Display

What this code does: Creates the game engine instance and starts it.

const display = new Display();
display.perform();

What's happening: new Display() creates the engine. It must be named display because the engine references that variable internally. display.perform() switches the render loop to requestAnimationFrame, which gives us smooth 60fps and accurate deltaTime.

2. Configuring the World

What this code does: Sets the game world to be larger than the visible canvas, so the camera has something to scroll through.

const TILE = 64;
const COLS = 30, ROWS = 12;
const WORLD_W = COLS * TILE;  // 1920
const WORLD_H = ROWS * TILE;  // 768

fake.canvas.width  = WORLD_W;
fake.canvas.height = WORLD_H;
display.camera.worldWidth  = WORLD_W;
display.camera.worldHeight = WORLD_H;

What's happening: The world is 30 tiles wide and 12 tiles tall. Each tile is 64 pixels. So the world is 1920×768 pixels — much bigger than the 800×600 canvas. The camera follows the player and scrolls the visible window across this world.

3. Building a Level

What this code does: Each level is a 2D array where each number refers to a tile type. The engine builds the level from this map.

const LEVELS = [
    {
        name: "Caverns",
        map: [
            [1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1],
            [1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1],
            // ... more rows ...
            [2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2],
        ],
        enemyCount: 7,
        bossHP: 3,
        bossX: 1750,
        bossChaseSpeed: 2.4,
    },
    // ... more levels ...
];

What's happening: Each row is an array of tile IDs. 1 is grass (solid), 2 is stone (solid), 0 is empty space, 3 is gold, 4 is spike, 5 is brick. The engine's TileMap class reads this map and creates the visible tiles.

Each level also has metadata: how many enemies, the boss's HP, where the boss starts, and how fast it chases the player.

4. Creating Custom Enemy Behaviour

What this code does: Defines a PatrolEnemy class that extends Component — enemies patrol, detect the player, chase, and return home.

class PatrolEnemy extends Component {
    constructor(x, y, cfg) {
        super(30, 30, cfg.color || "#ff4500", x, y, "rect");
        // ... setup ...
        this.state = "patrol";
    }

    think(player) {
        const dx = player.x - this.x, dy = player.y - this.y;
        const canSee = Math.abs(dx) < this.detectRangeX && 
                       Math.abs(dy) < this.detectRangeY;
        if (canSee) { this.state = "chase"; }
        // ... rest of the AI ...
    }
}

What's happening: The enemy has three states:

Patrol — walks back and forth between two points
Chase — moves toward the player at a faster speed
Return — walks back to its patrol centre after losing sight of the player

This is a simple but effective AI pattern. The think() method runs every frame and updates the enemy's state based on what it can "see."

5. Handling Collision with Tiles

What this code does: Resolves collisions between the player and any solid tile, snapping the player to the correct side.

function resolveTileCollisions(entity, tiles) {
    entity.onGround = false;
    for (let i = 0; i < tiles.length; i++) {
        const t = tiles[i];
        if (!t.crashWith(entity)) continue;

        const oL = (entity.x + entity.width) - t.x;
        const oR = (t.x + t.width) - entity.x;
        const oT = (entity.y + entity.height) - t.y;
        const oB = (t.y + t.height) - entity.y;

        const minX = Math.min(oL, oR), minY = Math.min(oT, oB);

        if (minX < minY) {
            // Horizontal collision
            if (oL < oR) entity.x = t.x - entity.width;
            else entity.x = t.x + t.width;
        } else {
            // Vertical collision
            if (oT < oB) {
                entity.y = t.y - entity.height;
                entity.gravitySpeed = 0;
                entity.onGround = true;
            }
            // ... handle ceiling ...
        }
    }
}

What's happening: For each tile the entity overlaps, we calculate how much they overlap on each axis. We pick the smallest overlap — that tells us which direction the collision came from — and push the entity out of the tile on that axis.

The entity.onGround = true flag is what allows the player to jump — jumping only works when onGround is true.

6. Managing Scenes

What this code does: Switches between the different game screens.

function goToScene(n) {
    currentScene = n;
    display.scene = n;
    sceneEnterTime = Date.now();
    clearHitAreas();

    if (n === SCENE_GAME) {
        fake.tileFace.show();
        display.once = true;
        display.camera.x = 0;
        display.camera.y = 0;
    }
    // ... handle other scenes ...
}

What's happening: Setting display.scene = n tells the engine to only draw and update components assigned to that scene. Components are assigned to a scene by passing the scene number as a second argument to display.add():

display.add(player, SCENE_GAME);
display.add(menuPlayBtn, SCENE_MENU);

This is what makes the scene system work. The player only exists on scene 1, so it's invisible on the menu.

7. Handling Player Damage

What this code does: Reduces HP, grants invincibility frames, and updates the heart display.

function damagePlayer() {
    if (Date.now() < invincibleUntil) return;
    playerHP--;
    invincibleUntil = Date.now() + 1500;

    for (let i = 0; i < hearts.length; i++) {
        hearts[i].color = i < playerHP ? "#ff3366" : "rgba(255,51,102,0.15)";
    }

    if (playerHP <= 0) {
        gameOver = true;
        goToScene(SCENE_OVER);
    }
}

What's happening: The invincibleUntil timestamp prevents the player from taking damage multiple times in quick succession — a technique called invincibility frames. When the player has HP left, the corresponding heart stays bright red. When they lose HP, the heart fades to a dim colour.

📝 A Note on the Source Code

The full source code is underway and will be released soon. When it's ready, you'll be able to:

See the complete JavaScript file
Run it locally by downloading epic.js from the Limn Engine site
Modify it to add your own levels, enemies, or mechanics
Publish your own version to the Limn Arcade

The code is already live on the arcade — this article is just the introduction. The full release will include:

Line-by-line explanations of every class and function
A guide to adding new levels
A guide to building your own custom enemies
A guide to publishing to the arcade

Follow Kehinde Owolabi on DEV.to to get notified when the source code is released.

🎯 What You've Learned

Concept	Why It Matters
Scene system	Lets you build menus, gameplay, pause, and game-over screens without destroying objects
Custom component classes	Extending `Component` lets you give each game object its own behaviour
TileMap levels	2D arrays are an easy way to design levels
Custom AI states	The patrol → chase → return pattern is a simple, effective AI
AABB collision resolution	Snapping to the smallest overlap prevents sticking and jittering
Invincibility frames	A timestamp prevents rapid repeated damage
Persistent settings	`localStorage` keeps volume settings between sessions
Touch and keyboard	The same game logic handles both input methods

🚀 What's Next?

If you enjoyed Neon Caverns, here's what you can do next:

Play the other arcade games — browse the Limn Arcade and see what others have built
Build your own platformer — use Limn Studio's Platformer template to get started fast
Read the platformer tutorial — a step-by-step guide to building a simpler version from scratch
Watch for the Neon Caverns source code — follow Kehinde on DEV.to for the release

🔗 Resources

Resource	Link
Play Neon Caverns	limn-engine-doc.vercel.app/arcade/game.html?slug=noen-caverns-thc5
Limn Arcade	limn-engine-doc.vercel.app/arcade
Limn Studio (Editor)	limn-engine-doc.vercel.app/editor
Limn Engine Docs	limn-engine-doc.vercel.app
GitHub Repository	github.com/terracodes004/limn-engine-doc
Report Bugs	github.com/terracodes004/limn-engine-doc/issues
Kehinde on DEV.to	dev.to/kehinde_owolabi_e2e54567a

🎯 The One-Line Summary

"Neon Caverns is a 3-level platformer with intelligent enemies, a boss fight, and full scene management — playable right now on the Limn Arcade, with source code coming soon." 🎮🚀

Draw your game into existence — one stomp at a time. 🎮🚀

How I Built a Platformer Game with Limn Engine — And the Arcade That Came After

Kehinde Owolabi — Tue, 15 Sep 2026 03:51:52 +0000

🎮 How I Built a Platformer Game with Limn Engine — And the Arcade That Came After

A step-by-step guide to building a complete platformer, plus an introduction to the Limn Arcade where anyone can publish and play games.

🎯 Live Demo

Play the finished game right now:

👉 limn-engine-doc.vercel.app/arcade/game.html?slug=platform-66ek

Arrow keys or WASD to move. Space, W, or the Up arrow to jump. Collect all 5 coins to win.

Build your own version in Limn Studio:

👉 limn-engine-doc.vercel.app/editor

Browse the arcade and see what others have made:

👉 limn-engine-doc.vercel.app/arcade

📖 Introduction

Platformers are one of the best ways to learn game development. They teach you gravity, jumping, collision detection, camera following, and game state — all in one project.

They're also one of the hardest things to get right when you're starting out. Most tutorials either go too fast (throwing hundreds of lines of code at you) or too slow (spending 20 minutes on "what is a variable").

This tutorial is different.

We're going to build a complete, playable platformer using Limn Engine — a lightweight 2D game engine designed for beginners. The player moves left and right, jumps on platforms, collects coins, and wins when all coins are collected.

By the end, you'll have a game you can publish to the Limn Arcade — a community platform where anyone can share and play games made with Limn Engine.

Here's what we'll cover:

Setting up the game world and camera
Creating the player, ground, platforms, and coins
Adding movement and jumping with deltaTime
Detecting collisions with rectangles
Writing the win condition and score display
Adding on-screen buttons for mobile
Publishing to the arcade

🚀 Step 1: Download Limn Engine

Before writing any code, we need the engine.

Go to the Limn Engine documentation website: limn-engine-doc.vercel.app
Click the download button to get epic.js — this is the entire engine in a single file
Place epic.js in the same folder as your HTML file

That's it. No npm install, no build tools, no configuration.

If you don't want to download anything, you can also use Limn Studio — the browser-based editor built by Desire — which includes the engine already. We'll mention that at the end.

🛠️ Step 2: Create the HTML File

Create a new file called platformer.html and add the following structure:

<!DOCTYPE html>
<html>
<head>
  <title>Platformer</title>
  <script src="epic.js"></script>
</head>
<body>
  <script>
    // All the game code will go here
  </script>
</body>
</html>

What we just did: We created a basic HTML page that loads epic.js. The <script> block at the bottom is where all our game code will live. Nothing renders yet because we haven't created a Display.

🎨 Step 3: Set Up the Display and Camera

What we're going to do: Create the game window, enable the high-performance rendering mode, and tell the camera how big the world is.

const display = new Display();
display.perform();
display.start(500, 300);
display.backgroundColor('#00ffff');

display.camera.worldWidth = 800;
display.camera.worldHeight = 600;

What we just did:

new Display() — creates the engine instance. It must be named display because the engine references that variable internally.
display.perform() — switches the render loop to requestAnimationFrame for smooth 60fps and accurate deltaTime. Without this, movement will feel inconsistent.
display.start(500, 300) — creates a 500×300 canvas. This is the viewport — the visible window into the game world.
display.backgroundColor('#00ffff') — sets the canvas background to a light cyan colour.
display.camera.worldWidth = 800 and worldHeight = 600 — tells the camera the game world is 800×600 pixels. The camera can scroll within this space to follow the player, but it will never show anything outside these bounds.

The key thing to understand here is the difference between the canvas (500×300, what you see) and the world (800×600, where everything actually lives). This is what makes platformers feel big even on a small screen.

🧱 Step 4: Create the Player, Ground, and Platforms

What we're going to do: Add every static object in the game — the player, the ground, and three floating platforms.

// Player
const player = new Component(40, 40, '#ff0000', 100, 400, 'rect');
display.add(player);

// Ground
const ground = new Component(800, 60, '#00ff00', 0, 540, 'rect');
display.add(ground);

// Platforms
const platforms = [
  new Component(150, 20, '#00ff00', 200, 460, 'rect'),
  new Component(150, 20, '#00ff00', 450, 380, 'rect'),
  new Component(150, 20, '#00ff00', 650, 300, 'rect')
];
platforms.forEach(function(p) { display.add(p); });

What we just did:

Created a 40×40 red square as the player, at world position (100, 400).
Created a wide 800×60 green rectangle as the ground, at (0, 540). Because the ground spans the entire width of the world, the player can never fall past the sides.
Created three platforms, each 150×20, at different heights and positions. The player will need to jump on these to reach the coins.
Pushed each platform into the platforms array so we can loop through them later during collision checks.

Important: Every component must be added with display.add(). Without it, the component exists in memory but never appears on screen or gets updated.

🪙 Step 5: Add the Coins

What we're going to do: Create 5 coins at specific positions in the world.

const coinPositions = [
  {x: 633, y: 380},
  {x: 594, y: 300},
  {x: 676, y: 220},
  {x: 566, y: 380},
  {x: 445, y: 300}
];

const coins = coinPositions.map(function(c) {
  const coin = new Component(24, 24, '#ffff00', c.x, c.y, 'rect');
  display.add(coin);
  return coin;
});

What we just did:

Created an array of 5 positions, each with an x and y coordinate. These positions are placed strategically so that the player has to jump across platforms to reach them.
Used .map() to loop through the positions and create a new 24×24 yellow coin at each one.
Stored each coin in the coins array so we can later check collision with them, remove them when collected, and detect when the last coin has been picked up.

Why map() instead of a for loop? Because map() returns a new array automatically — so we get both the creation and the array storage in one step. It's a common pattern in JavaScript game development.

📊 Step 6: Add the Score UI

What we're going to do: Create a score display in the top-left corner of the screen.

const score = new Tctxt(
  '20px', 'Arial', 'white',
  20, 40,
  'left', false, 'top',
  'rgba(0,0,0,0.5)', 10, 4
);
score.setText('Score: 0');
display.add(score);

What we just did:

Tctxt is Limn Engine's rich text component. The parameters are, in order: size, font, colour, x, y, alignment, stroke mode, baseline, background, paddingX, paddingY.
We set the position to (20, 40) so the text appears near the top-left corner.
The background is rgba(0,0,0,0.5) — a semi-transparent black so the text stays readable over the cyan canvas.
The padding of 10 horizontal and 4 vertical pixels gives the background some breathing room around the text.
setText('Score: 0') sets the initial text.

We'll update this text later when coins are collected.

🎮 Step 7: Add On-Screen Buttons for Mobile

What we're going to do: Create touch-friendly buttons so the game is playable on phones — not just desktops.

const BTN = 60;
const BTN_Y = 200;

function mkBtn(x, color) {
  return new Component(BTN, BTN, color, x, BTN_Y, 'rect');
}

const btnL = mkBtn(20,  '#1a1a2e');
const btnR = mkBtn(100, '#1a1a2e');
const btnJ = mkBtn(380, '#2563eb');

const lblL = new Tctxt('36px','Arial','white',50,240,'center',false,'middle');
const lblR = new Tctxt('36px','Arial','white',130,240,'center',false,'middle');
const lblJ = new Tctxt('16px','Arial','white',410,240,'center',false,'middle');

lblL.setText('◀');
lblR.setText('▶');
lblJ.setText('JUMP');

display.add(btnL);
display.add(btnR);
display.add(btnJ);
display.add(lblL);
display.add(lblR);
display.add(lblJ);

const btnList = [btnL, btnR, btnJ, lblL, lblR, lblJ];

What we just did:

Created a helper function mkBtn() that returns a new component with the same size and y-position but a different x and colour. This saves us writing the same new Component() call three times.
Created three buttons: left arrow, right arrow, and a blue jump button.
Created three text labels on top of the buttons — "◀", "▶", and "JUMP".
Added all six elements to the display.
Stored everything in a btnList array — but only the buttons (not the labels), because we'll only be testing button hits in the click detection.

Why this matters: Without these, the game would be unplayable on phones. A platformer that works with both keyboard and touch is far more useful than one that only works on desktop.

🏗️ Step 8: Set Up Game State and Helper Functions

What we're going to do: Declare the variables that track the game state, and write a helper function for rectangle collision.

let vy = 0;
let onGround = false;
let points = 0;
let won = false;

function rectHit(a, b) {
  return a.x < b.x + b.width &&
         a.x + a.width > b.x &&
         a.y < b.y + b.height &&
         a.y + a.height > b.y;
}

function inBtn(b, x, y) {
  return x >= b.x && x <= b.x + b.width &&
         y >= b.y && y <= b.y + b.height;
}

What we just did:

vy — vertical velocity. Positive = falling, negative = rising. We'll add gravity to this every frame.
onGround — a boolean that's true when the player is touching the ground or a platform. We need this so the player can only jump when standing on something.
points — the player's score, starting at 0.
won — a boolean that becomes true when all coins are collected, so we can stop the game logic.
rectHit(a, b) — the classic AABB (Axis-Aligned Bounding Box) collision test. It returns true if rectangle a overlaps rectangle b. Four comparisons — one for each edge.
inBtn(b, x, y) — a simpler check: is the point (x, y) inside button b? This is used for touch input.

🎬 Step 9: Write the Game Loop

What we're going to do: Write the update(dt) function that runs every frame — this is where all the game logic lives.

Here's the full function, broken into pieces so you can see what each part does.

9a. Camera and fixed UI

function update(dt) {
  display.camera.follow(player, true);
  btnList.forEach(function(e) { e.fixed(); });
  score.fixed();

  if (won) return;

What we just did:

display.camera.follow(player, true) — the camera smoothly follows the player. The true enables smoothing so the camera lerps toward the player rather than snapping.
btnList.forEach(...) — calls .fixed() on every button every frame. This keeps them locked to the screen even as the camera scrolls.
score.fixed() — same for the score display.
if (won) return; — if the player has won, stop running game logic. The camera and UI still update, but nothing else happens.

Important: .fixed() must be called every frame, not just once. It recalculates the component's position based on the current camera offset.

9b. Touch detection

  const mx = display.x;
  const my = display.y;

  const touchingL = mx !== false && inBtn(btnL, mx, my);
  const touchingR = mx !== false && inBtn(btnR, mx, my);
  const touchingJ = mx !== false && inBtn(btnJ, mx, my);

What we just did:

display.x and display.y hold the current mouse or finger position while pressed, and false when released.
For each button, we check two things: is the pointer pressed (not false), and is the pointer inside the button's rectangle.
The result is a true/false value for each button — we'll use these in the movement code next.

9c. Horizontal movement

  const sp = 280;

  if (display.keys[37] || display.keys[65] || touchingL) player.x -= sp * dt;
  if (display.keys[39] || display.keys[68] || touchingR) player.x += sp * dt;

What we just did:

sp is the player's horizontal speed, in pixels per second.
The player moves left if the left arrow (37) or A (65) is pressed, or if the left button is being touched.
The player moves right if the right arrow (39) or D (68) is pressed, or if the right button is being touched.
Multiplying by dt means movement is frame-rate independent — the player will move at the same real-world speed on a 30fps device and a 144fps device.

9d. Jumping

  const jf = 15;
  const keyJump = display.keys[38] || display.keys[32] || display.keys[87];

  if ((keyJump || touchingJ) && onGround) {
    vy = -jf;
    onGround = false;
  }

What we just did:

jf is the jump force — how much vertical velocity we apply when the player jumps.
The player jumps if the Up arrow (38), Space (32), or W (87) is pressed, or if the jump button is being touched.
The jump only happens if onGround is true. This prevents mid-air jumping.
Setting vy = -jf gives the player upward velocity. It's negative because in canvas coordinates, up is negative and down is positive.
We immediately set onGround = false so the player can't jump again until they land.

9e. Gravity and ground collision

  vy += 40 * dt;
  player.y += vy;
  onGround = false;

  if (rectHit(player, ground)) {
    player.y = ground.y - player.height;
    vy = 0;
    onGround = true;
  }

What we just did:

vy += 40 * dt — apply gravity. Every frame, the player's vertical velocity increases by 40 pixels per second squared, multiplied by dt.
player.y += vy — move the player by their vertical velocity.
onGround = false — reset the ground flag. It will be set back to true if we detect a collision with the ground or a platform below.
If the player's rectangle overlaps the ground rectangle, we snap the player to the top of the ground (ground.y - player.height), zero out the velocity, and set onGround = true.

The snapping is important — without it, the player would sink slightly into the ground each frame, accumulating errors over time.

9f. Platform collision

  for (const p of platforms) {
    if (rectHit(player, p) && player.y + player.height - vy <= p.y + 4) {
      player.y = p.y - player.height;
      vy = 0;
      onGround = true;
    }
  }

What we just did:

Loop through every platform.
Check if the player overlaps the platform.
Also check that the player was above the platform last frame — this is the player.y + player.height - vy <= p.y + 4 part. Without this second check, the player would "stick" to the underside of platforms when jumping up through them.
If both conditions are true, snap the player to the top of the platform, zero out the velocity, and set onGround = true.

This is the trickiest part of platformer physics — making sure the player can jump onto platforms from below but can't pass through them from above.

9g. Horizontal bounds

  if (player.x < 0) player.x = 0;
  if (player.x + player.width > 800) player.x = 800 - player.width;

What we just did: Prevent the player from walking off the left or right edges of the world. These two lines do the same job as move.boundTo(), but written explicitly because we only want to clamp horizontally — vertical movement is handled by gravity.

9h. Coin collection

  for (let i = coins.length - 1; i >= 0; i--) {
    if (rectHit(player, coins[i])) {
      coins[i].destroy();
      coins.splice(i, 1);
      points += 10;
      score.setText('Score: ' + points);
    }
  }

What we just did:

Loop through the coins backwards — from the last one to the first. This is important because we're removing items from the array as we go. If we looped forwards, removing an item would shift all the following items down by one index, causing us to skip the next coin.
If the player overlaps a coin, call coin.destroy() to remove it from the engine, and coins.splice(i, 1) to remove it from the array.
Add 10 points to the score and update the display text.

9i. Win condition

  if (coins.length === 0 && !won) {
    won = true;
    score.setText('You win! Score: ' + points);
  }
}

What we just did: If there are no more coins, and the player hasn't already won, set won = true and update the score display to show the win message. The game loop will return early from now on, so nothing else happens.

✅ Step 10: The Complete Code

Here's the entire game in one file. Copy it into platformer.html and open it in your browser.

<!DOCTYPE html>
<html>
<head>
  <title>Platformer</title>
  <script src="epic.js"></script>
</head>
<body>
  <script>
    // ── SETUP ──
    const display = new Display();
    display.perform();
    display.start(500, 300);
    display.backgroundColor('#00ffff');

    // ── CAMERA ──
    display.camera.worldWidth = 800;
    display.camera.worldHeight = 600;

    // ── PLAYER ──
    const player = new Component(40, 40, '#ff0000', 100, 400, 'rect');
    display.add(player);

    // ── GROUND ──
    const ground = new Component(800, 60, '#00ff00', 0, 540, 'rect');
    display.add(ground);

    // ── PLATFORMS ──
    const platforms = [
      new Component(150, 20, '#00ff00', 200, 460, 'rect'),
      new Component(150, 20, '#00ff00', 450, 380, 'rect'),
      new Component(150, 20, '#00ff00', 650, 300, 'rect')
    ];
    platforms.forEach(function(p) { display.add(p); });

    // ── COINS ──
    const coinPositions = [
      {x: 633, y: 380},
      {x: 594, y: 300},
      {x: 676, y: 220},
      {x: 566, y: 380},
      {x: 445, y: 300}
    ];
    const coins = coinPositions.map(function(c) {
      const coin = new Component(24, 24, '#ffff00', c.x, c.y, 'rect');
      display.add(coin);
      return coin;
    });

    // ── SCORE UI ──
    const score = new Tctxt('20px','Arial','white',20,40,'left',false,'top','rgba(0,0,0,0.5)',10,4);
    score.setText('Score: 0');
    display.add(score);

    // ── ON-SCREEN BUTTONS ──
    const BTN = 60;
    const BTN_Y = 200;

    function mkBtn(x, color) {
      return new Component(BTN, BTN, color, x, BTN_Y, 'rect');
    }

    const btnL = mkBtn(20,  '#1a1a2e');
    const btnR = mkBtn(100, '#1a1a2e');
    const btnJ = mkBtn(380, '#2563eb');

    const lblL = new Tctxt('36px','Arial','white',50,240,'center',false,'middle');
    const lblR = new Tctxt('36px','Arial','white',130,240,'center',false,'middle');
    const lblJ = new Tctxt('16px','Arial','white',410,240,'center',false,'middle');

    lblL.setText('◀');
    lblR.setText('▶');
    lblJ.setText('JUMP');

    display.add(btnL);
    display.add(btnR);
    display.add(btnJ);
    display.add(lblL);
    display.add(lblR);
    display.add(lblJ);

    const btnList = [btnL, btnR, btnJ, lblL, lblR, lblJ];

    // ── HELPERS ──
    function inBtn(b, x, y) {
      return x >= b.x && x <= b.x + b.width &&
             y >= b.y && y <= b.y + b.height;
    }

    function rectHit(a, b) {
      return a.x < b.x + b.width &&
             a.x + a.width > b.x &&
             a.y < b.y + b.height &&
             a.y + a.height > b.y;
    }

    // ── GAME STATE ──
    let vy = 0;
    let onGround = false;
    let points = 0;
    let won = false;

    // ── GAME LOOP ──
    function update(dt) {
      display.camera.follow(player, true);
      btnList.forEach(function(e) { e.fixed(); });
      score.fixed();

      if (won) return;

      const sp = 280;
      const jf = 15;

      // Touch detection
      const mx = display.x;
      const my = display.y;
      const touchingL = mx !== false && inBtn(btnL, mx, my);
      const touchingR = mx !== false && inBtn(btnR, mx, my);
      const touchingJ = mx !== false && inBtn(btnJ, mx, my);

      // Horizontal movement
      if (display.keys[37] || display.keys[65] || touchingL) player.x -= sp * dt;
      if (display.keys[39] || display.keys[68] || touchingR) player.x += sp * dt;

      // Jump
      const keyJump = display.keys[38] || display.keys[32] || display.keys[87];
      if ((keyJump || touchingJ) && onGround) {
        vy = -jf;
        onGround = false;
      }

      // Gravity
      vy += 40 * dt;
      player.y += vy;
      onGround = false;

      // Ground collision
      if (rectHit(player, ground)) {
        player.y = ground.y - player.height;
        vy = 0;
        onGround = true;
      }

      // Platform collision
      for (const p of platforms) {
        if (rectHit(player, p) && player.y + player.height - vy <= p.y + 4) {
          player.y = p.y - player.height;
          vy = 0;
          onGround = true;
        }
      }

      // Horizontal bounds
      if (player.x < 0) player.x = 0;
      if (player.x + player.width > 800) player.x = 800 - player.width;

      // Coin collection
      for (let i = coins.length - 1; i >= 0; i--) {
        if (rectHit(player, coins[i])) {
          coins[i].destroy();
          coins.splice(i, 1);
          points += 10;
          score.setText('Score: ' + points);
        }
      }

      // Win condition
      if (coins.length === 0 && !won) {
        won = true;
        score.setText('You win! Score: ' + points);
      }
    }
  </script>
</body>
</html>

📊 What You've Learned

Concept	Why It Matters
World vs canvas	The canvas is the viewport; the world is bigger and the camera scrolls within it
Delta time (`dt`)	Multiplies movement so speed is the same on every device
Gravity	A velocity that increases every frame and pulls the player down
Jump impulse	Setting `vy` to a negative value for one frame to launch upward
AABB collision	The rectangle overlap test that powers every collision in the game
One-way platforms	The extra `player.y + player.height - vy <= p.y + 4` check allows jumping up through platforms
Reverse loops	Required whenever you remove items from an array during iteration
`.fixed()`	Locks a component to the screen so it doesn't scroll with the camera
Touch + keyboard	The same logic handles both, so the game is playable anywhere

🕹️ Introducing the Limn Arcade

You've just built a complete platformer. Now here's the part that makes it more than a local project: you can publish it to the Limn Arcade.

The arcade is a community platform where anyone can upload, browse, and play games made with Limn Engine. It's built and maintained by Desire — the same developer behind Limn Studio.

What the Arcade Includes

Feature	What It Does
Game Gallery	Browse every published game, with search and filters
Game of the Week	A rotating spotlight on the best new game
Leaderboard	Weekly rankings of top games based on likes and comments
Likes and Comments	Community feedback on every game
Creator Profiles	See every game a developer has made
My Games	Manage your published games from one dashboard
Inbox	Stats, updates, and notifications
Discord Integration	Direct link to the community hub

Why This Matters for Beginners

The arcade lowers every barrier that normally stops people from finishing a game:

No hosting required — you upload, the arcade serves it
No distribution required — the arcade has an audience
No marketing required — the leaderboard gives your game visibility
Instant feedback — comments and likes tell you what's working

That last point is the most important one. In most game dev projects, you finish a game and never find out if anyone played it. On the arcade, you find out the same day.

How to Publish Your Game

Sign in to the arcade at limn-engine-doc.vercel.app/arcade
Click + Make a game
Paste your game code — either the code from this tutorial, or something you built in Limn Studio
Click share.

Your game appears in the arcade immediately, and anyone can play it, like it, and leave a comment.

🛠️ Or Build It in Limn Studio Instead

If you don't want to write all this code by hand, Limn Studio has a Platformer template that gives you a working starting point.

Go to limn-engine-doc.vercel.app/editor
Open the Build tab
Select Platformer from the template dropdown
Customise the game using the form fields
Switch to the Code tab to see (and edit) the generated Limn Engine code
Click Run to test
Publish directly to the arcade

Limn Studio also includes templates for Dress-Up, Runner, Shooter, and Clicker — so once you've got the platformer working, you can branch into other genres without starting from scratch.

🐛 Found a Bug? Report It

If something doesn't work, you can report it on GitHub:

👉 github.com/terracodes004/limn-engine-doc/issues

Please include:

A description of the problem
Steps to reproduce it
What you expected vs. what actually happened
Your browser and device

🚀 What's Next?

Now that you've built a platformer and published it to the arcade, try:

Adding enemies — patrolling obstacles that reset the player on contact
Adding lives — three lives before game over
Adding a timer — complete the level before the clock runs out
Adding moving platforms — platforms that travel left and right
Adding sound — jump, collect, and win sound effects with the Sound class
Building a second level — harder platforms, more coins, new obstacles

Then publish it. The arcade is waiting.

🔗 Resources

Resource	Link
Limn Engine Docs	limn-engine-doc.vercel.app
Limn Studio (Editor)	limn-engine-doc.vercel.app/editor
Limn Arcade	limn-engine-doc.vercel.app/arcade
Complete API Reference	limn-engine-doc.vercel.app/reference.html
Beginner Guide	limn-engine-doc.vercel.app/beginner.html
10x Developer Guide	limn-engine-doc.vercel.app/10x.html
GitHub Repository	github.com/terracodes004/limn-engine-doc
Report Bugs	github.com/terracodes004/limn-engine-doc/issues
Desire on DEV.to	dev.to/desire_george_434_ai

🎯 The One-Line Summary

"Build a complete platformer with Limn Engine in about 150 lines — then publish it to the Limn Arcade and let the world play it." 🎮🚀

Draw your game into existence — one platform at a time. 🎮🚀

[Boost]

Kehinde Owolabi — Sun, 13 Sep 2026 00:49:57 +0000

Adenola Adefemi

Sep 12

Excited to Share: I’m a Developer at Limn Engine🚀

#development #webdev #html #css

1 min read

DEV Community: Kehinde Owolabi

From Buggy Prototype to Polished Arcade: How I Upgraded Three Browser Games

From Buggy Prototype to Polished Arcade: How I Upgraded Three Browser Games

The Starting Point

Neon Caverns: Seasons

The Bugs

The Overhaul

Death Boost: Seasons

The Bugs

The Overhaul

Riftfire

The Overhaul

The Common Threads

1. Separate World Space from Screen Space

2. Never Trust Global Mutable State

3. Procedural Content Is Cheap and Endless

4. Input Handling Must Be Defensive

5. Difficulty Should Be a Single Scalar

What I'd Do Differently

Final Numbers

Closing Thoughts

Limn Engine Is Getting a Performance Plugin That Might Change How You Think About Browser Games

Limn Engine Is Getting a Performance Plugin That Might Change How You Think About Browser Games

What Limn Already Gets Right

"60fps Is the Ceiling"

What's Coming

Why This Matters

For solo developers

For game jams

For web games as a medium

For Limn's philosophy

What We're Not Claiming

What This Actually Changes

The Numbers We're Targeting

How to Try It

What's Next

What Happened After I Got a Zero for "Too Good" Code

The Instructor Replied First

What This Revealed

The winsound Thing

The Grade Came Back

What I Learned

1. The System Has Layers — Use Them

2. Not Every Instructor Is the Adversary

3. Cross-Platform Matters

4. Creativity Should Match the Environment

The Unexpected Part

What's Next

Final Thought

🧹 How I Cleaned Up Limn Engine's Global Variables (and Fixed Two Bugs Along the Way)

🧹 How I Cleaned Up Limn Engine's Global Variables (and Fixed Two Bugs Along the Way)

🎯 Try the New Version

📖 Introduction

🐛 The Problem with Globals

🛠️ What We're Going to Build

🔧 Step 1: The Namespace

🔧 Step 2: Updating References

🐛 Step 3: The Tile Bug

🐛 Step 4: The Particle Bug

🔊 Step 5: The Sound System Simplification

📊 Before and After

📊 What You've Learned

⚠️ A Note on Backwards Compatibility

🚀 What's Next?

🐛 Report Bugs

🔗 Resources

🎯 The One-Line Summary

I Got a Zero on a Beginner Python Assignment Because My Code Was "Too Good"

I Got a Zero on a Beginner Python Assignment Because My Code Was "Too Good"

The Submission

The Irony: My Code Isn't Even That Clean

1. The word list was a string, not a list

2. I left a placeholder in the word list

3. Bare except: instead of except ImportError:

4. Inconsistent variable names

5. Duplicate entries in the word list

6. Windows-only winsound

The Real Problem: Competence Looks Like Cheating Now

How I Handled It

What Educators Should Do Differently

The `winsound` Thing

3. Bare `except:` instead of `except ImportError:`

6. Windows-only `winsound`