The Great Engine Debate: Powering Our Two-Person Devlog Project

We were sat in a cramped Brighton kitchen, two empty coffee cups between us, when the penny finally dropped. The prototype for our new browser game—a weird little physics toy we’d been sketching on napkins—was already on life support and we hadn’t opened a code editor yet. We had fallen into the trap every tiny indie team dreads: paralysing ourselves with engine choice before a single asset was made. This devlog is the candid story of how two people navigated that paralysis, flirted with building our own stack, wrestled with the giants, almost shipped catastrophe, and ultimately learned that shipping fast matters more than ideological purity.

The Romanticism of Building From Scratch

There’s a quiet fantasy that lives inside every developer who’s ever attended a Brighton Indies meetup. It whispers that you don’t need Unity, Godot, or Phaser—you just need a blank index.html, a canvas element, and the raw discipline to craft your own bespoke JavaScript framework. Our duo got dangerously close to chasing that dragon. We’d just left a talk where a solo dev proudly demonstrated their hand-rolled WebGL renderer, and suddenly the idea of total control felt intoxicating. No bloat, no licensing drama, just the code we actually needed. For about six days, we genuinely believed we could write a lightweight entity-component system, a touch-responsive input manager, and a spatial hash for collision detection in a week. Then we sat down and totted up the hours we’d already lost to boilerplate that had nothing to do with gameplay. Reality landed hard.

The Sunk Cost of Boilerplate Code

By the end of that first sprint, we had a half-baked scene graph, a hot-reload script that only worked on my machine, and zero game logic. Every modern engine solves input handling, audio pooling, and asset loading out of the box, but we were writing promise chains to load a single sprite sheet. When we calculated how much time we’d spent just to get a rectangle moving across a screen at a stable 60fps, we couldn’t justify throwing more evenings into the void. Our prototype needed to be playable, not a monument to our technical self-importance.

Why ‘Handmade Hero’ Is a Trap for a Duo

Casey Muratori’s Handmade Hero series is a magnificent educational resource, and it’s seduced many developers into thinking low-level control is the one true path. For a two-person team shipping a browser game prototype on a tight deadline, though, it’s a siren song. We don’t have the bandwidth to debug SIMD optimisations while simultaneously designing levels and recording a devlog. The DIY ethos we love in the Brighton indie scene has to meet the practical constraint of shipping before enthusiasm evaporates. So we killed the custom framework with no regrets and moved on.

Unity: The Comfort Blanket with Heavy Batteries

Unity felt like the obvious next step. Both of us had C# muscle memory, the editor is a mature beast, and the ecosystem gave us the illusion of velocity. For a few weeks, we happily dragged GameObjects around and hooked up UI prefabs. The friction started the moment we hit the Build button for WebGL. Our tiny prototype—a single scene with some 2D sprites and procedural audio—spat out a build folder that was north of 30MB. On a decent fibre connection it was fine, but on 4G at a playtest event it was the kiss of death. The bouncy charm of our browser game evaporated while a loading bar crawled across the screen. Then, in September 2023, Unity dropped its runtime fee bombshell and suddenly the comfort blanket felt like it was on fire.

The Asset Store: A Double-Edged Sword for Prototypes

The Asset Store’s promise of ready-made solutions is seductive. We grabbed a slick tweening library and a particle pack that slashed a week off our vfx work. The dark side? Each asset came with its own dependencies, and when Unity deprecated the built-in networking layer in favour of netcode packages, our prototype turned into a dependency management nightmare. We wasted an afternoon resolving GUID conflicts instead of playtesting. For a two-person team, that kind of overhead is pure poison.

When the Build Size Kills the Bounce Rate

We tracked early playtester behaviour with a tiny analytics stub. If the game didn’t reach the title screen within four seconds, 40% of browsers closed the tab. Unity’s WebGL export, even with aggressive stripping and Brotli compression, consistently sat at a 6–8 second cold load. That might be acceptable for a large interactive experience, but for a snackable browser game prototype, it was an existential problem. No amount of C# comfort could outweigh a bounce rate that made our numbers look like a cardiac flatline.

Godot: The Open-Source Upstart from the UK Scene

The turning point came during a frantic prototype sprint where we forced ourselves to try Godot 4. The install weighed less than 50MB, and within an hour we had GDScript running collision checks on a tilemap. That lightweight feeling is hard to overstate. The Godot community in the UK is also surprisingly tight-knit; knowing that studios like Robot Gentleman—the Brighton-based team behind 60 Seconds!—support the engine gave us confidence that we weren’t betting on an obscure toy. We attended a Manchester “Pizza, Pints & Playtesting” night where three other teams were also running Godot prototypes, and the collective knowledge sharing felt like a genuine multiplier. For the first time in this project, the tool wasn’t fighting us.

Why GDscript Feels Like Pythonic Home

Our backend dev had a Python background, and GDScript’s indentation-driven syntax meant zero cognitive translation between thinking and typing. That might sound like a minor quality-of-life win, but when you’re jamming on a game loop at midnight after a day job, removing syntactic friction saves precious mental energy. Signals replaced the Unity event manager we’d previously yanked hair out over, and the node-tree architecture forced us to compose scenes in a way that made the codebase surprisingly legible after even a week away.

Web Export Workflows That Actually Respect Our Time

Godot’s HTML5 export gave us a build that weighed 4MB, loaded in under two seconds, and ran smoothly on a mid-range Chromebook. The template system let us strip out everything we didn’t need without a fight. That meant we could push a new build, share the link in Discord, and have playtest feedback rolling in during our coffee break. When BFI funding programmes back UK indie game prototypes, they don’t care about engine ideology; they care about a playable link that works. Godot delivered exactly that.

Phaser and the Pure Web Stack Reality

In parallel, we spent a focused sprint evaluating Phaser, the framework originally created by Photon Storm, a UK-based developer whose roots in Brighton gave us an immediate sense of kinship. Phaser is not an editor-driven engine; it’s a true code-first web framework that feels like an extension of the browser rather than a guest inside it. The sheer speed of iteration was startling. No build step, no scene serialisation, just TypeScript running directly in the dev server. Had we been aiming for a pure browser game intended for portals like Newgrounds or Armor Games, Phaser would have been the no-brainer pick. Its footprint let us keep the prototype under 2MB and boot it in under a second, which felt like magic after our Unity ordeal.

Keeping the Prototype Spirit Alive in the Console

The developer console became our game design playground with Phaser. We could tweak gravity, spawn enemies, and hot-swap sprites by pasting commands into the browser. That immediacy reminded us why we fell in love with browser games in the first place: they’re ephemeral, instantly shareable, and dirt-cheap to iterate. The only significant drawback was the absence of a mature visual editor, which meant level design workflows required a bit more muscle. For a duo where one member prefers visual layout, that friction was real but manageable.

The Brutal Postmortem of Our First Playtest

Everything came to a head at a London playtest night held in a converted warehouse not far from Tobacco Dock, the home of EGX Rezzed (now EGX London) where we’d demoed spare-time projects before. We’d put our latest build—still running on that early Unity prototype—onto a borrowed laptop. Fifteen minutes in, the screen froze, the audio looped into a banshee shriek, and the entire browser tab collapsed. It was a WebGL out-of-memory crash triggered by our asset-heavy particle system. Standing there while a room full of fellow devs tried to refresh the page was our lowest moment. That night forced a brutal postmortem: our engine choice had directly broken the player experience.

Frame Rate Tears and the 60fps Promise

On a loaner machine with integrated graphics, our Unity build would hover at 52fps with visible screen tearing. We’d made a promise to ourselves—and to the devlog—that the prototype would feel buttery smooth. The postmortem spreadsheet we compiled at 2AM revealed that 70% of frame time was spent in Unity’s UI canvas rebuild. We’d built a game that worked brilliantly in the editor and fell apart in the wild. That’s not a performance problem; it’s a tool selection problem.

How Quick Iteration Saved the Project

We stripped the project back to raw mechanics, rebuilt the rendering pipeline in a lightweight context, and had a new build playable within 36 hours. The fast turnaround reignited our morale. That speed was only possible because we’d had the Godot and Phaser spikes already done, so we weren’t starting from zero. The lesson was searingly clear: the ability to pivot overnight is worth more than any feature checklist on an engine comparison page.

Our Final Verdict: Speed Over Dogma

After weeks of debate, spikes, and one very public crash, we landed on a split decision that our indie game devlog will now follow. For purely browser-based prototypes where fast sharing and instant loading trump all other concerns, Phaser is our daily driver. The fact that it was born in the UK games scene, and that we can deploy a link to a playable build before the kettle boils, aligns perfectly with our need to keep the devlog momentum alive. For prototypes that might eventually need a native build or a more complex 2D world system, Godot has earned a permanent spot in our toolbelt. Unity, despite its power, simply cannot justify its WebGL weight for the kind of snackable browser game we’re making. That runtime fee panic of September 2023 was the final shove out the door.

The ‘Good Enough’ Engine Manifesto

We’ve written a small internal manifesto pinned above my desk: the engine has to be good enough to disappear. If we’re spending more time fighting the tool than building the game, it’s the wrong tool. For a two-person team with no funding beyond a small BFI grant application and the occasional pizza bribe, the engine that drops the fewest obstacles between idea and playable link wins. Every time we’ve chosen romantic complexity over boring simplicity, the devlog has suffered.

Whichever engine we reach for on any given Tuesday, the takeaway from this entire process is embarrassingly simple: the player does not care about our technology stack. A united duo wielding a boring, well-understood tool will always ship a more enjoyable prototype than a fractured team fighting over the newest architecture. The engine serves the game, not the other way around, and the moment we truly internalised that, our browser game prototype finally started to feel alive.

FAQ

Why didn’t you just use the Unity Tiny mode or Project Tiny?

We explored the lightweight DOTS-based solutions, but the tooling felt experimental and the documentation wasn’t mature enough for our deadline. The overhead of adapting our existing prototype would have eaten more time than migrating to a genuinely web-native engine like Phaser.

Is Godot production-ready for a commercial browser game in 2025?

Absolutely. With Godot 4’s improved Web export templates and growing adoption in the UK indie scene—including support from established studios like Robot Gentleman—we are confident shipping commercial prototypes with it. The HTML5 threading support has matured significantly, making it viable for substantial titles.

What’s the biggest hidden cost of switching engines mid-prototype?

The hidden cost is team momentum. Every engine change involves re-building custom tooling, re-learning input quirks, and re-gaining comfort with the debugging workflow. For a two-person team, a week of lost productivity can feel like a month, which is why we recommend spiking multiple engines before committing any production art.

How did the BFI funding influence your engine choice?

British Film Institute prototyping grants place a heavy emphasis on a playable deliverable that can be evaluated quickly. They don’t mandate any specific technology, but the need to produce a lightweight, easily distributable browser build pushed us away from bloated exporters and towards frameworks that prioritise web delivery.

Would you still consider Unity for a future project?

We would, but only for a project that targets native platforms from day one and has no immediate need for a tiny WebGL footprint. The runtime fee resolution of late 2023 eased some anxieties, but the fundamental WebGL performance profile hasn’t changed enough for our browser-first pipeline.