Your First Ten Games Will Suck, #1
The saying goes:
"Your first ten games will suck, so get them out of the way as fast as possible."
And if you're a game dev who hasn't shipped their metaphorical "first ten games" yet (myself included), you can very likely relate.I personally have only ever shipped one game, while the rest never got past clunky prototypes. It means I need 9 more games to get out of this pit of suckitude.
The dream? In making these first ten games, you become someone different.
You become a successful game developer, one who:
- Sees players playing the games you've made, and enjoying them.
- Makes games true to your creative voice: games with feelings that you want to convey, and experiences that you want to instill.
- Has a reputation similar to Sokpop or Punkcake, or any of the impossibly talented developers out there. The kind of developer that knows how to make a good game, cold.
And maybe one day – if you ever become good enough – you can publish games to Steam and people will like them enough to buy them.
Like making ceramics or playing the piano, there's really only one way to get better.
By doing the work, yes, but most importantly by reflecting on what you did at the end of every week.
How specifically is that devlog going to work? I break it into three steps...
🎮 1. The weekly game build.
It goes without saying, but if your goal is to be making your first ten games (and you haven't made ten games yet), you need to be working on a game at any given time!
Thus, every week you should share builds of your current game project, or at least share GIFs of the progress that you've made if your project is not yet playable.
Take my current game as an example: Baseball With Friends, a couch co-op game made in PICO-8, designed for people like my dad who love watching baseball, but don't play too many video games.
Because the game is not yet playable, perhaps I can show just an example of the progress I made on pitching:
And throwing and catching:
And picking up dropped balls:
The important part is to have tangible progress to show. Something that you can point to and say, "last week you couldn't do this, but this week you can!"
It also keeps you focused on getting the game working. Endlessly refactoring code won't help you make more GIFs or share a new game build here.
🏯 2. Review your commits and comment.
In addition to the user-facing changes that were made over the course of the week, I also like to walk through the actual code changes to reflect on what I could have done better.
This serves twofold:
- It points out days when you were less productive than expected, or development decisions that turned out to be dead ends.
- It allows you to review how your game's code structure has evolved over time, and whether that structure is evolving in the right direction.
🏯 3. Break it down for deliberate practice.
Given the user-facing progress you've made, and the code that you've written, the final step of this devlog is to:
- Identify the skills that need improvement, and
- Choose a specific skill to improve for the following week.
- Design a practice drill for how you will improve that specific skill.
Musicians call this deliberate practice. A pianist might practice a music passage with one hand, figure out the finger order, practice the other hand, and only then practice both hands together.
Game dev is the same way. Immediately, I can think of several areas of improvement for my own game project:
- Development speed. I'm not making this game fast enough. I need to get to a playable game loop sooner.
- Game appeal. The GIFs I made isn't "hooky" enough. It won't wow people online because the art is lousy.
- Time management. I need to manage my time better between game dev, work, and other commitments.
- Game design. My game's initial design hasn't been fully thought-out.
- Energy management. I need to prioritize getting enough sleep.
- Attention management. I need to get rid of distractions, and get better at focus.
- Game juice. My game needs better art and juice.
- Sound. My game needs sound.
- Ideation. All my ideas are boring; how do I come up with more creative ideas that I like?
- Playtesting. I'm ready to playtest my game. How do I find people to play my game so I can observe them?
Because "development speed" is top of mind for me, I might propose this practice drill:
Any game feature takes the following process to come to life: idea → requirements → design → code → debug/QA → clean up.
For any feature idea that you have next week (such as
player can swing bat at ball), jot down the time when you complete each phase of the process above.
Once you go through the entire process, observe the slowest parts of the process. Where are you getting stuck? How might you make that phase faster?
Making your first ten games isn't solely about the number; you could make ten game clones, which doesn't achieve your original goal of making original, true-to-yourself games.
But by identifying a specific subskill that you'd like to improve every week, and having a concrete plan of action for that skill, you can incrementally transform your game dev abilities into what you want them to be.
👌 It's a wrap!
So to wrap up, to "git gud" at making games requires not just doing work, but reflecting upon your work.
I proposed that you do so with a lightweight, 3-step devlog containing:
- A game build (or GIFs of new features).
- A self code review.
- A practice drill for a specific skill that you'd like to improve.
Over time, you reap the benefits of compounding improvement. And you can always share the devlog online; assuming this becomes a habit, I'll be sharing my own devlogs through the
What do you think of this process? Do you think it helps? Or is it too much work?
I'd love to hear your thoughts. Please feel free to comment in the comments below.