Good way to manage multiple game modes?

Question

/UPDATE:
I took one of the suggested solutions and tried to implement them. I implemented a BaseGameWorld class that contains the basic tetris gameplay. Every game mode extends this base class. If any of the game modes differ from that classic gameplay they will simply override any methods needed or add new ones. My GameScreen class is now structured like this:

public class GameScreen  {
    private BaseGameWorld gWorld;
    private GameRenderer gRender;

    public GameScreen (int gameMode) {
         // PuzzleGameMode extends BaseGameWorld
         gWorld = new PuzzleGameMode();
         // Constructor of GameRenderer takes a BaseGameWorld object
         gRender = new GameRenderer(gWorld);
    }

    public void render() {
         // Update Game World
         gWorld.update();
         // Draw Game World
         gRender.draw();
    } 
}

This is ofcourse not the complete code, but it should show everything important. The idea behind the GameWorld and the GameRenderer classes is to reduce any clutter in the GameScreen class and seperate the game world and the drawing of the game world in two seperate steps with the goal to improve maintainability. So far this approach works quite well.
The type gWorld get's initiated with depends on the gameMode input variable and is handled through a switch-case in the actual code. Just as an example I used the class PuzzleGameMode.

Now my problem is that any new things added in the PuzzleGameMode class can't be drawn inside the GameRenderer class, since the GameRenderer constructor takes a BaseGameWorld object. It can only draw things that are in the BaseGameWorld.

Is there a way to resolve this situation that doesn't involve making a seperate GameRenderer for every game mode? My hope was to only have different classes for each game mode but to have one universal GameRenderer class.

---

I am currently making a tetris clone to get back into game programming using libGDX. The game is currently seperated in different screens. MenuScreen (includes Options, Highscore, Credits etc.) and the GameScreen itself. The GameScreen also has one member (named GameWorld) that manages all the calculations and game states, aswell as another one (named GameRenderer) that does all the drawing.

This works fine for the moment, however I plan on adding multiple game modes. I could probably add them to the GameWorld class, but it is already very full and managing multiple game modes inside a single class would end up very confusing and not very nice to maintain later down the line.

I could make a different class for every game mode and just use one of them depending on the selected game mode. This would be a solution, however this seems like a waste since I would just copy most of the original code for some of the game modes.
Alternativly I could make a Superclass that all game modes inherit from, however I am not sure how well it would work since game modes can differ quite a bit from each other. One mode might change the fundamentals like collision or intoduce new mechanics that need to be implemented on a deeper level, while others only differ a bit from the classic tetris mode and use most of the already implemented stuff.

What would be a good way to implement different game modes?
If more information is needed or if I should specify something better, just tell me and I will add the missing information. :)

Answer 1

Take a look at GOF (Gang of four ) state machine , and Hierarchy State machines patterns state pattern State Pattern

In a Hierarchical state machines, A state can have a superstate (making itself a substate). When an event comes in, if the substate doesn’t handle it, it rolls up the chain of superstates. In other words, it works just like overriding inherited methods, So no code Duplication.

Answer 2

Consider the following UML diagram:

This is what is known as a finite state machine. In this way, an application, or game, can have several states, or behaviours. When certain conditions are met, such as a key being pressed, or a menu choice selected, a change in state is triggered, which changes how the application or game behaves.

Additionally, each state can have a set of sub-states themselves, which further granulates the behaviours.

Answer 3

I use what is essentially a simplified version of libgdx (no OpenGL, for example). It has a basic class called Screen. Of course there are other classes for saving the scores, etc., but the main classes in my game just extend this class: the opening screen, the menu screen, the setting screen, the game screen, the end of level screen, etc. Because the basic functionality I need is built into Screen -- recognising touch, drawing, updating, pausing, etc. -- it is relatively easy to build the different types of screen that I need and there is relatively little duplication of code.

In your case, I would build a basic game screen and then override the methods that need to change. I don't know libgdx well, but I would guess that you leave GameWorld alone and just focus on what you want on the screen. I could be wrong about that.