Everything you need to know, in one place.
Games are a combination of several separate skills, including design, programming, art, sound and testing, and that's exactly the reason why first…
Games are a combination of several separate skills, including design, programming, art, sound and testing, and that's exactly the reason why first attempts at game development fail quite often: trying to be proficient at all of them at the same time is simply not possible. The real first goal of making a game is not making a completed game but making something small and playable in an end-to-end manner, even though all parts of it might be done rather roughly. The understanding of it from the beginning changes how you should approach your project.
The main reason of why a first game never gets completed is trying to create something too ambitious at the very beginning of the journey – an open world, several levels, an entire story, without completing anything smaller first. A tiny, one-mechanic game, one that could be described in one sentence is a much better first project than a cut-down version of your dream game, since it is small enough to be completed. Cloning a simple and well-known mechanic almost exactly is a great way to start learning without having to worry about the decisions made in design.
Popular and free engines, specifically made for beginners, a few of them exist and have big communities and numerous free tutorials, will make a small first project, thus the choice is not as important as the fact of actually selecting an engine and starting work. Spending several weeks thinking about which engine to choose and not doing a single line of code is a very popular form of productive procrastination, which postpones the only thing that gives any progress in mastering game development – building something. Picking an engine with tutorials that cover the kind of game you want to make is completely reasonable.
You don't need to learn everything about programming before starting your first game; you just need to know how to make some specific things work, such as moving a character, making collision detection, and you can learn other things later on as you need them. Following a tutorial that creates a small, complete game from scratch will teach you much more than taking an abstract programming course not connected to the actual project. Considering the early code as something that will be rewritten and improved later helps to prevent any stalls at this point.
Adding levels, art, menus or the story after completing everything else is a mistake that leads nowhere. First of all, you should try to make the one central mechanic of your game work in a simplest possible way – jumping, shooting, matching or building, whatever it is. And if this mechanic is not enjoyable even in the roughest form, as a plain gray box with no art and no sound, it means that there is some basic problem that additional content and polish will not fix. Completing this part first is the highest-leverage move that you can make.
Using simple shapes, free assets or sketches instead of the finished art helps you to see whether the game is actually fun or not before investing any time in creating art that may need to be changed anyway if the mechanic proves to be bad. Many beginners spend too much time perfecting the art for a game, whose core mechanic was never proved to be enjoyable, and it is time invested in the wrong direction. Real art is worth adding only after the mechanic of the game has been proved to be fun.
Showing the unfinished, roughest version of your game to somebody else and observing how this person plays it reveals many of the moments that are hard to notice because you got too close to the project. Watching someone playing your game shows much more than asking this person to tell what he or she thinks about it, as many problems cannot be mentioned at all. Getting such feedback early in the process and while the changes are still possible is much more important than waiting until the game feels like it can be shown to anyone.
The final stage of the project, during which you are fixing bugs, cutting unnecessary features, and making your game shipable instead of polishing it forever, is a completely separate skill. Cutting off the unnecessary features in order to complete the game on time is usually the right decision to take. A smaller and completed game always gives much more profit and satisfaction than an ambitious project left unfinished. Considering the "small and finished" game as a genuine success and not a compromise is what allows to learn from the project cycle.
Your first completed game is probably not very good, but it is absolutely okay, as its real value is teaching you the whole process of developing games, and not being something impressive. All particular problems that you faced while making the game – the mechanic that is not fun, the art that takes too long, or the overgrown scope – will be the things that you will be able to plan for next time. Completing several small games one after another will give you much more profit than spending the same time on making one big but unfinished game.