Battling the Blob: How We Ruthlessly Cut Features to Save Our Indie Game

It was a drizzly Tuesday evening in our cramped London flat, the kind where the cost of living crisis makes you hyper-aware that every kilowatt-hour of electricity is burning through a rapidly dwindling budget. We were staring at a build of our browser game prototype that took nearly four minutes to load. The UI was a labyrinth. The crafting system, which we’d publicly hyped in our indie game devlog just a fortnight prior, crashed if you combined a stick with a specific shade of blue mushroom. That was the moment the gut-punch landed. We weren’t making a game anymore; we were nursing a bloated, unshippable creature that was devouring our savings and our sanity. We had to pick up the scalpel.

The Sunk Cost Fallacy in Our Prototype Phase

The heart of our problem wasn’t a lack of skill, but a surplus of misplaced love. During the initial prototype, we became obsessed with a complex alchemical crafting system. It wasn’t just mixing potions; it involved planetary alignments, material purity percentages, and a runic language we invented from scratch. We spent six weeks perfecting the logic, telling ourselves it was the unique selling point that would get us noticed at the next London indie meetup. Deep down, we knew it was a confusing mess, but we’d poured so much sweat into the code that abandoning it felt like admitting defeat. According to a recent UKIE report, the average indie development timeline overruns by nearly 40%, and looking back, our over-engineering was a textbook case of self-sabotage.

When a Feature Becomes a Pet Project

The alchemy system had stopped being a game mechanic and had become a pet project. We were adding layers of complexity not because they made the browser game more fun, but because they were intellectually satisfying to solve. We’d stay up late, not to squash bugs in the core loop, but to debate the thermodynamic properties of fictional elements. It was the kind of niche rabbit hole that reminded us of the obscure demon door puzzles in the classic British-developed game ‘Fable’—wonderful in isolation, but only working because they sat on top of an already solid foundation. We didn’t have a solid foundation yet. We had a chemistry simulator stapled to a walking simulator.

Calculating the Real Cost of ‘Just One More Fix’

The phrase “just one more fix” was a siren song leading us onto the rocks. We calculated the real cost not just in time, but in opportunity. Every hour spent trying to make the runic interface parse player input correctly was an hour stolen from the actual gameplay. We were months away from a viable product, and the financial pressure of the UK’s economic squeeze meant we couldn’t afford a hobby project. We needed a sellable game. The prototype had to pivot from a technical showcase of what we *could* code, to a tight experience players would actually pay for.

Death by a Thousand Paper Cuts: Identifying the Bloat

Once we admitted we had a problem, we needed to find the tumours. We sat down with our entire indie game devlog history and mapped every single feature we’d ever mentioned or built against the game’s core pillar: “A fast-paced, replayable tactical brawler.” The disconnect was staggering. We had a deep fishing mini-game, a relationship tracker with non-playable characters, and a dynamic weather simulation that would have made a meteorologist weep. None of them helped you punch an enemy in the face. We had fallen into the trap of adding ‘stuff’ to mask the fact that the core fight mechanics weren’t yet sharp.

Auditing Against the Core Pillar

We printed out a list of every mechanic and stuck it on the wall. With a red marker, we brutally crossed out anything that didn’t directly support the “tactical brawler” fantasy. The fishing? Gone. The friendship bracelets? Gone. It was a bloodbath, but a necessary one. We were inspired by a recent trip to the National Videogame Museum in Sheffield, where seeing the stripped-back, pure gameplay loops of retro classics reminded us that fun doesn’t come from feature lists; it comes from a perfectly tuned core interaction. We were suffocating our game under a pile of bullet points.

The Weather System That Had to Go

The most painful cut was the dynamic weather system. It was technically brilliant. A low-pressure system would roll in, realistically affecting visibility and leaving puddles that could conduct electricity. But in a fast-paced brawler, the player was moving too quickly to notice the subtle atmospheric pressure changes. It was a beautiful piece of simulation that didn’t serve the fun. It was a feature designed for a slow-burn role-playing game, not our browser game prototype. We were forcing a Tomb Raider-esque isolation atmosphere into a game that needed to feel like a bar fight.

The Cold, Hard Feature Triage Meeting

With our red-stained list, we called a team meeting that felt more like an intervention. The atmosphere was tense. We knew we were about to kill our darlings. To stop the conversation spiralling into subjective arguments, we introduced a strict priority matrix. We plotted every remaining feature on a graph with axes labelled ‘Impact on Core Fun’ and ‘Implementation Effort’. Suddenly, the arguments stopped. The alchemy system, which required high effort but had low impact on the brawling, was mathematically doomed. It wasn’t personal anymore; it was just a dot in the wrong quadrant.

Separating Ego from Evidence

The matrix was the best tool we’ve ever used for conflict resolution. It removed the ego from the equation. One team member had spent weeks on a complex enemy armour degradation system. When plotted, it sat firmly in the ‘high effort, medium impact’ zone. The data made the argument for us. We weren’t saying the code was bad; we were saying the numbers proved our time was better spent elsewhere. This cold, hard approach is something we now preach at every London game dev gathering, especially at the Loading Bar meetups in Dalston, where post-mortems over a pint often reveal the same universal truths about scope creep.

Introducing the ‘Post-Launch’ Bargaining Bin

To soften the blow, we created a ‘Post-Launch’ bin. This wasn’t a graveyard; it was a promise to ourselves and our community. The fishing mini-game and the weather system went there. It allowed us to say “not now” instead of “no forever.” This psychological trick stopped people from clinging to their work. It gave us a clear, clean slate for the vertical slice we needed to finish. The bargaining bin saved our morale, even if we secretly knew most of those features would never see the light of day once we started reacting to real player feedback.

Surgical Removal: Cutting Without Breaking the Build

Deciding to cut is one thing; physically ripping the code out is another. Our biggest technical challenge was removing a half-finished synchronous multiplayer mode. We had promised a cooperative experience in our indie game devlog, but the netcode was a nightmare, and the UK player base for a niche browser game simply wasn’t large enough to sustain matchmaking. However, the multiplayer logic was woven into the very fabric of the player controller. Pulling one thread threatened to unravel the entire single-player experience.

Unravelling the Spaghetti Code Safely

We couldn’t just delete the files. We had to perform surgery. We spent three days tracing dependencies, isolating the network tick rate from the local game loop. It was a painstaking process of commenting out large blocks, running the game, watching it crash, and slowly stitching it back together. The goal was to leave the single-player movement feeling exactly as it did before, just without the invisible ghost of the network manager trying to sync a second player who wasn’t there. It was tedious, but the alternative was leaving dead weight in the browser game that would cause untold future bugs.

Why We Tested More After Cutting Than Before

Paradoxically, we spent more time on quality assurance after the cuts than we did during the entire bloated feature-building phase. We ran rigorous regression tests on every single level. We checked hit detection, enemy artificial intelligence pathfinding, and menu navigation. A removal isn’t free; it leaves scars. We found that removing the multiplayer had subtly broken the pause menu because the game was still trying to check for a ‘host’ privilege. It was a stark reminder that cutting scope requires just as much discipline as adding it, if not more.

The Postmortem: Did We Cut the Right Bits?

Weeks later, we released the streamlined prototype to a small group of players from our UK community. The silence before the feedback was terrifying. Had we gutted the soul of the game? The response was a wave of relief. Players praised the “snappy” combat and the lack of “faff.” They didn’t miss the alchemy because they never really understood it in the first place. The death of the weather system went completely unremarked. It turned out that nobody plays a brawler to check if it’s raining.

Community Reaction and Silent Relief

One comment on our devlog stood out: “It finally feels like a game, not a tech demo.” That was the silent relief we needed. We had been holding our breath, terrified of backlash for cutting announced features. Instead, we found that players are far more forgiving of a focused, polished experience than a messy one that tries to do everything. The cost of living crisis had forced our hand, but it forced us to respect the player’s time and money. They didn’t want a sprawling, broken epic; they wanted a tight, replayable browser game that worked.

Lessons Learned for Our Next Game Jam

We’re taking these hard-won lessons into our next game jam. We now start with the ‘cut’ list before we write a single line of code. We define the core pillar and guard it with our lives. We learned that the most creative act isn’t dreaming up a complex feature, but finding an elegant way to evoke the same feeling with a simpler system. We stopped trying to be the next ‘Fable’ with its sprawling systems and started trying to be the best version of our own small, focused idea. The scalpel is now the most important tool in our kit.

Cutting scope isn’t a failure of creativity; it is the most disciplined creative act in game development. It is the process of chipping away the stone to reveal the statue underneath. We started with a bloated blob of code and a trail of broken promises to our community. By making the hard cuts, we salvaged a shippable game from the wreckage of our ambition. We didn’t just save our browser game prototype; we saved our team. The result isn’t a compromised vision, but a refined one, finally sharp enough to cut through the noise.

FAQ

How do you know when a feature is just bloat?

We use the ‘core pillar’ test. If removing a feature doesn’t make the core gameplay loop worse, it’s probably bloat. If you can describe your game without mentioning that feature, it likely isn’t essential to the player’s fun.

Isn’t cutting features a waste of development time?

This is the sunk cost fallacy talking. The time is already spent. The real waste is throwing more good time after bad trying to fix a feature that doesn’t serve the game. Cutting it frees you up to polish the mechanics that actually matter to the player.

How do you handle community backlash from cutting announced content?

Be honest and transparent. Explain *why* you cut it, focusing on the benefit to the overall game quality. Most players will forgive a cut if the final product is polished and fun. They are far less forgiving of a broken, bloated mess that tried to keep a dead feature alive.

What is a priority matrix in game development?

It’s a visual tool we use to rank features. We plot every task on a graph based on ‘Impact on Player Experience’ versus ‘Effort to Implement’. Anything in the ‘Low Impact/High Effort’ quadrant gets cut immediately. It removes personal bias and ego from the decision-making process.

Writing a Devlog That People Actually Read: Our Team’s Hard-Won Lessons

Let’s be brutally honest: our first six devlog entries received exactly zero comments. Not a single “cool prototype” or even a spam bot. Just deafening, soul-crushing silence. We’d publish a detailed breakdown of our latest browser game mechanics, close the laptop, and wait. Nothing. It felt like shouting into the void while everyone else chatted in the next room. Today, our Discord pings constantly when a new entry drops. The difference wasn’t a marketing budget or a viral tweet. It was learning that a devlog isn’t a soapbox—it’s a campfire. Here’s exactly how we turned that silence into a conversation.

Why Most Indie Game Devlogs Fail to Find an Audience

The graveyard of abandoned devlogs is vast, and we nearly joined it. The culprit is almost always the same: developers treat their blog like a personal diary rather than an exchange of value. We’d write entries reading like clinical changelogs—”Implemented A* pathfinding, refactored sprite batching, updated UI elements”—and expected applause. Nobody, not even fellow developers, cares about what you did unless they understand why it was a nightmare to do it. Stunning browser game prototypes with buttery-smooth 60fps performance get ignored because the writing feels sterile, devoid of the cold coffee and quiet desperation that actually went into the build.

The indie space is too noisy for the “build it and they will come” mentality. Your code might be elegant, but if your headline reads “Devlog #4: Inventory System Updates,” you’ve already lost. Discoverability requires narrative friction. The mindset shift happened when we stopped writing for an audience and started writing for collaborators. Instead of announcing a feature, we’d present a dilemma. This reframe invited readers to weigh in, transforming passive lurkers into invested contributors who genuinely cared if our physics engine imploded.

Finding the Narrative Hook in a Simple Prototype

Not every week involves a catastrophic server meltdown. Most of game development is mundane problem-solving. The skill lies in extracting gripping stories from boring tasks. We learned this when a minor browser game collision glitch—a character clipping through a wall—became our most shared post of the year. We didn’t just fix the bug; we turned the debug process into a whodunnit. The UK indie collective spirit, absorbed wandering the halls of EGX Rezzed in London, taught us that players are fascinated by human conflict, not technical perfection.

Instead of writing “Fixed collision bug,” we documented the moment we realised the vector math was gaslighting us. We showed red error logs spamming the console. We detailed three false hypotheses we chased before finding the real culprit hiding in a floating-point rounding error. This structure—mystery, dead ends, resolution—transforms a dry report into a page-turner. We also developed a technique we call the pivot: open with a technical hurdle, then immediately pivot to the emotional state it induced. “The pathfinding grid was misaligned by 0.1 units, and I genuinely questioned my career choices for forty-five minutes.” That sentence signals technical competence while being disarmingly human.

Structuring the Perfect Postmortem That Doesn’t Feel Dead

A traditional postmortem can feel like an autopsy: cold, retrospective, and lifeless. We’ve adopted a “living postmortem” format that documents failures while wounds are still fresh, avoiding the polished hindsight bias sanitising so many industry write-ups. We took heavy inspiration from Roll7, the London-based studio behind OlliOlli. Their transparency about creative friction is disarming without veering into self-deprecating cringe. They don’t brag or grovel—they simply state hard truths with a stiff upper lip, a very British trait we’ve tried to emulate.

We dedicate 70% of any postmortem to the disasters. Did we scope creep a simple browser game prototype into a six-month quagmire? Absolutely. Did we ignore playtester feedback because we were precious about a mechanic? Guilty. Sharing these specifics builds credibility faster than listing achievements. When presenting analytics, we avoid dry tables of retention stats. Instead, we visualise the cliff edge where players dropped off and speculate on the emotional reason: “87% of players quit the moment the crafting tutorial popped up—and honestly, we don’t blame them. The UI was a car crash.” Weaving data into a story of player psychology turns analytics from a spreadsheet into a confession.

Making Your Browser Game Devlog Visually Unskippable

A wall of text is a bounce-rate machine. No amount of lyrical prose can convey the juicy feedback loop of a satisfying jump arc. We enforce a strict rule: break text every 200 words with a bespoke GIF or embedded video. We studied Mediatonic’s early devlog output and noticed how their tactile UI posts set a gold standard for readability. Their posts felt less like blogs and more like interactive design documents.

Since implementing the visual break rule, our average time on page has doubled. A tightly looped 2-second GIF showing a before-and-after character animation comparison communicates more in a glance than a 500-word paragraph ever could. We obsess over short loops isolating a single satisfying interaction: a screen-shake on impact, a squash-and-stretch inventory pop, or the frame where a combo counter ticks over. These micro-moments are the dopamine hits making a browser game prototype feel alive. If the GIF itself feels good to watch on repeat, the game likely feels good to play.

Distribution: Why Your Devlog Needs a Second Life Beyond Your Blog

Publishing a post is only 20% of the work. The remaining 80% is distribution. We systematically repurpose a single devlog into five distinct content pieces. The long-form post sits on our site for SEO and depth, but we carve it into snackable formats tailored to specific platforms. The HTML5 game development subreddit gets a technical deep-dive excerpt, Twitter receives the flashiest GIF with a pithy observation, and our mailing list gets the personal, behind-the-scenes anecdote. Crucially, we tailor the tone for a UK-centric audience that appreciates dry wit and self-awareness over aggressive hard selling.

Nobody clicks a link screaming “MARKETING.” We craft social posts providing standalone value—a quick tip, a relatable fail, or a hot take on engine limitations. The link to the full devlog is almost an afterthought, a “read more if you fancy” rather than a desperate plea. This Trojan Horse approach builds trust. Additionally, Itch.io isn’t just a hosting platform; its devlog system is a built-in discovery engine. We cross-post every entry directly to our game’s Itch.io page, where the audience is already primed to play browser-based experiments. The tagging system surfaces our prototype to users browsing specific genres, creating passive discovery a standalone WordPress blog cannot match.

Building a Community That Writes the Devlog With You

The ultimate unlock was shifting from broadcasting to co-creating. We stopped treating the devlog as a finished product and started using it as a collaborative workspace. This mirrors the ethos thriving in the Bristol-based indie scene, where the “work-in-progress” mentality reigns supreme at local meetups. Developers in Bristol don’t wait for a polished vertical slice; they bring broken builds and half-baked ideas to the pub. We’ve digitised that spirit by embedding playable browser game builds directly into posts, turning passive readers into active playtesters.

Asking “What do you think?” is useless—too broad, inviting vague platitudes. We’ve learned to ask painfully specific questions: “Does the jump arc feel too floaty compared to Celeste, or is the gravity too low?” This constraint forces a reader to boot up the prototype and form a genuine opinion. Specificity signals their feedback will actually be actioned, dramatically increasing comment rates. We embed the prototype directly beneath the fold. A reader hits the page, scans the hook, and immediately has a playable tab open. This isn’t just convenience; it’s about dwell time metrics. When someone plays the game for three minutes directly on the page, search engines interpret that as a strong quality signal. The devlog becomes an experience, not just an article.

A thriving devlog isn’t a product of marketing savvy or algorithmic luck. It’s the natural byproduct of cultivating a genuine, shared obsession with the messy, non-linear process of creation. When you invite people into the trenches—showing broken builds, naive assumptions, late-night fixes—they stick around not just for the game, but for the story of its survival. Stop trying to sound like a polished studio and start documenting the beautiful struggle. Your next entry is waiting, and this time, someone will actually be listening.

Frequently Asked Questions

Here are the questions we get asked most often about running an indie game devlog:

• How often should we publish? Consistency trumps volume. We’ve settled on a bi-weekly cadence. Weekly was burning us out and led to thin, low-effort posts. Monthly was too sparse and caused our audience to forget we existed. A solid post every two weeks gives you enough time to actually build something worth writing about while keeping your project fresh in the community’s mind.
• Is Itch.io better than a personal website for hosting a devlog? It’s not an either/or situation; it’s a dual strategy. We maintain the canonical long-form post on our own domain for SEO longevity, but we always mirror the content to our Itch.io devlog page. The Itch.io audience is highly engaged and specifically looking for experimental browser games, making it an unparalleled discovery tool that a standalone site can’t replicate alone.
• What if our prototype is too ugly to show publicly? Show it anyway. Some of our most successful posts featured nothing but grey-box geometry and programmer art. The indie community values mechanical honesty over visual polish. If the core loop is interesting, placeholder assets won’t scare people off. Sharing the ugly, early stages often builds stronger emotional investment in your project’s eventual glow-up.
• How do we avoid sounding negative in a postmortem? Focus on facts and solutions, not blame. There’s a distinct line between brutal honesty and self-deprecating misery. We channel the tone of studios like Roll7: acknowledge the mistake clearly, explain the context that led to the poor decision, and detail the concrete steps you’re taking to fix it. The narrative should be one of competence gained, not confidence lost.
• What’s the single biggest mistake new devlogs make? Writing for themselves instead of the reader. Every sentence should either teach something, entertain, or invite participation. If a paragraph only serves to document your personal progress without offering a takeaway, cut it ruthlessly. Your devlog competes with every other form of content on the internet—make it worth someone’s limited attention.

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.

How We Triage Bugs as a Tiny Indie Team: A Devlog Postmortem

It was 11:47 PM in our Manchester flat-turned-studio, and the tea had gone cold again. We were staring at a browser game prototype that had decided, with spectacular timing, to hard-crash Google Chrome every single time a player touched the inventory icon. A playtest with eight fellow devs was scheduled for nine the next morning. One of us suggested cancelling. Another was already knee-deep in the console, muttering about a misbehaving WebGL call. That night, we didn’t just fix a bug—we realised our entire ‘fix-as-we-go’ philosophy was a house of cards. This devlog postmortem unpacks how that moment forced us to build a bug triage system that actually works for a tiny indie team, and what the data from our last three prototype cycles revealed about where our time really vanishes.

The Breaking Point: Why We Needed a System

Before that night, our approach to bugs was proudly organic. Someone spotted a glitch, shouted across the room, and whoever felt least buried in their current task would dive in. For a solo hobby project, that’s fine. For a team of three juggling a browser game prototype, a UK Games Fund grant application, and the creeping anxiety of Manchester’s rising cost of living, it was a disaster. The breaking point wasn’t just the crash itself—it was the two hours of duplicated effort that followed, because we hadn’t realised two of us were trying to patch the same corrupted save-state logic from different angles.

The Playtest That Almost Wasn’t

We’d booked that playtest session weeks in advance, carving out time during a lull between the chaos of EGX London 2024 and our next milestone deadline. The prototype was a narrative-driven browser game built in Phaser, and we’d been so focused on getting the dialogue trees to feel right that we’d neglected systematic testing. When the crash surfaced, our immediate reaction was panic-fixing—a frantic, adrenaline-fuelled scramble that introduced two smaller regressions we only caught because a playtester’s laptop was running an older version of Mozilla Firefox that handled the canvas element differently. The session happened, barely, but the feedback we received was coloured by instability we should have caught days earlier.

Identifying the Real Cost of Context Switching

What stung most wasn’t the late night—it was the creative hangover. The day after that playtest, none of us wrote a single line of meaningful code. We were fried. Context switching, we learned, isn’t just a productivity buzzword; it’s the silent killer of indie game devlog momentum. Every unplanned bug fix yanks a developer out of their creative flow, and for a tiny team, that cognitive reset can eat an entire morning. We started tracking it informally and found that a single unplanned interruption cost us, on average, forty-five minutes of productive design work. Multiply that by three people and a dozen surprise bugs per sprint, and the maths was grim.

Defining Severity When Everything Feels Urgent

When you’re sleep-deprived and staring at a red error log, every bug feels like a five-alarm fire. We needed a shared language to cut through the noise. Rather than adopting a rigid corporate scale, we built a subjective one tailored to the realities of a browser game prototype where polish isn’t always the priority. Our scale now runs from ‘Crasher’ to ‘Cosmetic’, with a special category we call ‘Comment Section Fuel’—because if a player on itch.io will publicly eviscerate us for it, it jumps the queue.

Crashers vs. Softlocks in the Browser

We draw a hard line between a crasher that dumps the player back to the desktop—or, in our case, freezes the browser tab entirely—and a softlock that traps the character behind a rock but leaves the game running. Crashers are instant P0 tickets, no questions asked. Softlocks get a severity rating based on how close they sit to the critical path. During our last prototype, a softlock in the tutorial level was treated as a crasher because it blocked first-time player retention; the same softlock in a hidden easter-egg room was marked P3 and sat in the backlog for two weeks. Browser-specific crashers, like the one that only manifested in Chrome’s V8 engine after a specific garbage-collection cycle, get their own sub-label so we can test in isolation.

The ‘Itch.io Comments Section’ Priority Factor

We have a rule: if a bug would generate more than three comments calling it out on our itch.io page, it gets bumped one severity level. It sounds flippant, but it’s grounded in reality. The indie game devlog community is wonderfully vocal, and early prototype players are often more forgiving of missing content than they are of a UI element that overlaps unreadably on a 1366×768 laptop screen. That specific bug—a CSS flexbox issue in our dialogue panel—sat at P4 until we imagined the comments. It was fixed by lunchtime.

The 10-Minute Stand-Up Triage Ritual

Every morning at 9:30, mugs in hand, we gather around a single monitor and triage. The entire ritual is capped at ten minutes. If a discussion threatens to spiral, we table it and the most senior dev on the feature makes the call. The goal isn’t consensus; it’s clarity. By 9:40, every new bug report from the previous day has a severity label, an owner, and a rough sprint placement. This tiny investment has saved us more hours than we can count.

Tools We Actually Use (And the Ones We Ditched)

We started with Jira because it felt ‘professional.’ We lasted three weeks. For a team our size, the configuration overhead was absurd. We switched to a shared Trello board with four columns—’Reported,’ ‘Triaged,’ ‘In Progress,’ ‘Verified’—and a handful of labels for severity and browser type. GitHub Projects now handles our code-linked tickets, but Trello remains our visual triage dashboard. The simplicity is the point. We also experimented with a Discord bot that logged bugs from chat messages, but it created too much noise. Now, bugs live in Trello or they don’t exist.

Assigning the ‘Fixer’ vs. the ‘Verifier’

One rule we stole from a talk at EGX London 2024: the person who fixes a bug is never the person who verifies it. On a team of three, that means verification often falls to the person whose domain is furthest from the fix—our narrative designer verifies engine patches, our programmer verifies UI fixes. It’s not about distrust; it’s about fresh eyes. We’ve caught so many ‘fixed’ bugs that still failed on Firefox because the fixer only tested on Chrome. The verifier’s job is to be the grumpy player who does everything wrong.

The Art of the ‘Won’t Fix’ for a Prototype

Closing a bug without fixing it feels like failure. But for a prototype, knowing what not to fix is a survival skill. Our last browser game prototype had a crafting system that generated seventeen bug tickets. We closed fifteen of them as ‘Won’t Fix’ after a brutally honest postmortem revealed the crafting loop wasn’t fun enough to justify the stability cost. That decision shaved two weeks off our timeline and let us polish the dialogue system that players actually cared about.

Killing Your Darlings to Save the Build

There’s a particular pain in cutting a feature you’ve already prototyped and shown in a devlog update. Our crafting system had its own devlog post, complete with GIFs and enthusiastic comments. Killing it felt like a public retreat. But the Interactive Entertainment Law considerations around our UK Video Games Tax Relief claim meant we needed a stable, playable vertical slice for our evidence package—and no amount of crafting charm would matter if the build crashed during the assessor’s review. We framed the cut not as a failure but as a strategic descoping, and the devlog post explaining it became one of our most-read updates.

How We Document ‘Never-Fix’ Decisions for the Future

Every ‘Won’t Fix’ ticket gets a short postmortem note explaining why. Not just ‘out of scope,’ but the specific reasoning: ‘Crafting UI conflicts with our dialogue-layer z-indexing; not worth refactoring for a prototype.’ These notes are gold when we revisit the concept for a full release or a new prototype. We also tag them with the prototype version number so we can filter them later. During our UK Games Fund grant application, we actually referenced these documented decisions as evidence of our iterative design process—turning what felt like a graveyard of dead features into a portfolio of disciplined scoping.

Postmortem: What Our Triage Data Tells Us

After three full prototype cycles, we crunched the numbers. Across 214 logged bugs, a clear pattern emerged. Browser compatibility issues accounted for 38% of all tickets. UI bugs—misaligned elements, unclickable buttons, font rendering quirks—made up 31%. Physics and gameplay logic bugs sat at 22%, with the remaining 9% spread across audio, save systems, and miscellaneous gremlins. Those percentages shifted our entire pre-production approach.

Common Browser Compatibility Culprits

Google Chrome and Mozilla Firefox remain our primary testing targets, and they disagree on more things than we ever expected. Firefox’s handling of the Web Audio API consistently produced crackling in our ambient sound layers that Chrome played cleanly. Chrome’s aggressive caching sometimes served stale JavaScript bundles after a hot-reload, leading to ‘bugs’ that didn’t actually exist in the current build. We now maintain a living document of known browser quirks, and every new team member reads it during onboarding. The biggest culprit across all three cycles? CSS Grid behaviour inside iframe embeds on itch.io—a nightmare we’ve learned to test first, not last.

Turning Bug Trends into a Pre-Production Checklist

That 38% browser compatibility figure was a wake-up call. We now run a pre-production checklist before writing a single line of game logic: test the empty canvas on Chrome and Firefox, verify audio context initialisation, check the viewport scaling at three resolutions, and confirm that the itch.io embed sandbox doesn’t break our input handling. It takes thirty minutes and has eliminated an entire category of late-stage panic. The checklist is a living document, updated after every postmortem, and it’s become the most boring but valuable asset in our toolkit.

Balancing Triage with Creative Momentum

Rigid triage can sterilise a project. The spark that makes an indie game devlog worth following often comes from unplanned experimentation—the kind that generates messy, low-severity bugs by its very nature. We’ve learned that the goal isn’t to eliminate chaos but to contain it, so it doesn’t poison the parts of the build that need to be stable.

Scheduled ‘Chaos Hours’ vs. Structured Sprints

Every Friday afternoon, our sprint rules relax. Chaos Hours are a two-hour window where anyone can prototype anything, no tickets required, and bugs discovered during that time don’t enter the triage queue unless they affect the main branch. We branch off, experiment wildly, and either merge the results into a feature branch or discard them entirely. This rhythm—four days of structured sprint, one afternoon of creative freedom—has kept morale high even as Manchester’s indie scene grapples with the rising cost of living and the pressure to monetise earlier than ever. Some of our best devlog content has come from Chaos Hour experiments that were never meant to ship.

Protecting the Devlog Narrative from Technical Noise

Our devlog isn’t a changelog. Readers don’t need to know about every CSS fix or WebGL edge case. We protect the narrative by filtering what reaches the public: bug fixes become devlog content only when they teach something universal or reveal something about our process. This postmortem is an example—the crafting system cut became a story about scoping discipline, not a list of closed tickets. The triage system itself, the behind-the-scenes plumbing, stays invisible so the devlog can focus on design, art, and the human experience of making games.

Conclusion

Bug triage, done right, is a mental health tool disguised as a workflow. It shields us from the crushing feeling that the build is perpetually broken and we’re perpetually behind. It gives us permission to close tickets, to say ‘not now,’ to protect the hours when we’re actually making something new. For a tiny indie team documenting their journey through devlogs, that protection is everything. The chaos of that late-night crash in our Manchester flat taught us that passion alone can’t ship a browser game—but a lightweight, honest triage process can keep that passion burning long enough to cross the finish line.

FAQ

How do you handle bug triage when the whole team is working remotely?

We’ve experimented with remote stand-ups during periods when one of us was travelling, and our ten-minute ritual translates surprisingly well to a quick video call with screen sharing. The key is keeping the Trello board visible to everyone and resisting the urge to extend the meeting. Async triage via Slack threads failed for us—too much back-and-forth, not enough decisions.

What’s the most common browser-specific bug you encounter in prototypes?

Without question, it’s CSS Grid and flexbox behaviour inside itch.io’s iframe embed. Firefox and Chrome handle the constrained viewport differently, and elements that look perfect in a local build can overlap or vanish entirely once embedded. We now test inside an iframe from day one of UI development.

Do you use automated testing for your browser game prototypes?

Not yet, and that’s a deliberate choice. Our prototypes shift too rapidly for automated tests to be cost-effective. We rely on manual testing checklists and our verifier system instead. For our next project, which has a longer lifespan, we’re exploring Playwright for basic smoke tests across Chrome and Firefox.

How did your triage process affect your UK Games Fund grant application?

Surprisingly positively. The documented ‘Won’t Fix’ decisions and bug trend analysis demonstrated a mature, iterative development approach. The assessors specifically noted our postmortem data as evidence that we understood our technical risks—something that strengthened the application considerably.

What’s the one tool you’d recommend for a tiny indie team starting triage?

A simple Trello board with no more than four columns and a handful of labels. Resist the urge to over-configure. The value isn’t in the tool; it’s in the daily ritual of looking at the queue together and making decisions quickly. Fancy automation can come later, if at all.

Crafting a Zero-Budget Art Pipeline: Our Indie Game Devlog Postmortem

We were three weeks into prototyping when the email landed. “Your Creative Cloud trial expires in 7 days.” Our lead artist stared at the screen, then at our barely-functional browser game prototype, and uttered a phrase that still echoes through our Manchester flat. “We’re buggered, aren’t we?” That moment of collective dread, staring down the barrel of fifty quid a month we simply didn’t have, forced us to scrap everything. Every layered Photoshop file, every Illustrator asset. Gone. What followed was a frantic, occasionally tearful, but ultimately transformative rebuild of our entire visual workflow. This is the postmortem of that pipeline.

The Brutal Postmortem of Our Failed Paid Pipeline

We’d built our initial prototype on borrowed time, coasting on the generosity of seven-day trials and a single educational licence about to expire. The work looked polished, but it was built on sand. When recurring subscription costs hit our hobbyist team, the maths didn’t work. We were building a free browser game with no funding, no publisher, and no guarantee anyone would play it. Tying our creative output to a monthly bill that could buy a week’s groceries felt reckless.

When the Creative Cloud Trial Runs Dry

Panic set in fast. Files became inaccessible unless we committed to a plan. Our artist had crafted beautiful, multi-layered character textures that suddenly became digital hostages. We briefly considered cracked software, but the risk to our project’s integrity, not to mention malware potential, shut that conversation down. The ticking clock forced a hard reset and a brutal question: could we make this game look good without spending a penny?

Why a Financial Reality Check Was the Best Constraint

As a UK-based hobbyist team, our income from this project was precisely zero pounds sterling. The anxiety of watching a direct debit leave an already stretched account was paralysing. That financial reality became an unexpected gift. Removing the option to pay for tools removed the pressure to monetise aggressively just to cover software costs. The constraint didn’t stifle creativity; it focused it. We stopped worrying about industry-standard workflows and started thinking about what our browser game prototype actually needed to function.

Assembling the Zero-Budget Toolkit

With our paid pipeline binned, we went hunting for alternatives. The open-source community didn’t just provide tools; it handed us a philosophy. We needed software handling the specific demands of a low-poly browser game: tight file sizes, efficient texture atlasing, and crisp UI elements that wouldn’t blur at different screen resolutions. What we found exceeded expectations.

Here are the core tools that formed our zero-budget stack:

• Krita for hand-painted textures and pixel art, with its invaluable wrap-around mode for seamless tiling.
• Inkscape for crisp, scalable UI assets, leaning heavily on its bitmap tracer for rapid icon iteration.
• Blender as the full 3D suite, from modelling to glTF export, replacing our fragmented paid workflow.
• Audacity for cleaning up raw foley recordings captured in our Manchester flat.
• BBC Sound Effects Archive for vintage atmospheres we couldn’t record ourselves.

Krita: Pixel Art and Hand-Painted Textures for Free

Krita became our digital canvas overnight. Initially known as a painting tool, we discovered it was a secret weapon for game texturing. The real game-changer was its wrap-around mode for seamless textures. Painting the edge of a brick wall and watching it automatically tile in real-time saved us from the tedious offset-and-clone-stamp nightmare we’d endured elsewhere. For our low-poly models, we sketched directly onto UV maps with tactile responsiveness. The brush engine handled everything from rough pixel art dithering to soft, hand-painted gradients on our protagonist’s tunic.

Inkscape: Crisp UI Assets Without the Price Tag

For our user interface, vectors were non-negotiable. We needed buttons, icons, and HUD elements scaling cleanly from phone screens to widescreen monitors. Inkscape stepped into the void left by Illustrator. We leaned heavily on its bitmap tracer for quick vector silhouettes, converting rough pencil sketches of potion bottles and sword icons into crisp, scalable assets in seconds. The trace tool allowed rapid iteration during playtesting, tweaking curves on the fly without redrawing from scratch.

The Open-Source 3D Modelling Workflow

Blender was the one tool we already used, but we’d treated it as a modelling island. We’d sculpt and texture there, then export to a paid ecosystem for rigging and animation. The pipeline collapse forced us to go all-in on Blender’s full suite, fundamentally changing how we approached asset creation for the web.

Why glTF Became Our Gold Standard for Browser Games

Getting 3D assets running smoothly in a browser is a dark art. We experimented with OBJ and FBX exports, but files were bloated and often lost material data during transfer. Committing to Blender’s glTF 2.0 exporter changed everything. The glTF format, often called the “JPEG of 3D,” transmitted meshes, textures, and animation data in a compact binary bundle the browser parsed effortlessly. The exporter preserved our PBR material nodes perfectly, meaning roughness and metallic values tuned in Blender looked identical in the WebGL renderer. It removed an entire step of guesswork.

Non-Destructive Workflows Using Free Blender Add-ons

We couldn’t afford plugins, but the Blender community provided. Two free add-ons saved our sanity. Node Wrangler, which ships with Blender but needs activating, let us quickly preview texture maps by ctrl-shift-clicking nodes. It turned material debugging from a chore into a visual playground. For environment design, we used Blender GIS to pull real-world height map data directly into the viewport, giving our fantasy landscapes subtle, realistic topography without manual sculpting. These non-destructive modifiers meant we could commit to a low-poly silhouette early, then dial complexity up or down depending on browser frame rate performance.

Audio and Vibe: Sound Design on a Shoestring

Visuals were only half the battle. A silent browser game prototype feels dead, but hiring a sound designer or buying royalty-free packs was out of the question. We decided to get our hands dirty. If we couldn’t buy atmosphere, we would capture it ourselves.

Recording Foley in a Manchester Living Room

Our flat near the Mancunian Way became a makeshift recording studio. We recorded sword clashes by hitting a metal spatula against a baking tray, and footsteps by stomping on different surfaces with a cheap condenser microphone. The raw audio was a mess of background hum, distant traffic, and the neighbour’s dog. Audacity’s noise reduction filter for cleaning up our flat recordings proved invaluable. We captured a clean noise profile from the room tone, applied the filter, and suddenly our metallic clangs sounded crisp and professional. The subtle rumble of a passing bus even made it into the final mix as ambient dungeon noise; a happy accident born of a city centre location.

Mining the BBC Sound Effects Archive

For sounds we couldn’t safely recreate, like a crackling campfire or a heavy iron portcullis, we turned to a national treasure. The BBC Sound Effects archive RemArc Licence allows personal and educational use, and after a deep dive into the legal terms, we confirmed our free browser game prototype qualified. We pulled vintage recordings of woodland atmospheres and industrial machinery, layering them under our foley work to create a soundscape feeling both nostalgic and deeply textured. The archive didn’t just fill gaps; the slightly lo-fi, analogue warmth of those recordings gave our game a distinct sonic identity we could never have afforded to create from scratch.

Integrating the Pipeline into Our Indie Game Devlog

We started the devlog to build an audience, but documenting this chaotic tool switch transformed it into something more valuable. Our readers weren’t just watching us build a game; they were watching us figure out how to build a game under constraint. The transparency resonated far more than a polished “here’s what we made this week” post ever could.

Why Constraints Speed Up Prototyping

Paradoxically, having fewer options made us faster. When our artist could use any brush in a bloated Adobe library, they spent hours tweaking settings. With Krita’s focused toolset, decisions happened in minutes. The zero-budget pipeline enforced a brutal minimalism. We couldn’t afford to sculpt high-resolution details never seen in a low-poly browser game. The tools forced us to ask “does this serve the prototype?” constantly, and the answer was often a liberating “no.” Iteration speed is the lifeblood of an indie game devlog, and our free toolkit pumped that blood faster than the paid one ever did.

Sharing the Ugly Steps in the Devlog

We made a rule early on: post the failures. The corrupted Inkscape files, the Blender rigs that turned our character inside out, the Audacity recordings sounding like a demonic washing machine. These “ugly steps” became the most popular entries on the site. Readers sent us their own Krita brush packs and Blender node setups. The devlog stopped being a broadcast and became a conversation about resourceful game development. By showing our work in its raw, free-tool state, we attracted an audience valuing ingenuity over polish.

This journey taught us that a zero-budget art pipeline isn’t about settling for less. It’s about cultivating a resourceful British “make-do-and-mend” spirit. The visual identity of our browser game wasn’t defined despite our constraints, but because of them. The warm, hand-painted textures from Krita, the crisp Inkscape vectors, the efficient glTF models, and the gritty Manchester foley all coalesced into something uniquely ours. We didn’t just save money; we found a voice that no subscription service could ever sell us.

FAQ

Can you really make a commercial-quality browser game with only free tools?

Absolutely, with a caveat on “commercial-quality.” You won’t achieve AAA photorealism, but for a stylised, low-poly browser game prototype, free tools like Blender and Krita provide everything you need. The limitation isn’t the software; it’s the time and skill you invest. Our prototype runs smoothly and looks cohesive because we leaned into a hand-crafted aesthetic the tools naturally support.

Is the BBC Sound Effects archive really free to use for games?

The BBC Sound Effects archive is available under the RemArc Licence, which permits personal, educational, and non-commercial use. If your browser game is a free prototype or a non-monetised project, you are likely covered. However, if you plan to commercialise the game later, you’ll need to replace those assets or negotiate a separate licence, as the RemArc terms restrict commercial exploitation.

How do you handle version control for large Blender and Krita files on a zero budget?

We rely entirely on Git, specifically using Git LFS (Large File Storage) for binary files like .blend and .kra files. Platforms like GitHub and GitLab offer free tiers with enough LFS storage for a small indie project. It requires discipline with committing and pushing regularly, but it saves us from the chaos of manually naming files “character_final_v2_fixed_for_real.kra.”

Does the glTF 2.0 format support animation from Blender?

Yes, Blender’s glTF 2.0 exporter handles skeletal animation, shape keys, and even basic material animation. We export our fully rigged characters with idle and walk cycles directly into the browser engine without needing to bake animations to vertex data. This keeps file sizes incredibly small, which is critical for quick loading times in a web context.