Game Structure

Hi,

I'd like to know how you actually build a game structure,
I know c++,win32,opengl and all, and if made a opengl game
but i keep running into the unsatisfactory of unorginized code.

I'd like to know how you seperate the game in classes, for
example should i make a class named render, that holds the
functions that render everything to the screen or should i
make indivudual classes that are called for example cube1 wich
holds all it's ascociated fuctions (render,rotate,scale etc.).
And what if you have a huge amount of objects, you're going to
have to make a class for all of them? how do you manage
something like that?

As you might have guessed i'd like to know how to orginize my
code the best way, at the moment i just have them in a pile of
functions all scattered through the program, wich is in my eye's
just a disaster.

Any help would be appriciated.

I separate it as DATA Classes and FUNCTION Classes.

Anything that is a physically represented object is gonna hold DATA Members like....

Code:

class ENTITY {

public:
  float x,y,z; //3D vector points
  float az;  //for azimuth
  int state; //state of the entity, helps with Frame animation reference
  int AIState; //state of the entity ai frame, what's it's current thought process.
  bool AIisON;  //Whether we've turned on the AI or not
  bool isAlive;  //Is this bot alive

...........
};

NOW FUNCTION CLASS that manipulates the ENTITY DATA members

class FXN_ENTITY{
public:
  bool checkAlive(ENTITY ent); //Check whether an Entity is alive
  ........
  };

For instance, you know that A RENDER applies to many or even all of your objects why rewrite the code umpteen times or worry about whether you have duplicated a function for similar objects.

I would create a RENDER FUNCTION CLASS that holds nothing but functions to draw objects. In that RENDER class I would have several different functions according to the object I want drawn. Certain objects require a set number of DATA points so I would create a SQUARE DATA CLASS with just data members in it and then I would create a function within the RENDER to accept my SQUARE DATA POINTS (OBJ) and draw it accordingly.

EDIT: For simple shapes that are supported by DirectX or OpenGL like the Square, triangle, etc. I wouldn't create a CLASS for them but rather a TOKEN or FLAG that I can pass to a generic Render function that would draw them.

classes have data and methods that act on the data.

I separate it as DATA Classes and FUNCTION Classes.

Usually this makes for confusing code. If you do this
you can make the function classes methods static.
But anyways you can write the same code less confusing like this

Code:

class ENTITY {
    float x,y,z; //3D vector points
    float az;  //for azimuth
    int state; //state of the entity, helps with Frame animation reference
    int AIState; //state of the entity ai frame, what's it's current thought process.
    bool AIisON;  //Whether we've turned on the AI or not
    bool isAlive;  //Is this bot alive
public:
    bool checkAlive() const { return isAlive; }
    virtual void draw() = 0;
};

Oke,reading your post's decided to do it this way,
i have certain classes that hold information about them, for
example class field (tictactoe) wich holds then functions to draw
it, to refresh position of them etc. , but i've seen alot of programs
wich have for evry object a class, like player and field and
vehichel and menu etc. , I once tried that i found out that i
coulnd't place my functions right, i was fighting with myself
wether to put that function in that class or that class, i think
multi file projects is a good thing but there are beraly any
tutorials to find on them, how you manage your classes and var's
or func's, Any good tutorial suggestion?

[edit]

Another reason i picked this way of programming was of the
capibility to easy rewrite a part of your program

OOP perspective on the situation:

Everything is in classes. I wouldn't recommend making "Function" classes and "Data" classes -- if the concept that you are modeling doesn't have both, then it simply shouldn't be a class -- though this doesn't ever happen with the pure OOP paradigm. All objects have a function/functions or else they would have no use in your program. The only time in Object-Oriented C++ that you really need functions that aren't a part of classes are when you overload a binary operator and you want the left hand operand to be a primitive datatype, and that's just because that's the only way you can do it in the language.

For rendering, what I recommend you do is create a bunch of classes for your primitives. In 2D those would be for still sprites, animations, etc. In 3D those would be your your triangles, triangle strips, triangle fans, etc.

Make an abstract rendering class and create a singleton for dynamic allocation of children of the abstract rendering class that can be constructed and destructed at runtime.

The rendering class should be responsible for drawing the primitives -- not the primitives themselves. The reason for this is you can easily program child renderers for different APIs such as Direct3D, OpenGL, etc. by just destructing the object created by the singleton and reconstructing with a different child renderer. That way, you don't have to change the primitives to change the way that they are rendered and you leave yourself open to create more renderers without altering any of the code for the primitives, and you can also then allow people to port your program to another API while only having to see a small portion of the code (IE load the child renderers via DLLs created by you or other programmers wishing to port).

Thank for the big and explaining reply,
But i still haven't figured out what method is best,
So are there any big multi file projects source for download?
I'm not really planning to port my program over to another API,
So what you suggest is to make a class that holds the rendering
functions?

Yeah, I still recommend making a rendering class -- might as well leave yourself open for modularity now so if you do decide to go back and change later it's not a rough trip. It's a good learning experience anyways.

The child rendering classes' constructors should be in charge of starting up and initializing anything you need in the API you're using. Destructing closes all of it back down. It's data is anything you need to interface with the API and any other data you see fit.

The renders should have overloaded virtual "Render" member functions -- one for each primitive type.

For organization, what I personally do is I make APIs for Audio, Graphics, Input, Time, Networking, Data Structures, Application Loop, and anything else you'd need. The APIs are as abstract as possible and I only keep the most basic classes as a part of them (usually no child classes). Usually, each API has 2 "levels." Each level represents a different level of complexity -- the lower level is only classes with solely inline functions (enumerations and associated functions, etc) and consists of just a header file, and the higher level is where the actual core abstract classes are.

Each API's high level has one header and one cpp for its abstract classes and any implementation.

Then, the next level is not a direct part of the API, but is made up of classes derived from and or containing classes from the high level of the API and consists of things that are much more application specific.

Most of the APIs have singletons used for construction and destruction at runtime to provide an extra layer of modularity and to allow people to dynamically destruct certain APIs when they aren't using them for memory conservation.

So heres a quick breakdown of how I personally set up the graphics of an application.

I've first got the low level of the graphics API. Here, you have classes for things such as color enumerations.

Next, I have the high level of the graphics API. Here is where you start making your primitives -- triangles, etc. as I explained previously. You also have our abstract renderer here (but no children yet).

Then, I have the personal "standard libraries" associated with the API. This is where you might put a 3D model class which uses the primitives from the high level of the graphics API.

Compile both level of the API to a static link library and do the same for any "standard libraries" you create from them.

What's good about this set up is you don't even have to include the "standard libraries" if you don't want to. It's very easy to reuse the code from the API without including game specific graphics classes that might be in your "standard libraries."

I create DLLs for the renderers -- try to keep them separate from the actual program because their implementations are usually not portable. What's great about this is, since the "standard libraries" we created are a level above the primitives and are rendered purely from primitive data, you, or someone else, can port the entire application's graphics (or other APIs) simply by creating a new DLL and they only have to see the two levels of the API and none of the libraries you created from them (IE they don't have to see any of your model classes, etc.).

It makes your program extremely modular and also makes it very well organized. It makes it almost impossible to get lost in your code.

Classes are a very good way to organize your code. In fact I've been making the GDS for my TBS game I'm making, and the past two days I've been just trying to design the class for the units and the linked lists to hold them (that's right, I'm using C++ and linked lists, so shoot me ). Usually it shouldn't take that long, but I've been trying new things, I've learned a LOT about OOP these past two days.

Make sure you plan, plan, plan, and then plan again. I've started a lot of projects, but I can't even remember the last time I finished one (or where in the world the floppy for it is ). Make a GDS, plan out your game. What type of game do you want to make? Then after you plan that plan out things like setting, main characters, etc. Then start writing out ideas of how you are going to structure your game's engine. I like to try for a data driven engine. Not just so I can use it in other games, more of I like to make an engine, then make a game, instead of making an engine and a game at the same time. Of course, you will find times where you need to add in stuff to the engine to do stuff. I usually just plan out the type of game I'm making and the UI then jump to the code structure, because I usually have the most problems with the programming.

Everybody has their own way of planning, and once you find a technique that works for you, use it. Just don't do what I used to do and say "I want to make an RPG" and go in and make a tile-engine and then realize "oh crap, I forgot to do this and this and that" and then say "okay, now I guess the only thing I can do is a complete overhaul of code. I need to just go in and delete everything and start from scratch, it'll be better next time". It may be better next time, but if you still didn't plan, you'll eventually have to overhaul the code again, more than likely.