3

When programming a simple game as an example. I always tend to get left with a large GameLogic class somewhere which is reponsible for gluing together all of the other portions of the software.

A Common example of the GameLogic class I talk about contains functions such as these. 

startNewGame();
showAd();
prepareLevel();
startLevel();
gameComplete();
restartLevel()
gameOver();

This class can become very large.

Is there any advice for how better to structure my future games? Should I be splitting these functions out into dedicated classes somehow as to reduce the complexity of the god class?

user1059939
  • 141
  • 4
  • possible duplicate of [Does increasing the number of classes increase code complexity?](http://programmers.stackexchange.com/questions/206610/does-increasing-the-number-of-classes-increase-code-complexity) "Cohesion and Coupling are the two relevant terms, however, there is no possible fixed answer due to their contradicting nature... As a best practice approach, I believe that the SRP is a safe bet..." – gnat Dec 08 '14 at 15:22

4 Answers4

6

Should I be splitting these functions out into dedicated classes somehow as to reduce the complexity of the god class?

Yes, that's a good idea. A good place to start might be to break up your single monolithic class into smaller classes with related functionality. Managing levels seems to be a common theme, so maybe creating a LevelManager class that contains prepareLevel(), startLevel(), and restartLevel(). Code related to ads could be moved to an AdManager class.

The exact details of how you refactor this will greatly depend on how your game is currently implemented, but I hope this gives you a good idea of how to start.

FrustratedWithFormsDesigner
  • 46,105
  • 7
  • 126
  • 176
4

When the game is simple, such a class should not be that large.

When the game progresses to large, you should split it up in the way that feels the most natural to you. I tend to end up with a simple finite state machine for the application state, then run a kernel (i.e updating prioritized tasks) in each state.

These tasks often live in a 'scene' so I can load the MainMenuScene, and then it can load LevelOne. Each scene in turn has the ability to run 'tasks'. A task is simply something that can be updated, and can send and receive messages to other tasks.

Lastly, game objects that live in the 'scene' are both a task and it follows the decorator pattern so that I can add aspects of behavior to one or many of the objects in the scene.

As an example:

FSM
   State (start)
      Task (load assets and saves)
      ...
   State (main menu)
      Task (listen for menu selection)
   State (level1)
      Task & Kernel level1 main 
         GameObject (player)
            Component (camera)
            Component (rigidbody)
            Task (physics)

Maybe this makes sense, maybe not. Tell me in a comment and I can try to make it easier to understand.

Also, this is just one way to go about it - not sure The One True Way exists.

AlexanderBrevig
  • 525
  • 2
  • 6
4

You should try drawing it out on a sheet of paper or in some kind of UML mocking program. It will take a few iterations to sort out what seems to model most accurately which roles should be assigned to which classes.

Given your example though, you have a few things that are completely unrelated in the same class:

startNewGame();
showAd();
prepareLevel();
startLevel();
gameComplete();
restartLevel()
gameOver();

Your main method should really only initialize and call start on a game object.

I think that your prepareLevel method should be in another class(the level class)

I am thinking something like:

Main
--------

public static void main (String[] args){

  new Game().start

}

Game
-------

// Should be the main driving class for menus and such, but shouldn't do any real work
// as that should be in renderers, input processors.Should do all the calls such as:
//   -- Show menu
//   -- Start()

public start(){
  Campaign c = new Campaign();
  gameCore.loadCampaign(c)
}


GameCore
---------
// Game logic not related to rendering.


loadCampaign(Campaign c){
   LevelProcessor.startCampaign(c); // -- maybe this shows your screen and such
}


Campaign
---------
// List of levels, in order


LevelProcessor
-----------

// Makes some calls to load all the assets in your level, shoves it to your game container.

Container
-----------
// Handles the calls and stuff to a renderer which draws your view, handles calls to 
// Input handlers and such.
davidahines
  • 218
  • 3
  • 10
3

Personally, I like the idea of stages, scenes and actors a lot, even for small projects. That way, you can always add new classes and just plop them in, and they act as individual objects that can be thought of as such.

By creating classes for all of your rendered items like so:

  • Stage (MainMenu)
    • Scene (MenuNavigator)
      • Actor (MenuItem)
      • Actor (MenuItem)
      • Actor (MenuItem)
      • Actor (MenuItem)
  • Stage (InGame)
    • Scene (Gameplay)
      • Actor (StarUnderlay)
      • Actor (Ship)
      • Actor (Enemy)
    • Scene (ScoreOverlay)
      • Actor (Text)
      • Actor (Text)
      • Actor (Text)
    • Scene (GameOver)
      • Actor (Text)
      • Actor (MenuItem)

You get a world of benefits.

By classing out your entities, you'll have reusability (Such as MenuItem, Text, and creating enemies that use a common class or anonymous classes). This means that you'll be rewriting less code and sharing logic across all objects.

By classing out scenes, you can also reuse this code, such as having an InGame Stage that uses a ScoreOverlay, as well as an InReplay Stage that also uses that score display, where the data is filled in by the stage.

By classing out your stages, you can put your core logic there as it is where your user is currently at in the game. A MainMenu stage can swap out for an InGame stage, and just by swapping out the object being rendered, you won't have to worry about deallocating the right objects as you'll either have garbage collection or the ability to request child objects be deallocated.

The idea is to reduce the responsibility both now and in the future of all of your classes, and thus you end up with individual units working together to produce a final product. If one thing breaks, you're more likely to know where and why, and you won't be digging through a 800 line file, but maybe a 100 line file.

When you go to pull it together, you can think of it as if you're putting on a play (hence why stages, scenes and actors are common used wordings). You need a monster to appear? Then you add a new actor to portray that monster. When that monster is no longer needed, it's pulled out of the scene.

Yes, you will likely end up with a good amount of classes, but a lot of people will argue that 100 classes is better than 1,000 lines, because again, you'll always know what's what when concepts are separated.

Thyme Cypher
  • 81
  • 4