Hi!
Im looking for help and guidance as i make my first real game.
I fairly know the basics of c++ as i am self tought and may have understood a few things wrong.
Ive made a basic rougelike and a simple text based RPG in the cmd.
Now my next goal is to learn how to use and implement raster graphics in a simple 2D based game.
And also polish my basic of c++ knowledge.

Congrats on completing your text-based games; that's a significant accomplishment!

For 2D graphics in C++, I really like SFML and SDL. I've used both of them, and both a great. If in doubt about which to choose, I'd lean towards SFML.

SFML and SDL both have 2D graphics, window creation, event input (keyboard, mouse, gamepad), and sound capabilities (for SDL, it's through a third-party add-on called SDL_mixer). Everything thing a growing game needs.

They abstract away platform-specific gunk like talking to the operating system directly, but are still low level enough that you'll need to write alot of your own game logic for things like loading and displaying maps, GUI stuff, enemy logic, and so on.

(In programming, "low level" means "close to the metal" of the operating system - (low level doesn't mean 'easy') - and "high level" means more abstracted and ready-to-use out of the box. Both SDL and SFML are somewhere inbetween. They are mid-level or low-level abstractions over even lower-level operating system specific features)

Though there are third-party libraries available for GUIs, like SFGUI, most basic games don't need all those features and just write a few basic classes from scratch.

What kind of advice are you looking for? Are there any specific questions you would like answered?

Hello,

You might also have a look at cocos2d-x an open-source cross-platform 2D framework (iOS, Android, Mac, Linux, Windows...). The core engine is C++ but Javascript and Lua scripting are also supported. I used it for my first game and it's really a great 2D engine.

Laurent

Thank you Servant!
Ive looked a bit into OpenGL and SDL before but i have never heard of SFML.
I even tried going through planetchili's tutorials on directX, not sure if i should wait untill i completly understand

the basics of C++ before looking in to it too much.
Im so eager to learn that i sometimes get over my head hehe.

But one thing that i wish to know more about is Object Oriented Programming.
I tend to write all my code in one file only and wish to learn how to split the code in different categorised files.
Ive tried to learn how to use classes and scopes but i never really figured it out.

And also, is there anyplace where you can find completed games that i can study further?
I tend to learn faster if i see the whole picture then splitting it in to small parts.

Thank you Voodoo!
Ill check it out! might be a good way to start!

Im so eager to learn that i sometimes get over my head hehe.

We've all been there!

But one thing that i wish to know more about is Object Oriented Programming.

There is alot of confusion about OOP, with alot of beginners (and professionals) not understanding and mis-explaining what OOP actually is. I probably don't have it entirely straight myself, so hopefully an expert will correct me if I say something factually incorrect.

OOP is a programming paradigm - it's a way to think about code engineering at a more abstract (theoretical/conceptual) level.

OOP is not the only paradigm - there are several different paradigms, and sometimes you'll want to even use different paradigms in different parts of the same project (some paradigms are better suited in certain situations, some paradigms apply to entire projects, some paradigms only apply to smaller sub-portions of the project).

There is misconception that 'classes' is OOP, which isn't true. You can use classes without coding OOP-styled code, and you can code in an OOP style without using classes.

OOP is not dangerous, and it's not a bad style, it's just not a high priority for a beginner. There are many very good ideas that have come out of OOP, and those ideas are good to learn once you have a more concrete understanding of the basics, but jumping into them too fast might make your head spin with terminology you haven't learned yet.

"Learning OOP" is not something I'd worry about yet, if I was you, but learning how to use C++ classes, and how to write good code? That is really important, and something you should start on as soon as possible. Whether or not you write code in the "OOP" style, is another matter.

I tend to write all my code in one file only and wish to learn how to split the code in different categorised files.

That's very important to learn (and is unrelated to OOP). This article should get you started, and if you have any questions, just ask!

Ive tried to learn how to use classes and scopes but i never really figured it out.

Keep at it! Some things are just confusing and confusing until suddenly, in a moment, you understand it and never have problems with it again. By banging your head against a wall enough times, sometimes you suddenly break through the wall.

But ask questions! And still more questions! It might save your forehead some pain.

Scopes and classes, despite both containing curly { } brackets, aren't really related. Do you have any questions about scopes or classes?

And also, is there anyplace where you can find completed games that i can study further?

There are some tutorials that step-by-step take you through simple games like Tetris or Asteroids, and usually include full sourcecode. (You can usually find them easily enough on Google - try something like "sfml c++ tetris tutorial")

There are also some full AAA games like Quake 2, Doom 3, Halflife 2, and so on, that have their full sourcecode publicly released. Those are really complex though, and not designed for learning, so although you'll definitely learn a bunch, it might not be the easiest way to learn, and you might accidentally learn bad coding habits when those developers were rushing to meet deadlines and were taking shortcuts.

They also aren't the easiest to jump into and start learning, because you first have to invest alot of effort to learn how to even compile such complex codebases, and just because Quake 2 and Doom 3 are opensource doesn't mean their game assets (3D models, levels, etc...) are publicly available, and even if the code works as intended, it may just crash without the assets.

Halflife 2 is a bit of a different story. While still very complex, there are at least more tutorials on how to compile it, the assets are included with it (assuming you own HL2 on Steam, which is only a few bucks, if not free), and it has a huge modding community around it who can answer more detailed questions. There are still likely to be bad habits and sloppy coding shortcuts, it's still not written with the intent to be learned from, and it still is overly complex if you don't already know foundational C++ features and behavior.

Some people find it helpful though.

Thank you Servant!
Ive looked a bit into OpenGL and SDL before but i have never heard of SFML.
I even tried going through planetchili's tutorials on directX, not sure if i should wait untill i completly understand

the basics of C++ before looking in to it too much.
Im so eager to learn that i sometimes get over my head hehe.

But one thing that i wish to know more about is Object Oriented Programming.
I tend to write all my code in one file only and wish to learn how to split the code in different categorised files.
Ive tried to learn how to use classes and scopes but i never really figured it out.

And also, is there anyplace where you can find completed games that i can study further?
I tend to learn faster if i see the whole picture then splitting it in to small parts.

Not to be a suck up, but if you want to learn quickly and correctly id do almost everything Servant has suggested. I'm also new to c++ and have posted topics similar to this asking for guidance. I think I have used every bit of advice he has given me and my project is really starting to pick up! He seems to be an informed fellow.

I'd also suggest SFML as that's what was suggested to me. Not only is it fairly easy to use, it's well known so whenever you're in need of help there will be many experienced users capable of answering questions quickly and efficiently!

In regards to your knowledge of OOP - It may seem like it's hard to use now, but the truth is it makes coding everything easier (although as mentioned, I'm not a c++ expert). This being said, try to plant the object oriented seed as early as possible. I learned a decent bit about it in school, but that was with Java. I'm not sure how much it will help with "the bigger picture", but this video gave me a refresher on proper class declaration and syntax.

->https://www.youtube.com/results?search_query=c%2B%2B+classes+and+objects+tutorial

It doesn't seem very overwhelming but if it is maybe watch a few of the videos he posted before. That guy has an annoying voice but he's not too bad at teaching someone who has little knowledge of a topic.

Good luck!

Thank you so much Servant!
I started going through everything you said since you mentioned it!
And im finally getting a grip around classes!
But i only have one problem left.
I have learned how to call and retrive functions through global classes, but when i try to initialize a global integer i get the Error.
1 IntelliSense: a nonstatic member reference must be relative to a specific object

I tried to make the int static, but i cant seem to get it right!

My point is to make the int global so that i can access it from any function though out the code.

haha yeah! i kinda understood that!

that explination of OOP was the best ive seen of the many articles i searched and read on the web.

I'd also suggest SFML as that's what was suggested to me. Not only is it fairly easy to use, it's well known so whenever you're in need of help there will be many experienced users capable of answering questions quickly and efficiently!



In regards to your knowledge of OOP - It may seem like it's hard to use now, but the truth is it makes coding everything easier (although as mentioned, I'm not a c++ expert). This being said, try to plant the object oriented seed as early as possible. I learned a decent bit about it in school, but that was with Java. I'm not sure how much it will help with "the bigger picture", but this video gave me a refresher on proper class declaration and syntax.

yeah i started looking into it all :) trying to learn as much as posible.
Since i got rejected from the course i wanted to study at the university i thought i might as well take up the studies in my own hands.

Hoping to enter next year!

And thank you very much for the link! i appreciate it!

But i only have one problem left.
I have learned how to call and retrive functions through global classes, but when i try to initialize a global integer i get the Error.
1 IntelliSense: a nonstatic member reference must be relative to a specific object

I tried to make the int static, but i cant seem to get it right!

My point is to make the int global so that i can access it from any function though out the code.

It's actually bad practice to create globals. Globals, in general, should be avoided. There are some cases where globals are very useful though.

The temptation to use globals is because "it's easier" to not have to pass in the variable (by reference) as a parameter. But that easiness comes back to bite you the larger your project gets, because it makes it harder to track down bugs and figure out the flow of the program.

This isn't to say all globals are bad. Constants, or values that behave similarly to constants, are fine as globals.

Some classes also make sense as globals (like "std::cout" and "std::cin" are actually globals). Error logging makes sense as globals. But in general, you want to be careful with them.

One example of a bad use of globals is when you have a function that gives different results even when you call it with the example same input parameters because it uses a global internally. Functions should, in general, always try to give the same result when passed in the same input.

That said, now that you know the general guidelines (that important when your projects start getting larger), and understand that it's not a rule and that it occasionally needs to be broken, here's how you use them:

Here's how to create a global constant, which is very good to use:

//In any one header file:
const int MyConstant = 12345;

If you define a constant in a .cpp file, only that .cpp file can access it. This is good, if only that file needs it.

If you define a constant in a .h file, any file that #includes that .h file can access that global. This is good if more than one file needs it.

Here's how to create a global that isn't constant:

//In myFile.h you do:
  extern int MyGlobal;
//^    ^
//Note the keyword 'extern'.
 
//In myFile.cpp you do:
int MyGlobal = 357;

With non-const globals, the source file creates and initializes the global, but the header file "exposes" it by using the 'extern' keyword. Any file that includes the header file, then has access to the global.