First of all, let me say that I found this site very helpful and that I read the article on beginning game programming.

OK, so let me begin. Me and my friends have decided to learn C++ in detail (we know other programming langauges, but since we want to create a game in C++, we wanted to learn C++ in detail). We told ourselves to first watch thenewboston's C++ tutorials on Youtube, then read Beginning C++ Through Game Programming and after that study SFML in detail (since our game is going to be created in SFML). We also found some SFML tutorials on Youtube.

Altough I read almost every article on Beginning Game Programming, the thing that bugs me is that no one tells you how to actually start creating a game.

To clarify myself, when we do all of the stuff above and learn C++ and SFML, so we can write games, we don't know what to do first. Will it be creating a menu, or putting a background image, or importing characters (2D), I don't know.

So, that's my question. Can someone write something like :

'OK, this is how it should go :

1. Create a window for the game

2. Create a background image

3. Create a menu

...'

So when we start coding, we don't waste a lot of time figuring out what to do first (menu, background, window, importing characters, collision detection etc.), but we know what to do and use that time to code.

Thanks in advance!

I recently submitted an article outlining the steps most common to beginning this process. Currently it is under review and hopefully will be published on this site soon. It will be a series of articles, following the steps I follow, that allows me to generate good, clean code and that I can "See" progress, which keeps me motivated.

The First thing you want to do is create a map that outlines the goals of your game. This will be a small map at first. Then you may want the AH HA effect or "YES" effect.

Create your first image and get it displayed on the screen. This will be your motivation factor. A small goal with a big acheivment effect.

While you think about what to do next, keep on creating your graphic images. If this is your first game, make it 2D. It will make concetrating on your game mechanics easier.

Try placing objects on the screen, Click/Drag and drop these objects.

My articles will contain the complete code for a simple 2D game. Which I hope can become the building blocks for everyone with you question.

Looking forward to reading that article! You will really be helping us a lot, because even tough we will know a lot about C++ and SFML, we get kinda lost on that question, which is 'Where to start?'.

Anyway, I hope your article is going to solve our questions and we were actually planning to make a 2D game, so this is a bullseye!

EDIT : Please post a link to your article in this topic, so I can see it right away. Thanks!

Thanks again!

I've had the same issue and I'm still unexperienced, so I'm figuring as I go, but I think I can show how I think it's supposed to be... I don't use SFML, so you'll have to know what you're supposed to switch in/out from these notes:

- Learn the basic of Win32 programming if you're programming on windows (and even if you aren't, just so you can set up your prototype engine and test it), and OpenGL (or another graphic library)

This is how to create and show a window, menus if it'll be a window game, how to get user messages and such. Most of this is pretty basic and you don't need to know much, since you can create your own menu ingame, etc

Also, the graphic library requirements, like "what do you need to show something on screen?"

Coordinates are the obvious attribute, but there's usually some more stuff you need... if it's OpenGL for example you'll need a VBO's objectID, and a texture's textureID, etc...

- Create the Engine Layout: Separate and define where you'll have the Input, Graphics, Resources, etc (classes and functions you know you'll need)

Since I haven't seen many engine sources before, I did sorta like the XNA game engine, my Engine class has an Initialize() that starts up all the stuff required to run, Draw() for the drawing the scene, Update() is where the main game code will be, and Clear() when it's closing down.

There's a bunch more others, but these are the main functions.

Then set up the Engine with the basic Win32 window you have. Set up the basic user commands, such as when the user clicks the mouse or press a keyboard key, you'll send it to your GameEngine to handle.

- Create the objects layout

Your game will have objects, and what do they require to run? A position (x, y obligatory, z only if it's 3D), a direction, etc... you'll be growing this as you discover more and more stuff you need.

Stuff like which texture it has, which ID it is, etc.

- Create the layout of the Input, Resource, Graphics codes.

Your game engine will handle all win32 incoming messages, and from there you'll send to the appropriate classes, such as "did the user press a keyboard key? what's the code and other info I require? Send it to the InputEngine then", and your InputEngine takes care of saving the states of keys, such as if they're being pressed, released, etc...

Your Resource class should be responsible for loading resources from a file (such as .BMP, .OBJ, .FBX) into your Object class.
Your Graphics class should be responsible for drawing it on the system you've choose, using the info avaliable from the Object classes.

- Create the SceneGraph

This is one of the parts I'm currently studying, so it's sorta complicated for me for now... but thinking in a simplistic manner, it's a list of objects you have currently loaded in memory and that will be draw on screen.

With this you have the base of your engine ready... now you'll need to figure if your game requires a map editor or not.

A Map Editor is a program that will create resource files for your game.

For example, say you have a room (2D or 3D) with a bunch of interactive objects (means the player can interact with them somehow), each has it's own position, values, and states (if it's been interacted already or not for example). They're also images from files such as .BMP, and you won't leave the .BMP files in your game folder so anyone can easily delete/replace them and cause unexpected behavior in your game...

So you need all the data from the original resource files (.BMP, .OBJ, etc) in a format of your own, which will also contain the information your engine requires to build the scene you're building.

In a binary file, it would be something like this:

[objectID 1][name "myDoor"][type "bmp"][start objectData][BMP data here (pixels info and such)][end objectData]
[objectID 2][name "myTable"][type "bmp"][start objectData][BMP data here (pixels info and such)][end objectData]
[objectID 3][name "myBackground"][type "bmp"][start objectData][BMP data here (pixels info and such)][end objectData]

//etc
//actual scene data now
[object 3][background][x, y, z] //background at x, y, z
[object 2][object][x1, y1, z1][actions, events, states, etc] //myTable.bmp at position x1, y1, z1
[object 2][object][x2, y2, z2][actions, events, states, etc] //another table at x2, y2, z2
[object 1][object][x3, y3, z3][actions, events, states, etc] //a door at x3, y3, z3
//"actions", "events", "states" are informations your engine will know what to do with it

And then you'll have your maps ready... you also need to add collision boxes, which are objects that the player/other objects will have collision checks, etc

Your MapEditor is a program that will let you build these informations easier than typing it yourself, unless it's a really simple game, it's inviable to type it yourself... it's basically a program that will put resources on screen, let the user drag and position it themselves, and have some sort of "events/actions/flags" properties, and save this information in a binary file for your engine to read.

Then you go back to your game's ResourceEngine, and make it properly load the data from the file and properly display it, filling your Object classes with all information you require.

And finally, in your gameEngine's Update() function, you add your game logic... like checking for collisions (or separate it in another Physics class or function), doing an certain action if the player's close to an interactive object, changing the states of your game such as "Boss 1 killed" (so this will affect something else in your code, such as a door being accessible now, etc).

Since you're using SFML, there's plenty of things that you won't have to do, so you'll figure what do you still require and adjust it from there.

There might be missing a bunch of things (I haven't mentioned audio for example, or scripts), but I think that's the general idea...

And I was so happy when I managed to display my first "teapot".fbx on screen, thinking "just a bit more and I can start to build up my game logic!"

...sigh

I've had the same issue and I'm still unexperienced, so I'm figuring as I go, but I think I can show how I think it's supposed to be... I don't use SFML, so you'll have to know what you're supposed to switch in/out from these notes:

- Learn the basic of Win32 programming if you're programming on windows (and even if you aren't, just so you can set up your prototype engine and test it), and OpenGL (or another graphic library)

This is how to create and show a window, menus if it'll be a window game, how to get user messages and such. Most of this is pretty basic and you don't need to know much, since you can create your own menu ingame, etc

Also, the graphic library requirements, like "what do you need to show something on screen?"

Coordinates are the obvious attribute, but there's usually some more stuff you need... if it's OpenGL for example you'll need a VBO's objectID, and a texture's textureID, etc...

- Create the Engine Layout: Separate and define where you'll have the Input, Graphics, Resources, etc (classes and functions you know you'll need)

Since I haven't seen many engine sources before, I did sorta like the XNA game engine, my Engine class has an Initialize() that starts up all the stuff required to run, Draw() for the drawing the scene, Update() is where the main game code will be, and Clear() when it's closing down.

There's a bunch more others, but these are the main functions.

Then set up the Engine with the basic Win32 window you have. Set up the basic user commands, such as when the user clicks the mouse or press a keyboard key, you'll send it to your GameEngine to handle.

- Create the objects layout

Your game will have objects, and what do they require to run? A position (x, y obligatory, z only if it's 3D), a direction, etc... you'll be growing this as you discover more and more stuff you need.

Stuff like which texture it has, which ID it is, etc.

- Create the layout of the Input, Resource, Graphics codes.

Your game engine will handle all win32 incoming messages, and from there you'll send to the appropriate classes, such as "did the user press a keyboard key? what's the code and other info I require? Send it to the InputEngine then", and your InputEngine takes care of saving the states of keys, such as if they're being pressed, released, etc...

Your Resource class should be responsible for loading resources from a file (such as .BMP, .OBJ, .FBX) into your Object class.
Your Graphics class should be responsible for drawing it on the system you've choose, using the info avaliable from the Object classes.

- Create the SceneGraph

This is one of the parts I'm currently studying, so it's sorta complicated for me for now... but thinking in a simplistic manner, it's a list of objects you have currently loaded in memory and that will be draw on screen.

With this you have the base of your engine ready... now you'll need to figure if your game requires a map editor or not.

A Map Editor is a program that will create resource files for your game.

For example, say you have a room (2D or 3D) with a bunch of interactive objects (means the player can interact with them somehow), each has it's own position, values, and states (if it's been interacted already or not for example). They're also images from files such as .BMP, and you won't leave the .BMP files in your game folder so anyone can easily delete/replace them and cause unexpected behavior in your game...

So you need all the data from the original resource files (.BMP, .OBJ, etc) in a format of your own, which will also contain the information your engine requires to build the scene you're building.

In a binary file, it would be something like this:

[objectID 1][name "myDoor"][type "bmp"][start objectData][BMP data here (pixels info and such)][end objectData]
[objectID 2][name "myTable"][type "bmp"][start objectData][BMP data here (pixels info and such)][end objectData]
[objectID 3][name "myBackground"][type "bmp"][start objectData][BMP data here (pixels info and such)][end objectData]

//etc
//actual scene data now
[object 3][background][x, y, z] //background at x, y, z
[object 2][object][x1, y1, z1][actions, events, states, etc] //myTable.bmp at position x1, y1, z1
[object 2][object][x2, y2, z2][actions, events, states, etc] //another table at x2, y2, z2
[object 1][object][x3, y3, z3][actions, events, states, etc] //a door at x3, y3, z3
//"actions", "events", "states" are informations your engine will know what to do with it

And then you'll have your maps ready... you also need to add collision boxes, which are objects that the player/other objects will have collision checks, etc

Your MapEditor is a program that will let you build these informations easier than typing it yourself, unless it's a really simple game, it's inviable to type it yourself... it's basically a program that will put resources on screen, let the user drag and position it themselves, and have some sort of "events/actions/flags" properties, and save this information in a binary file for your engine to read.

Then you go back to your game's ResourceEngine, and make it properly load the data from the file and properly display it, filling your Object classes with all information you require.

And finally, in your gameEngine's Update() function, you add your game logic... like checking for collisions (or separate it in another Physics class or function), doing an certain action if the player's close to an interactive object, changing the states of your game such as "Boss 1 killed" (so this will affect something else in your code, such as a door being accessible now, etc).

Since you're using SFML, there's plenty of things that you won't have to do, so you'll figure what do you still require and adjust it from there.

There might be missing a bunch of things (I haven't mentioned audio for example, or scripts), but I think that's the general idea...

And I was so happy when I managed to display my first "teapot".fbx on screen, thinking "just a bit more and I can start to build up my game logic!"

...sigh

Thank you for this detailed description. I am surely going to read it.

Here's the thing: you can read all you want, watch all you want and study all you want about programming. But you're missing one thing: you're not actually doing the coding yourself. How can you really think and understand until you actually confront programming face to face?

Programming is a game and a puzzle. It is also about ideas and how these ideas relate to each other and how you can combine the ideas to make something beautiful: a program.

For collision detection, you can bound a rectangle against your game character. Then bound a rectangle against your enemy monster. Test these rectangle for intersection. When these rectangles intersects happen, you know a character collided with a monster.

Start applying the concepts you learn even the most basic fundamentals are crucial to making the most basic and simple game. Start writing games that you can actually write.

Once you have a decent grasp of C++, start on the SFML. Learn it as you go, and just make parts of your game so you can see some visual results to give you encouragement to keep going. The tutorials on the SFML site show you some basics of how to use each piece, so you can build off of that.

I hope serapth doesn't get bothered by me going back to this: http://www.gamefromscratch.com/page/Game-From-Scratch-CPP-Edition.aspx

His C++ tutorial with some SFML mixed in.