Only learn those things you absolutely need to know.
As you need to know more stuff, learn it then, not before that.

If you don''t know ANYTHING to begin with:

Learn Linear Algebra and basic Calculus, THEN learn C/C++.

After that, its up to you what to do:

Create A Game
OR
Create something more useful

The Game Learning:

First learn how your computer looks like inside and the basic works.
Then learn how games are generally structured.
Play alot of games.
Play even more games.
While playing, fool around alittle with OpenGL.
Fool around some more with OpenGL.
Learn linked lists.
Learn binary trees.
Learn I/O (std iostream or such are easy)
Learn from all examples on NeHe''s site.
And get your questions answered in OpenGL.org forums.

Welcome to a life of gaming&coding.

Hrmm, some interesting posts here. I''ll try to give my perspective on some of the questions asked here. It''s long so beware.

I notice that a lot of people recommend specific math classes and such. These are useful classes to take in college because they will give you a heads up on how to handle some of the more complex aspects of graphics, but I think that this advice is missing a fundamental thing.

Just because you can use OpenGL or DirectX and some of your hard learned math skills to make a three dimensional ball bounce around on the screen doesn''t mean that you can design the basic infrastructure to actually make this easy to do and reproducable under the many conditions required by a game. Just knowing how to use the interfaces that a graphics API provide doesn''t mean that you will be able to use them in any way more meaningful than making a ball bounce back and forth.

Before you learn API''s and mathematics to do matrix transformations and the like you must learn how to design entire source code frameworks that operate with whatever graphics API you choose, that are independent of the mathematics you use.

The majority of ALL programming has nothing to do with which system you are programming on (there are exceptions, like operating systems programming) or which API for graphics you are using IF IF IF you design the system correctly.

The science of software design is really the ability to take a large task and break it down into small manageable pieces that have a limited reliance on other pieces yet still manage to complete their tasks. This is done through the use of generic interfaces (an interface is a collection of methods [functions] that provide a set of functionality. An interface NEVER changes in theory but can change in practice if you know what you are doing.)

In Comp Sci we call this weak coupling. In time you will learn that it is your best friend. REMEMBER THIS. To code and design a system right the first time will take MORE time in the INITIAL stages of programming but LESS time in the long run. Learn to think about system design and how to make REUSABLE design concepts. This doesn''t necessarily mean reusable in different projects as much as reusable in your current project.

So the class of study that I would recommend would be object oriented design. Many programmers will talk smack about it. I''m going to be arrogant here and say that this is because they don''t understand it. Mostly because they don''t study it. Also, realize that object oriented design has nothing to do with the language, it is all about how you construct the relationships between objects in your code. Get books on OOD. Live them, learn them, code with them and use them to help you design you own systems.

Here are some of the main portions of a game as I see them.

Graphics Rendering Engine (I use openGL but you COULD write your own, or use directX, SDL [simple direct layer])

3D graphics framework (Some API''s provide rudimentary functionality, like openGL and Direct3D)

Windowing framework (MVC [model view controller], DVA [document view architecture]. I use MVC because I think it is superior to DVA. Windows provides a DVA with MFC but most games have their own windowings system. I also use SDL to help with things like creating the main windows and such. You could also use DirectX for this. In any case I recommend insulating your design from any of these API packages so they can be easily replaced.)

Initialization/Game Loading system (I have a standard format that all of my config files follow and then I have a generic class that can read in config files of that type.)

Animation System (I load in animation set configuration files that tell me which graphics files make an animation. I also use some of the functionality of SDL for things like timers. The system that handles animation should be as separate from the Graphics API as possible.)

System Data containers and data structures. (This is usually broken down into modules internally where each module provides the mechanism to access, manipulate, and request notification of changes to its data. Remember, you should provide a central entrance point for all data modules through you main system data container. Usually this will be held in your Model [MVC] of in your document [DVA]. If you use "inline" functions for you data accessors [look this term up in your C++ book] you DONT have to worry about a performance hit for doing this.

AI systems (these should interact with the system data routines in a weakly coupled way, as in they should rely upon specific interfaces to the System Data containers but should NEVER EVER access public data in those containers.)

System Data Update routines. (These are actually a part the Data containers but they also can rely on the event manager to know when these things should take place.)

Main game flow algorithm (figures out when to call the different modules of the game. You should make this so that it can give specific time slices to certain components dynamically based on performance of the system. This may not be that large if you game architecture is highly multi-threaded.)

Networking (This is coupled to the data storage system and the event management system. These are usually operating system specific. I personally use standard UNIX style sockets. You can find out all about this kind of stuff on the net. MAKE sure that you don''t strongly bind your networking into the rest of the system. Use wrappers with inline functions if you have to.)

Event management (I use SDL which provides event functionality but this also ties in to how you handle events with you windowing system. If you are using MVC this is what the controller is for. If you are using DVA this functionality is part of the view. In any case, when certain events happen you controller is responsible for notifying the system data of the change [model or document] so that it can notify the views to update their data. This system also includes a method for allowing data storage modules to communicate with each other in a VERY de-coupled manner. I''ll tell you more about it in the future if you choose.)

Threading and Semaphores [data protection] (Yike! read up on this. This part is operating system specific usually, but if you are smart and use something like SDL, they''ll wrap the operating system specific mechanism for you so that you can use a standard interface on any OS, a-la weak coupling by using wrappers.)

Handling input data (Mouse, keyboard, joystick, etc. Make sure that you make this beautifully decoupled. I use MVC so my controller is where input data is relayed too. To decouple, at a wrapper level handle all input data as the same type, then you can attach input devices as you choose to those interfaces. This means that you''ll have a data input class that''ll handles ship movement. This class will be between the order to move the ship and the input devices to make the interpretation. In this way you could attach a keyboard, mouse or joystick to this class and they''d all use the same interface. Hence you save yourself a TON of coding by doing it right in the first place.)

GREAT methods for approaching these concepts can be found in any book on DESIGN PATTERNS. I recommend the gang of four''s books though. Ohh and one final thing. Learning to program games has NOTHING to do with playing games. Fundamentally programming games is no different than programming operatings systems is no different than programming accounting software (I know, I have done and do all three, currently being an operating system programmer.) My advice, spend less time playing games and more time learning how to program ANYTHING in general. Spend more time thinking about how you would design the SOFTWARE architecture of the game and less time playing them. Playing games is the game concept designer''s job.

Also, don''t just learn OpenGL or DirectX, learn how graphics API''s are created and how they work from a design perspective. Any good book on Graphics should teach you this. Don''t just learn link lists and binary trees. Learn about all kinds of data structures.

I also disagree with the first anon poster when he says "Only learn those things you absolutely need to know. As you need to know more stuff, learn it then, not before that." You''ll never know if you should use a certain data structure or certain graphics API if you don''t know about it before hand. If you don''t know about depth first graph traversals versus breadth first before hand you are going to waste so much time finding out that it may have been the way you should have done your traversal in the first place.

The first solution is not always the best solution. Learn as much as you can. It will help you avoid pitfalls.

savagerx, as you can see from my above rant so little of programming has to do with language or API [application programming interface] chosen. All a specific language or API will do is make your (the coder''s) job simpler in certain situations. Ex. It is easier to do proper OO implementation in C++ than in C.

Cheerz and happy coding all,

RandomTask

www.echoes.dhs.org/mp/
(The development website for my game. All content no crappy glitter.)

Randomtask: That was a long but much appreciated post. Thanks heaps. I dont really understand many of the concepts you wrote about, but at least now I know that these concepts exist, which gives me places to start. I think I have to go. I have a lot to learn.

shanemf

How can I create a topic?
Can anyone teach me?

hi,

I want to try out game programming too.

I know how to program in Delphi and Java but I am by no means an expert at either of these. Still, I understand OO because of Java.

C++ is a must for game programming, right? So what is the best book and compiler for C++ for someone at my level? Yes, I have checked the "beginners" section. What book has good step by step tutorials so that I can learn on my own?

Is C++ a big step up from the languages that I am already familiar with?

thanks

Alex