Alternate game modes

Game Play & Game Design
#1

Hello.

You know how most puzzle games have alternate game modes? An endless mode and a timed mode for example. I was wondering what the best way to organize my code would be so I could include an alternate game mode.

I was thinking of going with inheritence. If I don’t use inheritence there will be a fair bit of duplicate code. But the game modes will vary far too much to be in the same class. Have you had alternate games modes in your game, and did you use inheritence? If not how did you organize your code?

#2

Although its no puzzle game, I set up something similiar called WinRule for my game.

It’s an interface with different implementations, very simple.
The main method isFulfilled() is called every once a while from the game loop:

boolean isFulfilled(List actors, List players, Set winners);

There is one additional abstract class which got shared code for finding the winners, used by two rules.

Variations are so far: Infinity, Timespan, Highscore, Last-Man, Escape

#3

My advice is just hack it together and don’t worry about some super-clever code design that will achieve the result with aesthetically pleasing architecture.

Cas :slight_smile:

#4

You can separate them into different states, each states extending main game state to reduce duplicate codes.

#5

Ok, well thanks everyone. I think I will just go with inheritence then. I might actually write the new game mode from scratch and then see what is similiar and THEN write a superclass for both states.

#6

just an addition thats the strategy pattern http://en.wikipedia.org/wiki/Strategy_pattern

imho there are not much real world usecases for inheritance and the main reason to use inheritance is polymorphism . To avoid
dublicate code use composition. (http://en.wikipedia.org/wiki/Composition_over_inheritance)

But keep in mind there is no perfect code. If you can make the game you want dont worry about the “perfect” design or you will end up over-engineering the game instead of finishing it.