Already know C++ - where to learn game programming?

In order to get started I'd recommend using a widespread and well documented framework such as SDL (short for "Simple Directmedia Layer"). It's free to use and saves you all the tedious work associated with initializing a client window, setting up a graphics device etc.

Here's a step by step guide on creating games with SDL
http://www.sdltutori...tutorial-basics

and the actual homepage of SDL
http://www.libsdl.org/

I can't find a place to learn how a game is broken down into several source files, how to organise classes amongst the several source files, the logic of header/source file,

Those aren't game-specific topics, but you might try organizing code files in C and C++.

how to implement the game loop

Try deWiTTERS game loop and fix your timestep.

I read somewhere (can't remember the site) that a good checklist of games to make is [...]

That's a pretty good check-list, but I would recommend starting with Pong rather than Tetris. Both are relatively simple games that feature much of the functionality found in larger, more complex games, but the block logic in Tetris can be a bit complex for a beginner's first game and isn't something that is likely to continue to be useful unless you're making a very similar game.


Like the above member, I would also recommend choosing an API such as SDL, SFML or Allegro and working on some basic games.

Here's a step by step guide on creating games with SDL
http://www.sdltutori...tutorial-basics

There's also Lazy Foo's SDL Tutorials.


Hope that's helpful!

C++ by itself does not contain any library to access the video, input, and sound hardware, which is what you need for games. So in order to do that, you'd need to use a 3rd party API. SDL, SFML, as people mentioned are good candidates.

Once you familiarized yourself with the API, then you can start working on the core of the game. There isn't any 'de facto' Tetris tutorial, as there's no one correct way of making a Tetris (or anything else really). How you make it is up to you. Other people's source code should be good as points of reference. Here's one: http://code.google.c...e-tetris-clone/

As a beginner, I wouldn't suggest trying too much organizing your code. Your lack of experience will probably backfire -- chose the wrong patterns, premature optimizations, and all that. Do it as best as you can, but the most important thing is to actually complete your game. After you complete your game, your knowledge of project structure will skyrocket, and you'd know how to do it better next time.

Please try this site .. it shows you how to use SDL starting from the basics, and it has exmples : Pong , Tetris and Breakout

http://www.aaroncox.net/tutorials/arcade/index.html

As a beginner, I wouldn't suggest trying too much organizing your code. Your lack of experience will probably backfire -- chose the wrong patterns, premature optimizations, and all that. Do it as best as you can, but the most important thing is to actually complete your game

This is really invaluable advice. Do your best with what you already know, but don't worry too much about applying things you haven't previously used. Whilst there is value in reading about design patterns, code formatting, etc. you won't really understand a lot of these topics properly until you experience them first-hand. Write a game in any way you're able to make it work, and you'll learn a lot of lessons to improve future projects.

Hi,

The more I look into it, then the more that I see such an amazing variety of game structs. I know that you are looking for standard ways of doing things, but in view of all the endless kinds of games, there are few hard fixed standards in the coding because of the staggering variety of game designs, languages, technology, and needs. Much of the class structure, for example, is a matter of opinion, though there are ways of testing for performance. Considerations besides performance often dominate. Are you looking for formulas for coding success which apply across the board? You will find some.

Much of what you are asking will only be realized with hard work, experience, and deep ponder over a specific game.


Clinton

I would advice you to read book "Game coding complete" which describes very well game architecture, but it is not for total beginners.
If you want to see how particular game is built, check out, for example, Doom3 source code (available for free at web).

Of course building simple games is very different from pro gamedev. Try to not "overdesign" classes for breakout or tetris, as it will make most of your code redundant.

If you want to see how particular game is built, check out, for example, Doom3 source code (available for free at web).

I haven't reviewed the source code of doom3 myself, but I would guess it's way too complex as a starting point when trying to learn the basics of game development.

I think u should try learning native Windows api before choosing a game engine or DirectX (Engine Developing).

But WHY do you think that?

The design of a game depends on your own style and thought process. Some games such as pong may be more trivial(paddles are a class and the ball is a class) while other things such as complete game engines may require more work. In my opinion, it boils down to just looking at the concept for a game you thought up and analyzing it to find the best way to put it together. I would suggest starting with pong and SDL like other people have mentioned and work your way up from there.

My advice would be this...

1. Use C++ to create a command-line game. The logic here is to see what you can do with just the language on its own. Give it a title screen, main menu and then numbered-menu selections for the main game itself. It doesn't have to be fancy - just enough to enter keyboard text, load and save a game and to produce a game without the complications(distractions!) of learning APIs and generating art resources etc. My first command-line game was a turn-based RPG...it was a wonderful experience that taught me a great deal.

2. If you are using Windows, now go learn the Windows API. Your previous command-line effort will leave you hungry to put a simple image on the screen - the Windows API will allow you to make a more visual version with the added benefit of "point'n'click" with the mouse. In fact, the Windows API(using GDI+ or whatever it uses now) can allow you to make a simple action game such as pong or space invaders. I reckon one could even write a Ray-caster demo with WinAPI...possibly more. Its really a case of setting up a loop that runs on a timer, polling input from the keyboard & mouse, updating player/enemy positions etc, and then rendering...

3. With a sound grounding in both C++ and the Windows API, its time to consider two things - swatting up on your math skills, and learning a bit of software development. A bit of trig and algebra go a long way for those first few 2D games whilst software development will make you a more disciplined programmer. Your applications will have less bugs and your code will be clean and easy to understand...

...with all of this, games development will become a lot easier to understand. Take it from one who made just about every mistake under the sun when starting out...I would spare you that pain! o_O

If you decide to go with the previous poster's recommendation and learn the Windows API at an early stage, be prepared to spend considerable time just trying to grasp the concept of it. This particular step is difficult, and may kill your motivation altogether. It may seem like a trivial task, but just initializing a client window literally means hundreds of lines of code in this case. To complicate things further, the windows API uses their own type definitions for variables, instead of "int", you get "DWORD" etc, making the code almost unreadable at first for someone coming from a "pure" c++ environment. The beauty of frameworks like SDL and SFML takes care of all this (among other things) for you.

Don't get me wrong, I would still encourage you to grab the bull by its balls at some time and make use the windows API directly. Just remember it might seem overwhelming at first!

If you decide to go with the previous poster's recommendation and learn the Windows API at an early stage, be prepared to spend considerable time just trying to grasp the concept of it. This particular step is difficult, and may kill your motivation altogether. It may seem like a trivial task, but just initializing a client window literally means hundreds of lines of code in this case. To complicate things further, the windows API uses their own type definitions for variables, instead of "int", you get "DWORD" etc, making the code almost unreadable at first for someone coming from a "pure" c++ environment. The beauty of frameworks like SDL and SFML takes care of all this (among other things) for you.

Don't get me wrong, I would still encourage you to grab the bull by its balls at some time and make use the windows API directly. Just remember it might seem overwhelming at first!

That is a really bad idea.

Win32 is a right pain in the ass to learn, and...

It's dying. Microsoft is transitioning people to RT, basically you are doing the equivalent of learning Esperanto.

I mean, learning Win32 has some merit, especially in some more or less niche areas, but at this stage in your career, certainly not. Plus, my god does it teach bad practices.

I agree that the Windows API is a mess and teaches bad practice. My previous post was intended as a warning more than anything, where some of the API issues were highlighted.

However, unfortunately it's not dying. Despite Microsoft's recent efforts on Windows 8, Windows XP/Vista/7 are still by far the most used systems, and they will most probably remain to be over the next couple of years. For example, in September 2012, more than 21% of all desktops out there still ran under Windows XP! (http://en.wikipedia.org/wiki/Usage_share_of_operating_systems#cite_note-wikimedia-stats-1)

I agree that the Windows API is a mess and teaches bad practice. My previous post was intended as a warning more than anything, where some of the API issues were highlighted.

However, unfortunately it's not dying. Despite Microsoft's recent efforts on Windows 8, Windows XP/Vista/7 are still by far the most used systems, and they will most probably remain to be over the next couple of years. For example, in September 2012, more than 21% of all desktops out there still ran under Windows XP! (http://en.wikipedia....kimedia-stats-1)

Yeah, but reality is, almost nobody is writing to the Win32 level anymore. You are right, the API will be with us for a very very very long time.

However, people are either using a higher level framework ( like Qt, used for example by Autodesk Maya ) especially if they want to write cross platform code. Otherwise people are targeting the .NET layer above Win32. Even game developers dont really work with Win32... they write a small shim layer and that's about it. This coincidentally, is a "very good thing(tm)".

If you really want to look at app development using C++, look in to Qt.