Elysian Shadows

Thanks ahead of time to anyone who replies.

C++ is my first programming language, and I've been programming on and off for about the past year. I know some basics from online tutorials, and am finally getting a beginner's book to learn from (Sam's teach yourself c++, 7th edition). From anyone who's made a game already, will this be enough information to start game programming with? If not, please tell me what I do need to learn.

Unless you want a text-only game, you'll likely need to learn some sort of graphics library. http://lazyfoo.net/SDL_tutorials/index.php is popular. If you want network capabilities (networked multiplayer of some sort), http://beej.us/guide/bgnet/ is awesome.

Thanks for the reply. I've done a little bit with SDL already, and the Beej site looks like a good one.

I recommend SFML over SDL these days, though both are solid APIs. http://www.sfml-dev.org/tutorials/

SFML implements more than SDL and all in one library (rather than SDL, SDL_Image, SDL_ttf, etc.) It includes input, window management, audio, and networking. It also uses OpenGL by default rather than software based rendering (though both SDL and SFML allow the user to write their own OpenGL code).

I'll make sure I look into it. Also, thanks for doing such a great job on these forums. There's always someone to help and it's designed to be very user friendly.

The best way that I have found to learn is to start by modifying examples. My "Focus on SDL" book that I used way back in the day came with a companion CD as did the KallistiOS library for the Dreamcast. They had a bunch of demos on it doing things like simple rendering, movement, audio, input, etc. Without knowing a whole lot about much of anything, I was able to start modifying these. If I combined video and input, I could move a square around the screen. Then I could add the audio to the mix. Then when I wanted to do something like make the square shoot bullets, I could reference my C++ books for everything I didn't already know.

Don't make the classic mistake of placing too much emphasis on textbook learning. The human brain is optimized to learn better with emotion, and emotion is derived through experience. You have to learn through the process of creation and experimentation. You are an engineer, not a student. Don't read an entire textbook, expect to retain the knowledge, then begin coding. Code as you are learning the knowledge, and learn the knowledge as you code. Experience development, don't memorize it.

My suggestion is to always start with an idea. Get a vision in your head, no matter how big, of what you want the end product to be. Do you want it to look like Halo4? Shoot for that! Seriously, go for it.

I'll tell you this, it will be a painful experience. The KEY here is successfully identifying the PROBLEMS. There are alot of them. Successfully identifying problems will lead to to try to develop solutions. This is what you do in any type of project like this.

Find a group of talented individuals that you can launch this with. Get a game plan and go for it. I think this approach is more valuable than any other simply because it brings you closer to the reality of the problems that face competitive game developers much more quickly and in turn will make you a far more competitive and competent game developer in the long run.

Remember, "design" is different from "programming". Any monkey can "program".

qpHalcy0n wrote:Remember, "design" is different from "programming". Any monkey can "program".

It's important to realize qp is talking about project architectural design here, not game design. Any monkey can "design" a game, this doesn't bring them any closer to a game than the other monkey who is writing "programs" with no structure. Theory without practice gets nothing done, but practice without theory wastes equal time. As Falco pointed out, it is important to learn as you go, not before you've ever tried or after you've spent months failing.