2d Game building

Pages: 12
Hello All,

I just started learning c++ and was wondering what were the lessons that I would have to learn to be able to build a very basic game. So far, I have learned loops, arrays, parameters, and functions.

Thanks,
Those are the minimum really. But if you want to do anything big, invest in learning basic OOP.
What is the principles that make up OOP?
you got few more to learn, like references and pointers, OOP (object oriented programming) allows you to define Classes, which are very useful especially when you're writing games.
Okay, let me guess that those are more of the more advanced lessons when it comes to c++.
Classes themselves are actually not bad for beginners. Pointers and references take longer to get used to in my opinion. Both are immensely helpful in game development, whether it's 2d or 3d, indie or AAA.

You also might want to later on (After you learn classes, structs, pointers and references, and perhaps a few other things you need to learn) check out STL. It has some handy features.
I have heard about STL, but not done research. Is that a game engine? Also, is there a reason to pick certain free engines over others? Or do they all work the same?
STL stands for Standard Template Library. It's exactly as it sounds, a standardized library of various features and functions to make our lives easier in the long run. Every update with C++ adds something new to the STL, and C++14 (I believe) is said to be including the Boost library. If you don't have Boost, get it.

My advice would be to do what I did: Build simple games with what you know or want to know. Then rebuild, update, new project, update, new game, rebuild, ect, learning new things about the language and experimenting more and more with each iteration. A C++ reference manual wouldn't go amiss.

What I'm getting at is that there's no solid, "This is what you need to know to make games." list out there. You can pretty much make a game with virtually any combination of C++ facets, within reason.

Experience is the greatest teacher we can have.
Thanks,

So i will be following your advice and start learning up pointers, references, and in due time libraries. Thanks for the input.
After you are familiar with C++, start learning SDL library.

http://www.libsdl.org/

Also drop a look :
http://www.youtube.com/user/thecplusplusguy/videos?view=1&flow=grid
After you are familiar with C++, start learning SDL library.


I love the SDL library. It's a bit harder to learn in respect to Allegro or SFML, but it gives you so much more power and control where you need it.

You mentioned what kind of game engine you should choose for a game. For your first one, I don't think I'd be a bad idea to write your own engine. It's not difficult to make a simple one and it's a great learning experience for a beginner.

Just like Aleksandar linked, I highly recommend The C++ Guy to teach basic C++ and SDL/OpenGL.
I love the SDL library. It's a bit harder to learn in respect to Allegro or SFML, but it gives you so much more power and control where you need it.


SDL does not offer any more control than SFML does. In fact in my experience it offers significantly less.
SDL does not offer any more control than SFML does. In fact in my experience it offers significantly less.


What do you mean? SDL has been nothing but a rock-solid library for all of my projects. I've never been able to get into SFML like I have SDL. What can it do that SDL can't?
What can [SFML] do that SDL can't?


In typing a response related to SDL 2.0, I checked SDL 2.0 documentation and it appears as though the parts that I thought were not addressed have been addressed.... so this may no longer be the case.

But if you are comparing SFML to SDL 1.2, then the list is like a page long. I've ranted about it several times on this board and do not feel like repeating myself.


My biggest beef with SDL 2.0 is that it keeps around some of the old functionality which not only should have been deprecated, but probably should have been completely removed (read: SDL_Surface).
SDL_Surfaces have it's use when you're using them with OpenGL.
Why would you use them with OpenGL? OpenGL uses textures, not surfaces.
It makes life easier when loading images.

Just load in the image, check if it's NULL or not, and then it's really a matter of plugging in struct members in the function.
Alright so it doesn't just load straight to texture? You load to a surface then copy to a texture? That makes sense.
Last edited on
Doesn't it all work like that? I don't know from programming, but from modeling/rendering/etc, you have to give an object(.obj) a surface(material) before you can give it a texture.
SDL surfaces are different from the type of surface you're referring to.

But yes, it is common practice to load the texture into system memory before loading it into video memory as a texture.
Pages: 12