Programming paradigm advice

[starfruitinc]

Hello all!

I have begun a game project, and I would like a second opinion on a problem that has popped up.


The Problem:
This is my first game project as well as my first major C++ project, so if this is a horrid method of accomplishing this task, please inform me! I needed a way of organizing code for different screens in a game, so I asked a friend of mine who has had more experience in this field. This is what he tells me:

Each screen of the game (title, game, score, etc) is defined as a State. Each State should have functions:

Code: Select all

void draw(); //Draws the States visuals to the canvas
void update(logic params); //Update logic of the State
void getName(); //Get the name of the state
State(canvas); //Constructor


Have a manager (StateHandler) contain States in an array. It should have the following functions:

Code: Select all

void addState(); //Adds a state to the array
void switchState(std::string name); //Switch the active state
void drawState(); //Draw the current state
void updateState(); //Update the current state
StateHandler(input, canvas);


*input and canvas is whatever the sdk uses

Is this a good way of organizing a game? Even though he is more experienced than me in the game programming world, he codes in Java and C# not C++, so I’m not sure if his advice will apply.

Oh, one more thing that I came across, probably a silly question but:

Code: Select all

int * p1;
int & p2;


I know that the first one is a pointer, but what is the second one called? A reference? What is the difference between them? When I try looking up pointers and references it just gives me that a pointer is something that returns the value of the variable at address of p1 (in the example) and a reference is what you set p1 to (p1 = &var). I'm not sure what the difference between what they hold are.


Thank you!
SFI

[Sc4Freak]

What your friend describes is a state machine. The problem in general you're trying to solve is "game state management". And, yes, what your friend describes is a common approach to the problem.

int* is a pointer-to-int. int& is a reference-to-int. They accomplish similar goals (indirection). But the major differences are that a reference can never be reseated (you can't make a reference refer to a different object) and a reference can never be "null". References can be used in many places that pointers can, but are safer. Thus the general rule of thumb is "use a pointer only when you can't use a reference".

[Steax]

Since Sc4Freak already answered your main question; most programming practices apply to large groups of languages at a time - they're not too specific. So don't worry about misapplying patterns.

On the other hand, I really dislike the "Manager" object pattern. It's one of things from Java which I particularly hate with a passion, and just extra luggage to unnecessary structure. There is no reason for you not to simply make use of polymorphism and directly modify a single state which is your "current" state, and call its draw/update methods directly.

Some people like the extra abstraction/clean-ness from using "Managers", but I tend to prefer the practical and flexible method; just have a darn global variable store your current state, and load new states into that variable whenever you want to switch, with each state utilizing the same interface. In pseudocode:

Code: Select all

// the global
var state;

// the default
class state implements stateInterface{}
var titleScreen = new state();
state = titleScreen;

// the extending
class saveScreen extends State{}

// the new
var mainSave = new saveScreen();

// the switch
state = saveScreen

// the invoking, in your loop
state.update();
state.render();


I'm likely to get a lot of criticism for both this model, and the pseudocode language I'm using. I haven't had sleep in the last 24 hours.

[Jplus]

I'm not going to criticize poor Steax (dude, I hope you got some sleep in the meanwhile). Instead, just an addition to what he said: if you're allergic to global variables (which, in C++, wouldn't be a bad thing) then the Simpleton pattern provides a way to wrap them up in a clean way.

[TheAmazingRando]

if you're allergic to global variables (which, in C++, wouldn't be a bad thing) then the Simpleton pattern provides a way to wrap them up in a clean way.

This is what I'm calling Singletons from now on.

[Jplus]

LOL! Didn't realise my mistake.

[Steax]

I finally got myself some nourishment, yay!

But yes, if you're alergic to globals, go use a singleton. You'll hear people start to go all religious on singletons, but seriously, even the worst drawbacks of singletons have workarounds. It's a problem when suddenly everything becomes a singleton, but just write the code you have to write. It's better to write working but slightly crude code than just stare at religious wars and reading articles all day long. I eventually learned, one day, why singletons were bad out of my own code. I suggest waiting for that day rather than stalling your work.

[Ben-oni]

Did someone mention Religious Wars? Use Lambda, the Ultimate Design Pattern!</troll>