Starting graphic games

[Alex cpp]

Hello, It's a long time that I wanted to start off a graphic game in c++ and I would like to know the basics of graphic games. I want to make a simple game where there is the player that goes around in the map, to begin. Can anyone tell me how to do it or just giving me advice? How do I put images and stuff, thanks in advance.

( I started programming in c++ by doing text-based RPGs and then i passed to other programs and stuff, my last "creation" was a card game. )

[cran]

Get some type of GUI toolkit or something to help with this:

Allegro http://www.talula.demon.co.uk/allegro/ , wxWidgets http://www.wxwidgets.org/ , FLTK http://www.fltk.org/, QT http://qt.nokia.com/ .. and many more:

http://en.wikipedia.org/wiki/List_of_widget_toolkits#Based_on_C_or_C.2B.2B_.28including_bindings_to_other_languages.29

Play around with a few of them until you find one that suits your needs.

[filipe]

I wouldn't use a GUI toolkit to make a game. Use a proper graphics library. SFML is the most recommended around these parts.

[shadowvillian]

Use allegro it ridiculously easy. heres a link to some tutorials:

http://www.loomsoft.net/resources/alltut/alltut_index.htm

[Return 0]

Alex cpp... based on your post history it seems you are VERY new to c++ and have not touched pointers, classes and many of the more important features. If this is true, you will have great difficulty trying to work with a graphics API at this point. You should continue studying the language. If you insist however, google SDL and SFML. Allegro isn't a bad API, but it is less popular.

[Disch]

Alex cpp... based on your post history it seems you are VERY new to c++ and have not touched pointers, classes and many of the more important features. If this is true, you will have great difficulty trying to work with a graphics API at this point

I disagree.

Using SFML isn't any harder than using iostream, it's just different.

[Return 0]

Ok fine, I agree using it is easy, what I'm saying is he won't understand it. He needs to understand how classes work, creating objects, etc... to be effective. Otherwise what's the point. The API is implemented in C++, so naturally wouldn't you want to understand the language it's written in to effectively use it?

[Disch]

Ok fine, I agree using it is easy, what I'm saying is he won't understand it.

That's the beauty of using a black box. You don't have to understand it.

Do you really expect him to understand iostream? I don't even fully understand it.

He needs to understand how classes work, creating objects, etc... to be effective. Otherwise what's the point.

The point is to learn. You learn language details with time.

Obviously everyone has to start somewhere -- you can't know everything right out of the gate. Does it really matter whether you learn the basics by using iostream instead of by using SFML?

The API is implemented in C++, so naturally wouldn't you want to understand the language it's written in to effectively use it?

Same could be said of iostream.

[Return 0]

I agree with everything you are saying. Maybe I'm not making myself too clear. Look at his last post: http://www.cplusplus.com/forum/beginner/35405/.

Alex cpp wrote:

.(I know if and else statement, algorithms and switch statement)

Do you really think he will be able to effectively learn the language details experimenting with a graphics API when he's completely new to C++(he may be able to)? I'm not trying to insult the guy's intelligence and I'm sure he can pick things up. I'm simply saying that it will be considerably more difficult and suggest he master a few other concepts before moving on. To me this is the equivalent of a 3rd grader learning basic mathematics and saying screw this, I'll pick up the rest next year in linear algebra.

[hanst99]

You don't have to understand how iostream works internally, but you should at least understand the way it's built. You don't have to use object orientation to write games, but then you could write them in C anyways.

[ultifinitus]

I don't know, Return 0, I kind of wish I had started graphically- you can see the results of your work much quicker, and it shows the relative requirement for the rest of the stuff.
On the other hand, if you don't know basic variables and loops and logic, it'll be awfully difficult =)


I would say go for it, if you don't know how to do something look it up- (also I recommend SFML, as I always do...)

[Disch]

@ Return 0:

I don't know if this is the norm, but how I learned when I was starting was I took example code from my book and copy/pasted it into my program to act as a sort of foundation. I then used the concepts I understood to add on top of that.

Eventually I grew to understand the parts that previously I was just copy pasting, simply by having used them enough to notice what they do.

For example Alex cpp might take a simple program from the SFML tutorials that shows how to draw an image to the screen. He might add on to that to move that image to a new location every frame. From there he might move it based on user input.

Now maybe that's not the best way to learn, but as you kind of pointed out... the traditional "learn A before moving onto B" approach doesn't seem to be working for him, so I think it's worth a shot.

Another reason I like the approach is that it's way more fun. When learning is fun -- you're more motivated and you learn more. Being able to make interactive games (even if they're stupid and buggy) is much more motivating than making boring console programs that have no purpose other than to teach you language basics.

hanst99 wrote:

You don't have to understand how iostream works internally, but you should at least understand the way it's built.

I'm not sure I agree with that either -- but maybe I don't know what you mean by "understanding the way it's built".

Personally, I feel the only thing that matters is being able to use it. If you understand how to use a lib, it doesn't matter whether or not you understand how it works/how it's built.


EDIT:

ultifinitus wrote:

I don't know, Return 0, I kind of wish I had started graphically

I did start graphically, and I am happy I did.

In fact, the book I was using did introduce the console first, but I intentionally ignored those sections and skipped ahead because I wasn't interested in any of that.

Of course my early programs were all a HUGE mess, but I guess that's how it goes. XD

[Return 0]

ultifinitus wrote:

On the other hand, if you don't know basic variables and loops and logic, it'll be awfully difficult =)

That's all I'm referring to. I wouldn't want the guy to get discouraged when he runs into issues, it would just be easier to learn the fundamentals first, which really is the right way. I know that approach isn't for everyone, so if he's up for the challenge go for it.

@Disch, I guess there isn't anything wrong with learning that way. Probably just depends on how you are learning, solo, university, etc... Experimentation is definitely a great way to learn and is one of the things Computer Scientists do all day.

He could always start with Java and get instant gratification... kidding.

[filipe]

Disch wrote:

Personally, I feel the only thing that matters is being able to use it. If you understand how to use a lib, it doesn't matter whether or not you understand how it works/how it's built.

I couldn't agree more. Of course, often we get curious and take a peek under the hood, but it shouldn't be a requirement. Otherwise we'd never get anything done.

[cran]

I agree that you don't need to know how it works under the hood, but I think the argument is valid in a way. To drive a car you don't need to know how the car works, but you do need to know the rules of the road. Same with driving a motorcycle. You don't have to know how to use iostream, but you do need to know the basics of programming... I say learn on a motorcycle if you don't really want to use a car... hmm, maybe that analogy doesn't fit.

On another note, one (me) should probably read things before posting suggestions to them... Doh!

[Disch]

That's a catch 22. You can't know the language before you write code. Writing code is part of the learning process.

We all know that Alex cpp needs to learn more. We also know that you need some kind of I/O in your program in order for it to be a meaningful learning experience.

So the question here is should he learn with iostream as the I/O lib? Or should he learn with SFML (or another similar lib) as the I/O lib?

Personally, if he has more interest in making games, then I don't see any reason why he should be dissuaded from trying SFML. That's basically all I'm saying.

[hanst99]

I still think that using the basic I/O routines first is a better idea, simply because it lets you write far smaller programs, more understandable programs that focus more on the logic than on the output (for example, for a program to try vectors out writing a GUI is complete overkill) Getting all this graphics stuff is neat (I'm still working on that), but it's a lot of stuff to cover that you simply won't get, and might possibly distract you from learning what you are actually doing (At least that's why way I work- if I write code I want to know what exactly I am doing. Of course that doesn't mean I need to know the implementation of the entire iostream library, but I think it's hard to write own code when you don't understand what's going on in your current code. At least that's how I operate, maybe some people have different experiences with that.

Anyways, Alex cpp said he made text based rpgs already, if that's true then he should have enough knowledge to deal with graphics libraries, so I don't even know what we're having this discussion for.

Wait I just saw his post history. At that stage, he should definitely NOT dive into GUI development yet.

[Disch]

hanst99 wrote:

I still think that using the basic I/O routines first is a better idea, simply because it lets you write far smaller programs, more understandable programs that focus more on the logic than on the output

I think you are way overselling the difficulty of graphics... as most people generally do.

If a newbie can understand that cout << "something"; displays some text... then I'm sure they can understand that screen.Draw(image); draws an image to the screen. It's not exactly rocket science.

Yes, there's some additional set up code involved (such as loading the image, etc), but not really as much as people tend to think. And most of that can just be copy/pasted from examples until they're ready to try and fully understand it.

What's more, there's always foundation code that a newbie puts in their program "just because". I mean, they all know then need to put #include <iostream> and using namespace std; at the top of their program, but ask them why and most of them won't have a clue. They just accept it as "something that needs to be there".

So instead, just replace those 2 lines of copy/pasta that they don't understand with maybe a dozen lines of copy/pasta that they don't understand. Yes, it makes the code bigger, but so what? Does that really make it any more difficult for them? I don't see why it would.

Wait I just saw his post history. At that stage, he should definitely NOT dive into GUI development yet.

Again I think you're selling him short.

Tons of programmers start with VB, which is GUI development. Personally I started with C++ w/MFC, which is GUI development.

In a way, it's actually easier. Code has a clear cause and effect. The user pushes a button, and they get a message. Simple. That's actually how I started. Push buttons and message boxes.

And I'll tell you something else... it's actually pretty easy to make simple games that way (which is what I did). Lots easier than it is to make games in the console.


Besides, when you get into anything nontrivial (ie: anything even remotely approaching what could be considered "fun"), console I/O quickly becomes awkward, clumsy, and difficult.

Consider the classic homework problem where you have to print a triangle like this:

   *
  ***
 *****
*******

This question is posted on the forums all the time by beginners. And for good reason. It's hard to do for something that seems really small and simple. It's much easier to just use a graphic lib to draw a freaking triangle. It often can be done with 1 line of code.

[3hM2Nwbp]

It all depends on the library being used. Some parts of virtually any graphics library can be pretty intimidating to use. The example below is posted just to play the devil's advocate. It's very easy to get pulled off of tutorial-land and into confusing concepts (at least it was for me). 2D is alright for a while until you get bored with it. 3D is a new kind of monster in itself.

Ogre::InstancedGeometry::OptimisedSubMeshGeometry::OptimisedSubMeshGeometry 	( 	 )

Stick with the tutorials and use care when venturing off the beaten path and you should be fine.

* Conclusion stands: I don't think that one should just say "graphics is easy"...because there's just so much more to the concept of computer graphics than just drawing images :-\

*Edit - I'd also like to point out there's a difference between making a GUI and making a GUI that doesn't look like a cow flop. I fall into the first category ;D

[Alex cpp]

...while you guys are kinda arguing I've read a 50 page guide and i made a space-ship game. :)