About Game Programming in C/C++

So, currently me and my 4 friends are all sophomores in Computer Science and we are all working the same job during the summer at a help-desk so moral of the story is we will all be able to program for hours a day every day. So we want to make a game, we are wondering what language would be best, We know Java extensively but we have already decided that we probably wont be able to work with that. We also know C but we don't know anything about library's or graphics. So if you guys had to recommend something would you recommend sticking with C and figuring out the graphics or would you recommend learning c++ (we hear it is pretty similar) and learn the graphics and stuff for that? Our game is going to be 3d, 3rd person if that helps. Thanks for any info you guys can give us, it will be much appreciated.}

**Edit** oh and i forgot to mention, would it be smart to use an engine and try and learn all of that? or just do it hon solo all from scratch?

C has no builtin graphics, you need a third-party library. Try using the X Window library, and/or ncurses, and/or gtk. If you want 3D, you might want to look at an engine such as OpenGL.

Information about all of these can be found very easily on Google ^^.

So if i chose the route of openGL because we wish for 3d, does anyone have a current good book we could buy? thanks for any info!

I love that "ncurses" was mentioned in a thread talking about a 3D games. ^_^

Anyway, asking this means you are probably shooting too high.

I'm not trying to discourage you, but newbies to game design and implementation always do better when they take on smaller games first.

Also, there is no real reason to learn C or C++ at all if you don't think you'll be using those languages long term. You can use OpenGL (ES) from Java. Trying to tackle a new language, a new type of program, a new library, a lot of new concepts, and a bit of mathematics besides is begging for difficulty.

Soma

If you want 3D, you might want to look at an engine such as OpenGL.

OpenGL is not an engine. OpenGL is a low level graphics API that engines can be built around. Most engines support a generic interface and therefore can use Direct3D or OpenGL while others choose one or the other.

If you do not know C++ and you want to make a game in it the first thing you will need is to learn it. I will not recommend a simpler route b/c I think eventually all routes start at understanding your language of choice be it C++, C#, Java, or whatever else is out there. Learn the language a bit and then begin to code. You do not have to know every facet of the language. You can start doing some game design now by drawing out the pieces of the game and how they are going to fit together, communicate, manage resources, etc. From there you should be able to get a rough idea of the class structure you will need.
Once you get all of that then you can begin implementing which is where you will put your newly found C++, C#, or Java knowledge to use.

Design is 80% of the task and 20% is implementation.

Originally Posted by phantomotap

Also, there is no real reason to learn C or C++ at all if you don't think you'll be using those languages long term. You can use OpenGL (ES) from Java.

To clear this up I just thought i would say that we know C, we just are unsure of the differences between C and C++ and if there was any real advantage to learning, We also don't want to go the way of java due to what we plan on having in the game due and the speed of java.

Originally Posted by VirtualAce

OpenGL is not an engine. OpenGL is a low level graphics API that engines can be built around.

Yea I figured that about 3 seconds after he posted it, and to that end you say that it is used to have engines be built around. I guess it makes sense to make an engine, but is it essential? Can one just make a game using the code or is it pretty much mandatory to create a engine of sorts first and then create the content?

Originally Posted by VirtualAce

If you do not know C++ and you want to make a game in it the first thing you will need is to learn it. I will not recommend a simpler route b/c I think eventually all routes start at understanding your language of choice be it C++, C#, Java, or whatever else is out there. Learn the language a bit and then begin to code. You do not have to know every facet of the language. You can start doing some game design now by drawing out the pieces of the game and how they are going to fit together, communicate, manage resources, etc. From there you should be able to get a rough idea of the class structure you will need.
Once you get all of that then you can begin implementing which is where you will put your newly found C++, C#, or Java knowledge to use.

Design is 80% of the task and 20% is implementation.

I noticed you didn't mention C as a language, you did however mention c++ being essential, whereas phantomotap said C or C++ (just trying to figure out if we can do it in C or if we should figure out c++)

Thanks for all the info guys

We also don't want to go the way of java due to what we plan on having in the game due and the speed of java.

My point was that you should try and bring as much as you can to the table. Crossing off "Learn a new language." will lesson the burden. You are still likely to fail, but not having to deal with learning a new language will help you focus on the "Let's make a game!" bits of making a game.

I guess it makes sense to make an engine, but is it essential?

The only real difference between "game engine" and "some game code" is how it is perceived and architectured. The code for a game may not be modular or useful outside of that specific game while "game engine" implies a modular, generally useful architecture.

If you have any skill for this at all you'll wind up separating some components from others and building clear, high level facilities based around those lesser primitives.

You will not make a great engine your first time out. (You probably will not your tenth time.) It isn't a big deal. Virtually everyone fails to make an awesome game engine.

For your first time out, focus on content. In other words, focus on getting a game made. Great design and squeezing every last it of performance out of your code is something that will come with experience. You can't really get a feel for what a great "game engine" might look like without making a lot of games so don't even bother. Just try to get your game made.

you did however mention c++ being essential

No he didn't. He didn't say anything of the sort.

He is basically saying the same thing I said in post four by lending his own voice and experience to it.

Here is what he actually said: If you want to program a game in language "X", learn language "X" before you start making a game.

Trying to learn so much new stuff while trying to get anything done represents a lot of hurdles you can't manage. Again, I'm not trying to be discouraging. None of us could manage learning so much new stuff while getting anything done. And isn't just your own problems you'll have to deal with if you are approaching this game with a group. You have to deal with their problems as well.

Let's say you pick C++. If you try to learn the way C++ "OOP" facilities work while making a game you will, unfortunately, find cases where C++ is broken beyond belief. (It would be the something in any other language.) You'll spend time trying to figure C++ out instead of making a game. Someone else may have problems wrapping their head around the "backwards" coordinate system of "OpenGL" (or "Direct3D").

To look further at this problem: I hesitate to recommend using anything but "OpenGL" because so many systems have support for "OpenGL", but you know, some people just don't get how "OpenGL" work. So, maybe, instead of saying "Let's build a game using "OpenGL" over "SGML" with C++." (or whatever) you should take a more reasonable approach and look at your options to find what your team finds familiar and understandable.

Look, even if you never believe anything else I say, trust my experience in this. The stronger the foundation you can start from, personally and as a team, the better off the game project will be. If you all know C and you all feel comfortable using C, I strongly suggest you start with C. You can always learn C++ later if a task calls for it.

Soma

Originally Posted by phantomotap

Look, even if you never believe anything else I say, trust my experience in this. The stronger the foundation you can start from, personally and as a team, the better off the game project will be. If you all know C and you all feel comfortable using C, I strongly suggest you start with C. You can always learn C++ later if a task calls for it.
Soma

Thanks for all the info, we are trying to figure out as much as we can before we jump in and actually write any code, currently reading a rather lengthy book on openGL and game development (about 200 pages in since I opened this thread) and im learning a ton of stuff I didn't even know needed to be done. We also decided to do what you recommended and try doing it in C and if we need to figure out c++ later on we can. thanks for all the info

P.S (when you mentioned openGl having a backwards coordinate system, so far only thing I have found is that most things are aimed down the negative zed axis, is there more i can expect to see in terms of un-natural coordinate systems?)

when you mentioned openGl having a backwards coordinate system, so far only thing I have found is that most things are aimed down the negative zed axis, is there more i can expect to see in terms of un-natural coordinate systems?

I think maybe you missed my point a little. Or my joking made it awkward.

It isn't backwards. It is just a notation. Some people just see it as being backwards and have trouble working at that facility level.

In practice, you'll have see four variations in the lowest level primitives. (I don't recall ever seeing a fifth one at the low level.) You have positive versus negative "Z" axis and column versus row major matrices. You can transform these simple values easily from what your group wants to what the library uses.

That said, you can use those lowest level facilities to build a lot of different higher level systems. I actually find a kind of polar coordinates (length:roll:yawitch) to be very natural. I have no idea why. Everyone else hates it seeing it as being completely "backwards" for one reason or the other.

The point is, you'll need to figure out what makes sense to your group if everyone is going to be coding.

[Edit]
Let me tell you, tracing down weird bugs introduced because of misunderstood coordinates or matrix layout is not a good use of your time when it can be avoided.
[/Edit]

Soma

Originally Posted by Zocheyado

Thanks for all the info, we are trying to figure out as much as we can before we jump in and actually write any code, currently reading a rather lengthy book on openGL and game development (about 200 pages in since I opened this thread) and im learning a ton of stuff I didn't even know needed to be done. We also decided to do what you recommended and try doing it in C and if we need to figure out c++ later on we can. thanks for all the info

P.S (when you mentioned openGl having a backwards coordinate system, so far only thing I have found is that most things are aimed down the negative zed axis, is there more i can expect to see in terms of un-natural coordinate systems?)

You are putting the horse before the cart reading an OpenGL book right now. Thats somewhat akin to reading a book about calculus before you have learned numbers. You need to start at the beginning; you can't skip the learning curve. I would recommend reading this guide , even though it's not completely complimentary to C++. Frankly, coordinate systems are a very remote concern at the moment.


For the record, Z-in coordinate systems are more intuitive to me, then z-up.

I hardly see how learning open gl at this point is putting the horse before the cart, you can use open gl in C which we know, i guess i just dont know what we should be learning as a pre requisite for learning open Gl, out of the 200 pages i have read so far nothing has been above me.

i guess i just dont know what we should be learning as a pre requisite for learning open Gl, out of the 200 pages i have read so far nothing has been above me.

You should be learning about the language you are going to use to implement the game. You should be figuring out your game design and everything it needs to do or more importantly does not need to do. You should not be focusing on how to do X in Y graphics API if you do not know the language you are going to use, if you have not designed the game, and if you do not understand a little about game programming in general. Games are all about resources and data. If you cannot manage all of that you will not be able to create the game. To manage your resources you will need to make use of various constructs in the language of your choice and if you do not know that language then you cannot manage said resources.

I say it again. Learn the language now and learn the API later.

Ty for all the help guys!

Originally Posted by Zocheyado

I guess it makes sense to make an engine, but is it essential?

Only if the current offering out there does not provide what you need. There are quite a few graphics engines out there. Ogre3D and Irrlight off the top of my head. Do a google for graphics engines and take a look at what is out there and what has been built with them. Any in-game videos that may shed light on their capabilities and performance should be viewed.

On the light of C vs C++...
If you are tasked of creating a program in assembly or C, which language would you choose? Why?
If you are tasked of creating a program in C or Java, which language would you choose? Why?
Finally, if you are tasked of creating a program in C or C++, which language would you choose? Why?

Note: when it comes to pure speed, your two languages suited for the task is C and C++, but let's forget that for a moment. I am also assuming that you would be equally skilled in all of these mentioned languages when you choose to answer these questions. Finally, consider that C++ is a high level language while C is mostly a low level language (that is, no higher level constructs such as classes; mostly only very close to the hardware).

This is by no means a complete list of what you should think about, but I just want to make a point here.
(Read: don't take this as a guide to what language you absolutely must use. You need to consider other factors such as how difficult it is to learn it, etc.)