Why I'm not joining NextFest

So I've been using Godot for two years and I've been working on a commercial project for just over a year where about 8 months of which is actually full time work.

I'm relatively new to the game dev scene and I've been oblivious to the community until the last year. I didn’t seek advice, so I’ve learned all of these things the hard way. I want to take the opportunity to celebrate a missed milestone to share all the things I learned so that you can avoid the pits I’ve fallen into.

My game dev journey and why I’m not joining NextFest

My original goal was to release a prototype publicly within the month of February (2025). I made promising progress, but I didn’t meet this goal. I did manage to publish something on itch.io but it wasn’t finished enough to share publicly. This was incredibly ambitious even even just like a prototype.

Last summer, I decided to quit my full time job and focus on game development full time with the goal of publishing a demo in November and the full game before the end of the year. I had some wiggle room too: the latest I wanted to release was in March 2026 with the idea of joining the February NextFest on Steam beforehand.

So that isn’t happening. I didn't have a demo ready by the beginning of November, but I did manage to produce a build that looked OK and was fun for ten minutes. There were many mistakes that I made specifically in that build. Four months later, I’m still learning from those mistakes and I’m making more! My time frame was ambitious, but also my intended scope was also way bigger than what I had originally expected.

I worked under the assumption that I was just as good at game development as I was in my day job as a software developer. This is despite the fact that I hadn't fully learnt the engine and this was the first time that I was going to publish something publicly. I was also very ignorant of all of the other things that I that actually went into developing a game beyond writing code. That’s even ignoring the fact that GDScript and Godot are different to use than what I was used to, despite some similarities and parallels.

The tl;dr of this is that I massively overestimated my ability and because of that, I’m not ready to market my game.

Things you ought to know before you make a game

Start small

Pick a project with a much smaller scope thin you think you can deliver. Take an idea cut it into thirds. Then cut the part you want into thirds again. You’ll end up with something that’s about 1/10th of the size of the original idea, but it’ll be manageable.

Try not to base your first project around abstract ideas: “What if game X played with feature Y” like “What if Balatro was scrabble instead of poker.” or “What if Mariokart was turn-based”.

Avoid scope creep where possible

This is something that I'd consider myself to be quite good at already because of my experience as a software developer, but I didn't realise the sheer volume of ideas that I had to shelve in order to focus on something that can actually be delivered but is still fun to play. Playtesters are very good at suggesting new features to include in your game too, and it’s really important to not get carried away by those suggestions. Make a note of them now and examine them later: be ruthless with which features and ideas make it into your final game.

I have a “Someday Maybe” list for this inspired “Getting Things Done” By David Allen. This makes me feel better about discarding ideas because I can convince myself that I can look through them later, even though I know I never will.

Be delusional, but in moderation

Try not to delude yourself too much. Don’t get me wrong, it’s really important to be delusional! It’s good for starting a project, maintaining motivation on it and it’s especially useful as an inoculation against taking negative feedback personally. Everyone needs a healthy dose of delusion to have the audacity to make something. However being delulu about your own ability can be crippling when you taste the truth.

My personal experience with this is that I thought I could build, market and publish a game without the experience of actually finishing a much smaller game first. In hindsight, I really should have participated in a game jam first so that I could have that experience. I still haven’t and it’s a known blind spot.

It’s more than just writing code and creating textures

There’s a lot more that goes into building a game. As a solo/indie game developer, you need to assume all these roles (and possibly some more that I’m not yet aware of):

• Software Developer/DevOps. You’ll need to write and publish code. This part should be obvious, but it’s not just code.
• Tester/Playtester. You’ll need to test your game yourself to make sure mechanics work but also to check whether it’s fun. You’ll also need to get other people to test it too, which overlaps with the next role.
• Product Owner. You need to research your audience and decide what features and mechanics you want in your game and how they will work. You’ll also spend time with playtesters and collecting their feedback. A fresh perspective is invaluable, and so is receiving the same feedback point from multiple people independently. I’ve found that supervising playtesting is a great way to maintain motivation, momentum and engagement.
• Graphic Designer. You’ll need to create textures and visuals for your game, likely in both 2D and 3D, regardless of whether your game is just 2D or 3D (unless you’re using pixel art).
• Sound Designer. You’ll need to think about the player’s overall experience. The background music and sound effects do a lot of heavy lifting for immersion and important gameplay like alerting the player to threats.
• (Digital) Marketer. You’ll need a strategy to publicise your game. What if you make the best game ever, but nobody knows about it? You need to have a plan for how will you get your game in front of an (existing) audience and then execute on it.
• Project Manager. You’ll need to manage your project, and build a roadmap to order the features your want to build. On a macro scale this looks like: prototype > vertical slice > demo > early access > full game. On a micro scale it looks like: build a dirty version to validate a feature or mechanic; then build the system to support the full scope of the feature; and finally the expand to all the different varieties or interactions that feature should have.

Know when to delegate

For each of the roles in the above paragraph, you’ll need to decide which of those you are going to do by yourself and which of those you can lean on other people to help you out. This can be to outsource tasks to someone who’s enthusiastic about your project or contract someone to work on the tasks to cover your skill gap. You could even learn something by getting a second opinion on something you already feel competent at, particularly if you’re self-taught. For example, a code review or looking through someone else’s code can highlight a better way to implement a game mechanic. Delegating can also act as a filter for bad ideas before reaching the point of playtesting: it’s easier to spot a bad idea when one of two (or more) people question that idea.

There are caveats to this though. If you have to keep to a budget, or find joy in learning everything without any time pressure, then there’s no harm in doing it all yourself. Just understand that it’ll take longer and the workload is disproportionately bigger because you’ll need to learn how to do something as well as actually doing it.

I’ve found it invaluable to outsource graphic and sound design to people who have expertise in these already. The assets are finished quicker that if I were to make them myself and I’ve learned where to start if I wanted to do them myself next time.

Leverage someone else’s audience

It can be difficult to grow an audience organically from scratch, especially if you’re introverted like me. Granted, I’ve not tried that hard. The thought of putting myself out there makes me feel uneasy and when I write content, it takes a lot more time and energy than it probably should take (this post included). I wouldn’t be surprised if many others feel the same way. But this is exactly my point: it’s expected to take a lot of time and energy to grow and maintain an audience. Time and energy that could be put to better use you make your game better.

Find a small group of people who have an audience already and already produce content based on similar games to the one you’re making and introduce yourself when you have something worth sharing publicly. Standing on their shoulders to get access to their audiences will be more efficient in terms both your time and their time too, if you make it trivially easy for them to play your game and your game is fun.

Set and celebrate project milestones

Reaching a project milestone is just like completing a level in a game: there’s a dopamine hit. Defining small and frequent milestones for developing your videogame will give you that dopamine hit more often. It’ll keep you motivated and gives you something easier to reach than the whole prototype/demo/game. It also helps to keep regular playtesters engaged as well as any third parties you’re working with to build your game. They share in your success. (Yes, I know I’m at risk of sounding like I’ve drank too much of the corporate kool-aid). Work with human psychology, not against it.

It's also good to remember that these milestones shouldn't always be treated like time-based deadlines. If you miss them, there shouldn’t really be any consequence for you. I would recommend using the SMART goal methodology in general (Specific, Measurable, Achievable, Relevant, Time-bound) to define milestones, but I would also recommend that project milestones aren’t time-bound unless it’s absolutely necessary. The main purpose should be to sustain motivation and engagement.

Work-life balance

You have all the energy and motivation in the world to work on your project 89172389 hours each week. Just know when to stop and take a break. Don’t overwork yourself for a time-bound milestone. Have patience and empathy for yourself so you don’t burn out, even if you have oodles of energy and enthusiasm. You are the engine of the project. You need to make sure that engine keeps running but also make sure that engine doesn't burn out. You don't need to chain yourself to a desk in order to do that.

Keeping the engine running will look different for everyone and be different on different days. If you’re working on a game full-time you likely have the capacity to choose when and where you work. Take advantage of that.

I go through cycles of high and low energy. I usually plan to work one or two hours on my game each day, which I often overshoot because I find my flow state and I let that happen. That being said, I’ve found it more consistent over the course of the project to restrain myself to working 9 or 10 hours instead of 15 when my energy really meets my enthusiasm.

Remember to have fun

You're a game developer after all! Hopefully you're building a game that you are passionate about and want to make exist. It's OK to be bored with a specific task either because it's difficult or it's just not intellectually stimulating for you. In times like that, it's important to remember the direction your project is going. Is that next milestone worth it? It certainly should be.

It's important to be able to tell the difference between being bored and disliking the game development process. If you find yourself in the latter camp, sit down and rethink the project in general. Which leads me to my final point.

The sunk-cost fallacy

It's OK to quit. Especially if building the game is consistently unenjoyable or the general feedback is negative or your project is far too big for you to handle with your current experience. It’s always better to stop sooner, despite everything you’ve poured into a project than to spend more time and energy trying to make it better. In the time you hesitate, you could have moved onto greener pastures. You could find something more fun and fulfilling to spend your time doing. You could validate/discard/complete a smaller idea in the same amount of time it would take to finish your current project, and still learn the same amount.

I know I’ve fallen into the sunk-cost fallacy. I don’t want to stop building my game now, even though my demo isn’t ready to launch for NextFest. I’ve known this since December and I am still reluctant to pivot to something else. The big reason is that the general feedback I’m receiving now is that my game has just started to become fun, which has renewed my excitement and passion. I also have a better idea of how long it’ll take me to be ready, but experience has taught me that I shouldn’t hold my breath if I’m aiming for the next NextFest.