An Unfinished Game — The Project That Almost Became Our Own Story

Every game starts unfinished, but who decides whether the game is finished or not?

There is something terrifying about going commercial for the first time.

Not because of the Steam Direct Fee, the Google Play Console, or even the pressure of releasing something people might actually pay for.

It's the possibility that, somewhere along the way, the project stops being something the team wants to make and becomes something only the founder wants to finish.

That was the fear behind An Unfinished Game.

The game tells the story of a founder whose ambitious project falls apart after the rest of the team abandons it. Instead of accepting defeat, he decides to finish everything alone. What follows is a strange world shaped by the development process itself, where design, programming, art, and music become puzzles and challenges.

But the real enemies aren't unfinished tasks.

They're the things happening inside the founder's head.

Perfectionism. Sunk cost. Burnout.

The belief that everything must be perfect, that years of work cannot possibly be abandoned, and that stopping means admitting defeat.

We wanted to explore a question that doesn't get discussed enough in game development:

What if finishing the game is the thing that's destroying you?

And, ironically, we had our own reasons to ask that question.

By this point, Slafurry Studios had started preparing for the commercial path. We finally had enough funding to afford the Steam Direct Fee and Google Play Console. The idea of taking our projects beyond game jams was becoming a real possibility.

But I was worried about something else.

What if I was the only person still motivated to finish the project? What if the game was slowly becoming an ego project, and I only realized it after everyone else had already left?

It wasn't an entirely unreasonable fear.

We had experienced enough production problems to know how easily things could go wrong. And while the team was getting better, coordination still wasn't perfect.

For example, sometimes someone would create an asset but forget to notify the project lead or the person responsible for integrating it. It sounds like a small issue, but it can become surprisingly frustrating when several people are working on the same project.

I considered enforcing stricter communication rules. Every asset update would need to be reported, every change would need to be announced, and everyone would have to follow the same reporting process.

But I was afraid that would create another problem.

More friction.

The artists would have to spend more time reporting their work instead of creating assets. Programmers would get interrupted by notifications. Production could slow down simply because everyone was busy keeping everyone else informed.

I didn't want to solve a coordination problem by creating an entirely new coordination problem.

Then Slatechnica, the Slafurry R&D Division, came up with a different approach.

Instead of asking everyone to communicate more, why not make the system handle the repetitive communication for us?

We started building three Discord bots.

One handles daily reminders, helping the team keep track of tasks and deadlines without requiring me to wake up every morning just to remind everyone.

Another monitors changes in Google Drive and retrieves the updated files into our GitHub repository. Asset creators can focus on Drive, while programmers can focus on the project itself.

The last one handles multi-platform builds for Windows, WebGL, and macOS, then uploads the results to itch.io with a single click.

Three bots. Three repetitive responsibilities removed from the team's daily workflow.

And the difference was enormous.

Suddenly, artists didn't need to worry about manually informing everyone every time an asset changed. Programmers didn't have to keep checking whether the latest files were available. And I didn't have to spend my mornings acting as a human reminder notification.

For once, we were reducing friction instead of adding more rules.

Eventually, we finished An Unfinished Game with a team of five.

It became one of the smoothest production experiences we've had in Slafurry Studios so far.

Which is honestly hilarious.

We made a game about an egomaniac founder trying to do everything by himself, while the actual development process was becoming less dependent on that exact person.

The game was practically warning us about something we were afraid might happen.

Fortunately, we managed to recognize the problem before it became our reality.

That doesn't mean we've solved everything. We're still learning how to manage production, coordinate people, and prepare ourselves for the responsibilities that come with commercial development.

But this project gave us something more valuable than another completed game.

It reminded us that a project should never depend entirely on someone's willingness to sacrifice themselves for it.

A healthy production system should help people work together, not demand that one person hold everything together.

And perhaps that's the most important lesson behind An Unfinished Game.

It's not about never giving up. It's about knowing what you're trying to save, and whether it's worth destroying yourself to save it.

Sometimes, a project needs more effort.

Sometimes, it needs better tools.

And sometimes, it simply needs someone to finally press the PUBLISH button.

For now, we're happy that this one made it there.