INTRODUCTION _________________________________________________________________________ For my first game I am making a turn based strategy game in SDL , C++. To massivly simplify the idea, think archon (if you dont know this game a) shame on you b) then think chess) meets capture the flag. The gameboard is a 16x10 square board, each team has 10ish units, each unit occupies a square. I am at the stage in development where I can place a unit on a square, and move it to another square at the click of a mouse. Ive got the movement restricted to be confined within the square. I also have a fair amount of interface/structure coded out so I dont have to redo this as Im building the game. Ive spent 95% of the time on this part and think ive developed a fairly flexible system. PROBLEM ---------------------------------------------------------------------- Now my problem is for how to deal with global variables or "game state" variables. EG boolean to store if a unit is currently being selected or the mouse (X,Y)position after a mouse click has taken place. I have come up with two possible solutions , and both present their advantages/disadvantages. SOLUTION1 Keep global "game state"variables in the main file that contains both the event loop and the main method. PROS This is what I typically see on all the tutorials / sample coding that ive read (although their size pale in comparison to my games estimated size), it works easy enough and doesn't convulute the code. CONS since my event loop is in this file, I have a feeling its going to get quite massive in size already by the end of my game. I want to avoid code in this file as much as is reasonable. Also, if I want to call a method say from the "unit" file.. My "unit" wants access to a lot of these global states. I dont want to also store these wanted global states in the unit file because of the extra memory required. So when the game increases in size i'm going to have to keep altering the arguments for these methods in the "unit " file eg unit1->attack(int xPos,int yPos,bool hasFlag........) SOLUTION 2 This is the current solution I have implemented, Keep global "game state" variables in their own class, outside of the event loop and the main method. PROS Solves both the cons of the previous method If I want a method from the "unit" file to acess the game states, I set it up like unit1->attack(GameBoard *board) and I can then access all of the states in the game. Creates massive flexibility and barely any overhead. CONS MAKES THE CODE MASSIVLY CONVULUTED!!!! I instantiate the class like GameBoard * board = new GameBoard(.....); the effect is I have so many board->'s in my event loop its almost silly :( example of it at its worst: if ( event.type == SDL_MOUSEBUTTONDOWN && board->mouseOnBoard()) { if ((board->unitAtCurrentPos() > -1) && (board->selectedID() < 0)) board->setSelectedID(board->unitAtCurrentPos()) ; board->setOldMouseX(board->mouseX()); board->setOldMouseY(board->mouseY()); ----------------------------------------------------------------------------- Conclusion: Im kind of torn between the two, as it is right now the flexibility option number 2 provides seems hard to pass up.... Ive considered a hybrid between the two, but I feel it may confuse me in the future which variables are in the main file, and which are in the GameBoard. Any advice the gurus could offer me would be much apreciated

Quote:Original post by Auron
For some reason, having board->method(board->member...) smells a bit to me. If that method needs state information from the instance on which it is operating, it shouldn't need it as a parameter. If there's some case where it can be something else, then you might prefer to use default parameters.

That alone would make a lot of things tidier...

-Auron

basically im equating one variable in my gameboard to another.
Since I am doing this from the main method and the variables are private, I have to use mutators/accessors.

eg

board->setX(board->getSomeOtherX());

which would be defined in GameBoard as
public:
void setX(int x); //{this-x = x;}
int getSomeOtherX(); //returns someOtherX

private:
int someOtherX;
int x;

If I was using my solution 1, I would basically just be doing
x = someOtherX;...

Do you have a suggestion that would alow me not to type
board->setX(board->getSomeOtherX());??

I guess I could create a new method equateX() which provides the same
functionality as board->setX(board->getSomeOtherX())
so I would just use board->equateX();
However, wont this require lots of additonal methods since I have a fair number of variables...

Man this is the first time ive ever had to organize this much code and its quite annoying :P

I'm not sure If I understand your problem fully so this might not aply. Why not have a gamestate class that gameobjects have a pointer to. then in your game objects constructor set the pointer the the main and only instance of gamestate.

This is the kind of thing that just takes experience to learn. It's also something hard to help you with without seeing to much code. Really it comes down to this. If your using to many set/gets your not writing object oriented code to begin with. Your just making cluttered and over verbose C.

The idea you should concentrate on when creating methods is encapsulation of functionality. A class should completely abstract a single part of your design. The interface to the class should be as simple as possible. Even if this means making "alot of methods."

I'll try to give an example based on the code you posted.

// in event loopif ( event.type == SDL_MOUSEBUTTONDOWN)  board->onMouseDown();// in board.cppBoard::onMouseDown(){  if (mouseOnBoard())  {    if (getUnit(mCurrentPos) > -1 && mSelectedID < 0)      selectUnit(getUnit(mCurrentPos));      storeMousePos();  }}

Obviously this wont fit directly into your code, but thats roughly the idea. One thing you should definitely do whereever possible is use a struct for x,y position of units/mouse (like I did for my mCurrentPos), that way you only need to call one function when your passing around position info.

A general rule of thumb is to avoid global variables as much as possible.

If you have a set of related variables which are at the program scope, group them together into a Singleton or a static class.

If you have a set of related variables which aren't at program scope, i.e. map, sprite, and weapon data, group them into a class, along with their associated operations.

Also, in general the fewer 'if's and 'switch's there are governing high-level program flow, the better. Illimuni's code example shows an example of what I mean.

Illimuni put it excellently. Pay heed to his post.

BTW: if you think pointer syntax looks ugly, wait till you start writing "true" low-level code, and when you start messing with templates. You ain't seen nothin' yet. Just take a look at the standard library files.