DEV Community: Kehinde Owolabi

🚀 From FlipaClip to SitePoint: The Full Story of Kehinde Owolabi

Kehinde Owolabi — Mon, 24 Aug 2026 03:43:40 +0000

🚀 From FlipaClip to SitePoint: The Full Story of Kehinde Owolabi

How a Nigerian teenager built a professional game engine with borrowed laptops, offline W3Schools, and pure determination.

🎮 Play the Game

Try Limn Engine Live — Space Shooter Demo

See what 4 years of determination built. This space shooter runs at 60 FPS on a Tecno Pop 4 with 1GB RAM.

📖 Introduction

Every developer has an origin story. Some start with a fancy computer and a computer science degree. Others start with a flipbook app and a sister who trusted them with her phone.

My name is Kehinde Owolabi. I'm 18 years old (born December 4, 2007), and I live in Lagos, Nigeria. I'm currently in PC103 at BYU Pathway, and I'm a member of The Church of Jesus Christ of Latter-day Saints.

I built a 94/100 professional game engine called Limn Engine. It runs at 60 FPS on a Toshiba with 4GB RAM. It was published on SitePoint and ranked #3 among 2D JavaScript game engines.

Nobody knew it was developed on a Chromebook, a borrowed Thinkpad (behind my sister's back), and a Toshiba that "hung like hell." That was the secret I kept for months.

But that's only one part of this story.

This is the full story of how I went from a button phone to a 94/100 game engine, from FlipaClip to SitePoint, from a boy who failed physics to a developer who built something that runs on a Tecno Pop 4.

The one-line summary: "I'm Kehinde Owolabi, an 18-year-old developer from Lagos, Nigeria who went from FlipaClip to building a 94/100 game engine on borrowed laptops — and got published on SitePoint." 🎮🚀

🎨 The Beginning: FlipaClip and the Spark of Creativity

Before I was a developer, I was an animator.

I used FlipaClip — a simple animation app on mobile — to create flipbook-style animations. I loved bringing characters to life, frame by frame. I would spend hours drawing, tweaking, and watching my creations move.

That creative spark stayed with me. I wanted to create interactive experiences. I wanted to build games. But I didn't know how.

At that time, I didn't even know what programming was. I just knew I wanted to make things.

What this taught me: Animation taught me the value of frame-by-frame iteration — a skill that later helped me debug game loops and rendering pipelines.

📚 The First Encounter with Code

When I was in SS1 (Senior Secondary 1), I opened my computer textbook and found something unexpected: a BASIC tutorial.

I read it cover to cover. I was fascinated by the idea that you could type words and make a computer do things. It felt like magic — but it was real. It was something I could learn.

But there was a problem: I didn't have a phone or a laptop.

I couldn't practice. I couldn't test the code. I could only read and imagine what it would be like to actually run the programs. I wrote down code snippets in my notebook, hoping that someday I would have a device to try them on.

What this taught me: You don't need a computer to start learning. I wrote code on paper before I ever typed it.

📱 The Turning Point: A Sister's Phone and a Love for Python

Then came physics class.

I was failing physics — not because I didn't understand it, but because I was absent from class. When I returned, I had fallen behind. My sister noticed and gave me her phone so I could read and research.

Instead of just studying physics, I started researching programming.

I discovered Python. I read about it. I watched videos about it. And I fell in love.

Python was simple. It was readable. It made sense in a way that physics didn't at the time. I knew I had to learn it. I spent hours reading tutorials, watching YouTube videos, and absorbing everything I could.

That's when I realized: I was genuinely interested in coding. It wasn't just a distraction from physics — it was something I wanted to pursue.

I still love physics, by the way. I only failed because I was absent. Once I caught up, I understood it just fine. But coding had already captured my heart.

What this taught me: Sometimes your biggest failure becomes your biggest opportunity. Physics led me to coding.

📲 The Button Phone Era

Before my sister got the laptop, I used my mom's Itel button phone.

Data was available sometimes. I would Google codes and write them down on paper — because I couldn't save files on a button phone.

When my sister's friend came around, I would borrow their phone and go to Webmaker to practice.

I learned to code without a laptop. That's not a flex — that's survival. I did whatever it took to keep learning.

What this taught me: Resourcefulness is more important than resources.

🌐 The JavaScript Journey

In 2023, I was asked to build a website for a competition in Public Art Africa. I built it on Replit using HTML, CSS, and JavaScript.

That's when I learned JavaScript. Not because I planned to — but because I had to. The competition required a website, and JavaScript was the language of the web.

After the competition, I wanted to build games. I knew about Pygame, but JavaScript worked in the browser — no installation needed, no complex setup. I could just open a tab and start coding.

That was the hook. JavaScript gave me the freedom to create without barriers.

What this taught me: Sometimes the best way to learn is to be thrown into the deep end. I learned JavaScript because I had to ship a project.

🖥️ The Laptop Heist Era

I didn't have a laptop of my own. Not for a long time.

Sister's Toshiba (4GB RAM — "Hangs Like Hell")

My sister got a Toshiba laptop with 4GB of RAM. It hung like hell. But I coded on it anyway. It didn't matter that it was slow — it was a laptop, and I could use it to build things.

The problem? She wouldn't give it to me willingly. I had to code behind her back. If anything happened to the laptop, she would blame me.

Every time I heard her footsteps, I would quickly close the lid. I coded in secret, in fear, in stolen moments. But I coded.

The charger spoiled. We didn't buy a new one for two months. But I didn't stop coding. I found other ways — borrowing phones, writing code on paper, waiting for opportunities.

What this taught me: Fear of being caught couldn't stop me. If you really want to build something, you'll find a way.

Brother's HP (He Let Me)

My brother David got a laptop later. He let me code on it. No guilt. No hiding. Just permission.

That HP saw TCJSGame V3. The breakthrough. The Tile Class. The flow state. For the first time, I could code without looking over my shoulder.

David's support meant everything. He believed in me when I didn't have much to show.

What this taught me: Permission and support are powerful. One person believing in you can change everything.

💻 The Thinkpad Era (Behind My Sister's Back Again)

After the Toshiba spoiled, I had to use my sister's Thinkpad — again behind her back.

That Thinkpad saw V2 of the engine.

I renamed it to TCgame, then TCJSgame.

Copilot helped clean up the code and organize everything into classes. It was the first time the engine looked like a real project.

What this taught me: Even when you're building in secret, you can still build something real.

📚 The Church WiFi

My chapel is the Agege Stake Center, and Abule Egba Ward. There's WiFi there.

So when I was in church, I would download:

YouTube videos
Offline W3Schools
PDFs

I learned Python, Java, JS, HTML, CSS, PHP, Scratch — everything I could. I was hungry for knowledge, and I took it wherever I could find it.

What this taught me: Education is available if you're willing to look for it. Even church WiFi can be a classroom.

🛠️ The Birth of JGame

I wanted to build games. I started with Pygame but didn't understand it.

So I decided to build my own engine by copying codes and learning how they worked.

That became JGame — the first version of what would eventually become Limn Engine.

JGame existed on the Toshiba laptop. I finished it but never published it.

Then the Toshiba spoiled.

What this taught me: Your first version doesn't need to be perfect. It just needs to exist.

🤖 The AI Analysis Era

I began analyzing TCJSgame with DeepSeek and ChatGPT.

I knew something was missing. So I added:

Scene management
TileMap
hide() and show()
Gradients
Fullscreen support

I developed all of this without AI — I just used AI to analyze what was wrong. I wanted to learn how to build things myself.

What this taught me: AI is a tool for analysis, not a replacement for understanding. I built the features myself; AI just helped me see what was missing.

🔥 The Dual-Renderer Breakthrough

Limn Engine V3 had low ratings because of performance.

I developed extensions:

Sonic.js (performance)
Tctxt (text rendering)

Then I developed the dual-renderer system.

The idea came from tile caching — but the first version had a bug: it rerendered every frame despite caching.

I fixed it. The dual-renderer was born.

The engine went from 4 FPS to 60 FPS on a Toshiba with 4GB RAM. That's a 15x improvement.

What this taught me: Sometimes the problem isn't that something is slow — it's that you're doing it too many times. Cache everything you can.

🔍 The Delta Time Bug

The original code used 1 / fps calculated every second. The problem? The FPS counter resets every second, so at the start of each second, the FPS would start at 0 and build up to 60. This made the game spike at the beginning of every second.

I tested the fix on my sister's HP laptop without her knowing. The Pygame-style method — calculating the time difference between frames — worked perfectly and eliminated the spikes.

What this taught me: The simplest bugs can have the biggest impact. Delta time is critical for consistent performance.

📱 The Tecno Pop 4 Test

Tecno Pop 4 is my mom's phone. 1GB RAM. Weak processor.

I tested the engine on it.

At first, it was laggy. The FPS was low. But after fixing the delta time bug and optimizing the renderer, it started working smoothly.

If it works on a Tecno Pop 4, it works on anything.

That moment when I saw my game running smoothly on that phone — I was proud. Like, "Ha, I actually did this."

What this taught me: Test on the worst hardware you can find. If it works there, it'll work everywhere.

🏷️ The Rebrand: TCJSgame → Limn Engine

TCJSgame was a working name. Technical. Hard to spell. No meaning.

Limn (verb) — to draw, paint, or portray.

Perfect. The engine helps you draw games into existence.

The name change was also practical: TCJSgame was given because all other names (TCgame, TC Games) were already taken. So I chose Limn Engine — a name with meaning, a name that reflects what the engine does.

What this taught me: A name matters. It should tell a story about what you've built.

🔗 The SitePoint Journey

In 2026, I published an article on SitePoint called "Top 10 2D JavaScript Game Engines for Beginners."

Limn Engine was ranked #3 with a 9/10 rating.

What this taught me: Recognition comes when you keep building. I didn't set out to get published — I just kept making things.

📊 The Rating

Limn Engine received a 94/100 rating.

Category	Score
Performance	95
Ease of Use	94
Feature Set	92
Documentation	92
API Design	88
Beginner Friendliness	94
Cross-Platform	85
Overall	94/100

What this taught me: Ratings are nice, but they're not the goal. The goal is to build something people can use.

🎯 The One-Line Summary

"I'm Kehinde Owolabi, an 18-year-old developer from Lagos, Nigeria who went from FlipaClip to building a 94/100 game engine on borrowed laptops — and got published on SitePoint." 🎮🚀

🔗 Follow Me

Platform	Link
DEV.to	Follow Kehinde Owolabi on DEV.to
GitHub	github.com/terracodes004/limn-engine-doc
Discord	Join the community
Live Demo	limn-engine-doc.vercel.app/test9.html

🐛 Report Bugs

Found a bug? Report it here:

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

📝 What's Next

Upcoming articles:

"How Limn Engine's Dual-Renderer Works" — The 4 FPS → 60 FPS story
"Building a Dungeon Crawler with Limn Engine" — Complete game tutorial
"Limn Engine vs Phaser: Which One Should You Choose?" — Honest comparison

🎯 What You've Learned

Concept	How It Applies
Resourcefulness	You can learn without a laptop
Persistence	Keep building, even in secret
Caching	Render once, paste forever
Delta time	Consistent performance across devices
Testing	Test on the worst hardware

🚀 Final Thoughts

I built a game engine on borrowed laptops, behind my sister's back, with offline W3Schools and church WiFi.

If I can do it, so can you.

The resources you have are enough. The time you have is enough. The knowledge you have is enough.

Just keep building.

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

🐛 How I Fixed the Delta Time Bug in Limn Engine (And How You Can Too)

Kehinde Owolabi — Fri, 21 Aug 2026 03:15:51 +0000

🐛 How I Fixed the Delta Time Bug in Limn Engine (And How You Can Too)

A story about frame rates, Chromebooks, and the one bug that broke everything

📖 Introduction

Let me tell you about a bug that haunted Limn Engine for months.

Limn Engine was developed on a Chromebook — but nobody knows that. It was tested on a Toshiba laptop with 4GB of RAM, and everything worked perfectly. Enemies moved at the right speed. The player controlled smoothly. The game ran at a crisp 60 frames per second.

But when I tested the same game on a Tecno Pop 4 (a low-end Android phone with 1GB of RAM and a weak processor), something strange happened.

The enemies moved at completely different speeds.

Sometimes they were too fast. Sometimes they were too slow. Sometimes they started fast and then slowed down for no reason.

The game was broken — and the problem was hiding in plain sight: delta time.

🎯 What Is Delta Time (And Why Should You Care?)

Delta time (often written as dt) is the amount of time that has passed since the last frame. It's measured in seconds.

Frame Rate	Delta Time
60 FPS	~0.0167 seconds
30 FPS	~0.0333 seconds
15 FPS	~0.0667 seconds

Here's the rule: If you multiply your movement speed by delta time, your game runs at the same speed on all devices.

// ✅ CORRECT: Frame-rate independent
player.x += 200 * dt;  // Moves 200 pixels per second

// ❌ WRONG: Frame-rate dependent
player.x += 4;  // Moves 4 pixels per frame (speed varies by FPS)

Without delta time, your game will run at different speeds on different devices. A fast computer (144 FPS) will feel like the game is in fast-forward, while a slow device (15 FPS) will feel like slow-motion.

🐛 The Bug: How I Broke Delta Time

Limn Engine already had delta time — but it was calculated using 1 / fps every second. Here's what the original code looked like:

setInterval(() => {
    display.deltaTime = 1 / display.fps;
    refresh = true;
}, 1000);

This worked... sort of. But there was a huge problem:

The FPS counter resets every second. At the start of each second, the FPS starts at 0 and builds up to 60. So for the first fraction of a second, 1 / fps was huge — sometimes 0.5 or even 1.0. This made components move incredibly fast at the beginning of each second, then suddenly slow down to normal speed.

It was like the game was having a seizure every second.

🔧 The Fix: Two Different Approaches

I tested two different fixes:

Approach 1: The `1 / fps` Method (Original)

setInterval(() => {
    display.deltaTime = 1 / display.fps;
}, 1000);

Problem: FPS builds from 0 to 60, causing dt to spike.

Approach 2: The Pygame Method (What I Ultimately Used)

function ani(time) {
    display.deltaTime = display.timeFromAllFrames - display.timeFromPreviousFrames;
    display.timeFromPreviousFrames = time;

    // Convert to seconds
    update(dt = display.deltaTime / 1000);
}

🧪 The Test: HP Laptop (Behind My Sister's Back)

I tested both approaches on my sister's HP laptop when she wasn't looking (don't worry, she still doesn't know). Here's what I found:

Method	Result
`1 / fps`	Worked, but had spikes at the start of each second
Pygame-style (difference between frames)	Worked perfectly, smooth movement

The Pygame-style method gave similar results but was more reliable. It didn't spike at the beginning of each second because it calculates the actual time between frames, not an average over a second.

📊 The Results: Before and After

Device	Before Fix	After Fix
Chromebook (dev machine)	Jagged movement	Perfect speed
Toshiba Laptop (4GB RAM)	Game too fast at start	Perfect speed
HP Laptop (tested behind sister's back)	Spikes every second	Perfect speed
Tecno Pop 4 (1GB RAM)	Game too slow	Perfect speed
Desktop (144 FPS)	Unplayable	Perfect speed

The same game now runs at the same speed on every device.

🔗 The Code

You can see the final working code here:

👉 Limn Engine Source Code (epic.js)

Look for the ani() function to see the delta time fix in action.

📝 The Documentation

For more information about Limn Engine, check out the complete documentation:

👉 Limn Engine Documentation on DEV.to

🐛 Found a Bug? Report It Here!

If you encounter any issues with Limn Engine, please report them on GitHub:

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

📋 How to Report a Bug (Helpful Template)

When you open an issue, please include:

A clear description of the bug.
Steps to reproduce it.
What you expected to happen vs. what actually happened.
Screenshots or error logs (if applicable).
Which version of Limn Engine you're using.

Here's a template you can use:

**Bug Description:**
[Describe the problem clearly]

**Steps to Reproduce:**
1. Do this...
2. Then do this...
3. Observe the bug...

**Expected Behavior:**
[What should have happened]

**Actual Behavior:**
[What actually happened]

**Screenshots/Logs:**
[Attach if available]

**Limn Engine Version:**
[v0.x.x]

**Device/OS:**
[e.g., Tecno Pop 4, Android 10]

💡 What I Learned

1 / fps is not the best way to calculate delta time. It works, but it's unreliable at the start of each second.
The Pygame method is better. Calculating the difference between frames is more accurate and doesn't spike.
Test on low-end devices. If it works on a Tecno Pop 4, it'll work on almost anything.
Test on different laptops. I tested on a Chromebook, Toshiba, and HP — and they all showed different issues.
The dual-renderer saved me. Even with the delta time bug, the game was running at 60 FPS on the Toshiba laptop. If I had been using a simpler engine, the performance would have been terrible too.
Develop on a Chromebook. Nobody knows Limn Engine was developed on a Chromebook — and now you know my secret.

🎯 The One-Line Summary

"I fixed a delta time bug that made my game spike every second — and you can too." 🎮🚀

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

✅❌ The Limn Engine Commandments: 31 Do's and Don'ts for Better Games

Kehinde Owolabi — Wed, 19 Aug 2026 21:46:44 +0000

✅❌ The Limn Engine Commandments: 31 Do's and Don'ts for Better Games

🎯 Setup & Configuration

1. ✅ DO: Call `display.perform()` Before `display.start()`

const display = new Display();
display.perform();  // ✅ MUST come first
display.start(800, 600);

Why: The perform() method is a critical performance patch that replaces the engine's default rendering loop. By default, when you call display.start(), the engine uses setInterval(() => this.updat(), 20) which locks your game to roughly 50 frames per second. This is because setInterval is unreliable — it doesn't sync with the monitor's refresh rate and can drift over time, causing stutter and inconsistent frame pacing. When you call display.perform() first, it overrides the start() method to use requestAnimationFrame() instead, which synchronizes your game loop with the monitor's refresh rate for smoother animations. More importantly, requestAnimationFrame pauses automatically when the user switches tabs, saving CPU and battery life. If you accidentally call start() before perform(), the setInterval loop is already running and the patch won't take effect. Always call perform() first, then start().

❌ DON'T: Call `display.start()` Before `display.perform()`

const display = new Display();
display.start(800, 600);  // ❌ Wrong order
display.perform();        // ❌ Too late — the damage is done

Why: When you call start() first, the engine launches the old setInterval loop that runs at an unreliable ~50fps. The perform() method works by replacing the start() method itself with a new version that uses requestAnimationFrame. However, if start() has already executed, the damage is done — the setInterval loop is already running, and the perform() patch won't stop it or replace it. You'll end up with two loops fighting for control, causing erratic behavior and inconsistent frame rates. The only way to fix this is to refresh the page and call perform() first. This is one of the most common mistakes beginners make, and it's also one of the hardest to debug because the game appears to run but feels "off" or stuttery. Always remember: perform() first, then start().

2. ✅ DO: Name Your Display Instance `display`

const display = new Display();  // ✅ Correct
display.start(800, 600);

Why: The Limn Engine was built with the expectation that your main display instance will be called display — lowercase, exactly as spelled. This isn't just a convention; it's a hard dependency baked into the engine's internals. Many of the engine's built-in methods and utilities, such as Component.crashWith(), display.camera.follow(), and the various move functions, directly reference a global variable named display. For example, when you call move.bound(player), the function internally uses display.canvas.width and display.canvas.height to determine the screen boundaries. If you name your instance something else — say, game or app — these internal references will fail because display will be undefined. You'll see cryptic errors like "Cannot read property 'canvas' of undefined" and your game will break. The engine was designed this way to keep the API simple for beginners, but it means you must follow this naming rule strictly.

❌ DON'T: Use a Different Variable Name

const game = new Display();  // ❌ Wrong
game.start(800, 600);

Why: The engine has display hardcoded in many places. When you use a different name, internal functions like move.bound() and Component.clicked() will look for a variable named display and find nothing. This results in undefined errors that can be confusing to debug. For example, move.bound(player) checks display.canvas.width, but if your instance is named game, display is undefined, and you'll get "Cannot read property 'canvas' of undefined." The error messages won't point to your variable name — they'll point to the internal engine code, making it even harder to figure out. The only way to avoid this is to use the exact name display. This is a small constraint that saves you from hours of debugging.

3. ✅ DO: Call `display.perform()` Before Using TileMaps

const display = new Display();
display.perform();        // ✅ Creates fake canvas
display.start(800, 600);
display.tileMap();        // ✅ TileMap works!
display.tileFace.show();  // ✅ Tiles appear!

Why: The TileMap system relies on an offscreen canvas called fake to render its tiles. This fake canvas is only created when you call display.perform(). Without perform(), the fake variable remains undefined, and the TileMap has nowhere to draw its tiles. The engine doesn't throw an error — it just silently fails to render anything, leaving you with a blank screen and no indication of what went wrong. This is especially frustrating because the code looks correct and no error messages appear. The fake canvas is also where the engine caches static content for performance, so it's essential for more than just TileMaps. Always call perform() before using any TileMap functionality. If you're using TileMaps, perform() is mandatory, not optional.

❌ DON'T: Use TileMap Without `display.perform()`

const display = new Display();
display.start(800, 600);  // ❌ No perform() called
display.tileMap();        // ❌ Creates tilemap
display.tileFace.show();  // ❌ Nothing appears!

Why: Without perform(), the fake canvas doesn't exist. The TileMap has no offscreen buffer to render its tiles, so nothing is drawn. The engine doesn't throw any errors — it just silently fails. You'll see a blank screen and spend hours wondering why your tiles aren't appearing. This is one of the most common and frustrating mistakes beginners make because everything looks correct in the code. The solution is simple: always call perform() before using any TileMap functionality.

4. ✅ DO: Use `deltaTime` for Movement

function update(dt) {
    player.x += 200 * dt;  // ✅ Frame-rate independent
}

Why: The deltaTime parameter (often abbreviated as dt) is the amount of time that has passed since the last frame, measured in seconds. On a 60Hz monitor, dt is approximately 0.0167 seconds (1/60). On a 144Hz monitor, it's about 0.0069 seconds (1/144). When you multiply your speed values by dt, you ensure that movement is frame-rate independent. For example, if you set player.speedX = 200, and then in your update loop you write player.x += player.speedX * dt, the player will move 200 pixels per second regardless of whether the game is running at 30fps, 60fps, or 144fps. On a 60Hz screen, each frame moves 200 * 0.0167 = 3.34 pixels. On a 144Hz screen, each frame moves 200 * 0.0069 = 1.39 pixels. Over the course of one second, both add up to exactly 200 pixels. This is essential for any game that should run consistently across different hardware.

❌ DON'T: Use Raw Numbers for Speed

function update(dt) {
    player.x += 4;  // ❌ Frame-rate dependent
}

Why: When you use raw numbers without dt, your game's speed becomes tied to the frame rate. On a fast computer running at 144fps, a speed of 4 pixels per frame translates to 576 pixels per second. On a slow computer running at 30fps, the same speed of 4 pixels per frame translates to only 120 pixels per second. This means your game will run at completely different speeds on different computers — a player on a high-end machine will zoom through levels while a player on a low-end machine will crawl. This is a game-breaking issue that makes your game unplayable for a significant portion of your audience. Always multiply your speeds by dt to ensure consistent gameplay across all devices.

5. ✅ DO: Normalize Diagonal Movement

let mx = 0, my = 0;
if (display.keys[37]) mx = -1;
if (display.keys[39]) mx = 1;
if (display.keys[38]) my = -1;
if (display.keys[40]) my = 1;

if (mx !== 0 && my !== 0) {
    mx *= 0.707;  // ✅ Prevents faster diagonal movement
    my *= 0.707;
}

Why: When you move a player or enemy by incrementing both x and y independently at the same speed, the diagonal speed becomes √(speed² + speed²) = speed × √2, which is approximately 1.414 times faster than horizontal or vertical movement. This happens because the two velocity vectors are added together at a right angle, and the resulting vector's magnitude is the square root of the sum of squares (the Pythagorean theorem). In practice, if your player moves at 200 pixels per second horizontally, moving diagonally will make them move at 282 pixels per second — a noticeable and disorienting speed boost. Players will feel like they're "sprinting" when moving diagonally, which breaks the consistency of your game's movement mechanics. To fix this, you need to normalize the direction vector. The most common approach is to multiply both mx and my by 1/√2 ≈ 0.707 when both are non-zero, which reduces the combined speed back to exactly 1. This ensures that whether the movement is horizontal, vertical, or diagonal, the resulting speed is exactly the same.

❌ DON'T: Ignore Diagonal Normalization

if (display.keys[37]) player.speedX = -200 * dt;
if (display.keys[39]) player.speedX = 200 * dt;
if (display.keys[38]) player.speedY = -200 * dt;
if (display.keys[40]) player.speedY = 200 * dt;

Why: When both left and up are pressed, the player moves at √(200² + 200²) = 282 pixels/second, which is faster than the intended 200 pixels/second. This is a fundamental principle of game physics and one of the most common "beginner traps" in game development.

🧩 Components

6. ✅ DO: Use `display.add()` for Every Component

const player = new Component(40, 40, "blue", 400, 300, "rect");
display.add(player);  // ✅ Required

Why: Creating a new Component with new Component(50, 50, "red", 100, 100) allocates memory for that object and sets up its properties — but it does not automatically add it to the rendering pipeline. The engine maintains an internal list of components called comm (short for "components") that it iterates over every frame. Inside updat(), the engine loops through comm, calls move() on each component to update its position, and then calls update() to draw it on the canvas. If you forget to call display.add(player), your player object exists in memory but is never added to comm. As a result, updat() never sees it, never updates its position, and never draws it. You'll have a perfectly valid Component object that simply never appears on screen. This is a common source of frustration for beginners who think they've done everything right but see nothing. The rule is simple: every Component you create must be passed to display.add() to become part of the game world.

❌ DON'T: Forget to Add Components

const player = new Component(40, 40, "blue", 400, 300, "rect");
// ❌ Missing display.add(player)

Why: Without display.add(), your component exists only in memory. It's like creating a character in a game but never spawning them into the world — they exist in the code but have no presence in the game. The engine's render loop iterates over the comm array to draw components, but your component isn't in that array. No error is thrown; the component just never appears. This is one of the most common and frustrating bugs for beginners because everything looks correct in the code, but nothing shows up on screen. Always remember: creating a component is only half the job — you must also add it to the display.

7. ✅ DO: Use `setImage()` for Images

player.setImage("hero.png");  // ✅ Correct

Why: The setImage() method was designed to handle the complexities of loading images in a browser. When you call component.setImage("player.png"), the method creates a new Image object, sets its src property, and attaches onload and onerror event listeners. The onload callback sets imageLoaded = true, which the engine checks before attempting to draw the image. The onerror callback provides a graceful fallback — if the image fails to load (due to a typo in the filename, network issues, or CORS restrictions), the component automatically converts itself to a red rectangle so your game doesn't crash with broken images. If you instead directly assign properties like component.image = new Image(); component.image.src = "player.png";, you bypass all of this safety logic. The component's type won't be set correctly, imageLoaded will remain false, and the engine might attempt to draw a non-existent image, causing runtime errors or invisible objects. Additionally, setImage() handles the case where you might want to switch images dynamically — it properly cleans up the old image before loading the new one, preventing memory leaks.

❌ DON'T: Directly Assign Image Properties

player.type = "image";           // ❌ Wrong
player.image = new Image();      // ❌ Wrong
player.image.src = "hero.png";   // ❌ Wrong

Why: Images load asynchronously, which means the browser continues executing code while the image is being downloaded. If you directly assign the image and then immediately try to draw it, the image may not have finished loading yet. The engine's imageLoaded flag is designed to handle this — it's set to true only after the image has fully loaded. When you use setImage(), this flag is properly managed. When you assign properties directly, you bypass this system, and the engine may try to draw an image that isn't ready yet, resulting in invisible objects or rendering errors. Additionally, setImage() sets the component's type to "image" automatically, which tells the engine how to render the component. If you forget to set the type, the engine will treat it as a rectangle and ignore the image entirely.

8. ✅ DO: Use `destroy()` for Permanent Removal

bullet.destroy();  // ✅ Removes forever

Why: The destroy() method is the proper way to permanently remove a component from your game. When you call player.destroy(), the method searches the global comm array (and the commp array used by the fake canvas) for references to that component and removes them. It then sets the component's update method to null, effectively cutting all ties to the rendering pipeline. This allows the JavaScript garbage collector to reclaim the memory used by the component and its associated resources (including images, which can be large). If you instead use hide() to make a component invisible, the component is still present in the comm array. Every frame, the engine will still call move() on it (updating its position), check its collision with other objects, and attempt to call update() on it (which now does nothing because you set update = null). This wastes CPU cycles — especially problematic if you have hundreds of destroyed enemies still being processed. hide() is designed for temporary invisibility, like when a coin is collected and you want to respawn it later. For permanent removal, always use destroy().

❌ DON'T: Hide Objects You'll Never Use Again

bullet.hide();  // ❌ Still in memory

Why: When you hide an object, it remains in the engine's internal arrays and continues to be processed every frame. The engine still calls move() on it, updating its position based on speed and physics. It still checks collision with other objects. The only thing that stops is drawing. This means you're wasting CPU cycles on objects that will never be seen again. If you have 100 bullets hidden this way, you're still updating 100 bullets every frame, which slows down your game. Worse, because the objects are still in memory, they contribute to memory usage and can cause performance issues over time. Use hide() only for objects that you plan to show again later. For objects that are gone forever, use destroy().

9. ✅ DO: Use `hide()` for Temporary Invisibility

enemy.hide();  // ✅ Disappears but can be shown later

Why: The hide() method is designed for scenarios where you need a component to disappear temporarily but plan to bring it back later. When you call coin.hide(), the method sets the component's update method to null, which prevents it from being drawn on screen. However, the component remains in the comm array and continues to be part of the game loop — its position is still updated, its collision is still checked, and it still exists in memory. This is perfect for a coin that the player just collected but that you want to respawn after 10 seconds. When it's time to respawn, you simply call coin.show(), which restores the update method to its original drawing function, and the coin reappears on screen. If you used destroy() instead, the coin would be completely removed from memory and you'd have to create a brand new component from scratch, with all the overhead of allocating memory, loading images, and re-adding it to the display. This becomes especially important for high-frequency objects like bullets or particles — creating and destroying thousands of objects per second would trigger frequent garbage collection, causing visible stutter.

❌ DON'T: Use `destroy()` for Temporary Removal

enemy.destroy();  // ❌ Gone forever

Why: destroy() is permanent — it removes the component from the engine's arrays, sets its methods to null, and marks it for garbage collection. If you call destroy() on an enemy that you planned to respawn later, you'll have to create a whole new enemy from scratch. This means allocating new memory, setting up all the properties again, loading any images again, and adding it back to the display. This is inefficient and can cause performance issues if done frequently. Use destroy() only when you're absolutely sure you won't need the object again. For objects that you'll reuse (like enemies in a wave-based game), use hide() to make them invisible and then show() to bring them back.

10. ✅ DO: Use `Tctxt` for UI Text

const scoreText = new Tctxt("24px", "Arial", "white", 20, 50);
scoreText.setText("Score: 0");
display.add(scoreText);

Why: The Tctxt class is a specialized text component that provides features regular text doesn't have. Unlike a basic Component with type = "text", Tctxt supports background colors with padding (so your text has a nice box behind it), text alignment (left, center, right), text stroke (outline effect), and baseline control. It also automatically measures text width to handle alignment correctly. When you use Tctxt, your UI will look polished and professional. If you use a basic Component for text, your text will be drawn directly on the canvas with no background, no padding, and no alignment options. This makes your UI look plain and hard to read, especially over complex backgrounds. For any UI element that displays text — scores, health bars, menus, dialog boxes — always use Tctxt for a cleaner, more professional look.

❌ DON'T: Use `Component` for Text

const scoreText = new Component("24px", "Arial", "white", 20, 50, "text");
scoreText.setText("Score: 0");
display.add(scoreText);

Why: The basic Component class treats text as a simple rendering operation — it draws the text at the specified position with the specified font and color, and that's it. There's no background, no padding, no alignment, and no stroke. This means your text will be drawn directly on top of whatever is behind it, making it hard to read if the background is busy or has similar colors. You also can't center the text easily because you'd have to manually calculate the text width and adjust the position. Tctxt handles all of this for you, providing a polished UI with minimal effort. For any game that needs to display information to the player, Tctxt is the way to go.

11. ✅ DO: Call `.fixed()` on UI Elements Every Frame

function update(dt) {
    scoreText.fixed();  // ✅ Keeps UI on screen
}

Why: The .fixed() method adjusts a component's position based on the camera's current position. When you call .fixed(), the component's x and y are recalculated to be relative to the camera's viewport. This ensures that the UI element stays in the same place on the screen, regardless of where the camera moves. Without .fixed(), UI elements would scroll with the camera — they'd move off-screen when the camera moves, and appear to drift around the world. This is because components are positioned in world space by default. By calling .fixed() every frame, you're telling the engine "this element should be fixed to the screen, not the world." You need to call it every frame because the camera's position can change every frame. If you call it once, the UI will be fixed to the camera's position at that moment, but when the camera moves, the UI will stay in the wrong place. For any UI element that should stay on screen (score, health, menus), always call .fixed() in your update() loop.

❌ DON'T: Call `.fixed()` Once

scoreText.fixed();  // ❌ Called only once

Why: .fixed() works by setting the component's position relative to the camera's current position. If you call it once at the start of the game, the component is positioned correctly for that moment. But as soon as the camera moves — because the player walks to the right, for example — the component's position is no longer correct. It stays in the world position it was fixed to, which is now off-screen or in the wrong place. To keep UI elements correctly positioned, you must call .fixed() every frame, so that the position is recalculated based on the camera's current position. This ensures that your UI stays in the same place on the screen, no matter where the camera moves.

🏃 Movement

12. ✅ DO: Use `move.bound()` to Keep Objects On Screen

move.bound(player);  // ✅ Keeps player on screen

Why: move.bound() is a single-line solution that replaces four separate if statements. When you call move.bound(player), the function checks if the player's x is less than 0 and sets it to 0 if so; checks if x + width exceeds display.canvas.width and sets it to canvas.width - width; and does the same for y and height. This keeps your player (or any component) within the visible screen area. Writing this yourself isn't difficult — it's just four conditionals — but doing it manually for every component that needs boundary checking is repetitive and error-prone. You might forget to subtract the component's width when checking the right edge, or accidentally use height instead of width. You might also need to check boundaries for enemies, bullets, and UI elements, leading to duplicated code. move.bound() centralizes this logic in one well-tested location, reducing bugs and keeping your code clean. It also has a companion function, move.boundTo(), which allows you to specify custom boundaries (like keeping a boss enemy within a specific arena), giving you even more flexibility without writing custom logic.

❌ DON'T: Write Your Own Edge Detection

if (player.x < 0) player.x = 0;
if (player.x + player.width > canvas.width) player.x = canvas.width - player.width;
if (player.y < 0) player.y = 0;
if (player.y + player.height > canvas.height) player.y = canvas.height - player.height;

Why: Writing your own edge detection is repetitive and error-prone. You have to remember to check all four edges, and you have to remember to subtract the component's width and height when checking the right and bottom edges. If you forget, your object will partially go off-screen before being stopped. You also have to do this for every component that needs boundary checking, leading to duplicated code. move.bound() handles all of this for you in a single function call, with all the edge cases handled correctly. It's faster to write, faster to read, and less likely to contain bugs.

13. ✅ DO: Use `move.accelerate()` and `move.decelerate()` for Smooth Physics

if (display.keys[68]) {
    move.accelerate(player, 0.6, 0, 8, 0);  // ✅ Smooth acceleration
} else {
    move.decelerate(player, 0.4, 0);        // ✅ Smooth deceleration
}

Why: move.accelerate() and move.decelerate() provide smooth, weighty movement that feels realistic and responsive. move.accelerate(player, 0.5, 0.5, 5, 5) adds 0.5 pixels per second² to the player's speedX and speedY, while capping the maximum speed at 5 pixels per second in each direction. This creates a feeling of momentum — the player gradually speeds up to their maximum velocity rather than instantly teleporting to max speed. move.decelerate() does the opposite, reducing speed toward zero, which creates friction and a sense of weight. If you directly set player.speedX = 5 and player.speedY = 5, the player immediately moves at full speed with no acceleration or deceleration, resulting in twitchy, unnatural movement that feels like ice-skating. This is especially noticeable in platformers, where acceleration and deceleration give the player character a sense of weight and control. Directly setting speed is appropriate for some scenarios (like teleportation or menu navigation), but for character movement in games, acceleration-based physics is almost always preferable.

❌ DON'T: Directly Set Speed for Physics

if (display.keys[68]) {
    player.speedX = 8;  // ❌ Instant speed change
} else {
    player.speedX = 0;  // ❌ Instant stop
}

Why: Directly setting speed creates jerky, unnatural movement. When you press a key, the player instantly jumps to full speed; when you release the key, the player instantly stops. This feels like ice-skating or sliding on ice — there's no sense of weight or momentum. In most games, players expect a gradual acceleration and deceleration. This makes the movement feel more responsive and gives the player a sense of control. move.accelerate() and move.decelerate() provide this smooth, weighty feel with just a few lines of code.

🎨 Rendering

14. ✅ DO: Use the Fake Canvas for Static Content

fake.add(tree);      // ✅ Cached, drawn once
fake.add(decoration);

Why: The fake canvas is an offscreen buffer that renders static content once and then caches it as an image. This is the core of the engine's performance optimization. When you add a component to the fake canvas (using fake.add()), it's drawn onto the fake canvas's context. The fake canvas is then drawn as a single image onto the main canvas every frame. This means that instead of drawing 100 trees individually every frame (each requiring its own draw call), the engine draws one image — the fake canvas — in a single draw call. This drastically reduces the number of draw calls, which is the primary bottleneck in 2D rendering. The difference can be dramatic: a game with 1000 static objects might run at 4fps without the fake canvas, but at 60fps with it. The fake canvas is ideal for backgrounds, tilemaps, decorations, and any other content that doesn't move. For dynamic content like players, enemies, and particles, use the main canvas with display.add().

❌ DON'T: Put Static Content on the Main Canvas

display.add(tree);   // ❌ Redrawn every frame
display.add(decoration);

Why: Every object on the main canvas is redrawn every frame. If you have 100 trees, the engine makes 100 draw calls every frame. Each draw call has overhead — the engine has to set up the context, apply transformations, and draw the object. This overhead adds up quickly. With 100 objects, you might not notice; with 1000 objects, your game will slow down significantly. The fake canvas solves this by combining all static objects into a single image. Instead of 100 draw calls, you have 1. This is one of the most important optimizations in the engine, and it's why the fake canvas exists. Always use it for static content.

15. ✅ DO: Call `fake.refresh()` After Changes

fake.bgComm.setImage("new_sky.png");
fake.refresh();  // ✅ Forces redraw

Why: The fake canvas caches its content to maximize performance. When you change the content of the fake canvas — for example, by changing the image of a background component, adding or removing tiles, or modifying any static object — the cached image becomes outdated. The engine won't automatically know that the content has changed, so it will continue to display the old cached image. To update the cached image, you need to call fake.refresh(). This forces the engine to clear the fake canvas, redraw all the static components, and cache the new image. If you forget to call fake.refresh(), your changes won't appear on screen, and you'll be stuck wondering why your new sky or updated tilemap isn't showing. Always call fake.refresh() after making any changes to the fake canvas.

❌ DON'T: Forget to Refresh

fake.bgComm.setImage("new_sky.png");
// ❌ Missing fake.refresh()

Why: The fake canvas is designed to be static — it renders once and then reuses the same image every frame. This is what makes it so performant. However, when you change the content of the fake canvas, the cached image becomes outdated. The engine doesn't automatically detect this change, so it continues to use the old cached image. Your changes appear to have no effect, even though the code is correct. This is a common source of confusion for beginners. Always remember to call fake.refresh() after modifying any content on the fake canvas.

🎥 Camera

16. ✅ DO: Set `worldWidth` and `worldHeight`

display.camera.worldWidth = 2000;
display.camera.worldHeight = 2000;

Why: The camera needs to know the boundaries of your game world so it can clamp its position and never show empty space outside the world. When the camera follows the player, it calculates its position based on the player's location. However, if the player moves to the edge of the world, the camera might try to move beyond the world boundaries, showing black space or empty areas. By setting worldWidth and worldHeight, you tell the camera the maximum extent of your world. The camera's follow() method uses these values to clamp the camera's position so that it never shows areas outside the world. Without these values, the camera defaults to 1000x1000, which may not match your world size. If your world is larger (say, 2000x2000), the camera will stop at 1000 pixels, cutting off half your world. If your world is smaller (say, 800x600), the camera will show empty space beyond the world boundaries. Always set worldWidth and worldHeight to match your world's actual size.

❌ DON'T: Leave World Bounds Unset

// ❌ Missing worldWidth and worldHeight

Why: Without world bounds, the camera has no idea where the world ends. When the player reaches the edge of the world, the camera will continue moving beyond the world boundary, showing empty space. This breaks the illusion of a cohesive game world and can be disorienting for players. The default bounds of 1000x1000 are arbitrary and won't match most games. Always set worldWidth and worldHeight to match your level's dimensions.

17. ✅ DO: Use Camera Shake for Impact

if (player.crashWith(enemy)) {
    display.camera.shake(8, 8);  // ✅ Impact feedback
}

Why: Camera shake is a powerful visual feedback mechanism that makes impacts feel more intense and satisfying. When the player collides with an enemy, takes damage, or triggers an explosion, a brief camera shake communicates the force of the event to the player. The shake is created by temporarily displacing the camera's position (and optionally its rotation) and then quickly returning it to normal. The camera.shake(x, y) method applies a displacement of x and y pixels, and then automatically reverts after a short duration (approximately 1/24 of a second). This creates a brief, sharp jolt that tells the player "something significant just happened." Without camera shake, impacts can feel flat and unsatisfying. However, camera shake should be used sparingly — too much shake is disorienting and can make players dizzy. A good rule of thumb is to use shake for major events (player hit, boss death, explosion) but not for minor events (collecting a coin, jumping).

❌ DON'T: Overuse Camera Shake

display.camera.shake(20, 20);  // ❌ Too intense

Why: Camera shake is like spice — a little bit enhances the flavor, but too much ruins the dish. When you use camera shake too frequently or with too much intensity, it becomes disorienting and annoying. Players may feel dizzy or nauseous, especially if the shake is combined with rapid movement. Use camera shake sparingly, for major events only, and keep the intensity moderate. A shake of 5-10 pixels is usually sufficient to convey impact without being overwhelming.

18. ✅ DO: Use `camera.follow()` Every Frame

function update(dt) {
    display.camera.follow(player, true);  // ✅ Called every frame
}

Why: The camera's follow() method calculates the camera's position based on the target's position. However, follow() only updates the camera's position at the moment it's called. If you call follow() once at the start of the game, the camera will lock onto the player's position at that exact moment and never update again. When the player moves, the camera will stay in its original position, and the player will eventually move off-screen. To keep the camera following the player smoothly, you need to call follow() every frame, typically in your update() loop. This ensures that the camera's position is recalculated based on the player's current position every frame, keeping the player centered on the screen (or at the specified offset). The second parameter, smooth, enables smooth interpolation, which makes the camera movement less jerky by easing the camera toward the target position over several frames. For most games, smooth following is preferable for a polished feel.

❌ DON'T: Call `camera.follow()` Once

display.camera.follow(player, true);  // ❌ Called only once

Why: camera.follow() is not a one-time setup — it's a continuous operation that needs to be performed every frame. If you only call it once, the camera will set its position to follow the player at that exact moment and then never update again. As the player moves, the camera stays in its original position, and the player eventually moves off-screen. This completely defeats the purpose of a following camera. Always call camera.follow() in your update() loop to keep the camera tracking the player.

19. ✅ DO: Set Zoom When It Changes

if (display.keys[90]) {
    display.camera.setZoom(1.5);  // ✅ Only when zoom changes
}

Why: The camera.setZoom() method applies a scale transformation to the rendering context, which affects how everything is drawn. This transformation is applied every frame as part of the rendering process. However, if you call setZoom() with the same value every frame, you're forcing the engine to recalculate and apply the same transformation 60 times per second, which wastes CPU cycles. The zoom level typically changes only when the player uses a zoom-in or zoom-out control, or during specific game events (like a sniper scope). For these cases, you should call setZoom() only when the zoom value actually changes. Store the current zoom level in a variable, and only call setZoom() when the variable changes. This reduces unnecessary calculations and improves performance, especially on lower-end devices.

❌ DON'T: Set Zoom Every Frame

function update(dt) {
    display.camera.setZoom(1.5);  // ❌ Every frame
}

Why: Setting zoom every frame is a waste of CPU cycles. The zoom level is a transformation that's applied to the canvas context. When you call setZoom(), the engine has to recalculate the transformation matrix and apply it to the context. This is a small operation, but when done 60 times per second unnecessarily, it adds up. More importantly, it clutters your code and makes it harder to read. Only set the zoom when it actually changes — typically when the player presses a zoom key or when a game event triggers a zoom change.

🗺️ TileMaps

20. ✅ DO: Set Fake Canvas Size to World Size

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

Why: The fake canvas serves as the offscreen buffer for your tilemap. When you render a tilemap, the tiles are drawn onto the fake canvas, and the fake canvas is then drawn as a single image on the main canvas. For this to work correctly, the fake canvas needs to be large enough to hold the entire tilemap. If the fake canvas is smaller than the tilemap, the tiles that fall outside the fake canvas boundaries won't be drawn. If the fake canvas is larger than needed, it wastes memory and might cause performance issues. The ideal size for the fake canvas is exactly the size of the tilemap in pixels, which should match the worldWidth and worldHeight you set for the camera. By setting fake.canvas.width and fake.canvas.height to the world size, you ensure that the entire tilemap fits perfectly on the fake canvas, with no wasted space or missing tiles.

❌ DON'T: Sync Camera Instead

fake.camera.x = display.camera.x;  // ❌ Defeats caching

Why: The fake canvas is designed to be a static cache. If you start moving the fake camera, you defeat the entire purpose of caching. The fake canvas is meant to be rendered once and then reused as a single image. If you move the fake camera, you're effectively trying to render the tilemap from a different perspective each frame, which means you'd have to redraw the tilemap every frame — exactly what the fake canvas was designed to avoid. The correct approach is to render the entire tilemap once on the fake canvas (with the fake camera at the origin), and then use the main camera to view different parts of the fake canvas.

21. ✅ DO: Use `tilemap.crashWith()` for Collision

if (tilemap.crashWith(player, 1)) {  // ✅ Collision with walls
    // Handle collision
}

Why: The tilemap.crashWith() method is an efficient way to check collision between a component and any tiles in the tilemap. You can optionally specify a tile ID to check collision only with specific tile types (e.g., ID 1 for walls, ID 2 for water, ID 3 for spikes). The method loops through the tilemap's internal list of tiles and checks collision between the component and each tile of the specified type. This is much more efficient than manually looping through all tiles and checking collision yourself, because crashWith() uses the engine's internal optimized collision detection, and it only checks tiles that are relevant (based on the tile ID filter). If you manually check collision with a for loop, you'll be duplicating logic that the engine already provides, and you'll likely miss the optimization that crashWith() implements. For any tile-based collision, always use tilemap.crashWith().

❌ DON'T: Use Manual Tile Collision

const tiles = tilemap.tiles(1);
for (let tile of tiles) {
    if (player.crashWith(tile)) {
        // Handle collision
    }
}

Why: Manual tile collision is inefficient and error-prone. You have to manually retrieve the tiles, loop through them, and check collision with each one. The tilemap.crashWith() method does all of this for you, with optimized internal logic that's faster and more reliable. Additionally, crashWith() only checks tiles that are near the component, not all tiles in the map, making it much more performant for large maps. Always use tilemap.crashWith() instead of writing your own collision loop.

⚡ Performance

22. ✅ DO: Use Object Pooling for High-Frequency Objects

class BulletPool {
    // Pre-creates bullets and reuses them
}

Why: Object pooling is a design pattern where you pre-create a set of objects and reuse them instead of creating and destroying them on the fly. In JavaScript, creating a new object with new Component() allocates memory, and destroying it with destroy() eventually triggers garbage collection when the memory is reclaimed. Garbage collection pauses the JavaScript engine, causing frame drops and stutter. If you're creating and destroying hundreds of objects per second (like bullets, particles, or enemies), garbage collection will happen frequently, causing visible lag. Object pooling avoids this by creating a fixed number of objects upfront and reusing them. When you need a bullet, you take one from the pool. When the bullet is done, you return it to the pool (by hiding it and resetting its properties). This eliminates constant allocation and garbage collection, resulting in smoother performance. For any game with high-frequency object creation and destruction, object pooling is essential.

❌ DON'T: Create and Destroy Objects Constantly

function shoot() {
    const bullet = new Component(5, 10, "yellow", player.x, player.y, "rect");
    display.add(bullet);  // ❌ Creates new object every time
}

Why: Creating and destroying objects constantly is a performance killer. Each new allocates memory, and each destroy() eventually triggers garbage collection. Garbage collection pauses the JavaScript engine to clean up unused memory, causing frame drops and stutter. In a game where the player shoots 10 bullets per second, you're creating 10 new objects per second and destroying them shortly after. This will cause frequent garbage collection, making your game feel laggy and unresponsive. Object pooling is a simple and effective solution to this problem.

23. ✅ DO: Remove Objects from Arrays

enemies.splice(i, 1);  // ✅ Removes from array

Why: When you use splice() to remove an element from an array, the array shrinks, reducing the number of iterations in future loops. This is especially important if you're iterating over the array frequently, such as in the update() loop where you process enemy AI, movement, and collision. A smaller array means fewer loop iterations, which means less CPU usage and better performance. Additionally, splice() properly removes the object from the array, allowing the garbage collector to reclaim its memory. If you instead set the element to null, the array remains the same size, and you'll need to check for null values in your loops, which adds unnecessary branching and CPU overhead. Over time, a large array with many null values will slow down your game. Always use splice() (or filter()) to remove objects from arrays.

❌ DON'T: Set Objects to `null`

enemies[i] = null;  // ❌ Still in array

Why: Setting an element to null doesn't remove it from the array — it just leaves an empty slot. The array length stays the same, which means your loops will still iterate over that slot. You'll have to add a check for null in your loops, which adds an extra branch and wastes CPU cycles. Over time, as more and more objects are set to null, your arrays will grow large with many empty slots, and your loops will waste time checking for null values. Use splice() to actually remove elements from the array.

24. ✅ DO: Use `clearMargin` Optimization

display.clearMargin = [800, 600];  // ✅ Optimized

Why: The clearMargin array controls the size of the area that the engine clears on the canvas before rendering. By default, it's set to [width*width, height*height], which is the square of the canvas dimensions. For a canvas sized 800x600, this defaults to [640000, 360000] — a massive area far larger than the visible canvas. This means the engine is clearing a huge rectangle off-screen, which wastes CPU cycles and can hurt performance. By setting clearMargin to the actual canvas dimensions (e.g., [800, 600]), you reduce the cleared area to exactly what's visible on screen, saving CPU cycles and improving performance. This optimization is especially noticeable on lower-end devices. Always set clearMargin to match your canvas size after calling display.start() or display.scale().

❌ DON'T: Keep the Default

// display.clearMargin = [640000, 360000];  // ❌ Huge area

Why: The default clearMargin is [width*width, height*height], which for a 800x600 canvas is [640000, 360000]. This is far larger than the visible canvas, meaning the engine is clearing a huge area off-screen that will never be drawn. This wastes CPU cycles and can cause performance issues, especially on lower-end devices. Always set clearMargin to the actual canvas dimensions to minimize the clearing area.

🎵 Audio

25. ✅ DO: Preload Sounds Before `display.start()`

const sound = new Sound("jump.wav");  // ✅ Preloaded
display.start(800, 600);

Why: Sound files need to be loaded from the server before they can be played. The Sound class loads the audio file asynchronously in the background. If you create a Sound object and immediately call play(), the audio file may not be fully loaded yet, causing a delay or a silent failure. Worse, if you create a Sound object during gameplay (e.g., in the update() loop), you're forcing the engine to load an audio file while the game is running, which causes lag and stutter. To avoid this, you should preload all sounds before the game starts. Create your Sound objects at the beginning of the game (before calling display.start()), and store them in variables or in a SoundManager. This gives the audio files time to load while the game is initializing, ensuring that they're ready to play when you need them. Preloading is especially important for sounds that play frequently, like jump sounds or collision sounds.

❌ DON'T: Play Sounds Without Preloading

function update() {
    const sound = new Sound("jump.wav");  // ❌ Created during gameplay
    sound.play();
}

Why: Creating a Sound object during gameplay forces the engine to load the audio file while the game is running. This causes a delay while the file is downloaded and decoded, resulting in lag and stutter. This is especially problematic for sounds that play frequently, like jump sounds or collision sounds, because the lag would happen every time the sound plays. Preloading all sounds at the start of the game eliminates this issue, ensuring that sounds play instantly when triggered.

26. ✅ DO: Use `move.sound.*` for Quick Audio

move.sound.play("jump");  // ✅ Shortcut

Why: The move.sound object provides a convenient shortcut for playing sounds that have been loaded into the global soundManager. Instead of writing if (soundManager) { soundManager.play("jump"); }, you can simply write move.sound.play("jump"). The move.sound wrapper handles null references (if soundManager doesn't exist) and manages volume automatically. It also provides shortcuts for music control (move.sound.playMusic(), move.sound.stopMusic()) and global volume control (move.sound.setMasterVolume(), move.sound.mute()). Using move.sound reduces code verbosity and makes your audio code cleaner and easier to read. For simple audio playback, always prefer move.sound over manually calling soundManager.

❌ DON'T: Manually Handle Audio for Simple Cases

if (soundManager) {
    soundManager.play("jump");  // ❌ More code
}

Why: Manually checking for soundManager and calling play() is verbose and repetitive. The move.sound wrapper handles these checks for you, with less code and less room for error. Additionally, move.sound provides volume management and other features that you'd have to implement yourself if you manually handled audio. Use move.sound for cleaner, more reliable audio code.

🧪 Testing & Debugging

27. ✅ DO: Use `console.log()` for Debugging

console.log("Player position:", player.x, player.y);  // ✅ Debug

Why: The console.log() function is a simple and effective way to understand what's happening in your game. By logging variables, positions, and states, you can trace the flow of your game and identify where things are going wrong. For example, if your player isn't moving, you can log the speedX and speedY values to see if they're being set correctly. If a collision isn't working, you can log the positions of the colliding objects to see if they're overlapping. Logging is especially useful for reproducing and diagnosing bugs that are hard to see visually. However, it's important to remove or comment out debug logs in production builds, as logging every frame can slow down the game and clutter the console with unnecessary information. Use logging liberally during development, but clean it up before releasing your game.

❌ DON'T: Leave Debug Logs in Production

console.log("Frame:", display.frameNo);  // ❌ Debug in production

Why: Logging every frame is a performance drain. Each console.log() call takes time, and if you're logging 60 times per second, it can add up and slow down your game. Additionally, leaving debug logs in production clutters the console with unnecessary information, making it harder to see important messages. Always remove debug logs before releasing your game.

28. ✅ DO: Test on Different Browsers

// ✅ Test on Chrome, Firefox, Edge, Safari

Why: Different browsers implement JavaScript, Canvas, and audio differently. What works perfectly in Chrome might break in Safari, or what's fast in Firefox might be slow in Edge. This is especially true for advanced features like WebGL, audio contexts, and touch events. To ensure your game works for all users, you should test on multiple browsers, including different versions. At minimum, test on Chrome (the most common browser), Firefox (for its excellent developer tools), and Safari (for iOS users). If possible, also test on Edge and on mobile browsers (Safari on iOS, Chrome on Android). Testing on different browsers will help you catch compatibility issues early and ensure that your game provides a consistent experience for all players.

❌ DON'T: Only Test on One Browser

// ❌ Only test on Chrome

Why: Testing only on Chrome is a common mistake. While Chrome is the most popular browser, it's not the only one. Safari, Firefox, and Edge all have significant market shares. Features that work in Chrome may not work in other browsers, or may work differently. By only testing on Chrome, you risk releasing a game that's broken for a significant portion of your audience. Always test on multiple browsers to ensure compatibility.

📚 Documentation

29. ✅ DO: Comment Your Code

// ── PLAYER MOVEMENT ──
// Arrow keys move the player at 200px/s

Why: Comments are essential for understanding your own code, especially when you come back to it after a few weeks or months. A well-commented codebase is easier to debug, easier to extend, and easier to share with others. Comments should explain the "why" behind the code — the intent, the reasoning, and the trade-offs. For example, instead of just writing if (display.keys[37]) player.speedX = -200 * dt;, you might comment // Left arrow: move player left at 200px/s, using dt for frame-rate independence. This helps you (and others) quickly understand what the code does without having to decipher it. Comments are especially useful for complex logic, math, and game mechanics. Always comment your code, especially the parts that aren't immediately obvious.

❌ DON'T: Leave Code Uncommented

if (display.keys[37]) player.speedX = -200 * dt;

Why: Uncommented code is hard to understand. When you come back to your code after a few weeks, you might not remember why you wrote a particular line or what it's supposed to do. This makes debugging and extending your code much more difficult. Comments help you and others understand the code more quickly and with less effort.

30. ✅ DO: Use Meaningful Variable Names

const playerSpeed = 200;  // ✅ Clear

Why: Meaningful variable names make your code self-documenting. When you read const playerSpeed = 200;, you immediately know that this variable represents the player's movement speed. When you read const a = 200;, you have no idea what a represents. This becomes a problem when you have dozens of variables — you'll constantly have to remember what each one does, or look back at where it was defined. Meaningful names reduce cognitive load, make code easier to read and maintain, and reduce the number of bugs caused by misinterpretation. In general, variable names should be descriptive but not overly long. playerSpeed is a good name; playerMovementSpeedInPixelsPerSecond is too long. Avoid abbreviations that aren't immediately obvious (pSpeed vs playerSpeed). Good naming is a habit that pays off in every line of code you write.

❌ DON'T: Use Cryptic Names

const a = 200;  // ❌ What is 'a'?

Why: Cryptic variable names make code hard to read and understand. When you use names like a, b, x, y, or temp, you're forcing yourself and others to remember what each variable represents. This is especially problematic in longer functions where you might have many variables. Meaningful names make your code self-documenting and reduce the need for comments. Always use descriptive names that clearly indicate what the variable represents.

🎯 Final Tips

31. ✅ DO: Have Fun and Experiment

// ✅ Try new things, break things, learn from mistakes

Why: Game development is a creative and iterative process. The best way to learn is to experiment, try new things, and make mistakes. Don't be afraid to break your game — that's how you learn what works and what doesn't. Every mistake teaches you something valuable, whether it's a subtle bug that took hours to find or a design choice that didn't work out. The most successful game developers are the ones who aren't afraid to fail and learn from their failures. So have fun with it! Try weird ideas, push the engine to its limits, and see what you can create. The journey of learning and building is just as rewarding as the final product.

❌ DON'T: Be Afraid to Make Mistakes

// ❌ Fear of breaking things prevents learning

Why: Fear of making mistakes is one of the biggest obstacles to learning. If you're afraid to break things, you'll never try new things, and you'll never grow as a developer. Mistakes are a natural part of the learning process. Every developer, from beginners to experts, makes mistakes. The key is to learn from them and move on. Don't be afraid to experiment, try new features, and push the boundaries of what you can create.

📊 Quick Reference Table

#	Do	Don't
1	Call `perform()` before `start()`	Call `start()` before `perform()`
2	Name your display instance `display`	Use a different variable name
3	Call `perform()` before using TileMaps	Use TileMap without `perform()`
4	Use `deltaTime` for movement	Use raw numbers for speed
5	Normalize diagonal movement	Ignore diagonal normalization
6	Use `display.add()` for every component	Forget to add components
7	Use `setImage()` for images	Directly assign image properties
8	Use `destroy()` for permanent removal	Hide objects you'll never use again
9	Use `hide()` for temporary invisibility	Use `destroy()` for temporary removal
10	Use `Tctxt` for UI text	Use `Component` for text
11	Call `.fixed()` every frame	Call `.fixed()` once
12	Use `move.bound()` to keep objects on screen	Write your own edge detection
13	Use `accelerate()` and `decelerate()` for physics	Directly set speed for physics
14	Use fake canvas for static content	Put static content on the main canvas
15	Call `fake.refresh()` after changes	Forget to refresh
16	Set `worldWidth` and `worldHeight`	Leave world bounds unset
17	Use camera shake for impact	Overuse camera shake
18	Call `camera.follow()` every frame	Call `camera.follow()` once
19	Set zoom when it changes	Set zoom every frame
20	Set fake canvas size to world size	Sync camera instead
21	Use `tilemap.crashWith()`	Use manual tile collision
22	Use object pooling for high-frequency objects	Create and destroy objects constantly
23	Remove objects from arrays	Set objects to `null`
24	Use `clearMargin` optimization	Keep the default
25	Preload sounds before `display.start()`	Play sounds without preloading
26	Use `move.sound.*` for quick audio	Manually handle audio
27	Use `console.log()` for debugging	Leave debug logs in production
28	Test on different browsers	Only test on one browser
29	Comment your code	Leave code uncommented
30	Use meaningful variable names	Use cryptic names
31	Have fun and experiment	Be afraid to make mistakes

🎯 The One-Line Summary

"Follow these 31 do's and don'ts to write better, faster, and more reliable Limn Engine games."

Draw your game into existence — the right way. 🎮🚀

🎮 Building a 3D Game in Limn Engine — Without a 3D Engine

Kehinde Owolabi — Mon, 17 Aug 2026 22:33:25 +0000

🎮 Building a 3D Game in Limn Engine — Without a 3D Engine

⚠️ THIS IS AN EXPERIMENTAL APPROACH — USE WITH CAUTION
Comment if error is found

📖 Introduction

Limn Engine is a 2D game engine — it was built for 2D games. But what if you want to create a 3D experience without switching to a 3D engine?

The answer: You fake it.

Many classic games created the illusion of 3D using 2D techniques. Games like Doom, Wolfenstein 3D, and Mode 7 racing games all used 2D rendering to simulate 3D worlds.

In this guide, we'll explore several techniques to create 3D-like experiences in Limn Engine — without a 3D engine.

🎯 The Challenge

Limitation	What It Means
No Z-axis	Everything is 2D — no depth
No 3D rendering	No WebGL, no 3D models
No 3D physics	No collisions in 3D space
No perspective	No vanishing points by default

The solution: Use 2D tricks to simulate 3D depth, perspective, and movement.

🧩 Technique 1: Mode 7 (Fake 3D Racing)

The Concept

Mode 7 was used in games like F-Zero and Mario Kart on the SNES. It creates the illusion of a 3D ground plane by scaling and rotating a 2D image.

How it works: Instead of a 3D world, you have a 2D image that you transform in real-time. You scale it, rotate it, and move it to simulate movement.

What We're About to Do

We're going to create a simple Mode 7 effect with a road image that scales and moves.

The Code

// ── MODE 7 FAKE 3D RACING (EXPERIMENTAL) ──

const display = new Display();
display.perform();
display.start(800, 600);
display.backgroundColor("#1a1a2e");

// ── CREATE ROAD IMAGE ──
// In a real game, you'd load an image. For this demo, we draw it.

const canvas = document.createElement('canvas');
canvas.width = 200;
canvas.height = 200;
const ctx = canvas.getContext('2d');

// Draw a simple road with lanes
ctx.fillStyle = "#333";
ctx.fillRect(0, 0, 200, 200);

// Road
ctx.fillStyle = "#555";
ctx.fillRect(40, 0, 120, 200);

// Lane markings
ctx.strokeStyle = "white";
ctx.setLineDash([20, 30]);
ctx.lineWidth = 3;
ctx.beginPath();
ctx.moveTo(100, 0);
ctx.lineTo(100, 200);
ctx.stroke();

// Road edges
ctx.strokeStyle = "red";
ctx.lineWidth = 2;
ctx.setLineDash([]);
ctx.beginPath();
ctx.moveTo(40, 0);
ctx.lineTo(40, 200);
ctx.stroke();

ctx.beginPath();
ctx.moveTo(160, 0);
ctx.lineTo(160, 200);
ctx.stroke();

// ── CREATE ROAD COMPONENT ──
const road = new Component(200, 200, null, 400, 300, "image");
road.setImage(canvas.toDataURL());
display.add(road);

// ── GAME STATE ──
let distance = 0;
let speed = 0;
const MAX_SPEED = 200;
const ACCELERATION = 200;
const FRICTION = 100;

// ── GAME LOOP ──
function update(dt) {
    // ── ACCELERATION ──
    if (display.keys[38]) {  // Up arrow to accelerate
        speed = Math.min(speed + ACCELERATION * dt, MAX_SPEED);
    } else {
        speed = Math.max(0, speed - FRICTION * dt);
    }

    // ── UPDATE DISTANCE ──
    distance += speed * dt;

    // ── CALCULATE SCALE ──
    // As distance increases, the road gets smaller (simulating distance)
    const scale = Math.max(0.5, 1 + (distance / 1000));
    const newWidth = 200 / scale;
    const newHeight = 200 / scale;

    // ── APPLY TRANSFORM ──
    road.width = newWidth;
    road.height = newHeight;
    road.x = 400 - newWidth / 2;
    road.y = 300 - newHeight / 2;

    // ── ROTATE FOR TURNING ──
    let rotation = 0;
    if (display.keys[37]) rotation = -0.02;
    if (display.keys[39]) rotation = 0.02;
    road.angle += rotation * speed * 0.001;
    road.changeAngle = true;

    // ── UI ──
    // (Add speed display, etc.)
}

What Each Line Does

Line 9-31: Creates a road image on a temporary canvas

The road is 200x200 pixels with lane markings
This is the image that will be transformed

Line 34: const road = new Component(200, 200, null, 400, 300, "image");

Creates a component that will display the road image

Line 35: road.setImage(canvas.toDataURL());

Converts the canvas to an image and sets it on the component

Line 39-41: Sets up game state variables

Line 47-50: Accelerates the car when Up arrow is pressed

Line 53: distance += speed * dt;

Increases the distance traveled

Line 56: const scale = Math.max(0.5, 1 + (distance / 1000));

Calculates the scale based on distance traveled

Line 57-58: const newWidth = 200 / scale; const newHeight = 200 / scale;

As scale increases, the image gets smaller (simulating distance)

Line 61-62: road.width = newWidth; road.height = newHeight;

Applies the new size to the road component

Line 68-70: Rotates the image for turning

🧩 Technique 2: Parallax Scrolling (Fake 3D Depth)

The Concept

Parallax scrolling creates the illusion of 3D depth by moving background layers at different speeds. This is how many classic 2D games created depth.

How it works: You have multiple layers of images. The foreground moves fast, the midground moves medium, and the background moves slow. This simulates the 3D perspective.

What We're About to Do

We're going to create a parallax scrolling effect with three layers.

The Code

// ── PARALLAX SCROLLING (FAKE 3D DEPTH) ──

const display = new Display();
display.perform();
display.start(800, 600);
display.backgroundColor("#1a1a2e");

// ── CREATE LAYERS ──
// Layer 1: Background (far mountains) - slowest
const bg = new Component(800, 200, "#2d5a7a", 0, 0, "rect");
display.add(bg);

// Layer 2: Midground (hills) - medium
const mid = new Component(800, 300, "#3a7a3a", 0, 200, "rect");
display.add(mid);

// Layer 3: Foreground (trees) - fastest
const fg = new Component(800, 200, "#5a8a3a", 0, 400, "rect");
display.add(fg);

// Add some trees to foreground (simplified)
for (let i = 0; i < 10; i++) {
    const tree = new Component(20, 40, "#2d5a2d", i * 80, 380, "rect");
    display.add(tree);
}

// ── GAME STATE ──
let offset = 0;
const SPEED = 100;

// ── GAME LOOP ──
function update(dt) {
    // Move offset based on speed
    offset += SPEED * dt;
    if (offset > 800) offset = 0;

    // ── MOVE LAYERS AT DIFFERENT SPEEDS ──
    // Background moves slow (20% speed)
    bg.x = -offset * 0.2;
    // Midground moves medium (60% speed)
    mid.x = -offset * 0.6;
    // Foreground moves fast (100% speed)
    fg.x = -offset * 1.0;

    // Keep layers in bounds by wrapping
    if (bg.x < -800) bg.x = 0;
    if (mid.x < -800) mid.x = 0;
    if (fg.x < -800) fg.x = 0;
}

🧩 Technique 3: Z-Sorting (Fake 3D Depth Ordering)

The Concept

In 3D games, objects closer to the camera are drawn on top of objects further away. You can simulate this in 2D by sorting objects by their "depth" and drawing them in order.

How it works: Give each object a z value. The lower the z value, the further away it is. Sort objects by z and draw them from back to front.

What We're About to Do

We're going to create a scene with objects at different depths, drawn in the correct order.

The Code

// ── Z-SORTING (FAKE 3D DEPTH ORDERING) ──

const display = new Display();
display.perform();
display.start(800, 600);
display.backgroundColor("#1a1a2e");

// ── CREATE OBJECTS WITH DEPTH ──

// Far background (z = -10)
const bg = new Component(800, 600, "#2d5a7a", 0, 0, "rect");
bg.z = -10;
display.add(bg);

// Mountains (z = -5)
const mountain1 = new Component(200, 150, "#3a5a3a", 100, 400, "rect");
mountain1.z = -5;
display.add(mountain1);

// Trees (z = 0)
const tree1 = new Component(30, 60, "#2d5a2d", 200, 500, "rect");
tree1.z = 0;
display.add(tree1);

const tree2 = new Component(30, 60, "#2d5a2d", 400, 480, "rect");
tree2.z = 0;
display.add(tree2);

// Player (z = 5)
const player = new Component(40, 40, "blue", 380, 520, "rect");
player.z = 5;
display.add(player);

// Enemy (z = 10) - drawn on top of player if overlapping
const enemy = new Component(40, 40, "red", 360, 530, "rect");
enemy.z = 10;
display.add(enemy);

// ── SORT OBJECTS BY Z ──

function sortByZ() {
    // Get all components
    const components = comm.map(c => c.x);

    // Sort by z (lower z first = drawn first = further away)
    components.sort((a, b) => (a.z || 0) - (b.z || 0));

    // Rebuild comm array in sorted order
    comm.length = 0;
    for (let comp of components) {
        comm.push({ x: comp, scene: display.scene });
    }
}

// ── GAME LOOP ──
function update(dt) {
    // Sort objects by z every frame
    sortByZ();

    // Move enemy to demonstrate overlap
    enemy.x += 20 * dt;
    if (enemy.x > 420 || enemy.x < 360) {
        // Reverse direction
        enemy.speedX = -enemy.speedX;
    }
}

What Each Line Does

Line 10-31: Creates objects with z values

Lower z = further away (drawn first)
Higher z = closer (drawn last)

Line 34-44: sortByZ() function

Gets all components from the comm array
Sorts them by their z value
Rebuilds the comm array in sorted order

Line 47-49: sortByZ(); called every frame

Ensures objects are always drawn in the correct order

🧩 Technique 4: 2.5D Isometric Projection

The Concept

Isometric projection is a way to create a 3D look using 2D graphics. Objects are drawn with a 45-degree angle, creating a "3D" view from above.

How it works: Instead of square tiles, you use diamond-shaped tiles. Objects are drawn with width and height, but positioned using isometric coordinates.

What We're About to Do

We're going to create a simple isometric grid with objects.

The Code

// ── 2.5D ISOMETRIC PROJECTION (EXPERIMENTAL) ──

const display = new Display();
display.perform();
display.start(800, 600);
display.backgroundColor("#1a1a2e");

// ── ISOMETRIC HELPERS ──

function isoToScreen(isoX, isoY, tileWidth, tileHeight) {
    const screenX = (isoX - isoY) * tileWidth / 2 + 400;
    const screenY = (isoX + isoY) * tileHeight / 2 + 100;
    return { x: screenX, y: screenY };
}

function screenToIso(screenX, screenY, tileWidth, tileHeight) {
    const isoX = (screenX - 400) / (tileWidth / 2) + (screenY - 100) / (tileHeight / 2);
    const isoY = (screenY - 100) / (tileHeight / 2) - (screenX - 400) / (tileWidth / 2);
    return { x: isoX, y: isoY };
}

// ── CREATE ISOMETRIC TILES ──

const tileWidth = 80;
const tileHeight = 40;

// Create a grid of isometric tiles
for (let row = 0; row < 5; row++) {
    for (let col = 0; col < 5; col++) {
        const pos = isoToScreen(col, row, tileWidth, tileHeight);

        // Alternate colors for checkerboard
        const color = (row + col) % 2 === 0 ? "#3a7a3a" : "#4a8a4a";

        // Create diamond-shaped tile
        // In a real implementation, you'd use a custom shape or image
        const tile = new Component(tileWidth, tileHeight, color, pos.x, pos.y, "rect");
        tile.changeAngle = true;
        tile.angle = Math.PI / 4; // 45 degrees
        display.add(tile);
    }
}

// ── CREATE OBJECT ON ISOMETRIC GRID ──

// Place a player at isometric position (2, 2)
const playerPos = isoToScreen(2, 2, tileWidth, tileHeight);
const player = new Component(30, 50, "blue", playerPos.x, playerPos.y - 20, "rect");
display.add(player);

// Place an enemy at isometric position (3, 1)
const enemyPos = isoToScreen(3, 1, tileWidth, tileHeight);
const enemy = new Component(30, 50, "red", enemyPos.x, enemyPos.y - 20, "rect");
display.add(enemy);

📊 Comparison of Techniques

Technique	Best For	Complexity	Performance
Mode 7	Racing games, top-down games	Medium	High
Parallax Scrolling	Platformers, side-scrollers	Low	High
Z-Sorting	Any game with depth	Low	High
Isometric	Strategy games, RPGs	Medium	Medium

💡 Pro Tips

1. Combine Techniques

// ── USE MULTIPLE TECHNIQUES TOGETHER ──
// Use parallax + z-sorting for a 3D feel
// Use isometric + z-sorting for strategy games

2. Use Images for Better Visuals

// ── USE IMAGES INSTEAD OF RECTANGLES ──
// Create a cube image for isometric tiles
// Use sprite sheets for different angles

3. Keep It Simple

// ── DON'T OVER-COMPLICATE ──
// Start with one technique and master it
// Add more techniques as needed

🎯 The One-Line Summary

"You can create 3D-like experiences in Limn Engine using 2D tricks — Mode 7, parallax scrolling, z-sorting, and isometric projection."

Draw your game into existence — even in 3D. 🎮🚀

🔧 Creating Extensions for Limn Engine — Make Game Development Better and Faster

Kehinde Owolabi — Mon, 17 Aug 2026 21:41:55 +0000

🔧 Creating Extensions for Limn Engine — Make Game Development Better and Faster

A Complete Guide to Extending Limn Engine with Custom Features

📖 Introduction

Limn Engine is already powerful out of the box. But what if you need a feature that doesn't exist yet? What if you want to add a health system, a level editor, or a custom physics behavior?

The beauty of Limn Engine is that it's plain JavaScript. You can extend it without touching the core engine code. In this guide, we'll show you how to create extensions that make game development faster and more powerful.

🎯 Why Create Extensions?

Reason	What It Means
Reusability	Write once, use in multiple projects
Sharing	Share extensions with the community
Productivity	Build common features faster
Learning	Understand the engine internals
Customization	Add exactly what you need

🧩 Extension Pattern 1: Prototype Extension

The Concept

JavaScript allows you to add methods to existing classes using prototype. This is the simplest way to extend Limn Engine.

How it works: Every Limn Engine class (like Component, Display, Camera) is a JavaScript class. You can add new methods to these classes that will be available on all instances.

What We're About to Do

We're going to add a health system to every component. This is useful for players, enemies, and anything else that needs health.

The Code

// ── EXTEND COMPONENT WITH HEALTH SYSTEM ──

// Add health system to every component
Component.prototype.setHealth = function(max) {
    this.hp = max;           // Current health
    this.maxHp = max;        // Maximum health
    this.invincible = 0;     // Invincibility frames counter
    console.log(`💚 Health set to ${max}`);
};

// Damage method
Component.prototype.damage = function(amount) {
    // Check if invincible
    if (this.invincible > 0) {
        console.log(`🛡️ Invincible! No damage taken.`);
        return false;
    }

    // Apply damage
    this.hp = Math.max(0, this.hp - amount);
    this.invincible = 30;    // 30 frames of invincibility

    // Check if dead
    if (this.hp === 0) {
        console.log(`💀 ${this.constructor.name} died!`);
        return true;  // Returns true if dead
    }

    console.log(`❤️ ${this.hp}/${this.maxHp} health remaining`);
    return false;  // Returns false if still alive
};

// Tick invincibility frames
Component.prototype.tickInvincible = function() {
    if (this.invincible > 0) {
        this.invincible--;
    }
};

// Draw health bar above component
Component.prototype.drawHealthBar = function(ctx) {
    // Don't draw if at max health
    if (this.hp === this.maxHp) return;

    const pct = this.hp / this.maxHp;  // Health percentage (0 to 1)
    const barW = this.width;           // Bar width matches component width
    const barH = 5;                    // Bar height

    // Background bar (dark gray)
    ctx.fillStyle = "#333";
    ctx.fillRect(this.x, this.y - 10, barW, barH);

    // Health fill (color based on health)
    let color;
    if (pct > 0.5) color = "#00cc44";      // Green — healthy
    else if (pct > 0.25) color = "#ffaa00"; // Yellow — wounded
    else color = "#cc0000";                  // Red — critical

    ctx.fillStyle = color;
    ctx.fillRect(this.x, this.y - 10, barW * pct, barH);
};

// ── USAGE ──

// Create player
const player = new Component(40, 40, "blue", 400, 300, "rect");
display.add(player);

// Set health
player.setHealth(100);

// In the game loop
function update(dt) {
    // Tick invincibility frames
    player.tickInvincible();

    // When enemy hits player
    if (player.crashWith(enemy)) {
        const died = player.damage(15);
        if (died) {
            console.log("Game Over!");
            display.stop();
        }
    }

    // Draw health bar
    player.drawHealthBar(display.context);
}

What Each Line Does

Line 4: Component.prototype.setHealth = function(max) {

Adds a new method called setHealth to every component
The max parameter is the maximum health

Line 5-6: this.hp = max; this.maxHp = max;

Sets the current health and maximum health to the same value

Line 7: this.invincible = 0;

Stores invincibility frames counter (0 = not invincible)

Line 12: Component.prototype.damage = function(amount) {

Adds a damage method to every component

Line 14-16: if (this.invincible > 0) { return false; }

If the component is invincible, no damage is taken

Line 19: this.hp = Math.max(0, this.hp - amount);

Reduces health, but not below 0

Line 20: this.invincible = 30;

Makes the component invincible for 30 frames

Line 23-24: if (this.hp === 0) { return true; }

Returns true if the component is dead

Line 36: Component.prototype.tickInvincible = function() {

Adds a method to count down invincibility frames

Line 37-39: if (this.invincible > 0) { this.invincible--; }

Reduces invincibility counter by 1 each frame

Line 42: Component.prototype.drawHealthBar = function(ctx) {

Adds a method to draw a health bar above the component

Line 45: if (this.hp === this.maxHp) return;

Skips drawing if health is full

Line 47: const pct = this.hp / this.maxHp;

Calculates health percentage

Line 48-49: const barW = this.width; const barH = 5;

Sets the health bar size

Line 52-58: Draws the background and health fill with colors based on health percentage

🧩 Extension Pattern 2: Utility Extension

The Concept

Instead of adding methods to existing classes, you can create your own utility objects. This is cleaner for features that don't naturally belong to a specific class.

How it works: You create a new object that contains helper functions. These functions take components as parameters and work on them.

What We're About to Do

We're going to create a level utility that helps with level design.

The Code

// ── LEVEL UTILITY ──

const level = {
    // Create a simple level from a 2D array
    create: function(map, tileSize, tileColors) {
        const tiles = [];

        for (let row = 0; row < map.length; row++) {
            for (let col = 0; col < map[row].length; col++) {
                const tileId = map[row][col];
                if (tileId === 0) continue; // Skip empty

                const color = tileColors[tileId] || "#555";
                const tile = new Component(
                    tileSize, 
                    tileSize, 
                    color, 
                    col * tileSize, 
                    row * tileSize, 
                    "rect"
                );
                display.add(tile);
                tiles.push(tile);
            }
        }

        return tiles;
    },

    // Add walls around the edge of a level
    addWalls: function(map, wallId = 1) {
        const rows = map.length;
        const cols = map[0].length;

        // Top and bottom walls
        for (let c = 0; c < cols; c++) {
            map[0][c] = wallId;
            map[rows - 1][c] = wallId;
        }

        // Left and right walls
        for (let r = 0; r < rows; r++) {
            map[r][0] = wallId;
            map[r][cols - 1] = wallId;
        }

        return map;
    },

    // Find empty spaces in a level
    findEmpty: function(map) {
        const empties = [];
        for (let row = 0; row < map.length; row++) {
            for (let col = 0; col < map[row].length; col++) {
                if (map[row][col] === 0) {
                    empties.push({ row, col });
                }
            }
        }
        return empties;
    },

    // Get a random empty position
    randomEmpty: function(map) {
        const empties = this.findEmpty(map);
        if (empties.length === 0) return null;
        return empties[Math.floor(Math.random() * empties.length)];
    }
};

// ── USAGE ──

// Define a level map
let myMap = [
    [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]
];

// Add walls
myMap = level.addWalls(myMap);

// Define tile colors
const tileColors = {
    1: "#654321",  // Wall
    2: "gold",      // Coin
    3: "red"        // Enemy spawn
};

// Create the level
const tiles = level.create(myMap, 64, tileColors);

// Find a random empty position
const empty = level.randomEmpty(myMap);
if (empty) {
    console.log(`Empty space at row ${empty.row}, col ${empty.col}`);
    // Place a coin at that position
    myMap[empty.row][empty.col] = 2;
}

// ── SAVE AND LOAD LEVELS ──

level.save = function(map, name = "myLevel") {
    localStorage.setItem(name, JSON.stringify(map));
    console.log(`💾 Level "${name}" saved!`);
};

level.load = function(name = "myLevel") {
    const data = localStorage.getItem(name);
    if (!data) {
        console.log(`❌ Level "${name}" not found!`);
        return null;
    }
    return JSON.parse(data);
};

// Save a level
level.save(myMap, "level1");

// Load a level later
const loadedMap = level.load("level1");
if (loadedMap) {
    console.log("✅ Level loaded successfully!");
    // Recreate the level with the loaded map
    const newTiles = level.create(loadedMap, 64, tileColors);
}

What Each Line Does

Line 4: const level = {

Creates a new utility object called level

Line 6: create: function(map, tileSize, tileColors) {

Takes a 2D array map, tile size, and color mapping
Creates components for each non-zero tile

Line 9-14: for (let row = 0; row < map.length; row++) { for (let col = 0; col < map[row].length; col++) { const tileId = map[row][col]; if (tileId === 0) continue;

Loops through every cell in the map and skips empty cells (0)

Line 16-22: Creates a component for each tile with the right position and color

Line 33: addWalls: function(map, wallId = 1) {

Adds walls around the edge of a map

Line 35-37: const rows = map.length; const cols = map[0].length;

Gets the dimensions of the map

Line 39-42: Adds walls to the top and bottom rows

Line 44-47: Adds walls to the left and right columns

Line 54: findEmpty: function(map) {

Finds all empty cells (value = 0) in a map

Line 68: randomEmpty: function(map) {

Returns a random empty position from the map

Line 79-82: save: function(map, name = "myLevel") { localStorage.setItem(name, JSON.stringify(map)); }

Saves a level to localStorage as JSON

Line 86-90: load: function(name = "myLevel") { const data = localStorage.getItem(name); if (!data) { return null; } return JSON.parse(data); }

Loads a level from localStorage

🧩 Extension Pattern 3: Custom Class Extension

The Concept

Sometimes you need a completely new class that extends Limn Engine's classes. This is useful for creating complex objects with specialized behavior.

How it works: You create a new class that inherits from a Limn Engine class (like Component) and adds new properties and methods.

What We're About to Do

We're going to create a Player class that extends Component. This class will have built-in health, movement, and shooting.

The Code

// ── CUSTOM PLAYER CLASS ──

class Player extends Component {
    constructor(x, y) {
        super(40, 40, "#5b8cff", x, y, "rect");

        // Player-specific properties
        this.speed = 200;
        this.hp = 100;
        this.maxHp = 100;
        this.invincible = 0;
        this.score = 0;
        this.bullets = [];
        this.lastShot = 0;
        this.shootCooldown = 0.3; // seconds

        // Enable physics
        this.physics = false;
    }

    // Update player (called every frame)
    updatePlayer(dt) {
        // Movement
        this.speedX = 0;
        this.speedY = 0;
        if (display.keys[37]) this.speedX = -this.speed * dt;
        if (display.keys[39]) this.speedX =  this.speed * dt;
        if (display.keys[38]) this.speedY = -this.speed * dt;
        if (display.keys[40]) this.speedY =  this.speed * dt;

        // Shoot
        if (display.keys[32]) {
            this.shoot();
        }

        // Invincibility timer
        if (this.invincible > 0) {
            this.invincible--;
            this.alpha = 0.5;  // Blink effect
        } else {
            this.alpha = 1;
        }
    }

    // Shoot a bullet
    shoot() {
        const now = performance.now() / 1000;
        if (now - this.lastShot < this.shootCooldown) return;

        this.lastShot = now;

        const bullet = new Component(6, 12, "yellow", 
            this.x + this.width/2 - 3, 
            this.y - 5, 
            "rect"
        );
        bullet.speedY = -300;
        display.add(bullet);
        this.bullets.push(bullet);

        // Limit bullets
        if (this.bullets.length > 50) {
            const old = this.bullets.shift();
            old.destroy();
        }
    }

    // Take damage
    takeDamage(amount) {
        if (this.invincible > 0) return false;

        this.hp = Math.max(0, this.hp - amount);
        this.invincible = 60; // 1 second at 60fps
        display.camera.shake(8, 8);

        if (this.hp === 0) {
            console.log("💀 Player died!");
            return true; // Dead
        }
        return false; // Still alive
    }

    // Draw health bar
    drawHealth(ctx) {
        const pct = this.hp / this.maxHp;
        const barW = this.width;
        const barH = 5;

        ctx.fillStyle = "#333";
        ctx.fillRect(this.x, this.y - 10, barW, barH);

        const color = pct > 0.5 ? "#00cc44" : pct > 0.25 ? "#ffaa00" : "#cc0000";
        ctx.fillStyle = color;
        ctx.fillRect(this.x, this.y - 10, barW * pct, barH);
    }

    // Update bullets
    updateBullets() {
        for (let i = this.bullets.length - 1; i >= 0; i--) {
            const b = this.bullets[i];
            if (b.y < -50) {
                b.destroy();
                this.bullets.splice(i, 1);
            }
        }
    }
}

// ── USAGE ──

// Create player
const player = new Player(400, 300);
display.add(player);

// In the game loop
function update(dt) {
    // Update player
    player.updatePlayer(dt);
    player.updateBullets();
    player.drawHealth(display.context);

    // Check player collision with enemy
    if (player.crashWith(enemy)) {
        const died = player.takeDamage(15);
        if (died) {
            display.stop();
        }
    }
}

What Each Line Does

Line 4: class Player extends Component {

Creates a new class called Player that inherits from Component
This means it has all Component properties and methods

Line 6: constructor(x, y) {

The constructor function runs when you create a new Player

Line 7: super(40, 40, "#5b8cff", x, y, "rect");

Calls the parent Component constructor with size, color, and position

Line 10-16: this.speed = 200; this.hp = 100; ...

Adds player-specific properties

Line 24: updatePlayer(dt) {

Custom update method for player logic

Line 26-31: this.speedX = 0; ...

Handles movement with arrow keys

Line 34-36: if (display.keys[32]) { this.shoot(); }

Checks for Space key to shoot

Line 39-44: if (this.invincible > 0) { this.invincible--; this.alpha = 0.5; } else { this.alpha = 1; }

Manages invincibility frames and blink effect

Line 49: shoot() {

Creates and fires a bullet

Line 50-51: const now = performance.now() / 1000; if (now - this.lastShot < this.shootCooldown) return;

Enforces a cooldown between shots

Line 55-59: Creates a bullet at the player's position and adds it to the game

Line 62-65: if (this.bullets.length > 50) { const old = this.bullets.shift(); old.destroy(); }

Limits the number of bullets to prevent memory issues

Line 70: takeDamage(amount) {

Handles damage to the player

Line 72: if (this.invincible > 0) return false;

Ignores damage if invincible

Line 74: this.hp = Math.max(0, this.hp - amount);

Reduces health

Line 75: this.invincible = 60;

Sets invincibility for 1 second

Line 76: display.camera.shake(8, 8);

Shakes the camera for impact

Line 78-80: if (this.hp === 0) { return true; }

Returns true if dead

Line 85-96: drawHealth(ctx) {

Draws a health bar above the player

🧩 Extension Pattern 4: Scene Management Extension

The Concept

A scene manager helps you organize different game states like menu, gameplay, and game over screens.

What We're About to Do

We're going to create a scene manager that handles switching between scenes.

The Code

// ── SCENE MANAGER ──

class SceneManager {
    constructor() {
        this.scenes = {};
        this.currentScene = null;
        this.objects = {};
    }

    // Add a scene
    addScene(name, config) {
        this.scenes[name] = {
            enter: config.enter || function() {},
            update: config.update || function() {},
            exit: config.exit || function() {},
            objects: config.objects || []
        };
        console.log(`📋 Scene "${name}" added`);
    }

    // Switch to a scene
    switchTo(name) {
        // Exit current scene
        if (this.currentScene && this.scenes[this.currentScene]) {
            this.scenes[this.currentScene].exit();
            // Remove objects from previous scene
            if (this.objects[this.currentScene]) {
                for (let obj of this.objects[this.currentScene]) {
                    obj.destroy();
                }
                this.objects[this.currentScene] = [];
            }
        }

        // Enter new scene
        this.currentScene = name;
        const scene = this.scenes[name];

        if (!scene) {
            console.error(`❌ Scene "${name}" not found!`);
            return;
        }

        // Add objects for new scene
        this.objects[name] = [];
        for (let obj of scene.objects) {
            display.add(obj);
            this.objects[name].push(obj);
        }

        scene.enter();
        console.log(`▶️ Scene switched to "${name}"`);
    }

    // Update current scene
    update(dt) {
        if (this.currentScene && this.scenes[this.currentScene]) {
            this.scenes[this.currentScene].update(dt);
        }
    }

    // Get current scene name
    getCurrentScene() {
        return this.currentScene;
    }

    // Add object to current scene
    addObject(obj) {
        if (!this.currentScene) return;
        if (!this.objects[this.currentScene]) {
            this.objects[this.currentScene] = [];
        }
        this.objects[this.currentScene].push(obj);
        display.add(obj);
    }
}

// ── USAGE ──

// Create scene manager
const scenes = new SceneManager();

// ── MENU SCENE ──
const titleText = new Tctxt("48px", "Arial", "white", 400, 200);
titleText.align = "center";
titleText.setText("🎮 MY GAME");
titleText.hide();

const startText = new Tctxt("24px", "Arial", "white", 400, 300);
startText.align = "center";
startText.setText("Press SPACE to start");
startText.hide();

scenes.addScene("menu", {
    objects: [titleText, startText],
    enter: function() {
        titleText.show();
        startText.show();
        console.log("🎮 Menu scene entered");
    },
    exit: function() {
        titleText.hide();
        startText.hide();
        console.log("🚪 Menu scene exited");
    },
    update: function(dt) {
        if (display.keys[32]) {
            display.keys[32] = false;
            scenes.switchTo("game");
        }
    }
});

// ── GAME SCENE ──
const player = new Player(400, 300);
player.hide();

const scoreText = new Tctxt("24px", "Arial", "white", 20, 50);
scoreText.setText("Score: 0");
scoreText.hide();

scenes.addScene("game", {
    objects: [player, scoreText],
    enter: function() {
        player.show();
        scoreText.show();
        console.log("🎯 Game scene entered");
    },
    exit: function() {
        player.hide();
        scoreText.hide();
        console.log("🚪 Game scene exited");
    },
    update: function(dt) {
        player.updatePlayer(dt);
        player.updateBullets();
        player.drawHealth(display.context);
        scoreText.setText("Score: " + player.score);
    }
});

// ── START THE GAME ──
scenes.switchTo("menu");

// ── IN THE GAME LOOP ──
function update(dt) {
    scenes.update(dt);
}

What Each Line Does

Line 4: class SceneManager {

Creates a class to manage scenes

Line 6-9: this.scenes = {}; this.currentScene = null; this.objects = {};

Stores all scenes, current scene name, and objects per scene

Line 12: addScene(name, config) {

Adds a new scene with a name and configuration

Line 13-18: this.scenes[name] = { enter: ..., update: ..., exit: ..., objects: ... }

Each scene has enter, update, and exit functions, plus a list of objects

Line 23: switchTo(name) {

Switches to a different scene

Line 25-35: Exits the current scene and removes its objects

Line 37-40: Enters the new scene

Line 42-48: Adds objects for the new scene

Line 61: addObject(obj) {

Adds an object to the current scene

📊 Extension Patterns Comparison

Pattern	Best For	Complexity
Prototype Extension	Adding simple methods to existing classes	Low
Utility Extension	Standalone helper functions	Low-Medium
Custom Class Extension	Complex objects with specialized behavior	Medium
Scene Manager	Organizing game states	Medium

💡 Pro Tips

1. Keep Extensions Modular

// ── GOOD: Each extension in its own file ──
// health-extension.js
// level-extension.js
// player-class.js
// scene-manager.js

2. Use Namespaces

// ── PREVENT NAMING CONFLICTS ──
const LimnExtensions = {
    Health: { ... },
    Level: { ... },
    Scene: { ... }
};

3. Check for Existing Methods

// ── DON'T OVERRIDE EXISTING METHODS ──
if (!Component.prototype.setHealth) {
    Component.prototype.setHealth = function(max) { ... };
}

🎯 The One-Line Summary

"Extensions make Limn Engine infinitely extensible — add health systems, level editors, scene managers, and custom classes without touching the core engine."

Draw your game into existence — and extend it. 🔧🚀

🏃 The Ultimate Guide to Movement in Limn Engine

Kehinde Owolabi — Fri, 07 Aug 2026 23:26:30 +0000

🏃 The Ultimate Guide to Movement in Limn Engine

Everything You Need to Know About Moving Objects in Limn Engine

📖 Introduction

Movement is the heartbeat of every game. Whether you're dodging bullets in a top-down shooter, leaping across platforms, or guiding a character through a vast open world, how things move defines the player's experience. Get it right, and your game feels smooth, responsive, and alive. Get it wrong, and it feels clunky and frustrating.

Limn Engine offers a rich toolkit for movement — from simple speed-based motion to complex physics and smooth gliding. In this guide, we'll explore every movement method available, when to use each one, and how they work under the hood.

🎯 The Two Core Movement Methods

Before we dive into the specific functions, it's important to understand the two fundamental ways Limn Engine handles movement:

Method	How It Works	When to Use
`move()`	Moves an object using `speedX` and `speedY`	Standard movement — independent of angle
`moveAngle()`	Moves an object along its current `angle`	Directional movement — speed applied relative to angle

These two methods are called automatically by the engine based on the angularMovement property of your component.

🧩 Method 1: Basic Movement with `move()`

The Concept

move() is the default movement method in Limn Engine. It works by taking the values stored in speedX and speedY and adding them to the component's x and y position every frame. This is the simplest way to move objects.

How it works internally:

When the engine calls move() on a component, it does this:

If physics is enabled, it adds gravity to the vertical speed
It adds speedX to x (horizontal movement)
It adds speedY to y (vertical movement)

This means you control movement by setting speedX and speedY each frame. If you set speedX = 5, the object moves 5 pixels right every frame. If you set speedY = -3, it moves 3 pixels up every frame.

Why you need dt:

Without dt, movement speed depends on frame rate — faster computers move faster. By multiplying speed by dt (delta time), you convert "pixels per frame" to "pixels per second," making movement consistent on all computers.

The key principle: In move(), you control speed directly. The engine applies it automatically. You don't calculate positions manually — you set speeds.

What We're About to Do

We're going to create a player that moves with arrow keys. This is the most common type of movement in games — simple, responsive, and easy to understand. We'll use move() to handle the actual movement, and we'll use dt to make it frame-rate independent.

The Code

const display = new Display();
display.perform();
display.start(800, 600);
display.backgroundColor("#1a1a2e");

const player = new Component(40, 40, "#5b8cff", 400, 300, "rect");
display.add(player);

function update(dt) {
    // Reset speed each frame
    player.speedX = 0;
    player.speedY = 0;

    // Arrow keys
    if (display.keys[37]) player.speedX = -200 * dt; // Left
    if (display.keys[39]) player.speedX =  200 * dt; // Right
    if (display.keys[38]) player.speedY = -200 * dt; // Up
    if (display.keys[40]) player.speedY =  200 * dt; // Down

    // Keep player on screen
    move.bound(player);
}

What Each Line Does

Line 1-4: Creates the game window, activates 60fps mode, sets the canvas size to 800x600, and sets the background to dark blue

Line 6-7: Creates a 40x40 blue square at the center of the screen and adds it to the game world

Line 9: function update(dt) {

The game loop function, called 60 times per second
dt (delta time) is the time since the last frame, usually about 0.016 seconds
Using dt makes movement consistent on all computers

Line 10-11: player.speedX = 0; player.speedY = 0;

Resets speed to 0 at the start of each frame
Without this, the player would keep moving forever in the last direction

Line 13-16: if (display.keys[37]) player.speedX = -200 * dt;

display.keys[37] checks if the left arrow key is pressed
37 is the keycode for the left arrow
player.speedX = -200 * dt sets horizontal speed to -200 pixels per second (moving left)
39 is right arrow, 200 * dt means 200 pixels per second to the right
38 is up arrow, -200 * dt means moving up
40 is down arrow, 200 * dt means moving down

Line 18: move.bound(player);

Keeps the player on screen by clamping their position to the canvas edges
If the player tries to go past an edge, it stops them

🧭 Method 2: Angular Movement with `moveAngle()`

The Concept

moveAngle() is the second movement method in Limn Engine. Instead of using speedX and speedY directly, it applies speed relative to the component's angle property. This is useful when you want objects to move in the direction they're facing.

How it works internally:

When the engine calls moveAngle() on a component, it does this:

If physics is enabled, it adds gravity to the vertical speed
It calculates the horizontal movement: speedX * cos(angle)
It calculates the vertical movement: speedY * sin(angle)

This means if you set angle = 45 degrees and speedX = 5, the object moves diagonally. As the angle changes, the direction of movement changes.

The key principle: In moveAngle(), the speed values are applied relative to the object's facing direction. This makes it perfect for rotating objects, orbiting, and directional movement.

What We're About to Do

We're going to create an object that moves in the direction it's facing. This is useful for orbiting objects, enemies that chase the player, and driving games.

The Code

const display = new Display();
display.perform();
display.start(800, 600);
display.backgroundColor("#0a0a10");

const orbiter = new Component(20, 20, "cyan", 400, 300, "rect");
orbiter.angularMovement = true;  // Uses moveAngle() instead of move()
orbiter.speedX = 2;
orbiter.speedY = 2;
display.add(orbiter);

function update(dt) {
    // Rotate continuously
    orbiter.angle += 0.02;
}

What Each Line Does

Line 6: const orbiter = new Component(20, 20, "cyan", 400, 300, "rect");

Creates a 20x20 cyan square at the center of the screen

Line 7: orbiter.angularMovement = true;

This is the key line. Tells the engine to use moveAngle() instead of move()
With this set to true, the component's speed is applied relative to its angle

Line 8-9: orbiter.speedX = 2; orbiter.speedY = 2;

Sets the speed values that will be applied in the direction the object is facing

Line 10: display.add(orbiter);

Adds the orbiter to the game world

Line 13-14: function update(dt) { orbiter.angle += 0.02; }

Increases the angle by 0.02 radians each frame
As the angle changes, the direction of movement changes — creating an orbit

🚗 Method 3: Directional Movement (Car Example)

The Concept

Directional movement combines rotation with movement. The object can turn and then move forward in its new direction. This is how cars, tanks, and many game characters work.

How it works:

Limn Engine provides helper functions for directional movement:

move.forward() — Moves the object in the direction it's facing
move.backward() — Moves the object opposite to the direction it's facing
move.turnLeft() and move.turnRight() — Rotate the object

These functions use the object's angle property internally. move.forward() calculates the direction using cos(angle) and sin(angle), then moves the object that way.

The key principle: Directional movement separates turning from moving. You turn first, then you move forward. This creates realistic movement like a car.

What We're About to Do

We're going to build a car that drives forward, backward, and turns. This demonstrates directional movement, rotation, and how to combine movement functions.

The Code

const display = new Display();
display.perform();
display.start(800, 600);
display.backgroundColor("#1a1a2e");

const car = new Component(40, 20, "#ff6b6b", 400, 300, "rect");
car.changeAngle = true;  // Enable rotation
display.add(car);

function update(dt) {
    // Car controls
    if (display.keys[38]) move.forward(car, 3);      // Up: drive forward
    if (display.keys[40]) move.backward(car, 2);     // Down: reverse
    if (display.keys[37]) move.turnLeft(car, 0.05);  // Left: turn left
    if (display.keys[39]) move.turnRight(car, 0.05); // Right: turn right

    // Keep car on screen
    move.bound(car);
}

What Each Line Does

Line 6-8: const car = new Component(40, 20, "#ff6b6b", 400, 300, "rect"); car.changeAngle = true; display.add(car);

Creates a 40x20 red rectangle at the center (car shape)
changeAngle = true — Enables rotation on the car so it can turn
Adds the car to the game world

Line 11: if (display.keys[38]) move.forward(car, 3);

display.keys[38] checks if the up arrow is pressed
move.forward(car, 3) — Moves the car forward 3 pixels in the direction it's facing

Line 12: if (display.keys[40]) move.backward(car, 2);

display.keys[40] checks if the down arrow is pressed
move.backward(car, 2) — Moves the car backward 2 pixels

Line 13: if (display.keys[37]) move.turnLeft(car, 0.05);

display.keys[37] checks if the left arrow is pressed
move.turnLeft(car, 0.05) — Rotates the car left by 0.05 radians (about 3 degrees)

Line 14: if (display.keys[39]) move.turnRight(car, 0.05);

display.keys[39] checks if the right arrow is pressed
move.turnRight(car, 0.05) — Rotates the car right by 0.05 radians

Line 16: move.bound(car);

Keeps the car on screen

✨ Method 4: Smooth Movement with `glideTo()`

The Concept

glideTo() creates smooth, easing-based movement to a target position. Instead of teleporting or moving at constant speed, the object starts fast and slows down as it approaches its destination. This is called "ease-out" and creates natural-looking motion.

How it works internally:

When you call move.glideTo(coin, 1000, 500, 300):

Records the starting position and the current time
Each frame, calculates how much time has passed (progress from 0 to 1)
Applies cubic easing formula: eased = 1 - (1 - progress)³
Calculates the new position based on the eased value
Updates the object's position

The key principle: glideTo() handles all the timing and easing for you. You just specify the target and how long it should take.

What We're About to Do

We're going to move a coin smoothly to random positions with easing. This creates professional-looking movement without manual lerp functions.

The Code

const display = new Display();
display.perform();
display.start(800, 600);
display.backgroundColor("#1a1a2e");

const coin = new Component(30, 30, "gold", 400, 300, "rect");
display.add(coin);

const infoText = new Tctxt("18px", "Arial", "white", 20, 50);
infoText.setText("Press Space to move coin");
display.add(infoText);
infoText.fixed();

function update(dt) {
    // Move coin to random position when Space is pressed
    if (display.keys[32]) {
        move.glideTo(coin, 1000, Math.random() * 700, Math.random() * 500);
        display.keys[32] = false; // Prevent holding
    }
}

What Each Line Does

Line 6-7: Creates a 30x30 gold square at the center and adds it to the game world

Line 9-12: Creates a text label at the top-left and locks it to the screen position so it doesn't move with the camera

Line 15-19: Checks if Space is pressed, then glides the coin to a random position over 1 second

⚡ Method 5: Physics-Based Movement

The Concept

Physics-based movement uses acceleration and deceleration to create realistic, weighty motion. Instead of moving at constant speed, objects smoothly speed up and slow down.

How it works:

move.accelerate() — Adds acceleration to speed, clamped to a maximum
move.decelerate() — Reduces speed toward zero without overshooting

The key principle: You control acceleration, not speed directly. This creates realistic physics like a car.

What We're About to Do

We're going to create a player with smooth acceleration and deceleration, like a car. This creates realistic, weighty movement.

The Code

const display = new Display();
display.perform();
display.start(800, 600);
display.backgroundColor("#1a1a2e");

const player = new Component(40, 40, "#5b8cff", 400, 300, "rect");
display.add(player);

function update(dt) {
    // Accelerate or decelerate
    if (display.keys[68]) {  // D key
        move.accelerate(player, 0.6, 0, 8, 0);  // Accelerate right
    } else if (display.keys[65]) {  // A key
        move.accelerate(player, -0.6, 0, 8, 0); // Accelerate left
    } else {
        move.decelerate(player, 0.4, 0);        // Slow down
    }

    // Keep player on screen
    move.bound(player);
}

What Each Line Does

Line 9: if (display.keys[68]) { move.accelerate(player, 0.6, 0, 8, 0); }

Checks if the D key is pressed
move.accelerate() — Adds horizontal acceleration at 0.6 per frame, max speed 8

Line 11: else if (display.keys[65]) { move.accelerate(player, -0.6, 0, 8, 0); }

Checks if the A key is pressed
Negative acceleration moves the player left

Line 13: else { move.decelerate(player, 0.4, 0); }

move.decelerate() — Reduces horizontal speed toward zero at 0.4 per frame

Line 16: move.bound(player);

Keeps the player on screen

🎯 Method 6: Complete Movement Demo

The Concept

In a real game, you'll often need to combine multiple movement methods. This demo shows how different movement techniques can work together in one game.

What We're About to Do

We're going to combine multiple movement methods into a single complete game.

The Code

const display = new Display();
display.perform();
display.start(800, 600);
display.backgroundColor("#1a1a2e");

// ── PLAYER ──
const player = new Component(40, 40, "#5b8cff", 400, 300, "rect");
display.add(player);

// ── ORBITER ──
const orbiter = new Component(20, 20, "cyan", 400, 300, "rect");
orbiter.angularMovement = true;
orbiter.speedX = 2;
orbiter.speedY = 2;
display.add(orbiter);

// ── UI ──
const infoText = new Tctxt("18px", "Arial", "white", 20, 50);
infoText.setText("Arrow keys to move, Space to glide, A/D to accelerate");
display.add(infoText);
infoText.fixed();

function update(dt) {
    // ── PLAYER MOVEMENT (Arrow Keys) ──
    player.speedX = 0;
    player.speedY = 0;
    if (display.keys[37]) player.speedX = -200 * dt;
    if (display.keys[39]) player.speedX =  200 * dt;
    if (display.keys[38]) player.speedY = -200 * dt;
    if (display.keys[40]) player.speedY =  200 * dt;
    move.bound(player);

    // ── ORBITER (Angular Movement) ──
    orbiter.angle += 0.02;

    // ── GLIDE (Space Key) ──
    if (display.keys[32]) {
        move.glideTo(player, 1000, Math.random() * 700, Math.random() * 500);
        display.keys[32] = false;
    }
}

What Each Line Does

Lines 6-7: Creates the player with basic arrow key movement

Lines 10-14: Creates an orbiter with angular movement that orbits continuously

Lines 17-20: Creates a UI label that stays on screen

Lines 23-29: Player movement with arrow keys and boundary keeping

Lines 31-32: Orbiter rotation — increases angle each frame

Lines 34-38: Glide effect — when Space is pressed, the player glides to a random position

💡 Pro Tips

1. Always Use `dt` for Consistent Speed

// ✅ CORRECT: Frame-rate independent
player.speedX = 200 * dt;

// ❌ WRONG: Frame-rate dependent
player.speedX = 4;

Why this matters: On a fast computer, speedX = 4 moves at 240 pixels per second. On a slow computer, it moves at 120 pixels per second. Using dt ensures everyone plays at the same speed.

2. Normalize Diagonal Movement

let mx = 0, my = 0;
if (display.keys[37]) mx = -1;
if (display.keys[39]) mx = 1;
if (display.keys[38]) my = -1;
if (display.keys[40]) my = 1;

if (mx !== 0 && my !== 0) {
    mx *= 0.707;  // Prevent faster diagonal movement
    my *= 0.707;
}

player.x += mx * 200 * dt;
player.y += my * 200 * dt;

Why this matters: Without normalization, moving diagonally is 1.4 times faster than moving in a single direction. The 0.707 factor (which is 1/√2) keeps the speed consistent.

3. Combine Movement Methods

// Use accelerate for smooth movement + bound to stay on screen
move.accelerate(player, 0.6, 0, 8, 0);
move.bound(player);

// Use pointTo to aim + forward to move
move.pointTo(enemy, player.x, player.y);
move.forward(enemy, 2);

Why this works: Each function handles one aspect of movement. Combining them gives you complex behavior with simple code.

📊 Movement Method Reference

Method	What It Does	When to Use
`move.bound()`	Keeps object on screen	Every game
`move.boundTo()`	Custom boundaries	Arena games
`move.forward()`	Move in facing direction	Driving games
`move.backward()`	Move opposite facing direction	Driving games
`move.turnLeft()`	Rotate left	Driving games
`move.turnRight()`	Rotate right	Driving games
`move.pointTo()`	Face a target	Aiming, tracking
`move.circle()`	Orbital motion	Orbiting enemies
`move.glideTo()`	Smooth movement	Animations, cutscenes
`move.accelerate()`	Smooth acceleration	Physics-based movement
`move.decelerate()`	Smooth deceleration	Physics-based movement
`move.project()`	Projectile physics	Arrows, fireballs
`move.hitObject()`	Platform collision	Platformers
`move.teleport()`	Instant position	Respawns, checkpoints

🎯 The One-Line Summary

"Limn Engine offers 15+ movement methods — from simple speed-based movement to complex physics, smooth gliding, and angular motion — so you can build any game mechanic."

Draw your game into existence — one movement at a time. 🏃🚀

⚔️ Godot vs Limn Engine: Which One Should You Choose?

Kehinde Owolabi — Wed, 05 Aug 2026 19:53:12 +0000

⚔️ Godot vs Limn Engine: Which One Should You Choose?

A Brutally Honest Comparison of Two Completely Different Engines

📖 Introduction

Godot and Limn Engine are both free, open-source game engines. Both are beginner-friendly. Both can build 2D games.

But they are fundamentally different.

Godot is a full-featured, professional-grade engine with a visual editor, node-based architecture, and support for 2D and 3D . Limn Engine is a lightweight, zero‑configuration JavaScript framework that runs entirely in the browser .

This comparison isn't about which is "better" — it's about helping you choose the right tool for your goals.

🎯 What Each Engine Is

Limn Engine

Limn Engine is a zero‑configuration, browser‑based 2D game framework. You drop a single epic.js file into an HTML page, write a few lines of JavaScript, and your game runs in any browser .

The philosophy: "Common outcomes should be functions." Every repetitive task — edge detection, screen shake, UI anchoring — has been turned into a one‑line function .

Built on: A Toshiba laptop with 4GB RAM, offline W3Schools, and borrowed siblings' laptops. No team. No funding. Just determination .

Godot

Godot is a full‑featured, open‑source game engine with a visual editor, node‑based architecture, and support for both 2D and 3D game development . It operates under the MIT license, meaning it is 100% free with no royalties, no subscriptions, and no vendor lock‑in .

The philosophy: "Everything is a node." Games are built by composing scenes from reusable building blocks .

Built on: Over a decade of open‑source development, a large and growing community, and contributions from developers worldwide .

📊 Head‑to‑Head Comparison

1. Setup & Installation

Aspect	Limn Engine	Godot
Installation	None — just include `epic.js`	Download and install the editor (~150MB)
First Game Time	~60 seconds	~5–10 minutes
Environment	Browser (HTML + JS)	Desktop application

Verdict: Limn wins for pure speed. You can start coding immediately. Godot requires installation but gives you a full visual editor.

2. Language & Learning Curve

Aspect	Limn Engine	Godot
Language	JavaScript	GDScript (Python‑like) or C#
Learning Curve	Very low	Low–Medium
Type of API	Function‑based	Node‑based + scripting

Verdict: Limn's API is designed to be predictable and intuitive — move.bound(), camera.shake(), sound.play() . Godot's GDScript is beginner‑friendly and Python‑like , but requires understanding nodes, scenes, and signals.

3. Scene Management

This is where the two engines diverge most dramatically.

Feature	Limn Engine	Godot
Scene Concept	A number	A Node
Setup Time	0 seconds	2–5 minutes
Code Required	`display.scene = 1`	`get_tree().change_scene_to_file("res://game.tscn")`
Learning Curve	Very Low	Low–Medium
Scene Transitions	❌ No	✅ Yes
Data Passing	❌ No	✅ Yes

Verdict: Limn's scene system is the simplest in any game engine — scenes are just numbers . Godot's system is more powerful but requires understanding nodes and scenes.

4. Key Features

Feature	Limn Engine	Godot
2D Support	✅ Excellent	✅ Excellent (native pipeline)
3D Support	❌ No	✅ Yes
Visual Editor	❌ No	✅ Yes
TileMap	✅ Built‑in	✅ Built‑in
Particle System	✅ Six presets	✅ Yes
Physics	Basic	✅ Robust
Animation	✅ Sprites	✅ Full animation system
Audio	✅ SoundManager	✅ Yes
Rendering	Canvas (CPU)	OpenGL (GPU)
ClearMargin Trick	✅ Unique	❌ No
Dual‑Renderer	✅ Unique	❌ No

Verdict: Godot has far more features — it's a full engine. Limn has a few unique optimizations that Godot doesn't have .

5. Performance

Aspect	Limn Engine	Godot
Rendering Engine	Canvas (CPU)	OpenGL (GPU)
Draw Calls	Optimized with dual‑renderer	Standard
Memory Usage	Very low	Low–Medium
Performance	4 FPS → 60 FPS with `perform()`	60 FPS with thousands of sprites

Verdict: Limn's dual‑renderer system is a clever optimization that drastically reduces draw calls . Godot has GPU acceleration, making it faster for complex scenes.

6. Platform Support

Platform	Limn Engine	Godot
Web	✅ Native	✅ (HTML5 export)
Windows	❌ No	✅ Yes
Mac	❌ No	✅ Yes
Linux	❌ No	✅ Yes
Android	❌ No	✅ Yes
iOS	❌ No	✅ Yes

Verdict: Godot exports to everything . Limn is web‑only.

7. Community & Ecosystem

Aspect	Limn Engine	Godot
Community Size	🟡 Growing	🟢 Large
Tutorials	✅ DEV.to series	✅ Thousands
Asset Store	❌ No	✅ Growing
Documentation	✅ Comprehensive	✅ Excellent
License	MIT	MIT

Verdict: Godot has a much larger community and ecosystem . Limn is newer but has passionate developers.

📊 Comparison Table

Category	Limn Engine	Godot
Setup & Installation	10/10	8/10
Language & Learning	9/10	8/10
Scene Management	10/10 (simplicity)	8/10 (power)
Key Features	7/10	10/10
Performance	8/10	9/10
Platform Support	5/10	10/10
Community	6/10	9/10
Overall	8.2/10	8.8/10

🎯 Which One Should You Choose?

Choose Limn Engine If:

You want to build browser games instantly
You want zero configuration — just one script tag
You want to learn how game engines work (the code is open and readable)
You want to learn JavaScript while making games
You value simplicity over features
You want to ship games fast (one HTML file + epic.js)

Choose Godot If:

You want a full, professional‑grade engine
You need 3D support
You want a visual editor
You need to export to multiple platforms (Windows, Mac, Linux, mobile)
You want a large community and ecosystem
You prefer Python‑like syntax (GDScript)
You're building a commercial game that needs to ship everywhere

🎯 The One‑Line Summary

"Limn Engine is for the web — one file, one script tag, zero setup, instant deployment. Godot is a complete engine — visual editor, 3D support, all platforms, full control."

Draw your game into existence — with the engine that fits your goals. 🎮🚀

Build Your First Browser Game in 60 Seconds with Limn Engine

Kehinde Owolabi — Mon, 03 Aug 2026 02:52:35 +0000

🎮 Build Your First Browser Game in 60 Seconds with Limn Engine

A Complete Coin Collector Game in Under 100 Lines of JavaScript

🎯 Live Demo

See the final result first: [limn-engine-doc.vercel.app/test8.html](http://limn-engine-doc.vercel.app/test8.html]\(https://limn-engine-doc.vercel.app/test8.html\))

Play the game, move the blue square with arrow keys, collect all 10 gold coins, and win!

📖 Introduction

Most game engines require npm installs, build tools, and hours of setup before you see anything on screen. Limn Engine is different — one script tag, one canvas, and you're ready to build.

In this tutorial, you'll build a complete coin collector game in under 100 lines of code. You'll learn:

How to set up Limn Engine
How to create and move a player
How to generate coins at random positions
How to detect collisions
How to track score and win the game
How to restart with one keypress

The result: A fully playable game that you can share with anyone.

🚀 Step 1: Download Limn Engine

First, you need to get the Limn Engine file.

Go to the Limn Engine website: [limn-engine-doc.vercel.app](https://limn-engine-doc.vercel.app)
Click the download button to get epic.js
Place epic.js in the same folder as your HTML file

Why this matters: Limn Engine is a single file. No npm, no build tools, no complex setup. Just one JavaScript file and you're ready to go.

📁 Step 2: Create Your HTML File

Create a new HTML file and include the Limn Engine script. This is the foundation of your game.


<!doctype html>

<html>

<head>

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

</head>

<body>

<script>

// All your game code goes here

</script>

</body>

</html>

Let's break this down so you understand what's happening:

<!doctype html> — This tells the browser to use the latest version of HTML. Think of it as saying "Hey browser, I'm using modern HTML, please render this correctly."
<html> — This is the root element of your page. Everything else goes inside it.
<head> — This section contains information about your page that the browser needs before it starts rendering. Things like the title, character set, and in our case, the script we're about to load.
<script src="epic.js"> — This is where we load the Limn Engine. The src attribute tells the browser to fetch a file called epic.js from the same folder as your HTML file. This gives you access to all the Limn Engine features like Display, Component, Tctxt, and everything else we'll use.
<body> — This is where the visible content of your page goes. The canvas will be created here automatically when we start the display.
<script> — This is where we write our game code. The browser will run this code after it loads epic.js.

What happens if you skip this step: If you don't include epic.js, the browser will throw an error saying Display is not defined because it doesn't know what a Display is.

🎮 Step 3: Create the Display

The Display is your game window. It creates the canvas, manages the game loop, and handles input from the keyboard and mouse.


const display = new Display();

display.perform();

display.start(800, 600);

display.backgroundColor("green");

Let me explain each line so you understand what it's doing:

const display = new Display(); — This creates a new Display object. Think of it as telling the engine "I want a game window." This object will manage everything about your game.
display.perform(); — This turns on performance mode. Without this, your game runs at about 50 frames per second. With it, you get 60 frames per second and a special rendering system that makes your game faster. Always call this before start().
display.start(800, 600); — This actually creates the canvas on your page. The two numbers tell the engine how big you want the game window: 800 pixels wide and 600 pixels tall. After this line, you'll see a blank canvas on your page.
display.backgroundColor("green"); — This sets the background color of your canvas. You can use any color name or hex code here. If you skip this, the background will be transparent (white in most browsers).

A helpful way to think about it: Creating the Display is like setting up a stage. perform() is like turning on the lights, start() is like raising the curtain, and backgroundColor() is like painting the backdrop.

🧩 Step 4: Create the Player

A Component is any game object — player, enemy, coin, wall. Think of it as anything that appears on screen and can move or be interacted with.


const player = new Component(40, 40, "blue", 400, 300, "rect");

display.add(player);

Let me walk you through what each part means:

new Component(40, 40, "blue", 400, 300, "rect") — This creates a new Component. The five pieces of information are:
40, 40 — The width and height of the component in pixels. This creates a 40×40 square.
"blue" — The color of the component. This can be a color name, hex code, or even an image path.
400, 300 — The starting position on the screen. This puts the player at the center of an 800×600 canvas.
"rect" — The type of component. This tells the engine to draw a rectangle. Other options include "image" and "text".
display.add(player); — This tells the engine to add the player to the game world. Without this line, nothing would appear on screen because the engine wouldn't know about your player.

What if you want to change the player's position? You can set player.x and player.y to any number. For example, player.x = 100; moves the player to the left edge.

📝 Step 5: Create the UI (Score and Win Text)

Tctxt is a special text component that gives you more control over how text looks. It can have backgrounds, padding, alignment, and more.


const scoreText = new Tctxt("24px", "Arial", "white", 20, 50);

scoreText.setText("Score: 0 / 10");

display.add(scoreText);

const winText = new Tctxt("48px", "Arial", "gold", 400, 300);

winText.align = "center";

winText.setText("YOU WIN!");

winText.hide();

display.add(winText);

const restartText = new Tctxt("20px", "Arial", "white", 400, 380);

restartText.align = "center";

restartText.setText("Press R to play again");

restartText.hide();

display.add(restartText);

Let me explain each piece:

Score Text:

new Tctxt("24px", "Arial", "white", 20, 50) — Creates text at position (20, 50) from the top-left corner. The font is 24 pixels tall and uses the Arial font in white color.
.setText("Score: 0 / 10") — Sets the actual text content. This is separate from creating the object so you can update it later.
display.add(scoreText) — Adds it to the game world so it appears on screen.

Win Text (hidden at start):

.align = "center" — Centers the text horizontally. This is why the x position is 400 (the center of an 800-pixel screen).
.hide() — Makes the text invisible at the start. This is important because the player hasn't won yet.
.show() — Will be called later when the player wins.

Restart Text:

Similar to the win text, but positioned slightly lower at y=380.
Also hidden at start and will appear when the player wins.

Why use Tctxt instead of a regular Component? Tctxt gives you features like alignment, background color, and padding that normal text components don't have. This makes your UI look much more polished.

🪙 Step 6: Create the Coins

Coins are also Components. We'll create 10 coins at random positions using a loop.


const totalCoins = 10;

let coins = [];

for (let i = 0; i < totalCoins; i++) {

let coin = new Component(30, 30, "gold",

Math.random() * 700 + 50,

Math.random() * 500 + 50, "rect");

display.add(coin);

coins.push(coin);

}

Let me walk through what's happening:

const totalCoins = 10; — This sets how many coins we want. We use a variable so we can change it easily later.
let coins = []; — This creates an empty array to store all the coin objects. We need this so we can check collisions with each coin and remove collected ones.
for (let i = 0; i < totalCoins; i++) — This loop runs 10 times. Each time, it creates one new coin.
Math.random() * 700 + 50 — This creates a random number between 50 and 750. Why 50 and 750? We want the coins to appear away from the edges so they're reachable. The canvas is 800 pixels wide, so 50 and 750 give a nice margin.
Math.random() gives a number between 0 and 1.
Multiply by 700 gives a number between 0 and 700.
Add 50 gives a number between 50 and 750.
Math.random() * 500 + 50 — Same logic for the Y position. The canvas is 600 pixels tall, so this gives numbers between 50 and 550.
display.add(coin) — Adds the coin to the game world.
coins.push(coin) — Stores the coin in our array for later use.

What if you want more coins? Just change totalCoins to any number. The loop will create that many coins.

🎯 Step 7: Game State

We need variables to track the game status.


let score = 0;

let gameActive = true;

What these mean:

score — This starts at 0 and increases by 1 each time you collect a coin. It's what we show on the score text.
gameActive — This is a boolean (true/false). When true, the game updates normally. When false, the game stops. This prevents the player from continuing after winning.

Why do we need gameActive? Without it, the player could keep moving and the score could change even after winning. It gives us control over when the game ends.

🔄 Step 8: The Game Loop

The update() function runs every frame, which is 60 times per second. This is where all the action happens.


function update(deltaTime) {

// Restart with R key

if (display.keys[82]) {

location.reload();

return;

}

if (!gameActive) return;

Let me explain the flow:

function update(deltaTime) — This is where Limn Engine calls your game code every frame. The deltaTime parameter tells you how much time has passed since the last frame (usually about 0.016 seconds at 60fps).
if (display.keys[82]) — The display.keys array stores which keys are currently pressed. 82 is the keycode for the letter 'R'. When you press R, this condition becomes true.
location.reload(); — This reloads the page, which restarts the game. It's a simple way to reset everything.
return; — This exits the update function early. Without this, the game would keep running even as it reloads.
if (!gameActive) return; — If the game is not active (because you've won), this exits the function early. This stops the player from moving or collecting more coins after winning.

What is keycode 82? Every key on the keyboard has a numeric keycode. 82 is 'R', 37-40 are arrow keys, 32 is space. You can find a full list of keycodes online.

⌨️ Step 9: Player Movement

Now we add the controls to move the player with arrow keys.


// Player movement

if (display.keys[37]) player.speedX = -400 * deltaTime;

else if (display.keys[39]) player.speedX = 400 * deltaTime;

else player.speedX = 0;

if (display.keys[38]) player.speedY = -400 * deltaTime;

else if (display.keys[40]) player.speedY = 400 * deltaTime;

else player.speedY = 0;

move.bound(player);

Here's what each part does:

display.keys[37] — Keycode 37 is the left arrow key. If it's pressed, we set the player's horizontal speed to negative (move left).
-400 * deltaTime — This moves the player at 400 pixels per second. Multiplying by deltaTime makes the movement smooth and consistent regardless of frame rate. On a fast computer, deltaTime is smaller, so the player moves less per frame but more often. On a slow computer, deltaTime is larger, so the player moves more per frame but less often. The result is the same speed on both.
move.bound(player); — This keeps the player inside the canvas boundaries. Without this, the player would walk off the screen and disappear. It's like having an invisible wall at the edges.

Keycodes explained:

37 = Left arrow
39 = Right arrow
38 = Up arrow
40 = Down arrow

🪙 Step 10: Coin Collection

This is where we check if the player touches a coin and handle what happens.


// Coin collection

for (let i = 0; i < coins.length; i++) {

if (player.crashWith(coins[i])) {

[display.camera](http://display.camera).shake(3, 3);

coins[i].hide();

coins.splice(i, 1);

score++;

scoreText.setText("Score: " + score + " / " + totalCoins);

break;

}

}

Let me break this down carefully:

for (let i = 0; i < coins.length; i++) — This loops through every coin in our array. We use i to track which coin we're looking at.
if (player.crashWith(coins[i])) — This checks if the player overlaps with the current coin. crashWith() is a built-in collision detection function. It returns true if two components are touching.
display.camera.shake(3, 3); — This makes the screen shake slightly. The two numbers are the intensity on the X and Y axes. A small shake like this gives satisfying feedback to the player.
coins[i].hide(); — This makes the coin invisible. It's still in memory but not drawn on screen.
coins.splice(i, 1); — This removes the coin from the array. splice(i, 1) means "remove 1 item at position i".
score++; — This adds 1 to the score.
scoreText.setText("Score: " + score + " / " + totalCoins); — This updates the score display.
break; — This exits the loop early. Why? Because we've already found and collected a coin, so we don't need to check the rest of the coins this frame.

What happens if you don't use break? The player could collect multiple coins in one frame if they overlap with several at once, which would feel unfair and break the game.

🏆 Step 11: Win Condition

Finally, we check if the player has collected all the coins.


// Win condition

if (score === totalCoins && gameActive) {

gameActive = false;

[winText.show](http://winText.show)();

[restartText.show](http://restartText.show)();

scoreText.hide();

}

}

Here's the logic:

if (score === totalCoins && gameActive) — This checks two things:
The score equals the total number of coins (10)
The game is still active
gameActive = false; — This stops the game. The player won't be able to move or collect more coins.
winText.show(); — This makes the "YOU WIN!" text appear.
restartText.show(); — This makes the "Press R to play again" text appear.
scoreText.hide(); — This hides the score display since you don't need it anymore.

Why do we check gameActive? Without this check, the win condition could trigger multiple times. Once you win, the game is no longer active, so the condition won't run again.

📝 Complete Code

Here's the entire game in one file. You can copy this and run it immediately.


<!doctype html>

<html>

<head>

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

</head>

<body>

<script>

let gameActive = true;

const display = new Display();

const player = new Component(40, 40, "blue", 400, 300, "rect");

const scoreText = new Tctxt("24px", "Arial", "white", 20, 50);

const restartText = new Tctxt("20px", "Arial", "white", 400, 380);

display.perform()

display.start(800, 600);

let score = 0;

const totalCoins = 10;

let coins = [];

// Player

display.add(player);

display.backgroundColor("green")

// Score text

scoreText.setText("Score: 0 / " + totalCoins);

display.add(scoreText);

// Win text (hidden at start)

const winText = new Tctxt("48px", "Arial", "gold", 400, 300);

winText.align = "center";

winText.setText("YOU WIN!");

winText.hide();

display.add(winText);

restartText.align = "center";

restartText.setText("Press R to play again");

restartText.hide();

display.add(restartText);

// Create coins

for (let i = 0; i < totalCoins; i++) {

let coin = new Component(30, 30, "gold",

Math.random() * 700 + 50,

Math.random() * 500 + 50, "rect");

display.add(coin);

coins.push(coin);

}

function restart() {

location.reload()

}

function update(deltaTime) {

// Restart with R key

if (display.keys[82]) {

restart();

return;

}

if (!gameActive) return;

// Player movement

if (display.keys[37]) player.speedX = -400 * deltaTime;

else if (display.keys[39]) player.speedX = 400 * deltaTime;

else player.speedX = 0;

if (display.keys[38]) player.speedY = -400 * deltaTime;

else if (display.keys[40]) player.speedY = 400 * deltaTime;

else player.speedY = 0;

move.bound(player);

// Coin collection

for (let i = 0; i < coins.length; i++) {

if (player.crashWith(coins[i])) {

[display.camera](http://display.camera).shake(3, 3);

coins[i].hide();

coins.splice(i, 1);

score++;

scoreText.setText("Score: " + score + " / " + totalCoins);

break;

}

}

// Win condition

if (score === totalCoins && gameActive) {

gameActive = false;

[winText.show](http://winText.show)();

[restartText.show](http://restartText.show)();

scoreText.hide();

}

}

</script>

</body>

</html>

🎯 What You've Learned

| Concept | Why It Matters | How It Works |

|---------|----------------|--------------|

| Limn Engine Setup | No npm, no build tools — just one script tag | Include epic.js and start coding |

| Components | Every game object is a Component | new Component() creates one |

| Player Movement | Arrow keys with deltaTime for consistent speed | display.keys reads input, speedX/speedY moves |

| Collision Detection | crashWith() detects overlaps | Returns true when two components touch |

| Random Placement | Math.random() creates variety | Gives different positions every time |

| UI with Tctxt | Styled text with background and padding | Supports alignment, colors, and show/hide |

| Win Condition | Game state management | gameActive controls the game flow |

| Restart | One keypress to reload | location.reload() resets everything |

🚀 What's Next: Article 2 — "Build a Top-Down Shooter with Particles, AI, and Screen Shake"

Now that you've built your first game, it's time to level up. In the next tutorial, you'll build a complete top-down space shooter that demonstrates more advanced Limn Engine features.

What You'll Build


┌─────────────────────────────────────────────────────────────────┐

│ │

│ Score: 0 Lives: 3 Bullets: 12 │

│ │

│ 👾 (Enemy) │

│ │

│ 🟦 (Player) │

│ ↑ │

│ (WASD to move) │

│ (Space to shoot) │

│ │

│ ✨ (Particle trail behind player) │

│ │

└─────────────────────────────────────────────────────────────────┘

What You'll Learn

| Concept | Why It Matters |

|---------|----------------|

| Particle Systems | Visual effects make games feel alive |

| Enemy AI | Enemies that chase the player |

| Bullet Management | Limiting ammunition for balance |

| Screen Shake | Impact feedback |

| Invincibility Frames | Player protection after being hit |

| Game States | Lives, score, game over |

| Camera Follow | Keeping the player centered |

| UI with Tctxt | Displaying lives and bullets |

Key Functions You'll Use

| Function | Purpose |

|----------|---------|

| display.camera.follow() | Camera follows player |

| move.bound() | Keep player on screen |

| component.crashWith() | Collision detection |

| move.particles.explosion() | Explosion effects |

| move.particles.blood() | Blood effects |

| display.camera.shake() | Screen shake |

| particles.emit() | Custom particle effects |

| component.destroy() | Remove objects |

| display.stop() | End the game |

🎮 Preview the Game

Live Demo: limn-engine-doc.vercel.app/test9.html

Play the game, move with WASD or arrow keys, shoot with Space, and survive as long as possible!

🎮 Controls

WASD or arrow keys — Move the player
Space — Shoot (limited bullets, auto-recharge)
Enemies chase the player
Collect score by destroying enemies
Lose lives when enemies touch you

🔗 Resources

Resource	Link
Live Demo (Article 1)	limn-engine-doc.vercel.app/test8.html
Live Demo (Article 2)	limn-engine-doc.vercel.app/test9.html
Download Limn Engine	limn-engine-doc.vercel.app
Limn Engine Docs	limn-engine-doc.vercel.app
Beginner Guide	limn-engine-doc.vercel.app/beginner.html
Discord Community	discord.gg/ZqnUtTQb8

Draw your game into existence — one line of code at a time. 🎮🚀

🔥 Limn Engine vs Python Arcade — Which One Should You Learn?

Kehinde Owolabi — Fri, 31 Jul 2026 15:22:12 +0000

🔥 Limn Engine vs Python Arcade — Which One Should You Learn?

A Brutally Honest Comparison of Two Beginner-Friendly Game Engines

📖 Introduction

If you're a beginner looking to build 2D games, two names keep coming up: Limn Engine and Python Arcade. Both are designed for beginners. Both are free. Both make game development accessible.

But they are fundamentally different.

One runs in your browser with JavaScript. The other runs on your desktop with Python. One is a single file you drop into an HTML page. The other requires a Python environment and installation.

This comparison is about helping you choose the right engine for your goals — not about which is "better." Because "better" depends entirely on what you want to build and how you want to build it.

🎯 What Each Engine Is

Limn Engine

Limn Engine is a lightweight, zero-configuration 2D game engine for the browser. You drop a single epic.js file into an HTML page, write a few lines of JavaScript, and your game runs in any browser — no npm, no build step, no complex tooling.

The philosophy: "Common outcomes should be functions." Things you do in every game — edge detection, screen shake, particle effects — are built-in as one-line functions.

Python Arcade

Arcade is an easy-to-learn Python library for creating 2D games. It's built on top of pyglet and OpenGL, and it's designed for programmers who want to make games without learning a complex framework.

The philosophy: "Friendly API that caters to both beginners and experts." Arcade provides a clean, modern Python API with full type hints and excellent documentation.

📊 Head-to-Head Comparison

1. Setup & Installation

Aspect	Limn Engine	Python Arcade
Installation	None — just include `epic.js`	`pip install arcade`
Dependencies	Zero — no npm, no build tools	Python, pyglet, OpenGL
First Game Time	~60 seconds	~5 minutes
Environment	Browser (HTML + JS)	Python (desktop)

Verdict: Limn Engine wins here because there's literally no setup — just include a script tag. Arcade requires Python installation, which adds friction for absolute beginners.

2. Language & Learning Curve

Aspect	Limn Engine	Python Arcade
Language	JavaScript	Python
Target Audience	Absolute beginners	Beginners & educators
Learning Curve	Very low	Low-medium
Type Hints	❌ No	✅ Yes

Verdict: Both are beginner-friendly. Limn Engine's API is designed to be intuitive with one-liners for common tasks. Arcade has better type hints and Python's readability.

3. Key Features

Feature	Limn Engine	Python Arcade
Rendering	HTML5 Canvas	OpenGL
Camera Support	✅ Built-in	✅ Built-in
Physics	Basic (gravity, collision)	Simple physics engine
TileMap Support	✅ Built-in	✅ Built-in
Particle System	✅ Six presets	❌ No built-in
Sprite Animation	✅ AnimatedSprite	✅ TextureAnimationSprite
Audio	✅ Built-in	✅ Built-in
Screen Shake	✅ One-line function	❌ No built-in
Visual Editor	❌ No	❌ No

Verdict: Limn Engine has more built-in "polish" features (particles, screen shake) that Arcade lacks. Arcade has more robust physics, but Limn's feature set is better for beginners who want quick visual feedback.

4. Performance

Aspect	Limn Engine	Python Arcade
Rendering Engine	Canvas (CPU)	OpenGL (GPU)
Sprite Scaling/Rotation	Canvas-based	GPU-accelerated
Static Draw Calls	One per frame (dual-canvas)	Depends on implementation
Performance	4 FPS → 60 FPS with `perform()`	60 FPS with thousands of sprites

Verdict: Arcade has an edge for complex scenes (OpenGL acceleration). Limn Engine's dual-canvas system is optimized for static backgrounds, but it's still CPU-bound.

5. Memory Management

Aspect	Limn Engine	Python Arcade
Automatic GC	✅ JavaScript garbage collector	✅ Python garbage collector
Object Pooling	✅ Built-in (custom)	✅ Available
Memory Leak Prevention	`destroy()` method	`remove()` method
Sprite Management	Manual via arrays	SpriteList container
Resource Management	Images loaded once	Automatic resource cleanup

Verdict: Arcade's SpriteList and cleanup() methods make resource management easier. Limn Engine requires manual destroy() calls, which gives you more control but also more responsibility.

6. Platform Support

Platform	Limn Engine	Python Arcade
Web	✅ Native	❌ Not yet
Windows	❌ No	✅ Yes
Mac	❌ No	✅ Yes
Linux	❌ No	✅ Yes
Mobile	❌ No	❌ No
Raspberry Pi	❌ No	❌ No (Pi 4/5 only)

Verdict: This is the biggest difference. Limn Engine is web-native, which is great for instant deployment. Arcade runs on Windows, Mac, and Linux — three platforms instead of one.

7. Community & Documentation

Aspect	Limn Engine	Python Arcade
Documentation	✅ Comprehensive	✅ Excellent
Community	🟡 Growing	🟢 Established
Tutorials	✅ DEV.to series	✅ Real Python, official docs
License	MIT	MIT

Verdict: Both are well-documented. Arcade has a larger, more established community.

📊 Overall Scores

Category	Limn Engine	Python Arcade	Winner
Setup & Installation	10/10	8/10	🟢 Limn Engine
Language & Learning Curve	9/10	8.5/10	🟢 Limn Engine
Key Features	9/10	7.5/10	🟢 Limn Engine
Performance	8/10	9/10	🟢 Python Arcade
Memory Management	8/10	9/10	🟢 Python Arcade
Platform Support	7/10	9/10	🟢 Python Arcade
Community & Documentation	8/10	9/10	🟢 Python Arcade
Overall Average	8.4/10	8.6/10	🟢 Python Arcade (slightly)

🎯 Which One Should You Choose?

Choose Limn Engine If:

If You Want To...	Why
Build browser games	Limn Engine runs natively in the browser
Learn JavaScript	You'll write real JavaScript, not a visual language
Ship games instantly	One HTML file + `epic.js` = deploy to any web host
Avoid setup	No npm, no Python, no build tools
Understand game engines	The code is open and readable
Build quickly	One-liners for common tasks

Choose Python Arcade If:

If You Want To...	Why
Build desktop games	Arcade runs on Windows, Mac, Linux
Learn Python	Python is beginner-friendly and widely used
Work with OpenGL	GPU-accelerated graphics
Create complex games	More robust physics and sprite handling
Use established libraries	Large ecosystem of Python tools
No web deployment	You don't need to ship to the browser

🎯 The One-Line Summary

"Limn Engine is for the web — one file, one script tag, zero setup, instant deployment. Python Arcade is for the desktop — Python, pip, OpenGL, full control."

Draw your game into existence — with the engine that fits your goals. 🎮🚀

🎮 Top 10 2D JavaScript Game Engines for Beginners (Ranked)

Kehinde Owolabi — Mon, 27 Jul 2026 12:34:33 +0000

🎮 Top 10 2D JavaScript Game Engines for Beginners (Ranked)

A Brutally Honest Look at What Works and What Doesn't

📖 Introduction

Let's be real: most "beginner-friendly" game engines are either too simple to build anything useful or too complex to actually learn from. The game development community loves to recommend the same few engines over and over, but they rarely tell you the downsides.

This list is different. We're ranking the top 10 2D JavaScript game engines for beginners — but we're also telling you what's wrong with each one.

No marketing fluff. Just honesty.

🎯 What Makes an Engine "Beginner-Friendly"?

Factor	Why It Matters
Easy setup	No complex build tools or configuration files
Good documentation	Clear explanations and examples
Active community	Help when you get stuck
Forgiving API	Not too many ways to do the same thing
Quick results	See something on screen fast
No hidden costs	Free and open-source

#10 — Pixi.js

Rating: 7/10

Best For: High-performance 2D rendering

What It Is

Pixi.js is a 2D rendering library — not a full game engine. It provides high-speed 2D rendering using WebGL with Canvas fallback. It's used by Disney, Facebook, and Adobe.

Why Is It Below Others?

Pixi.js is at the bottom because it's not a game engine. It's a rendering library. If you want to build a game, you'll need to build everything else yourself — physics, input handling, audio, game loop, scene management. This is overwhelming for beginners. The steep learning curve and the fact that you have to piece together multiple libraries make it the least beginner-friendly option on this list.

What Works

Blazing fast — One of the fastest 2D rendering engines available
Used by big companies — Proven in production at scale
Excellent rendering — WebGL-accelerated with fallback
Great API — Well-designed and easy to use
Strong community — Large user base with many resources

What Doesn't Work

1. Not a Game Engine

Pixi.js is a rendering library, not a game engine. It doesn't include physics, input handling, audio, or a game loop. You'll need to build these systems yourself.

2. Steep Learning Curve

Because you have to build so much yourself, the learning curve is steep. You'll need to understand rendering, game loops, and system design.

3. More Code to Write

Everything takes more code. Want to handle input? You'll need to write your own system. Want physics? You'll need to integrate a physics library.

4. Fragmented Ecosystem

There's no single "right way" to build a game with Pixi.js. You'll need to piece together different libraries and frameworks.

5. Overkill for Simple Games

If you're building a simple game, Pixi.js is overkill. You'll spend more time setting up infrastructure than building your game.

Who Should Use It

✅ Developers who want full control
✅ Developers who already have their own game logic
✅ Developers building performance-critical applications

Who Should Avoid It

❌ Absolute beginners
❌ Developers who want a complete engine
❌ Anyone building a simple game

#9 — PlayCanvas (2D Mode)

Rating: 6.5/10

Best For: Teams building 2D games in the browser with visual editing

What It Is

PlayCanvas is a web-based game engine that, while primarily known for 3D, can also be used for 2D game development through its 2D sprite system. It features a visual editor, real-time collaboration, and WebGL rendering.

Why Is It Below Others?

PlayCanvas is a 3D-first engine. The 2D features feel like an afterthought. The editor is cluttered with 3D-specific options that beginners don't need. The free tier is limited, and the cloud dependence means you can't work offline. For pure 2D game development, there are better, more focused options.

What Works

Visual editor — Browser-based editor with real-time preview
Collaboration — Multiple people can work on the same project simultaneously
No software to install — Everything runs in the browser
Good for 2D — Includes sprites, tilemaps, and 2D physics
Export options — Export to web, mobile, and desktop
Asset management — Built-in asset pipeline

What Doesn't Work

1. 3D-First Design

PlayCanvas is built for 3D first. The 2D features, while functional, feel like an afterthought. The editor is cluttered with 3D-specific options that beginners don't need.

2. Pricing

PlayCanvas has a free tier with limitations. For advanced features or private projects, you'll need to pay. This can be a dealbreaker for beginners.

3. Cloud Dependence

Everything is cloud-based. If you lose internet access or the service goes down, you can't work. This also means your project files are stored on their servers.

4. Limited Free Features

The free tier is limited in terms of storage, private projects, and features. To unlock full capabilities, you'll need to subscribe.

5. Learning Curve

The 3D-first design makes the learning curve steeper than it needs to be for 2D development. You'll spend time filtering out 3D features you don't need.

6. 2D Physics is Basic

The 2D physics support (based on ammo.js) is functional but not as polished as dedicated 2D engines.

Who Should Use It

✅ Beginners interested in both 2D and 3D
✅ Teams working together remotely
✅ Developers who want a cloud-based workflow
✅ Developers who like visual editing

Who Should Avoid It

❌ Developers building pure 2D games
❌ Developers who prefer offline development
❌ Anyone on a tight budget
❌ Beginners who want a focused 2D experience

#8 — MelonJS

Rating: 6.5/10

Best For: Building lightweight games quickly

What It Is

MelonJS is a lightweight, open-source 2D game engine that tries to be simple and fast. It includes a basic set of features: sprite handling, audio, input, and a simple scene system.

Why Is It Below Others?

MelonJS is lightweight, but that comes at a cost. The engine lacks many features that you'd expect from a modern engine. Physics is basic. There's no built-in particle system. Animation support is minimal. The documentation is outdated, and the community is small. For a beginner, this means more time solving problems alone.

What Works

Extremely lightweight — The core engine is small and fast
Simple API — The code is straightforward and easy to understand
No build tools needed — Just include the script and start coding
Good for mobile — Optimized for performance on mobile devices
Clean codebase — The source code is well-organized and readable

What Doesn't Work

1. Limited Features

MelonJS lacks many features that you'd expect from a modern engine. Physics is basic at best. There's no built-in particle system, and animation support is minimal. You'll spend a lot of time building systems that other engines provide out of the box.

2. Small Community

The community is significantly smaller than Phaser or Godot. Finding tutorials, answers, or plugins is challenging. For a beginner, this means more time solving problems alone.

3. Outdated Documentation

The official documentation is sparse and often outdated. Many examples no longer work with the latest version. This can be incredibly frustrating when you're trying to learn.

4. Dated Design

The design philosophy feels stuck in the past. While other engines have evolved, MelonJS has remained mostly static. It works, but it doesn't feel modern.

5. Limited Platform Support

Export options are limited. You're mostly stuck with the web unless you want to build your own export pipeline.

Who Should Use It

✅ Developers who want a lightweight, fast engine
✅ Beginners building simple games
✅ Developers comfortable with minimal features

Who Should Avoid It

❌ Beginners who want a full-featured engine
❌ Developers building complex games
❌ Anyone who needs modern features like particles or advanced physics

#7 — CT.js

Rating: 6/10

Best For: Beginners who want a visual editor but still want to code

What It Is

CT.js is a 2D game engine that tries to be everything: visual editor, code editor, asset manager, and export tool all in one. It's built on Pixi.js for rendering and includes a visual editor that's somewhere between Construct and a code editor.

Why Is It Below Others?

CT.js tries to do too much and does none of it well. The visual editor is useful for placing objects, but anything beyond basic positioning requires writing code. The documentation is limited, and the community is small. The learning curve is confusing because you're mixing visual and code approaches.

What Works

Visual editor — You can see your game objects and levels laid out visually
Built-in tools — Asset manager, sprite editor, sound manager all included
Export options — Export to web, Windows, Mac, and Linux
One download — Everything you need in one package
Beginner-friendly UI — The interface is cleaner than most visual editors

What Doesn't Work

1. The Visual Editor is Half-Baked

The visual editor is useful for placing objects, but anything beyond basic positioning requires writing code. This creates a frustrating split: you're using a visual tool but still need to understand the code. It's the worst of both worlds.

2. Limited Documentation

The documentation covers the basics but falls short for advanced features. When you get stuck, you'll find yourself digging through forum posts and outdated examples.

3. Small Community

CT.js has a fraction of the community that Phaser or Godot has. Finding help, tutorials, or plugins is significantly harder. For a beginner, this means more time stuck and less time building.

4. Performance Issues

Because CT.js tries to do everything, it can be slower and heavier than more focused engines. Larger projects may experience lag.

5. Learning Curve

The visual editor makes it seem easier than it is, but you'll still need to learn JavaScript. The mix of visual and code creates a confusing learning experience.

Who Should Use It

✅ Beginners who want a visual editor but aren't afraid of code
✅ Developers building small to medium 2D games
✅ Beginners who want to export to desktop

Who Should Avoid It

❌ Absolute beginners with no coding experience
❌ Developers building large, complex games
❌ Anyone who just wants to code without a visual editor

#6 — GDevelop

Rating: 7/10

Best For: No-code game development

What It Is

GDevelop is an open-source game engine that allows you to create games without writing code. It features a visual event system and supports both 2D and 3D game development.

Why Is It Below Others?

GDevelop is powerful for no-code development, but you'll hit a ceiling quickly. Complex game logic can be difficult or impossible to implement without code. The performance of games built with GDevelop can also be slower than code-based engines.

What Works

No code required — Build games with visual events
Free and open-source — No licensing fees, no hidden costs
Visual editor — See your game come together in real-time
Export options — Web, mobile, and desktop
Good for educators — Great for teaching game design

What Doesn't Work

1. Limited Flexibility

The visual event system is powerful but limited. Complex game logic can be difficult or impossible to implement without code. You'll hit a ceiling quickly.

2. Performance Issues

Games built with GDevelop can be slower than code-based engines. This becomes noticeable with larger or more complex games.

3. Less Control

You're limited to what the visual editor allows. You can't easily extend the engine or add custom features.

4. Smaller Community

GDevelop's community is growing but still small. Finding help, tutorials, or examples can be challenging.

5. Learning Curve

The visual event system is intuitive but still has a learning curve. Understanding how events work and connect takes time.

Who Should Use It

✅ Absolute beginners with no coding experience
✅ Educators teaching game design
✅ Quick prototyping and game jams

Who Should Avoid It

❌ Developers who want to learn coding
❌ Developers building complex games
❌ Anyone who needs full control

#5 — Construct

Rating: 7.5/10

Best For: Professional no-code game development

What It Is

Construct is a visual game development tool with a drag-and-drop interface and powerful event system. It's one of the most popular no-code engines available.

Why Is It Below Others?

Construct is a powerful no-code tool, but it's not free. The free version is limited, and the full features require a paid license. For beginners, this can be a significant barrier. Additionally, because you're not writing code, you're not learning programming — which is a trade-off.

What Works

Powerful event system — Complex logic without code
Visual editor — Intuitive and well-designed
Great documentation — Well-maintained and comprehensive
Strong community — Large user base with many resources
Professional features — Export to multiple platforms

What Doesn't Work

1. Pricing

Construct is freemium. The free version is limited, and the full features require a paid license. For beginners, this can be a significant barrier.

2. Limited Flexibility

Like GDevelop, you're limited to what the visual editor allows. Complex game logic can be difficult or impossible to implement.

3. Performance Issues

Performance can be an issue for larger or more complex games. The abstraction layer adds overhead.

4. Less Learning Value

Because you're not writing code, you're not learning programming. This is a trade-off: you can build games faster but won't learn JavaScript.

5. Proprietary Format

Your game files are in a proprietary format. If you ever want to switch engines, you'll have to start over.

Who Should Use It

✅ Absolute beginners
✅ Educators and students
✅ Prototyping and game jams
✅ Non-technical game designers

Who Should Avoid It

❌ Developers who want to learn programming
❌ Developers building complex games
❌ Anyone who wants full control

#4 — Kaboom.js

Rating: 8/10

Best For: Game jams and quick prototypes

What It Is

Kaboom.js is a lightweight JavaScript game library with a playful, modern API. It's designed for fast prototyping and game jams.

Why Is It Below Others?

Kaboom.js is intentionally minimal. It lacks many features of a full engine: physics, particles, scene management, and audio are all limited. It doesn't scale well to larger projects. The simple API that makes it great for prototypes becomes limiting for complex games.

What Works

Minimal boilerplate — Get started with 5 lines of code
Playful API — Fun and intuitive to use
No setup required — Just include the CDN script
Good for learning — Clear, readable code
Great for game jams — Fast results

What Doesn't Work

1. Limited Features

Kaboom.js is intentionally minimal. It lacks many features of a full engine: physics, particles, scene management, and audio are all limited.

2. Not for Large Projects

Kaboom.js doesn't scale well to larger projects. The simple API that makes it great for prototypes becomes limiting for complex games.

3. Smaller Community

Kaboom.js has a smaller community than Phaser. Finding help, tutorials, and examples is harder.

4. Less Documentation

The documentation covers the basics but is sparse for advanced features.

5. Opinionated Design

Kaboom.js has a very specific way of doing things. This is great when it matches your style, but frustrating when you want to do something different.

Who Should Use It

✅ Beginners learning core game logic
✅ Game jam participants
✅ Quick prototypes
✅ Developers who like minimal APIs

Who Should Avoid It

❌ Developers building large projects
❌ Anyone who needs a full-featured engine
❌ Developers building commercial games

#3 — Limn Engine

Rating: 9/10

Best For: Absolute beginners who want to understand game engines

What It Is

Limn Engine is a lightweight, zero-configuration 2D game engine built on HTML5 Canvas. It's designed for beginners who want to learn game development without fighting complex build tools.

Why Is It #3?

Limn Engine is the best choice for learning how game engines work. The zero-configuration setup means you can start coding immediately. The intuitive API is predictable and easy to remember. The four progressive skill levels give you a clear learning path. The dual-canvas rendering system is built for performance, even on low-end hardware. And it's completely free with no hidden costs.

The only downsides are the smaller community (compared to Phaser) and the lack of a visual editor. But for a beginner who wants to learn, these are actually features — you learn more by writing code.

What Works

1. Zero Configuration

<script src="epic.js"></script>
<script>
const display = new Display();
display.start(800, 600);
// Start coding!
</script>

No npm. No build tools. No configuration. Just one file. Open it in a browser and start building.

2. Intuitive API

The API is designed to be predictable and easy to remember:

move.bound(player);        // Keeps player on screen
display.camera.shake(5,5); // Screen shake
move.particles.explosion(particles, x, y, 30); // Explosion effect

Every function is designed to do exactly what you expect. You'll spend less time reading documentation and more time building.

3. Clear Learning Path

Limn Engine is structured into four progressive skill levels:

Level	What You Learn
Beginner	Shapes, keys, collision
Intermediate	Physics, camera, tilemaps
Advanced	Particles, scenes, effects
10x Developer	Engine internals, performance

Each level builds on the previous one. You'll always know what to learn next.

4. Complete Examples

Every feature has working examples that you can try immediately. The examples are simple, self-contained, and easy to understand.

5. Built-in Performance

The dual-canvas rendering system (fake canvas + main canvas) is designed for performance, even on low-end hardware.

6. Active Development

Limn Engine is actively maintained and improved. The developer is committed to making it better.

7. No Hidden Costs

Limn Engine is completely free and open-source (MIT license). No paid features, no "pro" versions.

What Doesn't Work

1. No Visual Editor

Everything is code-based. If you want a visual editor, look elsewhere. This is deliberate — Limn Engine is designed for learning through code.

2. Smaller Community

Limn Engine has a smaller community than Phaser. This means fewer tutorials and fewer people to ask for help. However, the documentation is comprehensive.

3. Web Only

Limn Engine is designed for the web. There's no native mobile or desktop export.

4. Limited Physics

The physics system is basic — gravity and collisions. If you need advanced physics, you'll need to build them yourself.

Who Should Use It

✅ Absolute beginners who want to learn game programming
✅ Developers who prefer writing code over using visual tools
✅ Students who want full control over their codebase
✅ Anyone building a simple game or prototype
✅ Developers who want a lightweight, fast engine

Who Should Avoid It

❌ Developers who want a visual editor
❌ Developers building complex commercial games · ❌ Anyone who needs native mobile/desktop export

#2 — Phaser

Rating: 8.5/10

Best For: Building complete 2D games quickly

What It Is

Phaser is one of the most popular JavaScript game frameworks for building 2D games. It includes everything you need: physics, input, animation, sound, and a scene system.

Why Is It #2?

Phaser is the most popular JavaScript game engine for a reason. It's feature-rich, well-documented, and has a massive community. You can build complete 2D games quickly without having to piece together different libraries. The ecosystem is huge — there are thousands of tutorials, examples, and plugins available.

The downsides are the steeper learning curve and the complex scene system. But once you understand it, Phaser is incredibly powerful.

What Works

Feature-rich — Everything you need is included
Large community — Thousands of tutorials and examples
Good documentation — Comprehensive and well-maintained
Well-established — Proven in many production games
Active development — Regular updates and improvements

What Doesn't Work

1. Steep Learning Curve

Phaser has a lot of features, which means there's a lot to learn. The learning curve is steeper than simpler engines.

2. Complex Scenes

The scene system is powerful but complex. Understanding lifecycle methods and scene management takes time.

3. Opinionated Architecture

Phaser has a specific way of doing things. While this is helpful once you understand it, it can be frustrating when you want to do something different.

4. Performance Issues

Performance can be an issue with many objects. While Phaser is fast, it's not as fast as more specialized rendering engines.

5. File Size

Phaser's bundle size is larger than simpler engines. While this is expected, it can be an issue for projects with strict size constraints.

Who Should Use It

✅ Beginners who want a complete engine
✅ Developers building commercial 2D games
✅ Anyone who wants a well-established ecosystem
✅ Teams building larger projects

Who Should Avoid It

❌ Absolute beginners who want the simplest possible start
❌ Developers building high-performance applications
❌ Anyone who wants a minimal API

#1 — Godot (Web Build)

Rating: 9.5/10

Best For: Professional 2D game development

What It Is

Godot is a full-featured, open-source game engine with excellent 2D support. The Web build allows you to export games to HTML5. It's the only engine on this list that's truly professional-grade while still being beginner-friendly.

Why Is It #1?

Godot is the most complete engine on this list. It has everything you need: a powerful visual editor, great 2D support, a beginner-friendly scripting language, and export options for web, mobile, and desktop. It's free and open-source with no licensing fees.

The learning curve is steeper than simpler engines, but once you understand the fundamentals, it becomes intuitive. It's the best choice for beginners who want to build professional games.

What Works

Everything included — A complete, professional-grade engine
Visual editor — Powerful and intuitive
Great 2D support — Built specifically for 2D games
Free and open-source — No licensing fees
Scripting — GDScript is designed for beginners
Strong community — Growing rapidly
Export options — Web, mobile, desktop, and consoles

What Doesn't Work

1. Desktop-First

The editor is a desktop application. You'll need to install it on your computer. The web version is only for exporting, not editing.

2. Steep Initial Learning Curve

Godot has more features than any other engine on this list. The initial learning curve is steeper than simpler engines. However, once you understand the fundamentals, it becomes intuitive.

3. GDScript Syntax

GDScript is beginner-friendly but different from JavaScript. If you plan to use JavaScript in other projects, learning a separate language might be a downside.

4. Performance Can Be an Issue

For highly complex or performance-critical projects, Godot may not be as fast as more specialized engines. However, for most 2D games, it's more than sufficient.

5. Smaller Community Than Unity

Godot's community is growing but still smaller than Unity's. However, there are many tutorials and resources available.

Who Should Use It

✅ Beginners planning to build professional games
✅ Developers who want a complete, full-featured engine
✅ Anyone building 2D games for multiple platforms
✅ Developers who want a free, open-source alternative to Unity

Who Should Avoid It

❌ Absolute beginners who want the simplest possible start
❌ Developers who want to learn JavaScript specifically
❌ Anyone who prefers a code-only approach

📊 Comparison Table

Engine	Rating	Best For	Learning Curve	License	Visual Editor
Godot (Web Build)	9.5/10	Professional 2D games	Low-Medium	MIT	✅ Full
Phaser	8.5/10	Complete 2D games	Medium	MIT	❌ None
Limn Engine	9/10	Learning fundamentals	Very Low	MIT	❌ None
Kaboom.js	8/10	Game jams & prototypes	Very Low	MIT	❌ None
Construct	7.5/10	No-code development	Very Low	Freemium	✅ Full
GDevelop	7/10	No-code development	Very Low	MIT	✅ Full
CT.js	6/10	Visual editor + code	Medium	MIT	✅ Partial
MelonJS	6.5/10	Lightweight 2D games	Low-Medium	MIT	❌ None
PlayCanvas (2D Mode)	6.5/10	Collaborative web-based 2D games	Medium	MIT	✅ Full
Pixi.js	7/10	High-performance rendering	Medium	MIT	❌ None

🎯 The One-Line Summary

"If you want to learn how game engines work, start with Limn Engine. If you want to build complete 2D games fast, choose Phaser. If you want to build professional games, choose Godot."

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

🧩 Understanding Components and Their Children in Limn Engine

Kehinde Owolabi — Sat, 25 Jul 2026 04:55:24 +0000

🧩 Understanding Components and Their Children in Limn Engine

A Complete Guide to Tile, Text, Sprite, AnimatedSprite, and Tctxt

📖 Introduction

The Component class is the foundation of every Limn Engine game. Everything you see on screen — players, enemies, coins, walls, text, sprites — is a Component or a child of Component.

But Component isn't just one thing. It has several specialized children that handle specific tasks:

Child Class	Purpose
Tile	Individual tiles in a tilemap
Tctxt	Styled text with backgrounds
Sprite	Animated sprites from sprite sheets
AnimatedSprite	Multiple animation states
Particle	Individual particles (used internally)

In this guide, we'll cover all of them — what they are, when to use them, and how they work.

🎯 What We'll Cover

What is a Component?
The Tile class — building blocks of levels
The Tctxt class — styled text
The Sprite class — animated characters
The AnimatedSprite class — multiple animations
The Particle class — visual effects
Comparison table
Common mistakes

🧩 Part 1: What Is a Component?

A Component is the most basic building block in Limn Engine. Every visible object in your game is a Component.

The Basics

// A basic Component
const player = new Component(40, 40, "#5b8cff", 400, 300, "rect");
display.add(player);

What this does:

new Component(40, 40, "#5b8cff", 400, 300, "rect") — Creates a 40x40 blue rectangle at position (400, 300).
display.add(player); — Adds it to the game world.

Component Properties

Property	Type	Purpose
`x, y`	number	Position
`width, height`	number	Size
`color`	string	Fill color
`speedX, speedY`	number	Velocity
`angle`	number	Rotation
`physics`	boolean	Enable gravity
`gravity`	number	Gravity strength

Component Methods

Method	Purpose
`move()`	Move based on speedX/speedY
`crashWith()`	Collision detection
`clicked()`	Mouse click detection
`setImage()`	Load an image
`setColor()`	Change color
`destroy()`	Remove from engine

🧩 Part 2: The Tile Class — Building Blocks of Levels

Tile is a specialized Component used in tilemaps. Each tile represents a single cell in your level grid.

How Tiles Work

// Define a tile
const wallTile = new Component(64, 64, "#654321", 0, 0, "rect");

// In a tilemap, tiles are created automatically
display.tile = [
    new Component(64, 64, "#1a3a1a", 0, 0), // 1 = grass
    new Component(64, 64, "#2244aa", 0, 0), // 2 = water
    new Component(64, 64, "#555555", 0, 0), // 3 = stone
];

display.map = [
    [1,1,1,2,2,1,1,3,3,1],
    [1,0,0,0,0,0,0,0,0,1],
    [1,0,2,0,0,0,0,2,0,1],
];
display.tileMap();
display.tileFace.show();

What this does:

display.tile — An array of tile templates.
display.map — A 2D array where each number refers to a tile template.
display.tileMap(); — Creates the tilemap object.
display.tileFace.show(); — Renders all tiles to the fake canvas.

Tile vs Component

Aspect	Component	Tile
Purpose	General game objects	Individual tiles in a tilemap
Creation	Manual	Automatic from a map
Position	Set manually	Calculated from grid position
Use case	Players, enemies, items	Walls, floors, decorations

🧩 Part 3: The Tctxt Class — Styled Text

Tctxt is a specialized Component for displaying styled text with backgrounds and padding.

The Basics

const scoreText = new Tctxt("24px", "Arial", "white", 20, 50);
scoreText.setText("Score: 0");
display.add(scoreText);

What this does:

new Tctxt("24px", "Arial", "white", 20, 50) — Creates text at (20, 50) with 24px Arial white text.
scoreText.setText("Score: 0"); — Sets the text content.
display.add(scoreText); — Adds it to the game.

Full Constructor

const label = new Tctxt(
    "20px",                 // size
    "Arial",                // font family
    "white",                // color
    100, 200,               // x, y
    "center",               // align: "left", "center", "right"
    false,                  // stroke: false = fill, true = outline
    "alphabetic",           // baseline: "top", "middle", "bottom"
    "rgba(0,0,0,0.5)",      // background color (null = none)
    10, 5                   // paddingX, paddingY
);

Tctxt vs Component Text

Aspect	Component (text)	Tctxt
Background	❌ None	✅ Yes
Padding	❌ None	✅ Yes
Alignment	⚠️ Limited	✅ Full
Stroke	❌ None	✅ Yes
Baseline	❌ None	✅ Yes
Ease of use	⚠️ Basic	✅ Advanced

🧩 Part 4: The Sprite Class — Animated Characters

Sprite extends Component to handle animated sprite sheets.

The Basics

const hero = new Sprite("hero.png", 64, 64, 4, 10, 400, 300);
display.add(hero);

What this does:

new Sprite("hero.png", 64, 64, 4, 10, 400, 300) — Creates a sprite at (400, 300) from a sprite sheet with 4 frames, each 64x64, at speed 10.

How a Sprite Works

┌─────────────────────────────────────────────────────────────────┐
│                                                                 │
│   Sprite Sheet: "hero.png"                                     │
│   ┌──────────┬──────────┬──────────┬──────────┐               │
│   │ Frame 0  │ Frame 1  │ Frame 2  │ Frame 3  │               │
│   │ 64x64    │ 64x64    │ 64x64    │ 64x64    │               │
│   └──────────┴──────────┴──────────┴──────────┘               │
│                                                                 │
│   Sprite draws each frame in sequence:                         │
│   Frame 0 → Frame 1 → Frame 2 → Frame 3 → Frame 0...          │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘

Sprite Methods

Method	Purpose
`update()`	Advance to the next frame
`draw(ctx, x, y)`	Draw the current frame
`play()`	Start/continue animation
`stop()`	Pause animation
`reset()`	Reset to frame 0

Sprite vs Component

Aspect	Component	Sprite
Display	A single color/image	Multiple frames from a sprite sheet
Animation	❌ None	✅ Yes
Frame control	❌ None	✅ Full control
Use case	Simple objects	Characters, animated objects

🧩 Part 5: The AnimatedSprite Class — Multiple Animations

AnimatedSprite extends Sprite to support multiple animation states.

The Basics

const hero = new AnimatedSprite("hero.png", 64, 64, 400, 300);

// Define animations
hero.addAnimation("idle",   0,  3, 10, true);  // frames 0-3, loops
hero.addAnimation("run",    4, 11,  5, true);  // frames 4-11, loops
hero.addAnimation("jump",  12, 15,  4, false); // frames 12-15, one-shot
hero.addAnimation("attack",16, 19,  3, false); // frames 16-19, one-shot

display.add(hero);

function update() {
    if (isMoving) {
        hero.playAnimation("run");
    } else {
        hero.playAnimation("idle");
    }
    hero.updateAnimation();
}

How Animations Work

┌─────────────────────────────────────────────────────────────────┐
│                                                                 │
│   Sprite Sheet with multiple animations:                       │
│                                                                 │
│   ┌──────────┬──────────┬──────────┬──────────┬──────────┐   │
│   │ Idle 0   │ Idle 1   │ Idle 2   │ Idle 3   │ Run 0    │   │
│   ├──────────┼──────────┼──────────┼──────────┼──────────┤   │
│   │ Run 1    │ Run 2    │ Run 3    │ Run 4    │ Run 5    │   │
│   ├──────────┼──────────┼──────────┼──────────┼──────────┤   │
│   │ Run 6    │ Jump 0   │ Jump 1   │ Jump 2   │ Jump 3   │   │
│   ├──────────┼──────────┼──────────┼──────────┼──────────┤   │
│   │ Attack 0 │ Attack 1 │ Attack 2 │ Attack 3 │          │   │
│   └──────────┴──────────┴──────────┴──────────┴──────────┘   │
│                                                                 │
│   Animations:                                                   │
│   - idle: frames 0-3 (loops)                                   │
│   - run: frames 4-10 (loops)                                   │
│   - jump: frames 12-15 (one-shot)                              │
│   - attack: frames 16-19 (one-shot)                            │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘

AnimatedSprite Methods

Method	Purpose
`addAnimation(name, start, end, speed, loop)`	Define an animation clip
`playAnimation(name)`	Switch to a different animation
`updateAnimation()`	Advance the frame counter
`faceLeft()`	Flip the sprite horizontally
`faceRight()`	Reset the flip

The `playAnimation` Guard

playAnimation(name) {
    // ⚡ CRITICAL GUARD: Prevents resetting if already playing
    if (this.currentAnim === name) return;

    // Only reset if the animation name changed
    this.currentAnim = name;
    this.currentFrame = anim.start;
    this.frameSpeed = anim.speed;
    this.loop = anim.loop;
}

Sprite vs AnimatedSprite

Aspect	Sprite	AnimatedSprite
Animations	One continuous animation	Multiple named clips
State management	❌ None	✅ Built-in
Switching	❌ Manual	✅ `playAnimation()`
Use case	Simple animations	Characters with multiple states

🧩 Part 6: The Particle Class — Visual Effects

Particle is a specialized Component used in the ParticleSystem.

How Particles Work

// Particles are created by the ParticleSystem
const ps = new ParticleSystem(display);

// Single particle
ps.emit(x, y, { 
    color: "#ff6600", 
    life: 30, 
    gravity: 0.2 
});

// Multiple particles
ps.burst(x, y, 20, { 
    color: "#ff6600", 
    life: 30, 
    randomSpeed: 5 
});

What this does:

ps.emit() — Creates a single particle with custom options.
ps.burst() — Creates multiple particles at once.

Particle Properties

Property	Purpose
`life`	Frames until death
`gravity`	Downward acceleration
`friction`	Speed multiplier per frame
`alpha`	Starting opacity
`alphaFade`	Fade-out rate
`scale`	Starting size
`scaleFade`	Shrink rate

📊 Comparison Table

Class	Parent	Purpose	Use Case
Component	—	Base class for all objects	Players, enemies, items
Tile	Component	Individual tiles in a tilemap	Walls, floors, decorations
Tctxt	Component	Styled text with backgrounds	Score, menus, labels
Sprite	Component	Animated sprites from sprite sheets	Characters, animated objects
AnimatedSprite	Sprite	Multiple animation states	Characters with idle/run/jump
Particle	Component	Visual effects	Explosions, sparkles, blood

⚠️ Common Mistakes

Mistake	Why It's Wrong	How to Fix
Using Component for text	No background or alignment	Use `Tctxt` instead
Using Sprite for static images	Overkill for one frame	Use `Component` with `setImage()`
Not calling `updateAnimation()`	Sprite doesn't animate	Call it every frame
Forgetting the `playAnimation` guard	Animation resets every frame	It's built-in, don't override it

🎯 The One-Line Summary

"Component is the foundation — Tile builds levels, Tctxt displays text, Sprite animates characters, and AnimatedSprite manages multiple states."

Draw your game into existence — one component at a time. 🧩🚀

🔗 Resources

Resource	Link
Limn Engine Docs	limn-engine-doc.vercel.app
API Reference	limn-engine-doc.vercel.app/reference.html
Beginner Guide	limn-engine-doc.vercel.app/beginner.html

# 🎥 Mastering the Camera System — Part 2: The Fake Camera and When NOT to Sync

Kehinde Owolabi — Thu, 23 Jul 2026 23:43:23 +0000

🎥 Mastering the Camera System — Part 2: The Fake Camera and When NOT to Sync

Everything You Need to Know About the Fake Camera and Why Syncing Can Ruin Your Performance

📖 Introduction

In Part 1, we covered the basics of camera follow, shake, and zoom. But there's another camera in Limn Engine that most developers don't fully understand — the fake camera.

The fake camera is part of Limn Engine's dual-canvas rendering system. It controls the background layer (tilemaps, static decorations, and background images). Understanding when and how to use it is critical for performance.

The most common mistake? Syncing the fake camera with the main camera. In this article, we'll explain why that's a problem and how to fix it.

🎯 What We'll Cover

What is the fake camera?
How the dual-canvas system works
The problem with syncing cameras
When to sync (and when NOT to)
The correct approach: resize, don't sync
Practical examples
Common mistakes and how to avoid them

🎮 What Is the Fake Camera?

The fake camera is attached to the fake canvas — an offscreen buffer that caches static content.

Canvas	Purpose	Camera
Main canvas	Dynamic content (player, enemies, particles)	`display.camera`
Fake canvas	Static content (tilemaps, backgrounds, decorations)	`fake.camera`

The fake camera controls how the static background is rendered. It's part of the dual-canvas pipeline that gives Limn Engine its performance.

🏗️ How the Dual-Canvas System Works

Before we dive into the fake camera, let's understand how the dual-canvas system works.

┌─────────────────────────────────────────────────────────────────┐
│                                                                 │
│   ┌─────────────────────────────────────────────────────────┐   │
│   │                    MAIN CANVAS                          │   │
│   │                                                         │   │
│   │   Dynamic content: player, enemies, particles          │   │
│   │   Camera: display.camera                               │   │
│   │                                                         │   │
│   └─────────────────────────────────────────────────────────┘   │
│                                                                 │
│   ┌─────────────────────────────────────────────────────────┐   │
│   │                    FAKE CANVAS                          │   │
│   │                    (offscreen)                         │   │
│   │                                                         │   │
│   │   Static content: tilemaps, backgrounds, decorations   │   │
│   │   Camera: fake.camera                                  │   │
│   │                                                         │   │
│   └─────────────────────────────────────────────────────────┘   │
│                                                                 │
│   Both cameras are independent!                               │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘

What's happening here:

The main canvas is what you see on screen. It contains everything that moves — the player, enemies, bullets, and particles. Its camera is called display.camera.
The fake canvas is hidden. It's an offscreen buffer that contains everything that doesn't move — tilemaps, backgrounds, and static decorations. Its camera is called fake.camera.
The two canvases are rendered separately and combined on screen. The fake canvas is drawn first (as the background), then the main canvas is drawn on top of it.
Each canvas has its own independent camera. The fake camera is completely separate from the main camera.

The important thing to understand: The fake canvas is designed to be drawn once and then reused. Moving it every frame defeats its purpose.

🔴 The Problem: Syncing Cameras

Many developers assume they need to sync the fake camera with the main camera. Let's look at the wrong way first.

❌ The Wrong Way: Syncing Cameras

function update(dt) {
    // Step 1: Make the main camera follow the player
    display.camera.follow(player, true);

    // Step 2: Copy the main camera's position to the fake camera
    fake.camera.x = display.camera.x;   // ❌ This is a mistake!
    fake.camera.y = display.camera.y;   // ❌ This is a mistake!
}

What's happening here:

The main camera follows the player. This is correct.
We copy the main camera's position to the fake camera. This is the mistake.
Now the fake camera moves with the main camera every frame.

Why This Is a Problem

Issue	What Happens	Why It's Bad
Defeats caching	The fake canvas is supposed to be static. Moving it every frame breaks the cache.	The fake canvas was designed to be drawn once and reused. Moving it forces it to be redrawn every frame.
Performance hit	Instead of one draw call for the whole background, the engine has to re-render everything.	The whole point of the fake canvas is to reduce draw calls. Syncing increases them back to normal levels.
Wastes CPU	The fake canvas was designed to be drawn once. Syncing forces it to be redrawn every frame.	This defeats the performance benefits of the dual-canvas system.
No benefit	The fake canvas can be sized to the world, so moving it is unnecessary.	There's a better way that doesn't hurt performance.

What You Should Do Instead

Instead of moving the fake canvas, resize it to match the world size. Let's look at the correct way.

✅ The Correct Approach: Resize, Don't Sync

Step 1: Set the World Size

Here, you're going to define how big your game world is. This tells the engine the boundaries of your world so the camera knows how far it can move.

// Define how big your game world is
display.camera.worldWidth = 2000;
display.camera.worldHeight = 2000;

What this code does:

display.camera.worldWidth = 2000; — Sets the width of your game world to 2000 pixels. The camera will never show anything beyond this width.
display.camera.worldHeight = 2000; — Sets the height of your game world to 2000 pixels. The camera will never show anything beyond this height.

Why it matters: The world size determines how big the fake canvas needs to be. If you have a world that's 2000x2000, the fake canvas needs to be 2000x2000 to hold it all. If you don't set this, the camera defaults to 1000x1000, and anything outside that will be cut off.

When to use this: At the very beginning of your game setup, before you render anything to the fake canvas.

Step 2: Resize the Fake Canvas

Now you're going to make the fake canvas exactly the size of your entire game world. This way, it can hold the whole map without needing to move.

// Resize the fake canvas to match the world
fake.canvas.width = display.camera.worldWidth;   // Now 2000
fake.canvas.height = display.camera.worldHeight; // Now 2000

What this code does:

fake.canvas.width = display.camera.worldWidth; — Sets the fake canvas width to match your world width (2000 pixels).
fake.canvas.height = display.camera.worldHeight; — Sets the fake canvas height to match your world height (2000 pixels).

Why it matters: Because the fake canvas is now the full world size, it contains everything. The main camera just shows a window into it. The fake canvas never needs to move. If you don't do this, the fake canvas will be smaller than your world, and parts of your background will be cut off.

When to use this: Right after setting display.camera.worldWidth/Height, before rendering anything to the fake canvas.

Step 3: Render Static Content Once

Now you're going to draw all your static content — tilemaps, backgrounds, decorations — onto the fake canvas. This happens only once.

// Render the tilemap to the fake canvas
display.tileMap();
display.tileFace.show();

// Add static decorations to the fake canvas
fake.add(tree);
fake.add(decoration);

What this code does:

display.tileMap(); — Creates the tilemap object that will hold your level data.
display.tileFace.show(); — Renders all the tiles onto the fake canvas. This draws your entire level.
fake.add(tree); — Adds a tree decoration to the fake canvas.
fake.add(decoration); — Adds another decoration to the fake canvas.

Why it matters: After this, the fake canvas contains a complete image of the entire static world. It never needs to be redrawn. If you don't do this, your static content will be drawn on the main canvas, which means it will be redrawn every frame — killing performance.

When to use this: After resizing the fake canvas, before the game loop starts.

Step 4: Update Only the Main Camera

In your game loop, you only update the main camera. The fake canvas stays exactly where it is — it contains the entire world.

function update(dt) {
    // Main camera follows the player
    display.camera.follow(player, true);

    // ✅ NO fake.camera sync needed!
    // The fake canvas is already the full world size
}

What this code does:

display.camera.follow(player, true); — Makes the main camera follow the player with smooth interpolation.
No fake camera code is needed here.

Why it works: The main camera is like a window that moves over the fake canvas. The fake canvas itself never moves. If you sync the cameras, you'll defeat the caching and hurt performance.

When to use this: Every frame in your update loop.

📊 Visual Example

Wrong Approach (Syncing)

┌─────────────────────────────────────────────────────────────────┐
│                                                                 │
│   Frame 1: Move fake camera                                    │
│   Frame 2: Move fake camera                                    │
│   Frame 3: Move fake camera                                    │
│   ...                                                          │
│                                                                 │
│   Result: Fake canvas redrawn every frame.                   │
│           Caching is defeated.                                 │
│           Performance drops.                                   │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘

Correct Approach (Resizing)

┌─────────────────────────────────────────────────────────────────┐
│                                                                 │
│   Frame 1: Fake canvas contains entire world                  │
│   Frame 2: Main camera moves over it                          │
│   Frame 3: Main camera moves over it                          │
│   ...                                                          │
│                                                                 │
│   Result: Fake canvas drawn ONCE.                            │
│           Main camera shows a window into it.                 │
│           Performance is optimal.                              │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘

✅ When to Sync (and When NOT To)

Situation	Should You Sync?	Why
Static world	❌ No	Resize the fake canvas once
Tilemap	❌ No	The fake canvas can hold the whole map
Background image	❌ No	One image, one draw call
Decorations	❌ No	They don't move
Scrolling world	❌ No	Resize to world size, let the main camera scroll
Camera shake	❌ No	Shake the main camera only
Parallax layers	⚠️ Sometimes	Only if you're implementing parallax manually
Dynamic backgrounds	⚠️ Sometimes	Only if the background actually changes

🧠 Key Takeaways

Concept	What It Means
Fake canvas	Offscreen buffer for static content
Fake camera	Controls how the fake canvas is rendered
Syncing	Copying `display.camera` to `fake.camera`
The problem	Syncing defeats caching and hurts performance
The solution	Resize the fake canvas to match the world
The rule	Render static content once, move the main camera

⚠️ Common Mistakes

Mistake	Why It's Wrong	How to Fix
Syncing cameras	Defeats caching and hurts performance	Resize the fake canvas instead
Moving the fake canvas	It should be static	Set it once and leave it
Redrawing the fake canvas	Wastes CPU cycles	Use `display.once` correctly
Forgetting to set world size	Fake canvas is too small	Set `display.camera.worldWidth/Height`

🎯 The One-Line Summary

"The fake camera is NOT for syncing — it's for caching. Resize the fake canvas to match your world, and let the main camera do the moving."

Draw your game into existence — with a camera system that performs. 🎥🚀

🔗 Resources

Resource	Link
Part 1: Follow, Shake, Zoom	dev.to/kehinde_owolabi_e2e54567a/mastering-the-camera-system-follow-shake-zoom-i41
Limn Engine Docs	limn-engine-doc.vercel.app
10x Developer Guide	limn-engine-doc.vercel.app/10x.html

DEV Community: Kehinde Owolabi

🚀 From FlipaClip to SitePoint: The Full Story of Kehinde Owolabi

🚀 From FlipaClip to SitePoint: The Full Story of Kehinde Owolabi

How a Nigerian teenager built a professional game engine with borrowed laptops, offline W3Schools, and pure determination.

🎮 Play the Game

📖 Introduction

🎨 The Beginning: FlipaClip and the Spark of Creativity

📚 The First Encounter with Code

📱 The Turning Point: A Sister's Phone and a Love for Python

📲 The Button Phone Era

🌐 The JavaScript Journey

🖥️ The Laptop Heist Era

Sister's Toshiba (4GB RAM — "Hangs Like Hell")

Brother's HP (He Let Me)

💻 The Thinkpad Era (Behind My Sister's Back Again)

📚 The Church WiFi

🛠️ The Birth of JGame

🤖 The AI Analysis Era

🔥 The Dual-Renderer Breakthrough

🔍 The Delta Time Bug

📱 The Tecno Pop 4 Test

🏷️ The Rebrand: TCJSgame → Limn Engine

🔗 The SitePoint Journey

📊 The Rating

🎯 The One-Line Summary

🔗 Follow Me

🐛 Report Bugs

📝 What's Next

🎯 What You've Learned

🚀 Final Thoughts

🐛 How I Fixed the Delta Time Bug in Limn Engine (And How You Can Too)

🐛 How I Fixed the Delta Time Bug in Limn Engine (And How You Can Too)

📖 Introduction

🎯 What Is Delta Time (And Why Should You Care?)

🐛 The Bug: How I Broke Delta Time

🔧 The Fix: Two Different Approaches

Approach 1: The 1 / fps Method (Original)

Approach 2: The Pygame Method (What I Ultimately Used)

🧪 The Test: HP Laptop (Behind My Sister's Back)

📊 The Results: Before and After

🔗 The Code

📝 The Documentation

🐛 Found a Bug? Report It Here!

📋 How to Report a Bug (Helpful Template)

💡 What I Learned

🎯 The One-Line Summary

✅❌ The Limn Engine Commandments: 31 Do's and Don'ts for Better Games

✅❌ The Limn Engine Commandments: 31 Do's and Don'ts for Better Games

🎯 Setup & Configuration

1. ✅ DO: Call display.perform() Before display.start()

❌ DON'T: Call display.start() Before display.perform()

2. ✅ DO: Name Your Display Instance display

❌ DON'T: Use a Different Variable Name

3. ✅ DO: Call display.perform() Before Using TileMaps

❌ DON'T: Use TileMap Without display.perform()

4. ✅ DO: Use deltaTime for Movement

❌ DON'T: Use Raw Numbers for Speed

5. ✅ DO: Normalize Diagonal Movement

❌ DON'T: Ignore Diagonal Normalization

🧩 Components

6. ✅ DO: Use display.add() for Every Component

❌ DON'T: Forget to Add Components

7. ✅ DO: Use setImage() for Images

❌ DON'T: Directly Assign Image Properties

8. ✅ DO: Use destroy() for Permanent Removal

❌ DON'T: Hide Objects You'll Never Use Again

9. ✅ DO: Use hide() for Temporary Invisibility

❌ DON'T: Use destroy() for Temporary Removal

10. ✅ DO: Use Tctxt for UI Text

❌ DON'T: Use Component for Text

11. ✅ DO: Call .fixed() on UI Elements Every Frame

❌ DON'T: Call .fixed() Once

🏃 Movement

12. ✅ DO: Use move.bound() to Keep Objects On Screen

❌ DON'T: Write Your Own Edge Detection

13. ✅ DO: Use move.accelerate() and move.decelerate() for Smooth Physics

❌ DON'T: Directly Set Speed for Physics

🎨 Rendering

14. ✅ DO: Use the Fake Canvas for Static Content

❌ DON'T: Put Static Content on the Main Canvas

Approach 1: The `1 / fps` Method (Original)

1. ✅ DO: Call `display.perform()` Before `display.start()`

❌ DON'T: Call `display.start()` Before `display.perform()`

2. ✅ DO: Name Your Display Instance `display`

3. ✅ DO: Call `display.perform()` Before Using TileMaps

❌ DON'T: Use TileMap Without `display.perform()`

4. ✅ DO: Use `deltaTime` for Movement

6. ✅ DO: Use `display.add()` for Every Component

7. ✅ DO: Use `setImage()` for Images

8. ✅ DO: Use `destroy()` for Permanent Removal

9. ✅ DO: Use `hide()` for Temporary Invisibility

❌ DON'T: Use `destroy()` for Temporary Removal

10. ✅ DO: Use `Tctxt` for UI Text

❌ DON'T: Use `Component` for Text

11. ✅ DO: Call `.fixed()` on UI Elements Every Frame

❌ DON'T: Call `.fixed()` Once

12. ✅ DO: Use `move.bound()` to Keep Objects On Screen

13. ✅ DO: Use `move.accelerate()` and `move.decelerate()` for Smooth Physics

15. ✅ DO: Call `fake.refresh()` After Changes

16. ✅ DO: Set `worldWidth` and `worldHeight`

18. ✅ DO: Use `camera.follow()` Every Frame

❌ DON'T: Call `camera.follow()` Once

21. ✅ DO: Use `tilemap.crashWith()` for Collision

❌ DON'T: Set Objects to `null`

24. ✅ DO: Use `clearMargin` Optimization

25. ✅ DO: Preload Sounds Before `display.start()`

26. ✅ DO: Use `move.sound.*` for Quick Audio

27. ✅ DO: Use `console.log()` for Debugging