First you'd start learning how to program, not just games. Learn the syntax, programming logic, and so on. On its own, C++ is just a programming language, it can do anything but it comes bare-bones with a fairly low-level standard library. There is no "PlaySound" function, for instance, you have to write it yourself or get an existing engine which is capable of audio playback. As an analogy, C++ is like a hammer. It can hammer nails in pretty well, but it won't build houses on its own, that's your (the programmer's) job.

Then, if you are to use an engine, it provides lots of stuff to help you push stuff on the screen, make sounds play, load stuff from various file formats, and so on - indeed, that's what an engine does. For instance, it may provide you functions to load models from the disk, or to play an MP3 file, it will give you tools to display objects on the screen and shade them however you want, it may even help you in the game logic by implementing a physics engine, such that you only need to provide it with your objects' coordinates and maybe a collision detection function and it'll do the rest for you.

Then, you put it all together, and you have a game. Of course, it takes a lot of work, and even just learning how to use the engine will take a long time especially if you are going to use an unmanaged, low-level C++ interface. For instance, using DirectX, you will have - literally - dozens of functions, methods, data structures to juggle with, of course you probably won't use most of them but you know that they are there should you need them. Moving up a bit, SDL will expose most of this functionality but in a more friendly manner. As you go to a higher interface level, you naturally lose some flexibility and functionality, but things are a lot easier to set up.

Then you also need to distinguish "game engine" and "graphics engine" which is a common mistake. A game engine will give you the tools to do everything in your game, ranging from playing sounds and video to displaying complex models on the screen and even networking. A graphics engine on the other hand will only help you for the graphics part of your game, you're on your own for the rest (of course you can combine engines).

All in all, without prior programming experience, I suggest starting small with basic text-based games, once you've learnt the ropes of the language. Something like a "guess the number" game, then a text-based roguelike, then maybe move on to a graphical minesweeper or breakout (this one seems to be popular these days). Then you can give 3D games a shot, if you want to make one, and so on.. take it one step at a time or you will get discouraged.

Hiya Scoots,

Out of curiosity, do you have any platform in mind? By platform I mean devices, like a Windows Desktop or a Android Tablet, or the iPad, etc. Each device has their own little ways of doing things. For example, the Java programming language is considered the standard for Android based devices, where as the Apple devices primarily use a language called Objective-C. The Metro side of Windows 8 makes use of JavaScript, C#, or C++ depending on what type of application you plan on targeting, where as the 'good ol desktop' is pretty much open to whatever programming language you feel like using. I'm asking this because if you have a particular goal in mind then it may shape what you want to start learning.

Anyway, 'how do I start making games' is a surprisingly heavy question. There is bunch of stuff that a person must learn before they can really start making a game, and it is sometimes difficult to maintain the patience to learn all of the things correctly. After you have the platform in mind the next step is to start learning a programming language. You mentioned C++, but it might be a good idea to start with something a little less involved and gradually work your way up, or, who knows, perhaps you will find that you don't even need to move to C++ to meet your goals. C++ is complicated, but it isn't just the language that is complicated. Setting up the compiler/linker/IDE is much more involved than say, Python or C#, in which these extra steps pretty much don't exist.

A handy thing about programming languages is that the concepts learned in one have a very high level of transferability. If you play around with Python for a couple of months, it will be much easier for you to get the hang of any other language out there. The way the program looks aesthetically (called syntax) may vary from language to language, but the underlying concepts invariably are the same. This means once you get the hang of Python you could jump to a language that more closely resembles C, such as Java or C#. Then once you have the syntax down you could jump to C++.

A thing worth noting is that, depending on the platform, C++ is not required to make games. For an absolute beginner, it may be best to go with Python and Pygame. Pygame has a few tutorials on their website you could take a look at, but, as Bacterius mentioned, the first thing you will want to do is get a solid feel for the language you are using. Python, unlike C++, requires almost zero setup (you download and run an installer) and thus it is much more beginner friendly. Pygame is nice because it offers a gentle introduction into game development. Most of the annoying cruft is cut out, so you can focus on learning and experimenting instead of focusing on memory leaks and bizarre pointer issues.

Microsofts XNA or the open source MonoGame may also be a good starting point, but they are slightly more involved. It may actually be good to start with PyGame, and, once comfortable, move to XNA. XNA would introduce you to shaders and reveal a bit more of the 'metal' without getting too 'metaly.' I got my start with XNA and C#. It was pretty tough, but it was also so much easier than trying to tackle C++ and raw DirectX. I can't even imagine trying to do that without some bit of previous knowledge. C# & XNA was a great stepping stone.

Anyway, if you decide to start with C# or C++ you will want to download a thing called an Integrated Development Environment (IDE.) An IDE is pretty much a glorified text editor married to a complier that makes programming significantly faster and more pleasurable. For Windows I recommend Visual Studio. And it's free too ( at least the Express edition ) so there should be no barrier to playing around with it.

You also asked if you had to use an engine. The answer is no, you dont, but, depending on what you enjoy doing and how your mind works, you may enjoy working with an existing game engine over building your own. My mind enjoys the engineering, so I naturally shy away from Game Engines and build my own for the fun and experience. But perhaps you are the type who wants to make games more than write code. If you are that type than Game Engines are nice, but, as with programming, there is an unfortunately steep learning curve. Some Game Engines don't require you to know any sort of programming language, such as GameMaker (it uses a drag and drop event system, though it can be a bit challenging at times to achieve the behaviour you want.) It is also worth noting that many, but not all, game engines require you to purchase a software license to use them to their full potential, so that is something to keep in mind if you are strapped for cash.

The above posters have it pretty much in the bag, but I'd like to mention and emphasize the need to figure out your "current" goal. I say "current" because you can always change things later. For example, if you just want to make games, avoid C++ and go for something like GameMaker, though that doesn't mean you can't learn C++ later. And contrary to popular belief, the concepts you learn in GameMaker DO carry over to other languages, so it isn't a total loss.

On the other hand, if you really want to get down to the metal, go with the path mentioned by the others and do some language, any language(well, almost) and just make some small things, getting bigger each time.

Assuming you attempt both of these paths, you can see what you like better, and go one way or the other, or something in between. The extremes would be something like GameMaker vs. something low-level like C++, while mid-ground would be something like panda3d(with python or C++) or even Ogre3d and some other engines(for sounds, physics, etc...) with C++. In general you don't have to do everything yourself, and if your goal is to make games, you are better off doing as little reinventing as possible, and for more on that point, look up "Make Games, Not Engines" and you will see many opinions on that subject.

I would like to chime in and mention that C++ is actually one of the least commonly used languages for coding the logic of games. C++ is a very low level programming language that essentially gives it's coder access to operating system and hardware interfaces. From there you as a programmer can write thousands and thousands of lines of code to accomplish nearly anything.

With that being said I feel that someone should step up and stress that C++ is NOT a programming language for developing games, it's a programming language for creating engines, software and solutions. You should consider C++ as the means of interacting directly with a devices operating system and hardware. In the right hands C++ is capable of anything including game logic, but it is actually rarely used to create the logic of a game.

To elaborate just a bit more I suggest looking into some commonly used engines within the game development field. Unity for example uses JavaScript, Boo or C# to script up the games logic and itself is built on C++. UDK and Unreal also follow this same method, they are themselves written in C++ but you code your game in Unreal Script not C++. Lua is another scripting language that is commonly used to write logic, interface and menu's to the game (which in reality are the major driving force of the game's content itself). Lower level "Rendering Engines" such as Ogre3D and Irrlicht are C++ libraries that you can invoke and wrap your own Game Engine around, many times people using these rendering engines also write their logic in C++ (but my opinion says this isn't the best method).

There are many reasons why so many development professionals, teams and indies choose to use engines and write their logic systems in various scripting languages, so many so that it could warrant an entire conversation on it's own. I don't want to get too far off topic here but would like to highlight a couple of the main reasons why many people feel it's better to use an engine and simply script their games logic in whatever scripting languages are supported by said engine.

Ease and Productivity:

This is arguably the biggest benefit of using a scripting language for your content and logic. Simply put most scripting systems are tied into the engine in such a way where they directly relate to game objects and content. Most of the time it allows you to think more in game related content than in code objects and technology. This also allows you to be much more productive as it takes much less code to get results. C++ is a VERY complicated language that can take many many years to get good enough with to actually make progress in your projects. Scripting languages normally require just a basic understanding of coding and a problem solving mind set.

Hot Swapping & Quick Building:

Another very important point of using scripting languages is that most of them do not require complicated and time consuming compilation procedures like C++ does. A bit of a side note is that everyone mentions C++ is cross platform and powerful but very few announce the dirty little secret that the compilation of C++ code is vitally dependant on matching built libraries, installed pre-requisites and for best performance needs to be optimized to the specific hardware in which it is actually running on. Scripting languages normally bypass the majority of these complications by running in a C++ written interpreter. This interpreter likely was built in such a way that it will offer very good performance on a wide variety of hardware and you can focus entirely on your code instead of seeking out per system bugs and optimization issues. In some cases such as C# your code is actually executed through a virtual machine of sorts that in itself is optimized to the exact hardware that it is running on and in some cases can actually perform faster than generically optimized C++ builds.

All in all I'm not trying to discourage anyone from learning C++, nor am I trying to say that C++ doesn't have it's uses. I do believe that it is important to explain to newer developers that C++ is not the only way to get it done. Actually in many cases it's the last way that developers will go to create a game, and in some cases it actually hinders your productivity and performance if you are not an expert in the language and compilation procedures. If your goal is to be the best computer programmer you can be then C++ might be what you want to work on. If your end goal is to create a game and you have less than 8 years of real world experience with C++ I would advise that you get a ready made engine and learn it's scripting techniques to create your game's logic. This will apply to the programming techniques and theories that can later be applied to other languages up to and including C++.

Do you mean to say that an interpreted language such as some script is faster than a compiled language such as C++?

It's a known fact that the more information you give to a compiler or interpreter, the easier it will be for it to optimize your code. Low-level code is thus quite hard to optimize, whereas high-level code has it a bit easier because the compiler/interpreter can make better guesses as to what the code is doing at a high level and apply more specific optimizations whereas low-level compilers can only make generic attempts at optimizing the code. But this doesn't really apply to scripting languages because they are not built for performance.

What I think he meant is that for scripting languages, you don't need to recompile your entire game or program every time you change one tiny thing, which makes scripting languages ideal when you need to prototype something quickly. Do you really want to wait 5-10 (or more) minutes each time you tweak a constant or some formula to get the effect you want? With scripting languages, you don't have to Of course partial compilation (with object files) makes compiling C++ code faster, but it's still pretty slow overall (and if you change a header.. ouch..)