Before I became a solo indie developer and made games like Chessplosion and Ducky's Delivery Service, I spent over a decade working for other game studios. I was mostly a gameplay programmer at AAA studios (~150 people) and "big indie" studios (~15 people), and I've done some engine/tools programming and some game design consultant work too.
I was going to write a big post on the game production process but I realized that most of it is pretty obvious. You come up with an idea for a game, then you make sure that the idea is good by prototyping its mechanics and planning everything out (also known as pre-production), then you make the rest of the game (also known as production).
It's just like any other type of art. You think of an idea for a drawing, then you sketch it, then you render the final picture. You think of an idea for a book, then you write an outline and a rough draft, then you write the final novel.
The only part that isn't obvious, judging from how I've seen this exact mistake being made over and over again on all sorts of games, is that you shouldn't move on from pre-production to production until you are 100% confident that the game is already good enough. I really cannot overemphasize how important this is. Ignoring this is by far the biggest and most common mistake that I see game developers make, and it is often game-ruiningly bad.
NOTE: I'm writing this as someone who makes action games, both as part of a team and as a commercial solo game developer who spends at least a year on each game. Feel free to ignore as much of this advice as you want, especially if your games are different!
An example: my next game
It's easiest to explain this with an example. I'm currently in the pre-production stage of an action-adventure game where you hop around on a grid and attack enemies by bumping into them. It's sort of like Ys meets Crypt of the Necrodancer, with heavy influence from beat em ups and other arcade games.
Here's how the core combat gameplay prototype looked after a week or two of development, when I first got the basics working:
Despite being very simple and using placeholder sprites from my other games, it was enough to make me confident that I can probably make a good game using this type of gameplay system. I have seen lots and lots of teams who would stop prototyping here and jump straight into production, hoping that they'll be able to improve the game mechanics during the production process.
But there's a huge difference between a prototype that makes you confident that a good version of the game is possible, and a prototype that is the good version of the game. Here's my final core combat gameplay prototype:
The gameplay in this prototype feels good enough to carry a full-length game, and all of the different enemy types (most of which aren't in this video) give me confidence that there's enough variety for a full-length game too. And I've tested out the gameplay in scenarios similar in difficulty to what will probably be the hardest parts of the full game, giving me the confidence that the game mechanics won't fall apart in difficult sections. So now I'm free to move on and make the rest of the game.
There's a chance that I'll come up with some tweaks and improvements to these mechanics later on, especially after I get more feedback from friends and playtesters. But I'm no longer relying on miraculously coming up with some huge improvements during production to save my gameplay from being mediocre.
Why is this important?
It's very common to try something out during the prototyping phase and find out that it's not as good as you thought it would be. But you're free to just change it or throw it out and try something else, and it's no big deal because it probably didn't take much time to prototype in the first place.
If you find this out during production instead, it's a much bigger problem.
There's a huge difference between discovering during the prototyping phase that your combat is only fun in tiny rooms, and discovering the same thing after you've made a huge detailed overworld full of open areas. Or finding out during the prototyping phase that being able to fly away from enemies ruins your combat balance, and finding it out after you've designed and animated a beautiful bird as your main character and shown off a gameplay trailer of them flying around during fights.
I've seen plenty of games that had problems like this, all of which would have been much easier to fix if they kept prototyping until the mechanics were actually good enough.
If you were an artist, you would make sure that your sketch is good before you spend hours painstakingly rendering your final piece. You wouldn't just doodle something that looks like it has some promise, then go "ehhhh I'll improve this as I go" and immediately jump straight into rendering. So don't do it in game development either!
Another tip: prototype all of your mechanics!
You should prototype all of your game's mechanics, not just one or two of them. That might sound obvious, but it's the other main mistake that I've seen people make so many times. For example, if you're making a racing RPG you should prototype the racing part and the RPG part and make sure that they work well together, instead of just prototyping the racing part and assuming that the rest will be okay.
To use the art analogy again, you should sketch the whole picture! Don't just sketch a character's face and assume the rest of the drawing will turn out fine.
For my own game, I still need to prototype some other mechanics (e.g. items/weapons) and situations (e.g. boss fights) before I move out of pre-production. Otherwise I might build an entire dungeon where you use a bow & arrow and defeat a cool boss, only to discover that bows & arrows and boss fights just aren't fun in this game.
Why do people make this mistake over and over again?
For teams, this mistake is usually caused by poor management and wanting to ramp up the team size too early. If 2 people on a 20 person team are prototyping the game and the other 18 people are sitting around doing nothing, there's a lot of pressure to move into full production as soon as possible just to give the rest of the team something to do. But you should really try to schedule enough time to properly prototype a game before ramping up the team size that much, if you don't want to waste lots of time and money and potentially end up with a bad game.
For solo developers, I think some people are just eager to make the full game. This is understandable, and a big part of solo game development is managing your own morale and keeping up your enthusiasm as much as possible. Even in my two prototype videos, you can see that I drew lots of new sprites during the prototyping process instead of solely working on game design and gameplay programming. That's because I work much better if I can jump back and forth between jobs while I make games, instead of programming for a few months straight then drawing for a few months straight. But even if you adjust your production process to accommodate your needs as a person, I really think you should try to avoid moving into full production too early if you can.
Anyway, I hope this is useful! I've even made this exact mistake myself a few times earlier in my career, because this halfhearted way of prototyping was all I was ever taught to do. I would have saved myself a lot of time if someone else gave me this advice 15 years ago, so I hope I can at least save some other game developers a lot of time instead.
Thanks for reading! If you want to read more of my writing, I post on my Patreon and Ko-fi every Thursday. And if you like the look of my games, both Chessplosion and Ducky's Delivery Service are in the Steam sale and the itch.io sale right now!