Quote:Original post by Anonymous Poster
I think the above guy with the DLLs is pulling your leg.
Thats totally unecesarry for a simple game.

ummh, off the top of my head I'd say to look into Function Pointers. and have multiple gamemode functions that can be swapped at startup depending on what mode you choose.

im not pulling his leg, if he goes the route of function pointers the step of letting those pointers point to functions in dlls is trivial.
The class example i gave (zelcious beat me to it slightly but i hadn't read his post while i wrote mine) is pretty much the same as function pointers (except you have a single pointer to a class containing a group of methods instead).

Quote:
PROBLEM: In this new game, this cannot be made that simple because there will be more than four modes (single player classic, single player time attack, two player time attack etc. etc. etc), and each one will present a very different behaviour.

the key points here are:
* more than four modes
* very different behaviour

thus function pointers or abstract classes/inheritance is probably the best options, both of those can easily be replaced with dlls or scripts.

with function pointers you simply load the dll and let the pointers point to functions inside the dll.

the abstract class would be switched out for a loader and/or wrapper class in the case of scripts or dlls.
The wrapper/loader class would then contain function pointers that are initialized by the constructor (the constructor taking the name of the dll as an argument)

The reason for using dlls is basically just to make the game modable, its not really much extra work compared to function pointers or abstract classes. its up to the OP to decide if he wants his users to modify his game.

the main drawback would be mods containing nasty code that the OP don't want to be associated with.

In that case scripts are a better option but it requires more work and might not be worth the effort on a simple game. (only the OP knows exactly how simple his game is), scripts also has the advantage of being easy to modify at runtime, (you wouldn't even need to shutdown the game and recompile to tweek the game a bit).

Hi, guys!
The solutions using abstract classes or function pointers fall into the "State" design pattern (a better solution IMHO) category.

Quote:The State pattern is used when you want to have an enclosing class switch between a number of related contained classes, and pass method calls on to the current contained class. Design Patterns suggests that the State pattern switches between internal classes in such a way that the enclosing object appears to change its class.

More details here: Link (warning: PDF inside)
Now I'm almost certain that DLLs and scripting languages are more than what is really needed to solve my problems, and I'll stick with the "state" solution.
Thanks a lot!

PS.: Please, feel free to comment/criticize

Quote:Original post by MajinMusashi
Hi, guys!
The solutions using abstract classes or function pointers fall into the "State" design pattern (a better solution IMHO) category.

Quote:The State pattern is used when you want to have an enclosing class switch between a number of related contained classes, and pass method calls on to the current contained class. Design Patterns suggests that the State pattern switches between internal classes in such a way that the enclosing object appears to change its class.

More details here: Link (warning: PDF inside)
Now I'm almost certain that DLLs and scripting languages are more than what is really needed to solve my problems, and I'll stick with the "state" solution.
Thanks a lot!

PS.: Please, feel free to comment/criticize

i think everything suggested falls into the state design pattern, dlls and scripting languages are just an extra separation where the state code are moved away from the main executable to provide modability. (mostly useful for larger projects where compiletimes are massive or when you plan on selling the engine).
the pattern remains the same though.

a good idea is ofcourse to use methods for your state classes that are relevant to the program.
the example in the pdf lets each state handle input which may be a bad idea for a game but a decent solution for a paint program (i've used pretty much an identical solution for a java paint program except mine was modular (reflections).

a better idea for a game is to let the state handle events that are sent by the engine. (since things will happen even if the player remains idle).

thus you basically only need one method for the state (handleEvent), and possibly a pointer to the engine. (the example in the pdf uses a Mediator class instead which might be a better option)