Let's say I was working on a platform game. Each level has an exit. When the player reaches the exit, the game switches to the next level.

What would be the best way represent and switch to the next level?

One idea I had is to make a Level class. This class handles most of the game logic and has most of the program's code, but doesn't paint anything on the screen.

For each level, I create a class that extends (inherits) Level class. All of these classes would inherit everything from Level, but paint different things on the screen. When the player finishes a level, finishedLevel() method is activated inside class Main, and this class creates an instance of the next level.

Is this approach reasonable, or is there a better one?


2 Answers 2


Most games don't have a separate class for each level. The usual way is to store the layout of each level in a file. These map files contain the environment and the positions and properties of all objects in it.

When a level starts, the map file is loaded and a Level object is initialized with the data from that file.

When the player finishes the level, the Level object is discarded and a new one is initialized with the data from the file for the next level.

By storing the level-data in files, you are separating content from programming, which is usually a good thing from the maintainance perspective. You can use an external map editor to edit your maps (when you use a tile-based 2d engine, I can recommend Tiled as a map editor) and you can do so without having to recompile your game. This doesn't just makes it easier for yourself, it also allows you to work together with level designers who have no programming knowledge. They just need to know how to use your level editor and don't have to bother with your programming language and development tools.

  • \$\begingroup\$ Thanks. So basically, everytime a level is finished, I discard the Level object and create a new one. And to this new one, I load new data for this level from a file. Am I correct? \$\endgroup\$ Commented Jan 15, 2014 at 19:52
  • \$\begingroup\$ @user3150201 Yes, that's what I wrote. \$\endgroup\$
    – Philipp
    Commented Jan 15, 2014 at 19:55

Your approach is workable, but suffers from the problem of overusing inheritance. If all your Level classes share everything but their method that paints the actual level data on the screen, then perhaps there is a way you can have them share even that?

The solution is to store the description of what should be painted for a particular level in an external data source. Often, this is a file. The contents of this file can be as simple or as complex as you need to represent the entities in your level. For example, many games can get a way with a simple text file representing background or foreground tiles of the level with numbers or characters, such as


where spaces represent empty space, _ represents a floor, S the start position of the player, E the start position of an enemy, L a ladder and X the level exit.

This gives you enough information to load the level and understand what graphics to render where, where to place mobile game objects or collision information, and so on.

It also has the advantages of reducing the amount of code you have to maintain (now you have just a single level class) and driving your game more with data than with code (data is generally easier to change quickly and iterate upon).


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .