Help coding C++ Game?

Snoa-Tycho

Hello Peeps. First off, please excuse me if this is the wrong forum (As I believe it is, as I could of sworn I saw an Indie Games forum somewhere, but lost it), as you can see, this is my first post and I haven't gotten to know the forums just yet.

Anyways, I was wondering what are some good guides for coding games in C++, my friend is an artist, and I was thinking we could make a game together. It's based off of a book I wrote (Yes, I'm aware book-based games are terrible, but trust me. It'll work out), and it is just going to be a common shooter with lots of weapons, customization, and mostly story-based. I have looked around, but most guides I find are either not for C++, not specifically for coding games, or way to complicated for me to comprehend. I am not all that proficient in C++, so if C++ is the wrong language to program games, just say so and I could happily switch to a different language.

I thank you for your help, and please bear with me, for I am pretty dense and stupid

blakfeld

Well, ARe you sure you want to do C++? Also, 3D? 2D? Third Person? FPS? Sidescroller?

There are many different options, for example, given that you don't have a coding background, I'd look into XNA by Microsoft, or maybe even doing a mod of the Source Engine, everyone has Half Life 2 these days right?

Snoa-Tycho

Well, 2-D. And not side-scrolling. Sort of like that thing where you are viewing your character from up above. Like the Flash Game called Black. And Source Engine is out of the question. I am using a crap laptop right now, as my crap computer 'sploded on me. Computer parts for an awesome gaming rig will be coming on who knows when, and my friend is coming back on June 11th. So I have a bit of time to sort all of this out.

admanb

If you're not trying to do anything fancier than a Flash game, using C++ would be like bringing a holster of grenades to a knife fight. Even Flash would be better (Flash on the web is Satan's offspring, but for learnin' and tryin' it's good).

L Ron Howard

If you really want to learn C++ and how to program games, you'll be better off buying a book. There are thousands of books on how to program games in C/C++/C#.
If you just want to make a game, you can check out Flash or Microsoft's XNA - both of which have obviously been mentioned.
There are also tons of pre-made game engines where you need to supply a tiny bit of programming and some graphics, like the RPG Kit (the exact name I've just forgotten).
As yet another alternative, there's PyGame, where you can do it in Python. Lots of people like Python because it's fairly easy to learn and even easier to read, and there are millions of tutorials and support for that - just the same as anything, really.

JNighthawk

http://en.wikipedia.org/wiki/Game_Maker

It has support for a ton of different types of games (including first-person games).

The Anonymous

Let's be realistic here. You don't have much experience in programming, you aren't familiar with the language you want to use, and you don't have a detailed plan of any kind. Without these, you aren't going to be making anything, anytime soon.

That's why we're here to help.

First of all, before anything else, you need to ask yourself, "do I really want to make a game?" The process of actually creating a video game isn't a magical spell of some kind. It takes a lot of hard work and dedication to make a game, and not everyone can put in that kind of effort, at least not at first. And if you aren't doing it because you actually want to, but rather because you want to be famous or whatever, then forget it; you won't succeed if you think like that. So if you can honestly say "yes" to that one question, congratulations, because you're already a third of the way towards achieving your goal.

So now that you know what you want to do, you have to figure out how you're going to get there. After all, no one would've ever reached the South Pole if they didn't know where to go. If you don't know the basics of programming, then there's your first step: learning the ropes. You don't have to do it in C/C++. In fact, it's often said that ~95% of the differences between many languages are within their syntax - the "rules" of a language, so to speak. You can apply what you've learned to any language, not just the one you start out in. So pick a language, get a few "beginner" books for it, and start coding. Along the way, try giving yourself a few "exercises" to do; give yourself a "problem" that tests your current skills, spend time planning the solution, then develop it into a working program. If it doesn't work, look at why it failed, and go back to the drawing board if necessary, and keep trying until you succeed. This way you'll reinforce what you already know, perhaps even learn new things, and keep it all from getting boring. Keep at it all until you feel you're ready to take the next step.

Now it's time to actually make something for real. Pick a simple concept and explain it in detail, like so:

"Foobar" is a two-dimensional computer game in which the player, using the keyboard, controls a moderately-sized rectangular "bar" at the bottom of the screen; the bar is able to move left and right. The objective is to earn a high score; to do this, the player must use the bar to catch small square-shaped objects called "foos", which constantly fall from the top of the screen. Catching a foo is done by positioning the bar so that the foo lands on top of it. For every foo captured, one point is added to the player's score, and the speed at which foos travel is slightly increased. If the player fails to catch a foo i.e. it falls past the bar to the bottom of the screen, the player loses a life, of which there are three initially. When all lives are lost, the game is over and the player may record their name and score in a text file, after which the player may play again. The game itself may be paused at any time; doing so displays a simple "Paused" message on the screen, and the game may be unpaused afterwards.

This defines the game, its objectives, its functionality, and any other features it may have. As long as you stick to this, you'll know exactly what is needed. The next step then is to design the game graphically; open up GIMP (or your preferred image editor, but I prefer GIMP) and draw up some mock-up game screens; be sure to label the different parts of each mock-up, so you know what is what. Next comes designing the game flow i.e. what happens throughout the entire program and when. Only when you've done all this planning should you start any programming. Just like with the exercises, don't expect to get everything right as soon as you code it. There will be mistakes, bugs, features that may have to be cut. But as long as you did all the design beforehand and don't deviate from it until the end, you'll eventually end up with a working game. A simple game, but a game nonetheless. All that's left is to test it (read: try to break it in as many ways as possible, as painfully as possible, and then fix it up whenever you do), drink one last coffee, and be proud of yourself - you've made your first game!

You're probably wondering why this post is so Goddamn long. There are a lot of reasons for it, but one big one is that too many times I've seen someone decide they wanted to make a game, try to jump straight in and find themselves way out of their depth. Heck, even I've been there before. That's why it's so important to learn how to do it properly; if you don't know what you're doing, you won't end up where you want to go.

Good luck with learning to make a video game, and have fun!

Zombiemambo

I'm sure everything that needs to be said has been, but generally game programming is the next step from knowing how to write proficiently in a language. You should start with basic coding and then move on if you plan to use C++ or any other language.

mspencer

My general advice for learning to code:

1) Understand that there are many things you have to learn, and they fall into three main categories:

1a) You have to learn whatever language or languages you're going to be working with. A language comes with certain concepts that describe how it wants you to think about programming. It also has a grammar, a way it wants you to communicate those concepts. Some languages let you directly manipulate memory addresses. Some languages never let you touch memory addresses but give you references. That kind of thing.

1b) You have to learn the function of the machine you're working with, and the operating system it uses. Most beginning programming textbooks teach you about keyboard, screen, files, maybe even network sockets, because those are universal. If you're writing a game how do you interact with the graphics device, or the sound device? What kind of shader programs can your graphics card support?

1c) You have to learn some "computer science" -- a bunch of concepts and recipes and already-solved problems for how to make a machine manipulate information. A great man once said calling what we do "computer science" is like calling what a surgeon does "knife science." It's not about the computer, it's about solving problems.

2) You have to NEVER fear failure. It's just like playing a game, in that a good game is an environment that's structured to provide rapid low-cost failure for the player. Whoops that didn't work, try again. That failed but in a different way, try again. There, you got it, on to the next challenge! Problem is, when you play "learning to program" it's not a particularly well-designed game. You have to WANT to win. You have to be prepared for an environment that doesn't always show you why something didn't work; an environment that would love to chew up your resolve and spit you out as a discouraged quitter. Don't let it. Go the extra mile and learn to debug, learn to use watch points, learn to structure your code so it makes it known where things are failing. Realize that any code you write can cause you problems at any time, and be prepared for weird shit.

3) Don't be afraid to buy books, lots and lots of books. Buy redundant books. If you need to learn XNA 3.1, go buy three or four introductory books on XNA 3.1, and consume them all. You will find a lot of material covered redundantly, but it will be covered from different viewpoints and different perspectives. Things will make better sense. Don't look at it as "only the best book author deserves my money" -- look at it as "sure it sucks spending $200 instead of $50 to learn this one subject, but my time is worth more than that. It'll be worth it to learn faster and learn well." Don't obsess over finding the perfect book, because then you never buy any of them.

4) Making games is hard. Making a fun game is nearly impossible. It's really easy to get discouraged and quit. Avoid some common pitfalls by starting with a small project. Make Tetris. Or make a game with zombies in it. (!!1!1) When you're done, be proud that you made something that's roughly game-like and includes all the required features that a game must have. It may not be fun to play, but don't feel bad. Fun is difficult to create, hard to pin down, and requires a ton of iterative design, throwing away and redoing and retesting.

5) Even if you don't see yourself as a "game designer" someday -- even if all you want to do is join the industry and be a programmer -- learn about game design. Read books that talk about fun and learning and feedback. Any employee will tend to do a better job at work if they understand what their boss needs. It's OK to study game design as an amateur, just to gain that understanding. That doesn't mean you're a game designer wannabe, that just means you're curious about how to create fun.

CelestialBadger

Writing a game of any size is roughly as hard as renovating a broken down old house. It's certainly possible, but requires you to learn a whole new load of hard skills, and might fall down around your ears if you don't do it right. It also takes a very long time.

Best to start with a little game like Space Invaders or Breakout, which is roughly as hard as re-tiling the bathroom, and thus much more likely to get finished in your lifetime, as well as give you the skills you need for future, harder projects.

LoneIgadzra

Just some perspective: the first language I ever learned was C++, and as soon as I had maybe 50% of the syntax down and some basic knowledge of OpenGL, I downloaded SDL and set out to make a game. Two months later, I had a thing where you were a triangle and could shoot a square.

Now I could do that in an hour, but there are so many hard problems involved in writing that first game that you simply have no perspective on how to solve yet that you can't just jump right in and make a shooter.

Also, C++ is a hard language. I'm an experienced programmer with a computer science degree, and doing anything significant in C++ is a major challenge for me, due to all the type safety, reference and pointer semantics, operator overloading, initialization lists, templates, etc. I'd recommend heading for XNA instead, or maybe pygame. Using C++ as a beginner isn't really impossible (hey, I did it), but there's just so much extra stuff in it that will confuse you and delay reaching a true understanding of object-oriented programming.

Azegoroth

First of all, like many others have said, making a game is not easy.
There are some good books on game design out there, I'd suggest reading up on the process on creating a game, then you can start worrying about the programming part once you have a solid idea, concept, etc.

Do you have any previous experience with programming?
If you're gonna make a shooter, It is significantly easier to mod a pre-existing game engine with the content you want to make, especially if you're not an experienced programmer.

If you are dead set on using c++ though. I recommend OGRE, It's a graphic engine based on c++ code, and it is free. It has a wiki to help beginners, but you should probably get a c++ book to help you get started.