Seasons Dev: An Indie Game Devlog by a Small UK Team

There’s a specific, chaotic magic that happens when you hit ‘build’ on a fresh browser game prototype at 2 AM. The room is dark except for the glow of the monitor, a half-empty mug of cold tea sits dangerously close to the keyboard, and you’re holding your breath. It’s not about shipping a polished product at that moment; it’s about seeing a raw idea sputter to life for the very first time. We’re Seasons Dev, a small, scrappy team scattered across the UK, and we started this indie game devlog to capture exactly that messy, unpolished reality. We document the sleepless nights, the catastrophic bugs, and the tiny victories because we believe the process is just as important as the final game. This isn’t a highlight reel; it’s a workshop journal, and you’re invited to rummage through the blueprints with us.

Our Latest Indie Game Devlog Entries

Our development cycle is less of a straight line and more of a frantic scribble. We live by the mantra of failing fast and learning faster. Our current project is a narrative-driven puzzle platformer built entirely in the Godot Engine, and documenting the sprints has become essential for keeping our remote team sane. We treat every entry in this indie game devlog as a rubber duck debugging session that the whole world can eavesdrop on.

Sprinting Towards a Vertical Slice

The last two weeks have been a blur of greybox levels and placeholder art. We aren’t chasing beauty yet; we’re chasing the “fun” signal. Our goal was to stitch together three distinct puzzle mechanics into a seamless vertical slice. The tricky part wasn’t coding the logic—it was ensuring the transition between a physics-heavy seesaw puzzle and a tight platforming corridor didn’t feel jarring. We spent hours tweaking the acceleration curves in Godot until the character movement felt fluid enough to bridge the gap between brain-teasing and thumb-twitching.

Why We Rewrote the Physics Engine at 3 AM

Technical debt is a monster that usually waits until daylight, but sometimes it strikes late. During a routine playtest, we noticed our protagonist clipping through a moving platform if the frame rate dipped below 60. The culprit was a legacy interpolation script we’d cobbled together from an old tutorial. Rather than patching a fundamentally broken system, we ripped it out. By 3 AM, we had rewritten the core movement to rely on Godot’s `_physics_process` with a custom kinematic integrator. It was a brutal night, but the jitter vanished, and the game felt rock-solid. Sometimes, the only way out is through a late-night refactor.

The Art of the ‘Juicy’ Prototype

Juice isn’t just screen shake; it’s respect for the player’s actions. In our latest sprint, we focused on making the core interaction feel good even without final art. We added squash-and-stretch to the character sprite, particles that burst when you collect a key, and a subtle bass note that plays when you solve a puzzle. These tiny details require minimal code but transform a sterile prototype into something that makes you smile. It’s a reminder that a browser game prototype doesn’t have to look ugly just because it’s early.

Diving into Browser Game Experiments

We have a deep love affair with the web. There’s no friction like a download, no installation barrier. A browser game is the purest form of our craft because it forces us to respect the player’s time and hardware constraints. We regularly push experimental WebGL builds to the wild, using the open web as our personal testing ground.

Pushing WebGL to Its Limits

Getting a visually rich Godot project running smoothly in a browser is a dark art. We’ve wrestled with draw calls, shader compilation stutters, and memory leaks specific to the web export template. Our latest experiment involved a voxel-based terrain generator running in real-time. We learned that while WebGL 2.0 is incredibly capable, you have to be ruthless with your polygon budgets. We cut our terrain chunk size by half and implemented aggressive LODs, finally hitting a stable 60fps even on integrated graphics. The constraints of WebGL often lead to creative optimizations we’d never consider for a native Steam build.

Why We Love the Instant Feedback of a Browser Game

Platforms like itch.io are the lifeblood of our iteration process. We can push a broken build at noon, share the link on our Discord, and have detailed feedback by dinner. There’s no waiting for Steam’s approval process or worrying about patching clients. This rapid loop is especially vital when you’re testing a single mechanic. We’ve often uploaded a “game” that is nothing more than a white room with a single button, just to see if the core interaction feels intuitive. This immediate, raw feedback loop is something you simply can’t replicate with a closed alpha.

Our First Game Jam Submission: A Retrospective

Our entry for Ludum Dare was a turning point. We built a bizarre little browser game about a sentient teapot escaping a shelf, and we hosted it exclusively on itch.io. The pressure cooker of the 72-hour jam taught us more about scoping than any planned project ever has. We cut a crafting system, an inventory, and a boss fight in the final four hours to ship on time. The result was a tiny, polished loop that people actually played. That experience fundamentally shifted how we prototype today; we now treat every feature as a luxury, not a given.

The Art of the Prototype

A throwaway prototype is never truly wasted time. Even if the code never ships, the neurological pathways formed while solving a design problem remain. We aggressively prototype concepts before they poison our main project with bloat. Often, this starts away from the keyboard entirely.

Paper Prototyping vs. Digital Greyboxing

Before we launch Aseprite or Godot, we reach for a stack of index cards and a biro. There’s a speed to paper prototyping that digital tools can’t match. We sketch UI layouts, map out puzzle logic trees, and even simulate dice-roll combat on a coffee table. It’s easy to fall in love with a clever bit of code that serves a bad design; it’s hard to fall in love with a bad sketch. Only when the paper logic holds up do we move to digital greyboxing, blocking out the space with simple rectangles to test scale and timing.

How a 48-Hour Prototype Saved Our Main Project

We were six weeks deep into developing a complex dialogue system for our main game when a nagging doubt surfaced: was the core metaphor actually fun? Instead of debating it, two of us branched off for a weekend. We built a stripped-down, ugly prototype focusing purely on the emotional loop, completely ignoring the dialogue trees. It turns out, the metaphor was confusing. Players didn’t understand why they were collecting “memories.” That 48-hour detour saved us months of writing dialogue for a mechanic that needed a fundamental redesign. We salvaged the art assets but trashed the code, and the project is infinitely better for it.

Knowing When to Kill Your Darlings

Killing a project hurts. But the sunk cost fallacy is the indie developer’s greatest enemy. We maintain a strict “kill criteria” list for our prototypes:

• No spark in 15 minutes: If a new player doesn’t laugh, gasp, or say “one more go” within the first quarter-hour, the loop is broken.
• Technical fragility: If the core mechanic requires a perfect frame rate and zero latency to function, it won’t survive as a browser game.
• We can’t explain it to a friend: If the pitch takes more than two sentences, the scope is likely too muddy.

Applying these rules ruthlessly saves us from the zombie projects that drain energy from the ones that matter.

Honest Project Postmortems

An indie game devlog without a postmortem is just a marketing blog. We dissect our failures publicly because the lessons are too valuable to hide. We’ve shipped titles that stumbled and prototypes that crashed spectacularly, and we’ve learned to wear those scars with pride.

What We Learned from a Commercial Flop

Our first commercial Steam release was a brutal lesson in market realities. We built a competent twin-stick shooter that nobody asked for. The reviews were “mostly positive” but the sales were abysmal. The postmortem revealed a fatal flaw: we never validated the demand. We built it because we could, not because there was a hungry audience. We also launched without a wishlist campaign, believing that “if you build it, they will come.” They didn’t. That project taught us that a browser game prototype shared on itch.io six months earlier would have told us everything we needed to know about the market’s indifference, saving us a year of development.

Surviving Scope Creep on a Narrative Epic

We once attempted a branching narrative epic that nearly broke our spirits. The scope creep was insidious; a “small” side character became a fully voiced companion, and a simple fetch quest mutated into a farming simulator. The postmortem highlighted that we had no “scope anchor”—a single, immutable sentence defining the game’s soul. Now, we write that anchor on a sticky note and slap it on the monitor. If a feature doesn’t serve that sentence, it doesn’t go in.

The Multiplayer Server Disaster We Didn’t See Coming

We tried to add real-time multiplayer to a physics-based browser game. It was a disaster. We underestimated the cost of deterministic physics across different clients. Players saw objects in completely different locations, leading to chaos. The postmortem was humbling: we lacked the backend expertise to manage authoritative servers, and the bandwidth costs for syncing physics bodies over WebSocket were astronomical for a free web game. We shut it down a week after launch. It was a painful but vital lesson in respecting the complexity of networked physics.

The UK Indie Scene & Our Toolkit

Navigating the indie landscape from our bases in the UK provides a unique backdrop to our work. The scene here is vibrant, supportive, and refreshingly grounded, and we rely on a specific set of tools to keep our remote workflow from collapsing.

Finding Community in UK Hubs

Isolation is a productivity killer. While we work remotely, we make a point to connect in the physical world. Events like the Norwich Gaming Festival are a highlight of our calendar. It’s not just about showcasing work; it’s about seeing the reaction of a local crowd who aren’t necessarily hardcore gamers. Watching a child play with a prototype at the Norwich Gaming Festival provides a purer form of feedback than any analytics dashboard. The UK scene, with its mix of dry humour and technical skill, keeps our feet on the ground.

Our Essential Tech Stack: Godot, Aseprite, and Trello

We keep our toolkit lean and open-source where possible. The Godot Engine is the heart of our operation—its node-based architecture clicks with how our brains work, and the WebGL export is a first-class citizen, not an afterthought. For pixel art, we live in Aseprite; its animation timeline and tilemap features are indispensable for our 2D workflow. To stop the team from descending into chaos, we rely heavily on Trello. A simple Kanban board keeps our sprints focused, with columns for “Paper Prototype,” “Greybox,” “Juicing,” and “Ready for itch.io.” Simplicity in tools allows for complexity in design.

Balancing a Day Job with the Indie Grind

We won’t romanticise the grind; it’s exhausting. We juggle full-time jobs, family commitments, and the occasional need for sleep. Our strategy is consistency over crunch. We carve out one focused evening a week and a protected block on Saturday mornings. It’s a slow burn, but it’s sustainable. We also use asynchronous communication heavily, leaving detailed Trello cards and Loom videos for each other so the work doesn’t stall. The dream is to go full-time, but until then, the indie game devlog serves as our accountability partner, proving that we’re still moving forward, one commit at a time.

Creation is a cycle, not a straight line. Every project we ship, and every prototype we abandon, leaves a residue of knowledge. The postmortem of a failed multiplayer game directly informs the scoping of our current browser game. The panic of a 3 AM physics rewrite teaches us to architect better from the start. We document this loop not because we have all the answers, but because the blank canvas of a new Godot project is just as terrifying and exciting as it was the first time. We’re already sketching the next idea on a napkin, ready to turn the page. If you want to follow the messy journey—from napkin scribbles to a playable build on itch.io—browse our latest entries, and let’s build something strange together.

FAQ

Why do you prefer building browser games over native downloadable titles?

We love the low friction of distribution. A browser game lets someone jump in with a single click, which is essential for gathering honest, impulsive feedback on a raw prototype. The technical constraints of WebGL also force us to write efficient, tight code that focuses purely on the game feel rather than relying on high-end hardware specs.

How often do you update this indie game devlog?

We don’t stick to a rigid schedule because we never want to pad out an entry just to hit a date. You can expect a new post roughly every two weeks, usually coinciding with the end of a development sprint or the completion of a significant milestone, like a new vertical slice or a major postmortem.

Can I play your prototypes, and where do I find them?

Absolutely. We publish all our viable experiments to our official itch.io page. These aren’t polished demos; they are often rough, untextured greyboxes that we use to test specific mechanics. If you’re okay with seeing the “ugly” phase of development, you’ll find links to the latest builds in the sidebar of this devlog.

What made you choose the Godot Engine over Unity or Unreal?

The open-source nature of Godot aligns with our team’s philosophy, but practically, its WebGL export pipeline is superior for our 2D workflow. We also find the scene-tree structure far more intuitive for prototyping rapidly. The lack of licensing fees removes a mental barrier, allowing us to start a new project in seconds without worrying about splash screens or platform fees.

Do you have any advice for attending events like the Norwich Gaming Festival as a small developer?

Don’t hide behind a fancy booth. The most valuable thing you can do at an event like the Norwich Gaming Festival is to simply watch people play. Stand back, shut up, and observe where they get stuck or smile. Bring a build that resets quickly and can be played in under five minutes. The local UK community is incredibly supportive, so don’t be afraid to show work that is still in the prototype phase.