Solo Game Dev: From Dreamy Expectations to Harsh Realities

13 min readMar 11, 2025

Starting your first solo game development project is exhilarating. You see incredible indie successes like Stardew Valley, created by a single developer, and you think, “I can do this too!” The excitement fuels grand visions of intricate mechanics, stunning visuals, and deeply immersive worlds — all crafted by your own hands.

But then, reality kicks in. You start to grasp the vast gap between your ambitions and your actual skills. Every task is more complex than expected, and those inspiring indie success stories that once motivated you now feel intimidating. The journey ahead suddenly seems far more daunting than you imagined.

Initial Ideas with Big Ambitions

When I embarked on this journey, I was brimming with ambitious ideas, heavily inspired by remarkable indie games. These games seemed accessible, achievable — even easy to develop. I was eager to replicate beloved game mechanics, compelling storytelling styles, and charming visual designs.

My confidence stemmed from my 15 years of experience in software development, albeit in a different field. I assumed that implementing these mechanics would be mostly about understanding how to code them and design their UI, then simply moving on to the next feature.

Although I was aware of the classic pitfall of “you don’t know what you don’t know,” I was still overconfident. Looking back, I also realize I wasn’t humble enough to heed the advice of many experienced indie devs who kept emphasizing one thing: Start with stupidly simple games, iterate over micro-prototypes, and experiment with multiple game styles.

Ignoring these warnings, I dove headfirst into a large, elaborate project, driven purely by passion.

My Journey: Learning Through Reality

First Wall Hits

Almost immediately, my idealistic expectations clashed with harsh realities. Before starting my first game, I had taken a few online courses to learn how to use Godot and build a “complete” game — with assets, UI, save systems, and gameplay mechanics. I thought this preparation would be enough to create my first game on my own. That was a mistake.

My first project, Seeds of Tomorrow, was an isometric 2D RPG set in a post-apocalyptic future. Determined to make it truly mine, I decided to create all the art myself. After a grueling week, I had a decent animated character and a few walls. Encouraged by this progress, I prototyped the first area and built the core character controls. I even implemented a shiny inventory system, following some excellent YouTube tutorials — a feature I was particularly proud of.

Since everything seemed to be going well, I pushed further into the art, creating textures with normal maps to experiment with lighting and ambiance. And that’s when I hit my first major roadblock. I lost nearly two weeks trying to make 2D lighting behave properly in an isometric environment. Eventually, I got it working, only to encounter another hurdle: sprite depth sorting. After struggling through that as well, I was mentally drained. I needed a break before continuing the design of the first area.

Hoping for a quick reset, I decided to prototype a simple Android game — something I planned to finish in just one month before returning to Seeds of Tomorrow.

Spoiler: I never touched Seeds of Tomorrow again. Not a single line of code. Not a single piece of art.

First Game Was Simple, the Journey to Publish It Was Not

Frustrated by the exhaustion from my first attempt, I took a different approach when designing my next game. I applied two key lessons:

Start small and iterate.
Keep the game ridiculously simple.

I developed the core gameplay of The Buzzing Crusade during the last week of 2023. It was a straightforward arcade-style game where players had to move and dodge walls. The following week, I created all the artwork myself. Another week was spent refining the gameplay, adding scores, objectives, and a light narrative.

Everything was progressing smoothly. I dedicated another week to UI and the save system, and by the end of the month, The Buzzing Crusade was ready. I designed a logo, wrote a description, and prepared other marketing materials. Finally, I initiated the process of publishing the game on the Play Store.

And that’s when things got complicated.

Publishing on the Play Store involves navigating a maze of requirements. It felt like Google had recently intentionally raised barriers for small developers — possibly to discourage low-value or spammy apps. First, I had to register my company as a publisher to access the Play Console. Then came an unexpected hurdle: a mandatory “Closed Test” period.

This test nearly made me abandon the idea of publishing the game entirely. I had to recruit at least 12 people willing to install and keep the game on their phones for 14 consecutive days before I could even access the “Submit to Store” button. As a solo developer, this was a logistical nightmare. I had to find friends or colleagues who:

Used Android.
Had a compatible phone.
Were able to navigate a private install link.
Would not uninstall the game for two weeks.

In the end, it took two weeks to meet the requirement, plus another two weeks to organize everything. While this period helped me catch a few bugs, it mostly made me question whether I ever wanted to publish another mobile game.

When The Buzzing Crusade was finally released in April 2024 — after three months of work — I felt just as drained as I had after my first project. I lacked the motivation to continue improving the game’s levels and mechanics. A bit of introspection made me realize something crucial:

I had built a mobile game for the challenge of it, not because I was genuinely passionate about mobile or arcade games.

In hindsight, this should have been obvious. After all, I’ve spent years trying to reduce my mobile phone usage, not increase it. 😅

The Harsh Reality of Mobile Game Publishing

Under this new light, I asked myself: Should I spend a few more months adding new chapters to the game? I took a step back, analyzed the situation, and quickly felt discouraged by how unfriendly the Play Store is for indie developers.

• Ratings were mysteriously broken. Some testers and new users reported being unable to rate the game. For those who managed to leave a review, the store page still displayed zero ratings.

• Discoverability was non-existent. My game was completely buried under a sea of titles with 500K to 50M downloads. Even searching “buzzing crusade” yielded no relevant results. The only way to make it appear was to search for the exact title (The Buzzing Crusade), which felt like a hardcoded exception in Google’s algorithm — useless for organic discovery.

Realizing that my game was essentially invisible unless I actively promoted it, I decided to take a break before working on new levels. Spoiler: I never did. Instead, I only updated the game a few times to keep it compatible with newer Android versions.

Letting Go of the “Do Everything Myself” Mindset

Another important realization hit me at this stage. While I enjoyed creating the art for my games — it aligned with my broader goal of integrating drawing into my creative process — it was far too time-consuming. The time and energy required to reach an “acceptable” result drained my momentum.

So I made a decision: I would stop making all the artwork myself.

At first, I considered finding an art partner, but since none of my projects lasted more than two months, this didn’t seem like a viable option. Instead, I decided to purchase assets. Looking back, choosing to let go of full artistic control was the first major “axe cut” in what I had initially envisioned as my dream game project.

First Desktop Game: More Lessons Learned

As I embarked on my third attempt, I applied everything I had learned so far. This time, I set clearer guidelines for myself:

Develop a game on a platform I actually enjoy playing on (desktop or console).
Choose a genre I genuinely love.
Use asset packs whenever possible and only create custom artwork when necessary.

With these principles in mind, I was ready for my first desktop game!

My goal was to build a pixel-art, story-driven RPG set in a small town. The game, titled Goodman is Mad, followed a newcomer navigating the absurd, catastrophic decisions of the town’s eccentric mayor, Mr. Goodman.

At the same time, I decided to switch from GDScript to C# in Godot. While GDScript was fine, I started to feel limited by it, as I was used to working with object-oriented programming.

Things started well. I found some high-quality asset packs and began assembling the town area by area. Feeling more confident with the language, I also designed mechanics with reusability in mind — partly because I suspected I might abandon this project and reuse the code in another one later. In two months, I built several systems, including:

A dialogue system with full localization support.
A cutscene system that allowed me to assemble complex sequences in minutes.
A level navigation system for entering/exiting buildings while tracking player position.
An interaction system that linked objects in the world to player inputs and UI elements.
A modular quest system for tracking objectives.

Cutscene, Dialogue, Interaction and Quest systems in action.

Everything was in place. Now, I just had to use these tools to bring the story to life.

And that’s when I hit another wall.

I struggled to create a fun and engaging story. While I initially imagined an RPG, I realized I was actually more interested in letting players wander around town, interact with quirky characters, and experience cozy, slice-of-life moments rather than following a structured quest-driven narrative.

It dawned on me that writing a full RPG — complete with cutscenes, branching dialogue, and meaningful player choices — would take years. And worse: I wasn’t even passionate enough about writing an RPG to commit to that kind of long-term effort.

This led to my second major “axe cut”:

While RPGs are my favorite genre to play, they are an overwhelming nightmare to develop as a solo dev.

The “Devlog Comparison Trap”

As I struggled with my project, I became more determined to learn from others and avoid common pitfalls. I started following solo and small-team game developers on YouTube and Patreon, hoping to gain insights from those who were a few steps ahead of me.

At first, this was incredibly inspiring. But without realizing it, I fell into what I now call the “devlog comparison trap.”

Watching other developers showcase their progress, I found their results amazing — and slowly, I started measuring my own work against theirs. Every time I saw a polished, well-presented devlog, I couldn’t help but feel like my own progress was inadequate. I felt like I was always behind, always unfocused, never good enough.

This mindset became toxic. Instead of feeling motivated, I started doubting myself.

Thankfully, I had a breakthrough:

💡 Every developer is on their own journey.

Some struggle with things I find easy.
Some excel at things I find difficult.
Everyone starts from a different place.

The journey matters — not just the polished, edited results that are in devlogs.

So, I made a conscious decision: I would stop comparing my progress to others and focus on my own path.

That was easier said than done. In game development, sharing your progress is essential for marketing and community-building. But I knew I had to reframe how I viewed others’ work — as inspiration, not competition.

Second Desktop Game: Gameplay Works, but Is It Fun Enough?

For my second desktop game attempt, The Librarian, I followed a common approach: “copy a well-known game mechanic and add a personal twist.” I designed The Librarian to be a magical library management game, heavily inspired by Overcooked… but solo.

Looking back, I should have spotted the problem right from the design phase. 😅

Mechanically, the game worked well. The player had to find, manipulate, and deliver books under time pressure, requiring quick decision-making and prioritization — much like Overcooked’s recipe for chaotic fun. Development progressed quickly because I was able to reuse a lot of systems from Goodman is Mad, including the interaction mechanics and artwork. I even polished the game with a light narrative, clean menus, a save slot system, controller support…

Yet, once again, I hit the same issue: I wasn’t excited about making more than a handful of levels.

After some reflection, the flaw was clear:

💡 Overcooked-style mechanics are fun in co-op. While the game has a solo mode, that’s not what makes it famous.

Would I have to turn my game into a multiplayer experience? Sticking to my “keep it simple” principle, I decided against it. I had never developed an online or local co-op system before, and diving into that would open a huge unknown, requiring extensive testing — something incredibly difficult for a solo developer.

Once again, I was about to abandon the project and move on. But this time, I recognized the pattern — and I knew I had to break it.

Breaking the Pattern: Prototyping to Clear My Mind

Instead of trashing another project, I paused game development and took a different approach. I realized that several mechanics had been lingering in my mind for a long time, constantly tempting me to start new projects. These ideas were cannibalizing my focus, making it harder to commit to a single game.

So, I decided to get them out of my system by creating a few small prototypes:

Exploring 3D game development. To avoid dealing with complex animations and character modeling (which I knew I wasn’t good at), I designed a low-poly First Player puzzle game. In just two weeks, I built a white-boxed prototype with Blender and Godot.
Creating a living, simulated world. Inspired by cozy games, I experimented with a day/night cycle, changing seasons, and a dynamic calendar system that impacted the environment (bright summers, snowy winters, etc.).
Allowing players to modify the world. I tested mechanics where the player could edit the terrain, place buildings, add fences, and interact with a customizable environment.

By implementing these mechanics in standalone prototypes, they stopped distracting me. I no longer felt the urge to restart new projects just to explore these ideas.

With a clearer mind, I returned to The Librarian — this time, with a fresh perspective and a plan to make it work.

Redefining The Librarian: From Time-Management to Simulation

Coming back to The Librarian with a fresh mindset, I realized that the core concept needed to change. Instead of forcing it into a time-management game, I shifted the design toward a library simulation game.

To ensure this new direction was both appealing and feasible, I took a step back and visualized the full game concept:

I drafted a store page description, refining the vision until it felt exciting and realistic.
I sketched out mechanics, ensuring they were engaging and achievable within my skill set.
I focused on what made the game unique, rather than just mimicking Overcooked’s mechanics.

This process helped me feel more confident about the project than ever before. While I know this won’t be the last iteration, this version already feels more mature and sustainable than my previous attempts.

Challenges Ahead, But No Blockers

I can already see some upcoming struggles, but none of them feel insurmountable:

New mechanics I’ve never implemented before, like allowing players to edit the library layout using Godot TileMaps.
Some artwork will need to be customized or created from scratch, which will require time and effort.
The complexity of a simulation game. These games rely on multiple small interconnected systems (resources, upgrades, level progression, balancing, replayability), demanding endurance and focus.

However, despite these challenges, the vision of the finished game is motivating. The combination of unique mechanics feels promising, and I genuinely believe that creating a fun and engaging experience is within reach.

What I Learned: Key Takeaways

If there’s one lesson I’ve learned from my journey so far, it’s this:

💡 Game development is not just about technical skills — it’s about endurance, self-awareness, and knowing when to pivot.

In details:

Starting small is essential. Big projects are tempting, but without experience, they quickly become overwhelming.
Your passion should drive your projects. Making a game for the challenge of it, rather than because you truly love the concept, can sap your motivation.
Prototyping helps clear mental clutter. Exploring ideas in small, contained projects prevents them from hijacking your focus.
Comparing yourself to others is a trap. Every developer has their own journey — focus on progress, not perfection.
Game ideas evolve. The first version of your game is rarely the one you’ll end up with, and that’s okay.

A Journey of Growth, Not Just Games

Looking back, every abandoned project, every shift in direction, and every lesson learned has shaped me into a better game developer. While The Librarian is still in progress, I no longer see unfinished projects as failures — just necessary steps toward finding my own creative voice.

Solo game development is a marathon, not a sprint. The real success isn’t just shipping a game — it’s learning, improving, and staying motivated along the way. And this time, I feel like I’m finally building something that will last.

Thanks for reading! 🎉
If you enjoyed this article, feel free to check out my other content:
→ Showcases and updates on my games on my YouTube Channel.
→ Take a look at my games and enjoy a bit of what each world has to offer.
Stay tuned for more, and feel free to leave any feedback or questions in the comments. Happy coding!