DEV Community: Olu Desire

We Built an Arcade for Our Own Game Engine

Olu Desire — Tue, 15 Sep 2026 08:06:44 +0000

Or: how I spent three months using the platform we built at Evolved Tech, noticing what was broken, and refusing to stop

Kehinde Owolabi founded Evolved Tech and built the core: epic.js, our 2D game engine for the browser. Not Unity. Not Godot. Something small and honest — one file, no npm, no build step. Drop it into an HTML page, write some JavaScript, and you have a game running.

We called the project Limn Engine. Kehinde owns the engine core. It worked.

My name is Desire. I'm the co-founder of Evolved Tech. My job was everything around the engine — I built the editor where people actually make games with it, and the arcade where those games live once they're made.

Here's the situation we found ourselves in: the engine existed. Games could be made. But there was nowhere to put them. No gallery. No way to share. No way for anyone to see what you'd built.

Kehinde built the engine. I built the editor and the roads.

So I started building the arcade. Then I kept building — not because anyone asked, but because every time I used our own platform, something felt missing.

This is the story of how our engine became a full arcade with profiles, leaderboards, comments, replies, follows, weekly winners, an inbox that took two days to stop loading forever, and one screenshot that will haunt Kehinde for the rest of his football-watching life.

If you've ever added one feature and ended up with fifteen, pull up a chair.

Part 1 — The Arcade

Picture a game gallery. Grid of cards. Each card shows one game someone made.

That's the arcade. The problem: how do you show a game without a screenshot?

Games aren't images, they're JavaScript. There's no browser on the server to render one, and recording video on every publish is way too heavy for a platform where games ship in 30 seconds.

So I did the obvious thing: I draw the thumbnail from the game's own data.

Every game saves a small config — the positions and colours of its objects. A dress-up game has five coloured rectangles (hat, head, shirt, pants, shoes). A platformer has a player square and a goal. A shooter has a ship and an enemy.

At load time, the arcade reads that config and draws the shapes into an SVG. No screenshot needed. No server rendering. Just math.

I expected it to look terrible. It actually looks... fine. A bit abstract. Like a Mondrian painting, if Mondrian was into 2D side-scrollers.

I'll take it.

Part 2 — The Leaderboard (Which Nearly Broke Me)

Here's how my brain works. Watch closely.

"I should rank the games."

Okay, by what? Plays? Too easy to game — refresh five times, you're #1. Score? Every user writes their own game code, so there's no shared scoring format. Likes? Fine. Simple. One like per person per game.

"But likes should reset weekly, or the same game stays #1 forever."

Okay. Monday, 00:00 UTC. Every week. Automatic.

"But how do people know the leaderboard changed?"

Now there's a Weekly Leaderboard card in the inbox — top 5 games, like counts, comment counts. Like a game on Tuesday, the creator's inbox updates Wednesday.

"But that's kind of empty if nobody likes anything."

Then the card just doesn't render — which, in the platform's early days, meant it almost never did. Because I was the only user, and I wasn't going to like my own games.

...Reader, I liked my own games. I'm not proud of it. The leaderboard showed.

Part 3 — Comments with Replies (The `prompt()` Mistake)

Comments were easy. I built them in an afternoon.

Replies were not.

My first version used a prompt() dialog — the built-in browser popup. Ugly, unstylable, covers the whole screen on mobile, looks like it's from 1998. I shipped it anyway because it worked.

Then I tried it on my tablet.

Tapped "Reply." Grey box appeared. Typed. Hit OK. Box vanished.

Nothing happened.

Turns out the page had already reloaded from an earlier action, and the reply was posting against a stale game ID. The fix took twenty minutes. The rewrite of the UI took four hours.

The new version: an inline reply form under every comment — small text box, indented, blue left border. Reply appears underneath, slightly smaller, slightly dimmer, clearly nested. Two levels deep, max — root comments and replies. No more, because three levels of nested comments on a phone screen is a war crime.

Now it looks like a real comment section. Like Reddit, if Reddit had five users and all of them were me.

Screenshot above: that's Kehinde in one of our test comment threads, confidently typing "Arsenal will win the league this season" like a man who has never once watched Arsenal play in May. Sir, we are testing a **reply feature, not writing your eulogy. I kept the screenshot in the codebase for QA purposes. I kept it in this article for accountability purposes. History will remember this comment. History will also remember what happened next.

Part 4 — The Username Problem

Worth telling carefully, because it's the kind of bug that teaches you something.

Until recently, every game shipped with two pieces of creator info: author_id (a Supabase UUID) and author_name — the creator's email prefix.

So if your email was desiregeorge434@gmail.com, every game you published said "by desiregeorge434." Not your name. Not a handle. Your raw email prefix, sitting there, looking at you.

So I added usernames. The rules:

3–20 characters
Lowercase letters, numbers, underscores only
Unique across the platform
Locked forever once set

That last rule matters. If usernames could change, every /u/?u=desire link would break the moment Desire became @desirethegreat. Games, followers, old shares — all dead links.

So: one shot. Pick carefully. Live with it.

There's a second field — display name — which can change. You can be @desire forever while your display name bounces between "Desire" and "Desire the Magnificent" on a whim.

Two names. One permanent, one fluid. I only know this is the correct design because I got it wrong first.

Part 5 — The Two-Day Bug (Three Lines of Code)

My favourite story from this whole project.

For a week, every game showed its author's email prefix. Every profile page showed the actual username. The two systems never spoke to each other.

Games stored author_id / author_name. Profiles stored user_id / username. The arcade rendered games by reading author_name directly — it had no idea a profile system even existed.

I stared at this for two days. Rewrote the arcade query. Blamed Supabase. Blamed my browser cache. Blamed the phase of the moon.

Then it clicked: I needed a lookup.

const profile = profileMap[game.author_id];
if (profile && profile.username) return '@' + profile.username;
if (profile && profile.display_name) return profile.display_name;
if (game.author_name) return game.author_name.split('@')[0];

Three lines. Two days. This is what programming is. I've made peace with it.

Part 6 — The Inbox That Wouldn't Load

The inbox should load in two seconds. On my tablet, it loaded in never.

Here was the culprit:

try {
  const user = await supabase.auth.getUser();
  const docs = await supabase.from('user_documents').select('*');
  const updates = await supabase.from('engine_updates').select('*');
  // ...and four more fetches
} catch (err) {
  console.log('Error');
}

Every fetch inside one try/catch. If any single one hangs, the whole chain waits forever — and my data was clocking in at roughly 2 bars and a prayer that week, so they hung constantly. (Nigerian networks are fine, by the way. It's not the network. It's a man who refuses to buy more data and instead debugs for six hours as a substitute.)

The fix: every fetch gets its own try/catch and a hard timeout.

const result = await withTimeout(
  supabase.from('...').select('*'),
  4000
);

Four seconds, then move on. If a fetch fails, that one card just doesn't render — everything else still does.

The old inbox took 40 seconds to load, when it loaded at all. The new one takes 2. Twenty times faster, from forty lines of defensive code.

Lesson: fast isn't about speed. It's about knowing when to give up.

Part 7 — The Buttons Nobody Could See

My first on-screen button was rgba(255,255,255,0.18) — white at 18% opacity. Basically a ghost. Invisible on light backgrounds, barely-there on dark ones, a mistake on all of them.

Players would tap the screen, something would happen, and they'd have no idea why.

New buttons:

Button	Color	Purpose
Move	Dark navy `#1a1a2e` + white text	Solid, unambiguous
Jump	Bright blue `#2563eb`	Clearly an action
Fire	Bright red `#dc2626`	Clearly an action

Plus labels on top: ◀ ▶ JUMP FIRE. No more guessing.

The runner template has zero buttons — tap anywhere to jump. "The screen is the button." Beautiful, and free.

Part 8 — Game Over → Play Again

Before: you lose. The screen freezes. Your score just sits there, mocking you. You refresh the page. You lose your score too.

After: you lose, and a blue ▶ PLAY AGAIN button appears center screen. Tap it — score zeroes, timer resets, you're back in, one tap away.

Fifteen minutes of work. Turned every template from "play once and close the tab" into "play forever." This is the feature that separates a tech demo from an actual game.

Part 9 — The Features That Were Missing

Every feature below came from actually using my own platform and hitting a wall. Not a roadmap. Not user requests — I had no users yet.

Feature	Reason
The arcade	Because nobody could see the games
Thumbnails	Because blank cards look broken
Likes	Because I wanted a signal people were playing
Leaderboard	Because "top games" beats "all games"
Weekly reset	Because the leaderboard got stale fast
Comments	Because I wanted to know what people thought
Replies	Because one-way comments felt empty
Usernames	Because email prefixes should never be public
Profiles	Because usernames needed a home
Follows	Because "creator" is a real concept
Inbox	Because notifications make a platform feel alive
Touch buttons	Because tablets exist
Play Again	Because the game isn't over until you say so

That's the real lesson: you don't design a platform, you use one until the gaps become obvious — then you build them, one weekend at a time, because you're the only one who cares they're missing.

That's not "features nobody asked for." That's the job.

Part 10 — What I Actually Learned

You are your first user. Every confusing button and broken flow you notice before anyone else does is real. Fix it — that's not scope creep, that's the product.
Users don't care about your architecture. They care that the button is visible, the game loads fast, and the leaderboard updates. Your state management is invisible to them, on purpose.
Timeouts beat retries. Four seconds then move on is a design decision. Waiting forever is a bug wearing a trench coat.
Small UX wins beat big features. A PLAY AGAIN button beats a new template. A readable button beats a pretty one.
Usernames must be separate from display names. One person, two identities, two lifespans. Respect both.
"Loading..." past 5 seconds isn't loading. It's broken. Fix it.
You will spend two days on three lines of code, and it will feel like three years, and then you'll commit it, feel like a genius, open your email, and find 47 new messages. That's fine. That's the job too.

Part 11 — The Loop

Nothing is ever done. But right now, the loop works:

Make a game → Publish it → Share the link → Watch people play
→ Get likes → Rank on the leaderboard → Check the inbox → Make another

That's the thing that has to work before anything else matters. And it does.

Part 12 — What's Still Coming

Short-term (this month)

Feature	Why
Tags & categories	Filter by puzzle, runner, shooter, dress-up — instead of scrolling everything
Featured banner	Highlight one game a week on the arcade home page
Search by tag	Pairs with existing search — find all "runner" games at once
Real thumbnails	Render an actual screenshot on publish instead of abstract rectangles
Mobile multi-touch	Move and shoot at once — an engine-level fix, not just a platform one

Medium-term (1–2 months)

Feature	Why
Profile badges	"Won the week of Sep 8" — give people bragging rights
Per-category leaderboards	Top platformer, top runner, top puzzle — rewards variety
Notifications	"Kofi replied to your comment" — instead of checking the inbox manually
Private sharing	Publish without listing in the arcade, for WIPs and friends-only games
Follow feed	A timeline of games from creators you follow

Long-term (not sure yet)

Feature	Why I'm hesitating
Collaborative editing	Two people, one game, live. Cool in theory, nightmare in practice
Moderation tools	Right now I delete comments manually via the Supabase dashboard
Monetization	Sounds nice, adds friction to a platform that currently has none
Native mobile app	The web app works fine on tablets — this is a big lift for a small platform
Open-sourcing it	I want to. I need to clean up the 4-second timeouts first

How I decide what's next: not by writing a roadmap and following it religiously — by opening my own arcade and getting annoyed at something that should exist and doesn't. Every item in Part 9 came from that process. Every item above will too.

The one thing I'm sure of: the loop works. Everything else is decoration.

What's New — At a Glance

Feature	Description
🎮 Arcade gallery	Browse every published game as a card with an auto-generated SVG thumbnail
🏆 Weekly leaderboard	Top 5 games ranked by likes, resets every Monday at 00:00 UTC
💬 Comments + replies	Two-level nested comments with inline reply forms (no more `prompt()`)
🧑 Usernames + profiles	Permanent unique handles, editable display names, public `/u/?u=` profile pages
👥 Follows	Follow creators, see their games from one place
📥 Inbox	Weekly leaderboard cards, notifications — loads in 2s flat, timeout-protected
🕹️ Touch controls	Redesigned high-contrast buttons for mobile play, plus tap-anywhere runners
🔁 Play Again	One-tap restart on every game template — no more refreshing the page

Try It

🕹️ Arcade: limn-engine-doc.vercel.app/arcade
🎨 Build a game: limn-engine-doc.vercel.app/editor
⚙️ Set up a profile: limn-engine-doc.vercel.app/settings.html
👤 Follow me: /u/?u=desire — follower count currently says 1, and I'm 90% sure that 1 is me

If you make a game, send me the link. I'll play it. I'll probably like it. I might even comment.

Get Involved / Get Help

Resource	Link
💬 Discord	discord.gg/kVpSmYWXr
🧑‍💻 GitHub	github.com/terracodes004
📧 Email	evolvedtech004@gmail.com

Bug reports, feature ideas, "why is my button rgba(255,255,255,0.18)" — all welcome.

Credits

Limn Engine — built by Kehinde Owolabi, founder of Evolved Tech. He built the core engine: one file, no dependencies, no build tools. Every game on this platform runs on his code.

The editor, arcade, leaderboard, profiles, comments, inbox, buttons, and everything in Part 12 — me, Desire, co-founder at Evolved Tech. Built one weekend at a time, on a tablet, while muttering about timeouts — because I kept using our own platform and kept finding things that bothered me.

If the games run, that's Kehinde. If the buttons work, that's me. If something's broken, it's probably both of us, and we'll fix it together — right after Kehinde finishes explaining, again, why this is finally Arsenal's year.

Draw your game into existence — with a canvas and a dream. 🎨🎮

#javascript #gamedev #webdev #showdev

Limn Engine Just Got Smarter — Here's What We Added (And Why It Matters)

Olu Desire — Mon, 07 Sep 2026 18:50:31 +0000

The question that started it all: "Why do we have to write the same code in every single game?" So we built Limn Engine — a zero-configuration, browser-based 2D game engine that hits 60 FPS on hardware old enough to vote. It got published on SitePoint and ranked #3 among 2D JavaScript game engines, which we now mention in every conversation, including this one.

Today's post is about what's new. And to be crystal clear: all of it is live right now. Not "coming soon," not "in beta," not "works on our machine." You can go use every single feature below today, this minute, before you even finish this sentenc—okay you finished it, go use them.

Fair warning: some of these features exist purely because we got tired of doing something annoying, several times, in a row, forever.

📋 The TL;DR (For Those Who Scroll First, Read Later — No Judgment)

Feature	What It Does	Why You'll Care
🔐 Google OAuth	One-click sign-in via Google, plus email OTP as backup. Powered by Supabase Auth.	No passwords, no forms, no "forgot password" emails haunting your inbox at 3 AM.
🔗 Shareable Code Snippets	Write code in the playground, hit Share, get a unique URL.	Send exact working code to friends instead of dumping 200 lines into Discord like a ransom note.
🔍 Universal Search	Global search overlay — hit ESC or click the icon.	Find docs, API refs, tutorials, and community posts instantly. Even we use it now.
📱 Touch-Friendly Design	Fully responsive interface across desktop, tablet, and phone.	Build your game from the couch. We don't make the rules, we just enable them.
💬 Inbox & Messaging	Built-in messaging system for updates and collaborator chats.	Stay in the loop without alt-tabbing to five other apps.

Status: all shipped. All live. Go bother them.

Now, for those of you who like the director's commentary — here's the full story behind each one.

The Problems That Kept Us Up At Night

Rule one of building Limn Engine: "Common outcomes should be functions." Edge detection, camera math, collision loops — if we typed it twice, it became move.bound(player) or camera.shake(5,5) before we typed it a third time out of spite.

But the engine's infrastructure needed the same intervention. Three problems in particular were staging a nightly protest in our brains:

· Authentication — every game needs users, and building sign-up/login/password-reset from scratch takes weeks we do not have and would rather spend on, frankly, anything else.
· Collaboration — "send us your code" in Discord meant receiving 200 unformatted lines that looked like a ransom note.
· Discovery — finding anything on our own website had become a scavenger hunt with no prize at the end.

So, in the spirit of turning problems into functions, we fixed them. All three. They're live. We already told you that but it bears repeating because we're proud of ourselves.

🔐 Google OAuth: One Click, No Passwords — Live Now

Nobody has ever, in the history of the internet, been excited to "Create an account." You see that button, your soul leaves your body a little, and you close the tab. We know. We've done it to other websites while building the fix for our own.

So Limn Engine now runs on Google OAuth as the primary login method:

· One click, and you're in. No forms, no email verification purgatory, no "forgot password" email arriving at 3 AM to remind you of your own incompetence.
· Instant onboarding — straight to building, zero friction, zero excuses left to procrastinate with.
· We never see your password, mostly because we don't want that responsibility. Google can have it. Google seems more organized than us.

Prefer not to hand Google the keys? We also added email OTP login, because choice is nice and so is not being cornered.

Under the hood, this runs on Supabase Auth, a real production-grade auth system built by people who are much better at this than we are. We know our strengths, and "building auth from scratch" is not one of them. We have games to make.

The takeaway: authentication should never be the reason someone bounces off your engine. Consider that reason eliminated. You're welcome.

🔗 Shareable Code Snippets: Collaboration Without The Crime Scene — Live Now

This one's personal.

Every debugging session in Discord went the same way: "send us your code," followed by 200 lines of unindented JavaScript arriving like evidence at a trial nobody asked for. Our DMs looked less like a support channel and more like a crime scene with syntax errors.

So now the playground has a Share button that generates one clean URL, sendable anywhere — Discord, WhatsApp, Twitter, email, and yes we did consider carrier pigeon and no it did not make the roadmap.

What that gets you:

· Debugging that doesn't require detective work — stuck on a physics bug? Send the link. Your friend sees exactly what you see, and "works on my machine" officially retires.
· A place to flex — nailed a particle effect in 30 seconds? Send the link and let people watch it run live, no copy-paste required.
· A Discord server that's actually readable — no more scrolling past a wall of code to find the one message that matters. Our eyes, and yours, say thank you.

The takeaway: sharing code is now exactly as easy as sharing a meme, which was frankly always the bar.

🔍 Universal Search: Find Anything, Instantly — Live Now

Our website had grown a lot of rooms and forgotten to build any hallways. Docs, API references, tutorials, community posts — all real, all somewhere, none easily findable, including by us. We have genuinely spent 10 minutes hunting for our own documentation, which is a special kind of humbling.

So we built a global search overlay. Hit ESC, or click the icon, type your question, get your answer. No reloads, no menu spelunking.

Searchable: API references, documentation, community threads, game templates, tutorials, and everything else we forgot to list here (which the search bar will also find, conveniently).

It's fast, it's obvious, and it makes Limn Engine feel like a serious tool built by serious people — a costume we are, at this point, fully committed to wearing in public.

📱 Touch-Friendly Design: Build Anywhere — Live Now

Games get played on desktops, tablets, and phones, so it never made sense that you could only build one hunched over a laptop like it's a ritual. We rebuilt the interface to be genuinely touch-responsive, whether you're:

· Skimming docs on a tablet in bed
· Managing your community from your phone on a lunch break
· Poking at your game on whatever screen happens to be nearby

No pinch-to-zoom archaeology, no buttons sized for a smaller species of thumb. Just an interface that works wherever you decided to be productive today, including the couch, which we fully endorse.

💬 Inbox & Messaging: Stay Connected — Live Now

Building alone is fine. Building with people who occasionally message you back is better. So we added a built-in inbox and messaging system for:

· Getting updates and announcements, so "what's new" isn't a mystery
· Talking to collaborators without leaving the platform
· Staying plugged into the wider Limn Engine community

It's a small feature that makes us feel disproportionately like a real company — one with an actual office, not just a room, some laptops, and a shared refusal to give up.

🎮 What's Next?

Currently in the workshop (these ones, unlike everything above, are genuinely not out yet — we'd tell you):

· TypeScript support — for developers who like their errors caught before runtime, understandably
· An NPM package — npm install limn-engine is coming, we promise, for real this time
· More game templates — for when the blank canvas is scarier than the actual coding
· Better physics and particles — because if something explodes in your game, it should look incredible

We're building this for the long haul, and we'd like some company.

🙌 Join The Community

Already here? You're basically family at this point, and we mean that with zero legal obligation attached.

New? Come say hi:

· #beginner-help — no question is too small, we've asked worse
· #showcase — show us your first game, we will cheer, possibly too loudly
· #engine-dev — help build the engine itself, we need every hand we can get
· #performance — help us make this thing run on a toaster, we're only half joking

🏁 Final Thoughts

We started with a Toshiba laptop, 4GB of RAM, and one stubborn question: "Why do we have to write the same code in every single game?"

That question is now a real, live, shipped engine with:

· Zero configuration, because life is complicated enough already
· 60 FPS on low-end hardware, yes, even that one
· Google OAuth, one click, no passwords, no drama
· Shareable code snippets, because copy-paste had its moment and that moment ended
· Universal search, so nobody has to hunt for their own documentation again (looking at us)
· Touch-friendly design, because the couch is a legitimate workstation
· A community that keeps showing up, which is honestly the part we're proudest of

Built by a team that refused to give up, mostly out of stubbornness.

🔗 Links


💬 Discord	discord.gg/kVpSmYWXr
💻 GitHub	github.com/terracodes004
✉️ Support Email	evolvedtech004@gmail.com

Got questions, bugs, or just want to show off what you built? Drop into the Discord or email us — we read everything, we promise, we're not just saying that like a company that doesn't.

Draw your game into existence — the easy and advanced way.

🕹️ The Reinvention Tax: Why We Ditched Pure Scratch for Epic.js (and You Should Too)

Olu Desire — Tue, 25 Aug 2026 00:31:39 +0000

How we tried to build a whole game engine out of stubbornness, and what the browser had to say about that.

📖 Introduction: The "We Can Build It" Syndrome

Every developer starts a project with a dangerous amount of confidence. The day we decided to build a custom HTML5 canvas arcade shooter, we walked into the room like champions — "no shaking, we go handle am." No pre-built modules, no shortcut libraries, no dependencies. Just us, a blank browser tab, and a keyboard doing overtime past midnight.

We genuinely thought hand-coding the physics, the enemy spawn logic, and the bullet arrays would be a calm weekend job. Instead, the CPU started shouting the moment two enemies appeared on screen at once. Frame rate dropped to single digits like it was on strike. Our code turned into spaghetti — and not the good kind you enjoy on a Sunday. It showed us pepper.

We were busy reinventing the wheel from zero, completely blind to the fact that a solid core engine — epic.js — was sitting right there, fully able to carry the heavy part of the matter for us.

This isn't just a "we failed, then we won" story, though. We're going to show you exactly why the naive version fell apart, line by line, and exactly what replaced it — so you can skip the three days we spent finding this out the hard way.

The one-line summary: We tried to build an arcade shooter entirely by hand, our browser humbled us in public, and switching to a pooled, delta-time-driven architecture on epic.js is the thing that actually saved the project.

🪤 Sector 1: Falling Into the "Pure Scratch" Trap

Every developer passes through that phase where using an existing framework feels like cheating. We want total control. We want to write every variable ourselves so we can beat our chest later and say "I built this from the ground, nobody helped me."

Our early object-tracking system was pure chaos. Instead of a clean entity manager, bullets went straight into a raw, unmanaged array that looped endlessly on the main thread:

// Our painful, hand-coded bullet loop
function updateBullets() {
  for (let i = 0; i < playerBullets.length; i++) {
    playerBullets[i].y -= 10; // manual coordinate tracking
    if (playerBullets[i].y < 0) {
      playerBullets.splice(i, 1);
      i--;
    }
  }
}

This loop worked fine when there was one lonely bullet on screen, moving like a snail with nowhere to be. But scale that up to a real arcade wave — lasers, particle sparks, three enemy formations descending at once — and the browser will very quickly show you pepper.

🧯 Sector 2: Why Our Hand-Coded Architecture Packed Up (The Actual Technical Reason)

It didn't take long for the DIY masterpiece to scatter completely. On a web canvas, performance is not a bonus feature — it's the entire difference between a smooth arcade game and a slideshow with extra steps.

Here's the part most devlogs skip: why exactly that loop was the problem, not just that it was slow.

Reason 1 — splice() inside a loop is quietly expensive. Every time splice(i, 1) removes a bullet, JavaScript has to shift every element after it one position to the left to close the gap. That's an O(n) operation, happening potentially dozens of times per frame, inside a loop that's already O(n). With 5 bullets on screen, you'd never notice. With 200 bullets, particles, and enemies all doing this every frame, you're paying that shifting cost constantly — this alone was a big chunk of our frame drop.

Reason 2 — we were creating and destroying objects every frame. Every new bullet was { x, y, ... } freshly allocated with push(), then thrown away with splice() a second later. JavaScript's garbage collector has to clean up after all that churn, and garbage collection pauses are exactly the kind of thing that shows up as a stutter, not a steady slowdown — which is why our frame rate wasn't just low, it was inconsistent.

Reason 3 — collision checks were brute-force. Every bullet was checked against every enemy, every frame — an O(n × m) comparison with no shortcuts. Ten bullets and ten enemies is 100 checks. Fine. Fifty bullets and thirty enemies is 1,500 checks, every single frame, on the main thread, alongside rendering.

Stacked together, here's roughly what that did to us on a mid-range laptop:

Scenario	Active bullets/particles	Frame rate
One bullet on screen	~1	60 FPS, smooth
A real wave (lasers + enemies + sparks)	~180	6–9 FPS
Same wave, boss fight	~350	Effectively frozen

Our custom approach failed for three structural reasons on top of the raw math:

Reason	What it actually looked like
CPU overload	Every bullet trajectory, boundary check, and collision box was computed manually on the main thread — the browser choked under the weight
Tightly coupled code	Game logic, rendering, and input listeners were tangled like cheap earphone wires — touch one variable, three unrelated features scatter
The "reinventing the wheel" tax	Three full days spent hand-writing collision logic that solid engine frameworks had already solved years ago

We were so busy trying to prove a point that we forgot the first rule of smart engineering: don't carry heavy load when a trailer is passing free of charge. Ego writes the first draft. Engineering rewrites it.

🚦 When to walk away from pure-scratch: if your frame rate dips below 30 FPS with fewer than 100 objects on screen, stop optimizing your hand-rolled version and start integrating an engine. That's the reinvention tax ceiling — past that point, you're paying in days what a framework already solved in years.

To be fair to our stubborn selves, though — building it wrong first wasn't pure waste. If your goal is learning how canvas internals actually work, keep going by hand, that struggle is the whole point. Just don't ship the hand-rolled version to production. Know which one you're doing before you start.

🔧 Sector 3: The Actual Fix — Object Pooling and Delta Time

Before we get to epic.js itself, we want to show the two changes that mattered most — because you can apply both of these in any canvas game, engine or no engine.

Fix 1 — Object pooling (stop creating and destroying bullets)

Instead of constantly allocating new bullet objects and throwing them away, we pre-allocate a fixed pool once, and just recycle inactive ones:

// A simple bullet pool — allocate once, reuse forever
const BULLET_POOL_SIZE = 200;
const bulletPool = Array.from({ length: BULLET_POOL_SIZE }, () => ({
  x: 0, y: 0, active: false
}));

function spawnBullet(x, y) {
  const bullet = bulletPool.find(b => !b.active);
  if (!bullet) return; // pool exhausted, skip spawn this frame
  bullet.x = x;
  bullet.y = y;
  bullet.active = true;
}

function updateBullets(deltaTime) {
  for (const bullet of bulletPool) {
    if (!bullet.active) continue;
    bullet.y -= 600 * deltaTime; // speed in px/sec, not px/frame
    if (bullet.y < 0) bullet.active = false; // recycle, don't destroy
  }
}

No splice(). No push(). No garbage collector chasing after us. We just flip a boolean. This one change took our bullet-heavy scenes from stuttering to steady on the same laptop.

Fix 2 — Delta time instead of fixed pixel steps

Our original loop moved bullets by a flat 10 pixels every frame — which means speed was secretly tied to frame rate. Drop to 30 FPS, and every bullet moves at half the speed it should, which makes a slow machine feel even more broken than it is.

let lastTime = performance.now();

function gameLoop(currentTime) {
  const deltaTime = (currentTime - lastTime) / 1000; // seconds since last frame
  lastTime = currentTime;

  updateBullets(deltaTime);
  render();

  requestAnimationFrame(gameLoop);
}

requestAnimationFrame(gameLoop);

With delta time, updateBullets always knows how much real time passed, so movement stays consistent whether the game is running at 60 FPS on a good laptop or 25 FPS on a tired one. Speed becomes pixels per second, not pixels per frame — a small change with a big effect on how "broken" a slow device feels.

Where epic.js comes in (and where it honestly doesn't)

Let's be precise here, because we don't want to overclaim what the engine hands you for free. Once our engine version was routed correctly:

if (versionDropdown) {
  let selectedVersion = versionDropdown.value.toLowerCase();
  if (selectedVersion.includes('v4')) {
    engineScriptFile = "https://limn-engine-doc.vercel.app/asset/epic.js";
  }
}

...here's what epic.js actually gave us, straight from the source:

A component system with built-in collision, so we stopped hand-writing AABB math. Every game object is a Component — you give it a width, height, position, and it comes with .crashWith(otherObject) for rectangle collision (with rotation support baked in) and .enableCircleCollision() / .crashWithCircle() if you'd rather check circles:

const bullet = new Component(4, 12, "yellow", playerX, playerY);
bullet.speedY = -10;
display.add(bullet);

// later, in your own update loop:
if (bullet.crashWith(enemy)) {
  bullet.destroy(); // removes it from the engine's render list for you
  enemy.destroy();
}

We didn't have to write crashWith() ourselves — that was three of our "reinvented the wheel" days, gone.

Automatic viewport culling, which is the real reason the frame rate recovered. Here's the part we didn't expect: the engine checks each component's Rect-like x property — which holds x, y, width, and height — against the game area bounds before doing any work on it:

if (TCJSgameGameArea.crashWith(component.x)) {
  component.x.update(display.context);
}

Off-screen bullets, particles, and enemies still exist in memory, but they stop costing us render and update time the moment they leave the visible area. That single check quietly did more for our frame rate than anything we'd hand-rolled ourselves — it wasn't pooling that saved us, it was the engine simply refusing to do work on things nobody could see.

What it does not give you for free: object pooling. This is the honest part. Objects go into a global list via display.add() and come back out via .destroy(), which does a findIndex + splice() under the hood — the exact same pattern we were trying to escape in Sector 1. Even the engine's own particle system creates and destroys particles this way. If you want true pooling — pre-allocating and recycling — that's still on you to build on top of Component, the same way we showed in the manual fix above.

Speed is still per-frame, not per-second, by default. move() applies this.x += this.speedX directly — no delta-time scaling built in. display.deltaTime is exposed for you to use in your own update() function, but the engine won't apply it for you automatically. So the delta-time discipline from the fix above still matters, even once you're on epic.js — the engine gives you the tools, not the guarantee.

Being honest about it: this wasn't instant magic. Wiring epic.js into a codebase that had spent three days being hand-rolled and tightly coupled meant untangling our own mess first — pulling rendering logic out of the input listeners it had no business living inside. The framework didn't fix our architecture. It gave us collision handling and free culling. Pooling and delta time discipline were still ours to get right.

So when do you actually switch?

We were three days in when we switched. That's not a universal number — here's a rougher rule of thumb than "just use an engine":

Your situation	What to do
Object count under ~50, frame rate is fine	Stay pure. You don't have a performance problem yet.
Object count over ~50, frame rate holds but you're hand-writing AABB/circle collision	Grab a collision-only library or a `crashWith()`-style utility — you don't need a full engine yet.
Object count over ~50 and frame rate is dropping and you're hand-writing collision	Grab the engine. You've hit both problems at once — that's the actual signal, not a fixed day count.
You're doing this specifically to learn canvas internals	Keep going by hand, on purpose — just don't ship that version.

The difference, in numbers

Version	Active bullets/particles	Frame rate
Original — `splice()`, no delta time, checking everything on-screen or not	~180	6–9 FPS
Manual fix — pooling + delta time, still checking everything	~180	48–55 FPS
On `epic.js` — built-in `crashWith()` + automatic viewport culling, our own pooling on top	~350	Steady 60 FPS

Same laptop, same scene, three different architectures. The lesson wasn't "epic.js is magic" — it's that pooling and delta time recovered most of the performance ourselves, and the engine's free viewport culling plus not having to hand-write collision math is what let us push the object count even higher on top of that.

🎓 Sector 4: Hard-Earned Lessons From the Trenches

Some lessons don't come from documentation. They come from watching your frame rate crawl at 1 AM and asking yourself hard questions.

Under-the-hood mechanics still matter. Writing those messy loops by hand taught us why canvas rendering contexts and coordinate grids behave the way they do. You genuinely have to break something manually at least once to understand how it ticks — the pain wasn't wasted, even if the code was.

Frameworks aren't cheating. Leaning on a solid core asset like epic.js isn't cutting corners — it's smart architecture. It frees up your mental bandwidth for the part that actually moves the needle: game design and how it feels to play.

Knowing when to pivot is a skill, not a defeat. Admitting your hand-coded system has become the bottleneck isn't failure — it's a checkpoint in engineering maturity. The stubborn version of us needed to hear that first.

📊 What You've Learned

Concept	How It Applies
`splice()` cost	Removing from the middle of an array shifts every element after it — expensive when it happens every frame
Object pooling	Recycle objects instead of creating/destroying them — cuts garbage collection stutter dramatically
Delta time	Move objects by `speed × secondsElapsed`, not a flat number per frame, so speed stays consistent across devices
Viewport culling	Skipping update/render work on objects outside the visible area can matter more than clever collision math
Read your dependency's source	We assumed `epic.js` did pooling for us — it doesn't. Checking the actual code saved us from shipping on a wrong assumption
The reinvention tax	Solving a problem a mature framework already solved costs days you don't get back

🚀 Conclusion & What's Next

Building an arcade shooter from scratch taught us humility, patience, and the real value of proper tool selection. Dropping the ego, ending the "pure scratch" marathon, and integrating epic.js is what saved this project from a very avoidable disaster.

Here's the receipts — the editor running the real V4 build, and the actual arcade wave rendering steady instead of crawling:

If you're currently hand-coding every single piece of your own engine, take a breath. Step back, look at your tools honestly, and let clean architecture carry some of the weight for you. And if you take nothing else from this, at least go add object pooling and delta time to whatever you're building right now.

🔗 Come Say Hi

🌐 Docs & assets: Limn Engine Vercel Assets
💬 Community & support: Join our Discord
📂 Source code: GitHub

Your turn: what's the thing you rebuilt from scratch before finally admitting a library already did it better? Drop it below. 🎮

Limn Engine — draw your game into existence. No shaking, no scattering, just clean architecture doing the heavy lifting for you. 🎨✨

🛠️ How We Upgraded the Limn Engine Playground Editor for Version 4

Olu Desire — Mon, 24 Aug 2026 23:09:40 +0000

One dropdown, one bug, and the afternoon we almost shipped it broken.

📖 Introduction

The Version 4 launch of Limn Engine had everything — a new particle system, audio management, a slick preview. What it didn't have was a way for the playground to actually find the damn file.

We'd already built epic.js — the new core script with particle systems and audio management baked in. That part felt great. That part felt like progress, like something to post about. But none of it mattered if the playground editor couldn't even find it. A developer could select "Version 4" from the menu, hit run, cross their fingers... and the preview would just keep loading the old engine. No error. No warning. Just the wrong file, running like nothing happened. Very smooth criminal behaviour from our own code.

That's the kind of bug that scares us more than any crash — the one where nothing looks broken, so you almost sign off on it and go rest.

This is the story of how we fixed it, what we got wrong the first time, and what's still genuinely unfinished about it — because pretending otherwise would defeat the point of writing this at all.

The one-line summary: We upgraded the Limn Engine playground editor to detect and load Version 4 — and learned the hard way that "it works for us" and "it works" are not the same thing.

🔍 The Problem Nobody Would Notice Until It Was Too Late

The playground editor doesn't ask any server which engine version you want — no config file, no manifest, no backend deciding for you. It simply looks at the page, finds a <select> element, reads whatever text is sitting inside it, and tries to match that text to a script. That's the whole idea. Fast, simple, zero dependencies.

But that convenience comes with a price. If the scanner doesn't recognize a version string, it doesn't shout — it doesn't crash. It just quietly keeps whatever it last loaded, which is exactly how we almost shipped V4 broken. We selected it, hit run, saw the canvas render... and only after staring longer than we'd like to admit did we realize it was the old engine playing dress-up as the new one. Nobody would've known unless they checked very carefully.

What this taught us: the bugs that don't announce themselves are the ones that reach production. We started treating a suspiciously calm preview as a warning, not a relief.

🧵 Teaching the Scanner to See V4

Here's the loop that walks the dropdowns on the page — the actual fix, straight from the runn() function that powers the "Run" button:

let engineScriptFile = "epic.js";
let allDropdowns = document.querySelectorAll('select');
let versionDropdown = null;

for (let select of allDropdowns) {
    let text = select.textContent.toUpperCase();

    // Updated search check to recognize V2, V3, and V4
    if (text.includes('V2') || text.includes('V3') || text.includes('V4') || select.value.toUpperCase().includes('V')) {
        versionDropdown = select;
        break;
    }
}

Before we touched it, that condition stopped politely at V3, like V4 never existed. Every dropdown labeled "Version 4" was invisible to the scanner — not broken, not flagged, just completely skipped.

Adding V4 to that condition was one line. Finding out it was missing took an entire evening, because our first assumption was that the routing was wrong — not that the dropdown was never being found in the first place.

Future-proofing note we haven't shipped yet: hardcoding each version string like this means every new release needs another || clause. A cleaner version — worth doing before V5 — is a simple array:

const VERSIONS = ['V2', 'V3', 'V4', 'V5'];
if (VERSIONS.some(v => text.includes(v)) ||
    select.value.toUpperCase().includes('V')) {
  versionDropdown = select;
}

Still on the todo list. Mentioning it here so future-us can't pretend we didn't know.

🎯 Routing the Version to the Right File

Once the scanner can actually see the dropdown, something decides which script file to load:

if (versionDropdown) {
    let selectedVersion = versionDropdown.value.toLowerCase();

    if (selectedVersion.includes('v2')) {
        engineScriptFile = "tcjsgame-v2.js";
    } else if (selectedVersion.includes('v3')) {
        engineScriptFile = "tcjsgame-v3.js";
    } else if (selectedVersion.includes('v4')) {
        engineScriptFile = "epic.js";
    }
}

Notice engineScriptFile starts life as "epic.js" before this block even runs — so if no dropdown is found at all, or nothing matches, the playground defaults to V4 anyway rather than falling back to an older version. That's not fallback logic. That's a variable we forgot to reset, quietly doing the right thing by pure accident — the coding equivalent of surviving a disaster because you happened to fall asleep in the safest corner of the room.

What this taught us: sometimes your "fallback behavior" isn't something you designed — it's whatever your default variable happens to be. Worth checking that it's the safe default, not just a default, before you accidentally get credit for engineering discipline you didn't actually apply.

🖼️ The Part the Article Almost Skipped: What Actually Happens on "Run"

Once the right script file is picked, here's what the rest of runn() actually does — and it's more interesting than just "load a script tag":

It checks if you're not even using the engine at all. Before any of the version-routing logic runs, the function checks whether your editor code looks like raw HTML:

let hasHtmlTags = /<[a-z][\s\S]*>/i.test(userEditorCode) || userEditorCode.includes('<!DOCTYPE');

if (hasHtmlTags && iframe) {
    iframe.srcdoc = userEditorCode;
    return;
}

If you paste a full HTML document into the editor, the playground doesn't fight you about it. It just shrugs, decides "ah, you don craft your own thing," and runs your raw HTML straight through — like a landlord who stops asking questions the moment rent shows up on time. No engine, no version dropdown, no opinions. We hadn't thought to mention this branch in earlier drafts, but it's real, and a reader who hits it without knowing it's there will absolutely think something is broken.

Console output gets piped from the sandboxed iframe back to the editor UI. The generated preview document overrides console.log so that anything the user's game code logs shows up in a console panel in the parent editor, not just buried in the iframe's own devtools:

const _customLog = console.log;
console.log = function(...args) {
    _customLog.apply(console, args);
    const joinedArgs = args.map(arg =>
        typeof arg === 'object' ? JSON.stringify(arg) : arg
    ).join(' ');

    if (window.parent && window.parent.document) {
        const consoleDisplay = window.parent.document.getElementById('editor-console-logs');
        if (consoleDisplay) {
            const line = window.parent.document.createElement('div');
            line.textContent = joinedArgs;
            consoleDisplay.appendChild(line);
            consoleDisplay.scrollTop = consoleDisplay.scrollHeight;
        }
    }
};

That's genuinely a nice touch for a browser playground. Your console.log doesn't stay trapped in iframe jail — it climbs the fence, walks over to the parent window, and reports what it saw like a very well-behaved snitch.

Runtime errors get caught and reported automatically. If the user's code throws, the playground catches it and posts the error message to a webhook so we can see what's breaking for real users without waiting for a bug report:

try {
    ${userEditorCode}
} catch(err) {
    console.log("Engine Runtime Error: " + err.message);
    // error message dispatched to an internal alerts channel
}

We're intentionally not showing the actual webhook wiring here — it's a plain fetch call with a URL baked in, and an earlier draft of this article almost pasted that URL straight into the code block. We caught it before publishing, but only just. Publishing your own alert webhook URL in a public tutorial is the developer equivalent of posting a photo of your house key on Twitter with the caption "come design my kitchen." So: fixing that properly (move it behind a real backend endpoint instead of calling a webhook straight from client-side code) is next on the list, and until it's done, the URL stays out of anything we publish. Worth remembering if you're building something similar: a "just post to Discord" error reporter is fine for a personal project, but the moment the code that contains the URL is public — like, say, in a blog post — the URL is public too.

✅ The One We Actually Went Back and Fixed

Talk is cheap, so before publishing this version, we went and closed the loudest gap: the missing timeout. Here's what actually shipped.

First, the script tag inside the generated iframe gets an id and real onload/onerror handlers, plus a timeout in case the browser never fires either event:

<script id="engineScript" src="./${engineScriptFile}"></script>
<script>
    const ENGINE_LOAD_TIMEOUT_MS = 5000;

    const engineTimeout = setTimeout(() => {
        reportEngineLoadFailure('Engine timed out after 5s — check your connection or the script URL.');
    }, ENGINE_LOAD_TIMEOUT_MS);

    const engineScriptTag = document.getElementById('engineScript');

    engineScriptTag.onload = () => {
        clearTimeout(engineTimeout);
    };

    engineScriptTag.onerror = () => {
        clearTimeout(engineTimeout);
        reportEngineLoadFailure('Engine script failed to load — 404, CDN issue, or bad URL.');
    };

    function reportEngineLoadFailure(message) {
        if (window.parent && window.parent.document) {
            const banner = window.parent.document.getElementById('engine-error-banner');
            if (banner) {
                banner.textContent = "⚠️ " + message;
                banner.style.display = 'block';
            }
        }
    }
</script>

Second, runn() itself resets the banner at the start of every run, so a stale error from three runs ago doesn't sit there haunting someone who already fixed the problem:

let errorBanner = document.getElementById('engine-error-banner');
if (errorBanner) {
    errorBanner.style.display = 'none';
    errorBanner.textContent = '';
}

Same trick as the console piping from earlier — the sandboxed iframe reaches out to window.parent.document to update a banner that lives in the actual editor UI, not buried where nobody will see it.

Is this everything? No — the dropdown-renaming gap and the "which engine actually loaded" confirmation are both still open, and we're not going to pretend otherwise twice in one post. But this is the difference between a paragraph promising a fix and a code block that is the fix. One down.

🩹 What's Still Actually Missing

Here's the part we got wrong last time we wrote about this: we described hardening we hadn't actually built yet — a load timeout, an error banner, a fallback config object. Only the first two of those existed only as a paragraph back then. We fixed the timeout and banner for real, above. The rest still doesn't exist, and we're not going to pretend it does.

What the current runn() function still does not handle, as far as we can tell from the code itself:

Gap	Current reality
Dropdown label gets renamed without updating the matching logic	Still pure string matching, no fallback config object. If someone changes "Version 4" to something the scanner doesn't recognize, we're back to square one.
Confirming which engine actually loaded	The console piping shows game output, not engine version. There's no `console.log` confirming "epic.js (v4) loaded" anywhere in the real code — the new banner only fires on failure, not on success.

One honest caveat: we're describing the script-loading path specifically, not every corner of the editor — there's still some iframe styling elsewhere in runn() we haven't traced all the way through. If something down that path already touches error handling in a way we missed, consider this table mostly right instead of fully right. We'd rather flag the uncertainty than state it with false confidence.

Two down from three. All of them are still worth naming, which is a more honest place to leave this post than claiming they're all done.

🔁 What If V4 Just... Doesn't Work?

If epic.js fails to load or throws early, there's currently no automatic fallback to V3 — the developer has to manually reselect it from the dropdown. Combined with the missing timeout above, a broken V4 load can currently look identical to "the playground is just loading forever," with no clear signal to the user about what's actually wrong.

🗣️ Honesty About the Trade-offs

String-matching a dropdown label is not how a "serious" IDE would do this. Bigger tools use config manifests, package registries, versioned APIs — systems that don't fall apart just because someone renamed a label without checking the routing logic.

We know. We built it this way anyway, because Limn Engine is still small enough that a full config system would be more machinery than the actual problem deserves — for now. But we won't pretend the trade-off isn't there. If this editor grows past what it is today, string-matching is the first thing on the list to retire — right alongside the webhook that needs to move server-side.

What this taught us: "good enough for now" is a real engineering decision, not laziness in disguise — as long as you say it out loud instead of hiding it in the commit message. And "we fixed it" should mean the code changed, not just that we wrote a paragraph saying it did.

📊 What You've Learned

Concept	How It Applies
Silent failure	A missing condition doesn't crash — it quietly does the wrong thing
Default values as accidental fallbacks	Check whether your variable's default is actually the safe choice, not just a choice
Secrets in client-side code	Anything a browser can fetch, a reader can copy — webhook URLs and API keys don't belong in code that ships to the client
Write down what's still broken	A devlog that only shows the fix and skips the gaps isn't more impressive, it's just less useful

🚀 Final Thoughts

The routing fix that shipped was one line of code. Writing honestly about everything around that line — the parts that still don't work — took a lot longer, and mattered more.

If you're building anything that reads the DOM to make a decision — a dropdown, a data attribute, a class name — assume it will fail quietly before it ever fails loudly. And if you're going to write about your own fix, resist describing the version of it you meant to build instead of the one that's actually running.

Draw your game into existence — and make sure your dropdown knows which version to use. We're still working on the rest.

🔗 Come Say Hi

🌐 Try Limn Engine live (Version 4): limn-engine-doc.vercel.app
💻 Source & issues: GitHub
💬 Join the community: Discord

Your turn: what's your most embarrassing version-mismatch bug? Drop it in the comments — we promise ours isn't the worst one out there. 🎮

DEV Community: Olu Desire

We Built an Arcade for Our Own Game Engine

Or: how I spent three months using the platform we built at Evolved Tech, noticing what was broken, and refusing to stop

Part 1 — The Arcade

Part 2 — The Leaderboard (Which Nearly Broke Me)

Part 3 — Comments with Replies (The prompt() Mistake)

Part 4 — The Username Problem

Part 5 — The Two-Day Bug (Three Lines of Code)

Part 6 — The Inbox That Wouldn't Load

Part 7 — The Buttons Nobody Could See

Part 8 — Game Over → Play Again

Part 9 — The Features That Were Missing

Part 10 — What I Actually Learned

Part 11 — The Loop

Part 12 — What's Still Coming

What's New — At a Glance

Try It

Get Involved / Get Help

Credits

Limn Engine Just Got Smarter — Here's What We Added (And Why It Matters)

📋 The TL;DR (For Those Who Scroll First, Read Later — No Judgment)

The Problems That Kept Us Up At Night

🔐 Google OAuth: One Click, No Passwords — Live Now

🔗 Shareable Code Snippets: Collaboration Without The Crime Scene — Live Now

🔍 Universal Search: Find Anything, Instantly — Live Now

📱 Touch-Friendly Design: Build Anywhere — Live Now

💬 Inbox & Messaging: Stay Connected — Live Now

🎮 What's Next?

🙌 Join The Community

🏁 Final Thoughts

🔗 Links

🕹️ The Reinvention Tax: Why We Ditched Pure Scratch for Epic.js (and You Should Too)

📖 Introduction: The "We Can Build It" Syndrome

🪤 Sector 1: Falling Into the "Pure Scratch" Trap

🧯 Sector 2: Why Our Hand-Coded Architecture Packed Up (The Actual Technical Reason)

🔧 Sector 3: The Actual Fix — Object Pooling and Delta Time

Fix 1 — Object pooling (stop creating and destroying bullets)

Fix 2 — Delta time instead of fixed pixel steps

Where epic.js comes in (and where it honestly doesn't)

So when do you actually switch?

The difference, in numbers

🎓 Sector 4: Hard-Earned Lessons From the Trenches

📊 What You've Learned

🚀 Conclusion & What's Next

🔗 Come Say Hi

🛠️ How We Upgraded the Limn Engine Playground Editor for Version 4

📖 Introduction

🔍 The Problem Nobody Would Notice Until It Was Too Late

🧵 Teaching the Scanner to See V4

🎯 Routing the Version to the Right File

🖼️ The Part the Article Almost Skipped: What Actually Happens on "Run"

✅ The One We Actually Went Back and Fixed

🩹 What's Still Actually Missing

🔁 What If V4 Just... Doesn't Work?

🗣️ Honesty About the Trade-offs

📊 What You've Learned

🚀 Final Thoughts

🔗 Come Say Hi

Part 3 — Comments with Replies (The `prompt()` Mistake)