DEV Community: Kehinde Owolabi

Build your own game:

📊 What You've Learned

Concept	Why It Matters
Portal submission	A major milestone for any engine or game
Raycasting	A 1990s rendering technique that still works today
Procedural generation	Seeded maps give 360 unique levels from one codebase
Procedural audio	No files needed — sound is synthesized at runtime
Persistent state	`localStorage` saves progress across sessions
Touch controls	The same game works on mobile without a separate build
Engine validation	A portal review validates the engine itself

⚠️ What's Next

The review is pending. Here's what happens either way:

If accepted:

RIFTFIRE goes live on CrazyGames.
We announce the launch and link to the portal listing.
We monitor reviews and fix any issues that come up.

If rejected:

We read the feedback carefully.
We fix the specific issues the reviewer raised.
We resubmit.

Either way, we'll write a follow-up article once the review is complete, sharing the outcome and what we learned from it.

🐛 Report Bugs

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

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

🔗 Resources

Resource	Link
CrazyGames Preview	crazygames.com/preview/3496eeae-ae2c-4fed-9961-610279212d8a
Limn Arcade	limn-engine-doc.vercel.app/arcade
Limn Engine Docs	limn-engine-doc.vercel.app
Limn Studio	limn-engine-doc.vercel.app/editor
Light Editor	limn-engine-doc.vercel.app/editor/light-editor.html
GitHub Repository	github.com/terracodes004/limn-engine-doc
Report Bugs	github.com/terracodes004/limn-engine-doc/issues
Discord	discord.gg/kVpSmYWXr
Kehinde on DEV.to	dev.to/kehinde_owolabi_e2e54567a

🎯 The One-Line Summary

"RIFTFIRE — a 360-level raycast FPS built with Limn Engine — is now awaiting review on CrazyGames. The preview build is playable today." 🎮🚀

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

📬 How to Reach Me Directly — A Personal Note from Kehinde Owolabi

Kehinde Owolabi — Fri, 06 Nov 2026 03:48:01 +0000

📬 How to Reach Me Directly — A Personal Note from Kehinde Owolabi

Beyond DEV.to and GitHub — the accounts where you can actually talk to me.

🎯 The Short Version

Facebook (personal account):

👉 facebook.com/damilare.ape

Name on Facebook: Owolabi Sam

DEV.to:

👉 dev.to/kehinde_owolabi_e2e54567a

GitHub:

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

Discord (Limn Arcade community):

👉 discord.gg/kVpSmYWXr

📖 Introduction

Most of the interactions I have with readers happen on DEV.to and GitHub. You comment on an article. You open an issue. You fork a game. That's the public layer of the ecosystem — and it's where most questions belong, because the answers help everyone who reads them later.

But sometimes you don't want to write a public comment. Maybe you have a question that doesn't fit into an article. Maybe you want to send feedback that isn't a bug report. Maybe you just want to say hi, tell me what you built with Limn Engine, or ask me to look at something specific.

For those cases, the public channels aren't always the right fit. This article is about the direct channel — the Facebook account I use for personal and community contact, and how to use it well.

🎯 A Quick Note on Names

Before I explain how to reach me, I need to explain something. My DEV.to account is under the name Kehinde Owolabi. My Facebook account is under Owolabi Sam. Both names refer to the same person.

This is normal for personal accounts. I've used Facebook longer than I've used DEV.to, and the Facebook name is what my friends and family know. But it means if you search for "Kehinde Owolabi" on Facebook, you might not find me. If you search for "Owolabi Sam" on DEV.to, you might be confused.

The link below connects the two:

👉 facebook.com/damilare.ape

That's the account. Whatever name appears on the profile, that's me.

📬 When to Use the Facebook Account

Good uses:

Saying hi. If you built something with Limn Engine and want to show me, this is the channel. I love seeing what people build.
Questions that don't fit DEV.to. If you have a question that's too short for an article but too long for a comment, a message is fine.
Feedback on articles. If a tutorial didn't make sense or an article had an error you spotted, a message is a fast way to tell me.
Collaboration requests. If you want to work on something together — a game, an article, a feature — the Facebook account is a good starting point.
Community connection. If you're building Limn Engine games and want to talk about the ecosystem, I'm happy to chat.

Not-so-good uses:

Bug reports. Those belong on GitHub Issues so they're trackable and searchable.
Technical questions with long answers. Those belong on DEV.to or Discord so others can find the answers later.
Anything urgent that isn't actually urgent. Facebook messages aren't monitored on a schedule. If it's truly urgent, use the Discord community — there are always people there.

🎯 When to Use the Other Channels

Each channel has a purpose. Here's how I'd recommend using each one:

Channel	Best For	Response Time
DEV.to comments	Questions on specific articles, general Limn Engine discussion	Usually within a day
GitHub Issues	Bugs, feature requests, documentation gaps	Within a few days
Discord	Community chat, quick questions, help from other developers	Usually within hours (community-run)
Facebook	Personal connection, feedback, questions that don't fit the others	Depends on my schedule

The Facebook account is a bit like a direct message to me. It's not for public interaction. It's not monitored by a community. It's just me.

📝 A Note on Time Zones

I'm based in Lagos, Nigeria. That means I'm on West Africa Time (WAT). If you're writing from a different time zone, expect a delay if you message at what's for me an unusual hour.

This isn't a complaint — it's just a fact of building things from a specific place. If your message arrives at 3am my time, I'll answer it when I'm awake. That's usually the next day.

🎯 What You Can Expect

If you message me on Facebook:

I'll read it. I try to read every message that isn't spam.
I'll respond when I have time. That might be the same day, it might be a week later.
I'll answer honestly. If I don't know something, I'll say so rather than making something up.
I'll keep it brief. If your message turns into a long technical discussion, I'll probably suggest we move to Discord or GitHub so the answer can help others.

📊 What You've Learned

Channel	Purpose
DEV.to	Articles, public discussion, technical questions
GitHub Issues	Bugs, feature requests, structured feedback
Discord	Community chat, quick help, community-run support
Facebook	Personal connection, direct messages to me

⚠️ A Note on the Public Record

Facebook messages are private. They're not indexed by search engines. Nobody else can read them. That's part of why they're useful — some things don't belong on a public comment thread.

But there's a trade-off. When you ask me something privately, only you get the answer. When you ask it publicly on DEV.to or Discord, everyone who comes after you gets the answer too.

Both are valid. Use whichever makes sense for the question you're asking.

🚀 What's Next?

The Limn Engine ecosystem is still growing. Here are some ways to stay connected:

Follow the DEV.to series for new articles on the engine and the arcade.
Star the GitHub repo to keep up with issues and updates.
Join the Discord for community conversation and quick help.
Add me on Facebook if you want a direct line.

I'm always happy to hear from people building with Limn Engine. If you have a project you're working on, a question I haven't answered in an article, or just want to say hello — all of those are welcome.

🔗 Resources

Resource	Link
Facebook	facebook.com/damilare.ape
DEV.to	dev.to/kehinde_owolabi_e2e54567a
GitHub	github.com/terracodes004/limn-engine-doc
Discord	discord.gg/kVpSmYWXr
Limn Engine Docs	limn-engine-doc.vercel.app
Limn Arcade	limn-engine-doc.vercel.app/arcade
Limn Studio	limn-engine-doc.vercel.app/editor
Light Editor	limn-engine-doc.vercel.app/editor/light-editor.html

🎯 The One-Line Summary

"Facebook is the direct channel — Owolabi Sam on facebook.com/damilare.ape is Kehinde Owolabi on DEV.to, and it's where you can message me one-on-one." 📬🚀

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

🎄 Limn League Christmas 2026 — Festive Arcade Football

Kehinde Owolabi — Tue, 03 Nov 2026 02:47:13 +0000

🎄 Limn League Christmas 2026 — Festive Arcade Football

A career-mode football sim wrapped in snow, santa hats, and Jingle Bells — now live on the Limn Arcade.

🎯 Play the Game

👉 Limn League Christmas 2026

The game is live on the Limn Arcade and ready to play. It was Last Week's Winner at the time of writing, and it's a strong showcase of what's possible with Limn Engine in the browser.

📖 Introduction

Limn League Christmas 2026 is a browser-based football career simulator built with Limn Engine. It's the festive entry in the Limn League series — a family of football sims on the arcade that each take a different angle on the same sport.

This one wraps the season in snow, santa hats, and Jingle Bells. It has divisions to climb, cups to win, and a 30-match championship to grind through. It's the kind of game that starts as a five-minute test and turns into an hour of career management without you noticing.

Here's what makes it worth playing:

12 divisions to climb, from Street all the way to Immortal.
Cup tiers to win alongside the league.
A full 30-match championship as the endgame.
Upgrade systems so your squad improves over time.
A Christmas visual theme — snow, santa hats, seasonal audio.
No installs — it runs in the browser, on phone or desktop.

🎮 What the Game Is

The core loop. You start in a lower division, play matches, win games, earn rewards, upgrade your squad, and climb. The higher you climb, the tougher the opponents. The progression is the game — you're not trying to reach a single win condition, you're trying to build a career.

The divisions. Twelve of them, from Street to Immortal. Each one has its own difficulty curve. Advancing requires winning matches, and winning matches requires a squad that's good enough. That's where the upgrade system comes in.

The cups. Alongside the league, there are cup tiers. Cups are shorter, higher-stakes competitions that give you a chance at bigger rewards. Winning a cup accelerates your climb.

The championship. The endgame is a 30-match championship. If you can get through all 30 matches, you've proven your squad is competitive at the top. That's the long-term goal the divisions feed into.

The Christmas theme. Snow on the pitch, santa hats on the players, Jingle Bells as the soundtrack. It's the same football sim underneath, but the theme makes it feel like a holiday season — which is exactly what makes it a distinct entry in the Limn League series.

🚀 How It Plays

The game runs entirely in the browser. The arcade loads it, and the game's own logic takes over. From the arcade logs, we can see the game is a single file of about 138 kilobytes running on the epic.js engine — which is another 55 kilobytes. That's the entire game, engine included, at under 200KB.

For comparison: a single hero image on a modern website is often larger than that. The entire game is smaller than most social media avatars.

That's the point of Limn Engine. It's not trying to be Unity. It's trying to be small enough to load instantly and fast enough to feel good.

On mobile. The game is designed to work on phones. The preview image from the arcade shows it running at a phone resolution with readable UI and a play button that works. Tapping Play starts a game session with the same logic the desktop version uses.

On desktop. Same game, bigger screen. The arcade scales the canvas to fit.

📊 Behind the Scenes

Here's what happens when you open the game's URL, from the arcade logs:

Step	What Happens
1. Boot	The arcade calls `boot()` with the game's slug
2. Fetch	It fetches the game's code from Supabase
3. Load	The game's code (138KB) and the engine (55KB) are loaded
4. Render	An iframe is created and the game is rendered inside it
5. Session	The user's session is checked — if you're signed in, likes and comments are wired up

That's the entire load process. It takes about two seconds from clicking a game to seeing it on screen. That's fast enough that you can browse the arcade, tap a game, and be playing before your finger has left the screen.

🏆 Why It Was Last Week's Winner

The Last Week's Winner badge is the arcade's way of highlighting the best game of the week. When a game wins, it gets the top spot on the arcade home page for seven days, then moves to the Last Week's Winner slot for the following week before being archived in the Hall of Fame.

Limn League Christmas 2026 earned that badge. The reason is visible in the game itself — it's a complete, polished experience that feels like a real football career sim, not a demo. The Christmas theme makes it stand out, the divisions give it depth, and the cup and championship systems give it a long-term goal.

For a game built with a lightweight 2D engine, that's a lot of substance.

📝 What You've Learned

Concept	Why It Matters
Limn League series	A family of football sims, each with its own angle
Career-mode design	Divisions, cups, upgrades, and a championship give the game long-term depth
The Christmas theme	A seasonal wrap makes a familiar game feel fresh
Single-file games	The whole game is 138KB, engine included — under 200KB total
Fast load	Under two seconds from tap to play
Arcade infrastructure	Supabase fetch, iframe render, session check

⚠️ Known Limitations

The game is single-player only. There's no multiplayer or online leaderboard.

The Christmas theme is cosmetic — the underlying football mechanics are the same as other Limn League entries. That's deliberate: the theme is a skin, not a different game.

The career mode is long. Thirty championship matches is a lot of games. If you're looking for a quick session, this might not be the right entry point — but if you want something to sink time into, it is.

🚀 What's Next?

The Limn League series is still growing. Here are some directions:

More themes — the Christmas entry proves the series can wrap itself in different aesthetics. A summer theme, a Halloween theme, or a retro 8-bit theme would all work.
Cross-game progression — imagine carrying your squad from one Limn League entry to another.
Leaderboards — a public ranking of the best careers would make the championship feel more competitive.
Seasonal events — timed events tied to real-world seasons would keep the game feeling alive.

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

🐛 Report Bugs

If you find a bug in Limn League Christmas 2026, report it on GitHub:

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

Please include your device, your browser, and a description of what happened.

🔗 Resources

Resource	Link
Play Limn League Christmas 2026	limn-engine-doc.vercel.app/arcade/game.html?slug=limn-league-christmas-2026-hgz8
Limn Arcade	limn-engine-doc.vercel.app/arcade
Limn Engine Docs	limn-engine-doc.vercel.app
Limn Studio (Editor)	limn-engine-doc.vercel.app/editor
Light Editor	limn-engine-doc.vercel.app/editor/light-editor.html
GitHub Repository	github.com/terracodes004/limn-engine-doc
Report Bugs	github.com/terracodes004/limn-engine-doc/issues
Discord	discord.gg/kVpSmYWXr
Kehinde on DEV.to	dev.to/kehinde_owolabi_e2e54567a

🎯 The One-Line Summary

"Limn League Christmas 2026 is a festive career-mode football sim — twelve divisions, cup tiers, a 30-match championship, and a full Christmas theme, all in under 200KB of browser code." 🎄⚽🚀

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

⚡ Why I Built a Lighter Version of Limn Studio

Kehinde Owolabi — Sat, 31 Oct 2026 14:55:46 +0000

⚡ Why I Built a Lighter Version of Limn Studio

The full IDE was too heavy for mobile and low-end devices. Here's the version that isn't.

🎯 Try It

Light Editor:

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

Full Studio (still available):

The Arcade (play games made by others):

📖 Introduction

Limn Studio is the online IDE for Limn Engine — a place where you can write, run, and test games directly in the browser. It has templates, a file tree, a build tab, asset injection, a live preview, and a code editor with syntax highlighting. It's a full IDE, and for serious development, it's exactly what you want.

But it's heavy.

On a desktop with a decent connection, that's fine. On a phone, or a Chromebook with limited RAM, or a connection that's slower than you'd like, it can take long enough to load that you give up before you've written a line of code.

I built a lighter version to fix that. It's called the Light Editor, and it does the same core job — pick a template, run a game, edit the code — without the weight.

Here's what the light editor is, why it matters, and where it fits alongside the full studio.

🐛 The Problem: The Studio Is Heavy

The full Limn Studio is a proper IDE. When you open it, you get:

A Build tab with template selection, color tuning, and asset injection
A Code tab with a file tree, a main file editor, and a language selector
A live preview pane that runs your game
A console that shows errors and logs
Cloud sync so your projects are saved
Share links so you can send your game to someone else

All of that adds up. The build tab alone has multiple form fields, a preview, and a template picker. The code tab includes a full syntax-highlighting editor. Every one of those pieces has to load before the page is usable.

On a fast machine, that's a one-second load. On a phone with a slow connection, it can be ten seconds or more. And during that time, the user is looking at a blank screen wondering whether it worked.

That's a bad first impression for a platform whose entire pitch is "you can build a game in minutes."

🛠️ What We're Going to Build

The light editor is a stripped-down version of the same idea. It keeps the parts that matter for getting started, and drops the ones that make the page heavy.

Here's what stays:

Templates. All fifteen templates are still available. Pick one, get a working game.
Build / Code toggle. Same idea as the full studio — use the form, or edit the JavaScript directly.
A live preview. Hit Run, see your game.
A console. Errors and logs appear at the bottom.
Cloud sync and share links. Your projects are saved and shareable.

Here's what goes:

The full file tree. The light editor works on a single file. That's enough for a beginner.
The asset injection tab. If you need to inject HTML or CSS, use the full studio.
The file-based language tools. The light editor is JavaScript-only, which is all Limn Engine uses anyway.
The complex layout. The light editor is one column on mobile, two columns on desktop. It's readable on any screen.

The result is a page that loads in under a second on almost any device.

🔧 Inside the Light Editor

Let me walk through what you see when you open it.

The landing screen. When you first load the light editor, you see "Ready to build" with three instructions:

"Pick a template, customize the colors, then hit ▶ Run to launch your game."

Below that, a second line:

"Switch to ⌨️ Code to edit or export the generated JavaScript."

And a small badge row: "15 templates • Live preview • Cloud sync • Share links."

That's the entire onboarding. There's no tour, no tutorial, no modal. You're told what to do, and you can do it.

The template picker. Choose from fifteen templates — Platformer, Shooter, Runner, Dress-Up, Clicker, and the rest. Each one generates working game code when you select it. You don't have to write anything to see a game on screen.

The Build / Code toggle. The Build tab is the form-driven experience — pick a template, set colors, hit Run. The Code tab is the direct editing experience — the generated JavaScript appears in a text editor, ready to modify. You can switch between them at any time; the code you see in Code mode is exactly what Build mode generated.

The preview. When you hit Run, the game launches in the preview pane. It uses the same epic.js engine as the full studio, the arcade, and a local download. It's not a mock-up or a simulation. It's the real thing.

The console. At the bottom of the screen, a small console shows one line on load:

"22:48:07 • Console ready. Press ▶ Run, then type expressions below."

That's a hint. You can type expressions into the console and see the results. It's a small touch, but it's the difference between "I don't know what to do" and "I know exactly what to do."

Cloud sync and share links. Everything you create is stored under your account and shareable. That means you can start a game on your phone and continue it on your desktop, or send a link to a friend who can fork your game and remix it.

📊 Full Studio vs. Light Editor

Here's the comparison in a table.

Feature	Full Studio	Light Editor
Templates	✅ 15	✅ 15
Build tab (form-driven)	✅	✅
Code tab (direct edit)	✅	✅
Live preview	✅	✅
Console	✅	✅
Cloud sync	✅	✅
Share links	✅	✅
File tree	✅	❌ Single file
Asset injection (HTML/CSS)	✅	❌
Multi-file projects	✅	❌
Load time	~1s on desktop, longer on mobile	<1s on most devices
Mobile-friendly layout	Somewhat	Fully
Use case	Serious development	Quick experiments, first-time users

The short version: the full studio is for when you know what you're doing. The light editor is for when you don't yet.

🎯 When to Use Each

Use the light editor when:

You're on a phone or a low-end device.
You're trying Limn Engine for the first time.
You want to quickly test a template.
You're teaching a workshop and want everyone to start at the same place.
You want to send someone a link that "just works."

Use the full studio when:

You're working on a real project with multiple files.
You need to inject custom HTML or CSS.
You're editing with a full IDE-style file tree.
You want the full toolchain.

Both tools are bookmarked. Both are useful. The light editor doesn't replace the full studio — it's a lower-friction entry point to the same engine.

🚀 Try It Yourself

Open the light editor:

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

Pick a template. Hit Run. See a game. That's it.

If you've never used Limn Engine before, start here. If you've used it and you want more, the full studio is one link away.

📊 What You've Learned

Concept	Why It Matters
Light editor vs. full studio	Two entry points for different needs
Templates	Pick one, get working code
Build / Code toggle	Form-driven or direct editing, your choice
Live preview	Real engine, real game, no mocks
Console	Type expressions, see results
Cloud sync	Your projects travel with you
Mobile-first design	Works on phones, not just desktops

⚠️ Known Limitations

The light editor doesn't have a file tree. If you're building a project with multiple files, you'll need the full studio.

It doesn't support asset injection. If you need to inject HTML, CSS, or external scripts into the game's page, that's a full-studio feature.

It's JavaScript-only. That's fine for Limn Engine, but if you're mixing languages, the full studio is more flexible.

These are deliberate trade-offs. The light editor is lighter because it does less.

🚀 What's Next?

The light editor is still growing. Here are the next steps:

Auto-save so you never lose your work between sessions.
URL-based project state so you can share a game that starts with the code pre-loaded.
Template customization in the light editor — currently you pick a template and get it as-is; in the next version you'll be able to tune colors from the Build tab without switching to the full studio.
A "fork this game" button in the light editor that loads any arcade game's code directly.

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

🐛 Report Bugs

If you find a bug in the light editor, report it on GitHub:

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

Please include your device, your browser, and a description of what happened.

🔗 Resources

Resource	Link
Light Editor	limn-engine-doc.vercel.app/editor/light-editor.html
Full Studio	limn-engine-doc.vercel.app/editor
Limn Engine Docs	limn-engine-doc.vercel.app
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
Discord	discord.gg/kVpSmYWXr
Kehinde on DEV.to	dev.to/kehinde_owolabi_e2e54567a
Desire on DEV.to	dev.to/desire_george_434_ai

🎯 The One-Line Summary

"The light editor is Limn Studio's fast-start path — pick a template, hit Run, see a game in seconds. It's the version you send to someone who's never touched Limn Engine before." ⚡🚀

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

🎥 Video: The Display Class in Limn Engine

Kehinde Owolabi — Fri, 23 Oct 2026 02:45:19 +0000

🎥 Video: The Display Class in Limn Engine

A full walkthrough of the Display class — creating the game window, setting the background, and controlling the canvas.

🎯 Watch the Video

👉 Learn about the Display class in Limn Engine — YouTube

This is the next video in the Limn Engine tutorial series. It focuses on the Display class — the foundation of every Limn Engine game. It walks through creating the game window, setting the background color, and controlling the canvas.

Official documentation:

📖 Introduction

Every Limn Engine game starts with one line:

const display = new Display();

That single line creates the canvas, sets up the game loop, and prepares the engine to draw. Everything else — every component, every particle, every score, every pixel — is drawn through the Display.

The Display class is easy to use but easy to misuse. There are a few things you need to get right — the order of perform() and start(), the variable name display, and the difference between the canvas and the world. Getting them wrong doesn't crash the engine, but it does make your game behave in ways that are hard to debug.

This video walks through the Display class from start to finish.

Here's what the video covers:

Creating a Display and starting the canvas
The perform() method — why it comes first, and what breaks if you forget
Setting the background color
Sizing the canvas
The camera and how it relates to the Display
Common mistakes and how to avoid them

🎬 What the Video Covers

Creating a Display. The video starts with the one-line setup — new Display() — and explains what happens under the hood when you create it. The engine creates a canvas element, sets up a 2D drawing context, and prepares the game loop.

The perform() method. Most of the video focuses on this. display.perform() is what switches the engine from the default setInterval loop to requestAnimationFrame. Without it, the game runs at about 50fps with inconsistent pacing. With it, the game runs at a smooth 60fps (or whatever the monitor's refresh rate is).

The order matters: perform() must come before start(). If you call start() first, the patch doesn't take effect, and the game runs on the slow loop. This is one of the most common mistakes beginners make.

Setting the background color. The video shows display.backgroundColor(), which sets the canvas background via CSS. It also shows the gradient options — lgradient() for linear gradients and rgradient() for radial ones — for more polished backgrounds.

Sizing the canvas. display.start(width, height) sets the canvas dimensions. The video covers how to choose a size, how the size relates to mobile screens, and how to scale the canvas with CSS without changing its internal resolution.

The camera. The Display has a camera attached to it. The video explains how the camera moves independently of the canvas, how world coordinates differ from screen coordinates, and how to set the camera's world size so it doesn't scroll past the edges of the level.

Common mistakes. The video finishes with the most common Display-related bugs: forgetting perform(), using a different variable name than display, and calling start() more than once.

🚀 Try It Yourself

The engine:

The online editor (no download required):

The arcade (play games made by others):

📺 Full Video Series

This video is part of the ongoing Limn Engine tutorial series. Here's the current lineup:

#	Video	What It Covers
1	Series Start	Introduction to the series
2	—	Setup and first Display
3	—	Components and movement
4	Introduction to Limn Engine	What Limn is, and how to get started
5	The Display Class	Creating the game window, background colors, and canvas control

📝 Quick Reference: The Display Class

Here's the minimal Display setup from the video, in case you want to follow along without typing every line:

<!DOCTYPE html>
<html>
<head>
  <title>Display Demo</title>
  <script src="epic.js"></script>
</head>
<body>
  <script>
    // Create the engine
    const display = new Display();

    // MUST come before start()
    display.perform();

    // Create the canvas
    display.start(800, 600);

    // Set the background
    display.backgroundColor("#0a0a0a");

    // Game loop
    function update(dt) {
      // Game logic goes here
    }
  </script>
</body>
</html>

And here's the gradient version, for a more polished background:

display.lgradient("bottom", "#0f3460", "#16213e");
// or
display.rgradient("#1a1a2e", "#0a0a0f");

📊 What You've Learned

Concept	Why It Matters
`new Display()`	Creates the canvas, the game loop, and the camera
`display.perform()`	Switches to `requestAnimationFrame` for smooth 60fps
Order matters	`perform()` must come before `start()`
`display.start(w, h)`	Sets the canvas size and begins the game loop
`display.backgroundColor()`	Sets the canvas background via CSS
`display.lgradient()` / `rgradient()`	Gradient backgrounds for a more polished look
`display.camera`	Controls what part of the world is visible

⚠️ Common Mistakes to Avoid

Forgetting perform(). Without it, your game runs at about 50fps on an unreliable setInterval loop. Movement feels inconsistent, and dt doesn't behave the way you expect.

Calling start() before perform(). The patch doesn't take effect if start() has already run. Always call perform() first.

Naming the Display something else. The engine references display internally. Calling your instance game or app will throw errors in places you don't expect.

Calling start() more than once. The engine creates a canvas on every start() call. Multiple calls stack multiple canvases on the page.

🐛 Found a Bug?

If you find something in the video that doesn't work, report it on GitHub:

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

Please include your browser, your device, and the timestamp in the video where the issue appears.

🔗 Resources

Resource	Link
YouTube Video	The Display Class
Previous Video	Introduction to Limn Engine
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
Discord	discord.gg/kVpSmYWXr
Kehinde on DEV.to	dev.to/kehinde_owolabi_e2e54567a

🎯 The One-Line Summary

"A full walkthrough of the Display class — creating the game window, setting the background, sizing the canvas, and controlling the camera in Limn Engine." 🎮🚀

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

🎥 Video: Introduction to Limn Engine — Build Your First Game with JavaScript

Kehinde Owolabi — Mon, 19 Oct 2026 04:38:20 +0000

🎥 Video: Introduction to Limn Engine — Build Your First Game with JavaScript

A full video walkthrough of Limn Engine: what it is, why it exists, and how to get started.

🎯 Watch the Video

👉 Introduction to Limn Engine — YouTube

This is the fourth video in the Limn Engine tutorial series. It walks through what Limn Engine is, what problem it solves, and how to go from zero to your first running game.

Official documentation:

📖 Introduction

Most game development tutorials start with an installation step. You download a package manager, set up a build tool, configure a bundler, install dependencies, and wait ten minutes for npm to do its thing. By the time you write your first line of game code, you've already given up twice.

Limn Engine takes the opposite approach. There is no installation. There is no build step. There is no package manager. You download one file, include it in a script tag, and you have a game running in the browser.

That's the promise. This video walks through whether the promise holds up — and shows you how to actually use the engine once you've got it.

Here's what the video covers:

What Limn Engine is, and what it isn't
The zero-configuration philosophy
How to download and include the engine
Your first Display, Component, and game loop
Where to go next

🎬 What the Video Covers

What Limn Engine is. Limn is a lightweight 2D game engine for the browser, built on HTML5 Canvas. It's designed for beginners — people who know a little JavaScript and want to make a game without fighting tooling.

What Limn Engine isn't. It's not Unity. It's not Phaser. It doesn't try to be. It's not a visual editor, it's not a physics engine, and it's not a full-featured game framework. It's a small, focused set of tools that cover the most common tasks in 2D game development.

The zero-configuration philosophy. Most game engines require setup. Limn doesn't. The video walks through the one-file download process and shows just how small the setup actually is.

Your first game. The video builds a working game from scratch — a moving player, collision detection, and a score — in about fifty lines of code.

Where to go next. Once you have a game running, the video points to the official documentation for the next steps: physics, tilemaps, particles, camera controls, and the arcade where you can publish your game.

🚀 Try It Yourself

The engine:

The online editor (no download required):

The arcade (play games made by others):

The video uses the download-and-include approach, but if you don't want to download anything, the online editor runs the engine directly in the browser.

📺 Full Video Series

This is the fourth video in the series. If you're starting from the beginning, work through them in order:

#	Video	What It Covers
1	Series Start	Introduction to the series
2	—	Setup and first Display
3	—	Components and movement
4	Introduction to Limn Engine	What Limn is, and how to get started
5	—	Building your first complete game

📝 Quick Reference: The Minimal Game

Here's the smallest Limn Engine game you can build, in case you want to follow along in the video without typing every line:

<!DOCTYPE html>
<html>
<head>
  <title>My First Limn Game</title>
  <script src="epic.js"></script>
</head>
<body>
  <script>
    const display = new Display();
    display.perform();
    display.start(800, 600);
    display.backgroundColor("#0a0a0a");

    const player = new Component(50, 50, "#7fffb2", 375, 275, "rect");
    display.add(player);

    function update(dt) {
      if (display.keys[39]) player.x += 200 * dt;
      if (display.keys[37]) player.x -= 200 * dt;
      if (display.keys[38]) player.y -= 200 * dt;
      if (display.keys[40]) player.y += 200 * dt;
      move.bound(player);
    }
  </script>
</body>
</html>

Save that as an HTML file, put epic.js next to it, open it in a browser, and you have a working game. That's the whole setup.

📊 What You've Learned

Concept	Why It Matters
Zero-config engine	One script tag, no build tools, no package manager
Display	The canvas and the game loop — the foundation of every game
Component	Every game object — player, enemy, coin, wall
update(dt)	The game loop that runs every frame
deltaTime	Multiplies movement so the game runs at the same speed on all devices
move.bound()	Keeps objects on screen without writing your own edge detection

🐛 Found a Bug?

If you find something in the video that doesn't work, report it on GitHub:

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

Please include your browser, your device, and the timestamp in the video where the issue appears.

🔗 Resources

Resource	Link
YouTube Video	Introduction to Limn Engine
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
Discord	discord.gg/kVpSmYWXr
Kehinde on DEV.to	dev.to/kehinde_owolabi_e2e54567a

🎯 The One-Line Summary

"A full video walkthrough of Limn Engine — what it is, why it exists, and how to build your first game with JavaScript and zero configuration." 🎮🚀

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

Announcing the first limn engine extension called Bust Beta

Kehinde Owolabi — Thu, 15 Oct 2026 22:19:22 +0000

Bust Beta

Bust Bets
Limn Engine's dual-thread rendering plugin — in beta.

Bust Beta is an experimental performance layer for Limn Engine. It moves rendering work off the main thread and onto a Web Worker, then hands the finished frame back to the visible canvas for display.

On devices that can keep up, the result is a higher and more stable frame rate than a single-threaded Canvas 2D loop can deliver.

It is beta. It works. It is not finished.

What It Does
Why It Matters
How It Works
Status
Known Limitations
How to Try It
What's Next
Philosophy
Feedback
License
Links

What It Does

Limn already ships with a dual-canvas architecture — a hidden "fake" canvas caches the static layer, and the visible canvas draws the dynamic layer on top every frame. Bust Beta extends that idea across threads:

The main thread runs game logic, input, and the final composite.
The worker thread renders the dynamic layer into an OffscreenCanvas.
The worker returns the finished frame as an ImageBitmap.
The main thread blits it onto the visible canvas.

Both threads work at the same time. The display shows whichever frame is freshest.

Why It Matters

Most Canvas 2D engines are limited by what a single thread can do between two requestAnimationFrame ticks. On a 120Hz or 144Hz display, the panel is ready to show 120 or 144 frames per second — but the engine often can't produce them, because rendering and logic are fighting for the same thread.

Bust Beta decouples the two:

Higher refresh-rate utilization — on high-refresh panels, the worker can produce frames faster than a single-threaded loop.
More consistent pacing — when the main thread has a heavy frame, the worker keeps producing.
Same API surface — you don't rewrite your game. Bust Beta hooks ani() from outside.

This is not a claim that Canvas 2D beats WebGL. It isn't trying to. It's a claim that a Canvas 2D engine, properly threaded, can match the frame-rate consistency of a GPU engine on the class of 2D games Limn targets.

How It Works

The pipeline has four stages, repeated every animation frame.

Stage 1 — Main thread prepares the frame. The main thread runs update(dt) so game logic stays in sync with input. It also renders the static layer (the fake canvas) as it always did, and sends a message to the worker containing the current game state: the component list, the camera, the current scene, and the delta time.

Stage 2 — Worker receives and renders. The worker listens on onmessage. On first message, it stores the OffscreenCanvas and grabs its 2D context. On every subsequent message, it clears the offscreen canvas, applies the camera transform, loops through the component list, moves and draws each component, then calls transferToImageBitmap() to freeze the frame and hand it back to the main thread.

Stage 3 — Main thread receives the bitmap. The main thread's worker.onmessage handler stores the returned ImageBitmap in a variable called nextTCJSgameFrame.

Stage 4 — Main thread composites. On the next animation frame, the main thread blits the worker's bitmap onto the visible canvas via transferFromImageBitmap(), then draws the static layer on top, then draws any dynamic components that the worker didn't cover.

The net effect: while the main thread is running game logic, the worker is producing the next frame. Neither thread blocks the other.

Status

Item	Status
Worker pipeline runs	✅ Working
1:1 send/receive in steady state	✅ Confirmed
120fps on desktop (high-refresh panel)	✅ Observed on dev machine
Fallback main-thread render	⚠️ Still active — pipeline is additive, not replacing
Low-end device testing	❌ Not done
Delta timing across refresh rates	⚠️ Uses `1/fps`, drift possible between devices
Published benchmarks	❌ Pending

Beta means: the mechanism works, but the numbers aren't proven across devices yet. Treat it as a promising experiment, not a solved problem.

Known Limitations

upgradePerform() must be called manually. In this beta, you call it before display.start(). A future version will auto-activate on script load.

Delta timing uses 1/fps. On a 60Hz device vs. a 120Hz device, physics speed can differ. A fixed-timestep update loop is the eventual fix. Until then, tune physics constants for your target refresh rate.

The main thread still draws a fallback layer. Until that's disabled, both threads do some work. The intended final architecture is worker-only rendering for the dynamic layer.

No published benchmark suite yet. The claim of GPU-comparable consistency is based on local testing, not a public, reproducible benchmark.

Same-origin only. The worker cannot be loaded cross-origin. If you serve bust.js from a CDN, you'll need to fetch and Blob-wrap bust-worker.js yourself, or self-host both files.

How to Try It

Bust Beta is three files. Drop them next to your game:

<script src="epic.js"></script>
<script src="bust.js"></script>
<script src="test.js"></script>

Then, in your game file, call upgradePerform() before you create your Display:

const display = new Display();
upgradePerform();
display.perform();
display.start(800, 600);

bust.js loads bust-worker.js automatically. Both files must be served from the same origin — the worker cannot be loaded cross-origin.

Beta note: upgradePerform() must be called before display.start() runs. In this beta it is a manual step. A future version will auto-activate on script load.

That's it. Your existing Limn game runs otherwise unchanged.

What's Next

Auto-activate on script load, so upgradePerform() becomes optional.
Disable the fallback render path so the worker truly owns the dynamic layer.
Add a worker-side fps counter to prove the frame count is worker-produced, not RAF-tick-produced.
Test on low-end Android — the device class the plugin is for.
Publish a benchmark scene (open source) so anyone can reproduce the numbers.
Move to a fixed-timestep update loop so physics is refresh-rate independent.

Philosophy

Limn's rule is "common outcomes should be functions." Bust Beta's rule is "the engine shouldn't be the reason a frame is missed."

Add the script. Get a frame. If your hardware can show it, Bust Beta tries to produce it.

Feedback

Bust Beta is a beta. If it works on your device — or if it doesn't — open an issue with your device model, browser version, and the fps counter reading. Every report is a data point.

License

MIT

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: