• Advertisement
Sign in to follow this  

Implementing multiple game modes

This topic is 4251 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi! CONTEXT: I'm a not so beginner, and I'm designing a new game that is slightly more sofisticated than Pong or Breakout. In a Pong-like environment, 1P or 2P game mode is a matter of setting a boolean attribute of the game (for example, "bool singlePlayer") and checking the value of this attribute in some places of the code. 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. EXAMPLE:
// Pong
void Game::onKeyPress( Key pressedKey ) {
  switch( key ) {
    case KP_8: // Keypad 8
      if ( !singlePlayer ) {
        rightPaddle.moveUp();
      }
      break;
    // ...
  }
}

// New game
void Game::onKeyPress( Key pressedKey ) {
  switch( key ) {
    case KP_8:
      switch( gameMode ) {
        case GM_SINGLEPLAYERCLASSIC:
          // action 1
          break;
        case GM_SINGLEPLAYERTIMEATTACK:
          // action 2
          break;
        case GM_TWOPLAYERCLASSIC:
          // action 3
          break;

        // ... MAINTAINANCE HELL
      }
      break;
    // ...
  }
}

QUESTION: Some options that pops in my mind are to implement the "State" design pattern (used inside a "play" game state, for example), to create a new game state for each mode, or to use of a script language. What approach do you usually follow? What is the best way? Thanks a lot!

Share this post


Link to post
Share on other sites
Advertisement
Guest Anonymous Poster
depends a bit on how complex the game is and how different the game modes are. using scripts or modules (dll/so) is great if you want a very flexible system that is easy to expand

for a simple game you can use simple states or even simple if statements like this :
if (mode == 1 || mode == 2) {
//do this
}
if (mode == 2 || mode == 3) {
//do this
}
//do this for all modes

this can get really really ugly if you got lots of modes though.

Share this post


Link to post
Share on other sites
Quote:
Original post by Anonymous Poster
depends a bit on how complex the game is and how different the game modes are. using scripts or modules (dll/so) is great if you want a very flexible system that is easy to expand

for a simple game you can use simple states or even simple if statements like this :
if (mode == 1 || mode == 2) {
//do this
}
if (mode == 2 || mode == 3) {
//do this
}
//do this for all modes

this can get really really ugly if you got lots of modes though.


Yes, this is really ugly and I want to avoid it at all costs (as I've said, there will be more than four modes). The game will not be anything near the complexity of Wacraft III or Half Life, and no "mod" support is planned.

Thanks!

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
using scripts or modules would give you some mod support but is probably the best option even if you don't intend to support mods.

the easiest way is probably to have your engine call functions from a dll or run a script whenever X happens. this is easy if the game modes are very similar (since the number of functions that needs to be in modules or scripts would be limited), if the modes are very different the module system would be more complex (and the game would become highly modable as a side effect)

Share this post


Link to post
Share on other sites
Quote:
Original post by Anonymous Poster
using scripts or modules would give you some mod support but is probably the best option even if you don't intend to support mods.

What do you mean by "modules" and "module system"? The terms are far general...

Quote:
the easiest way is probably to have your engine call functions from a dll or run a script whenever X happens. this is easy if the game modes are very similar (since the number of functions that needs to be in modules or scripts would be limited), if the modes are very different the module system would be more complex (and the game would become highly modable as a side effect)

I don't understand why I should keep game modes inside a DLL. Can you elaborate, please?

Thanks!

PS.: Do you really need to reply as an anonymous poster? [wink]

Share this post


Link to post
Share on other sites
Guest 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.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
you don't have to use dlls, you could just use normal classes.

something like this for example


class GameMode {
protected:
Engine *eHandle;

public:
virtual void setEngineHandle(Engine *eHandle) { this->eHandle = eHandle; } //give the "module" a pointer to the engine so that it can affect stuff.
virtual void startGame(); //initialize whatever
virtual void update(float dt); //update gamestate (run each frame or timestep)
virtual void handleEvent(GameEvent e); //handles game events
}

then create child classes for each gameMode, you could add more functions if you feel like its necessary.

such as

class DeathMatchMode : public GameMode {
private:
//whatever variables you need for DM
public:
void startGame() {
//init the variables etc
}

void update(float dt) {
//do whatever needs to be done here
}

void handleEvent(GameEvent e) {
if (e.getType() == e.SOME_EVENT) {
//do some stuff internally
//run eHandle->someCoolFunction
//etc
}
}
}

using scripts or dlls instead works in pretty much the same way but has the extra advantage of allowing your users to mod the game. (dlls give the modders more power but will also allow a modder to create a mod containing nasty code)

Share this post


Link to post
Share on other sites
Quote:
Original post by Zelcious
How about an abstract class GameMode and four implementations...


This works, then with an event system you can tell the engine which class to use. Simple, nothing needs to know about anything else (technically, it can but why?) and is easy to add in more modes later.

Edit: People post as AP because sometimes they're in the industry and don't want to get into arguements with others, etc.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
abstract class could work too
but for something like a gameloop logic where lots of stuff is identical across modes, i think you'd probably end up with way too much overhead

they key here is that he's got a gameloop with multiple areas that change depending on mode, and having a switch or IfThen check at each point is ugly

I think Function Pointers cover that pretty well, they'd let you reduce the switch/IfThen check to a single point at the beggining to assign the pointer values, then at each modechange section rather than do a check just use whatever got assigned...

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
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)

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
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).

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
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)

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement