Level Implementation

Question

I recently started to create a sidescroller game, for learning purposes. While creating several levels for it, i stumbled upon the question, how to implement these levels into my game. I made (and i think this is the common way, correct me if i am wrong, i appreciate it) a state-based game, with a menu-state, a game-state and so on. So whats the common way to implement various levels in the game-state? Should i create a new state for each level? or should the game-state be the only "playable" state, and "know" (however realized) the current level it is in? How would you realize point-counting or something like that (like a live system, or a simple beat-the-highscore point system)

Answer 1

The implementation of the concept of level varies quite a lot, but two common techniques come to mind.

Most open games, ones where levels/progress are merely an internal state of the player, the normal implementation is to have the game assets catch up with the player state (so if your level starts out "in the docks", your game starts up by putting you there, and begins loading.) The game waits until all assets have finished loading, then switches to the "loaded" state.

The other common technique is to have the level be more explicit. The level to be loaded still comes from player session information, but you load the level into the game and then place entities on their starting points. This is the norm for games that have literal levels that are arenas for play. Save games for these style games tend to only save the difference from the starting conditions of the level.

As you can see, neither of these imply that you have a gamestate per level, only that the level is either playing catchup to player session information, or the assets are explicitly loaded for the level and the player is placed inside it.

In your sidescroller, this could be taken as your session information containing the level index/ID, and then loading that level on game starr. When your level index changes, you store all info that needs to travel with you from one level to the next, then free the current level and load the new one, finally drop in your saved state.

Points or game progress are normally managed through session info, which usually includes your current lives, score, time playing, but not the intra level information (such as health level, speed, number of bullets on screen). This separation is important in games where the level is not always mapped to the location (games where you revisit locations for example), but can help simplify your thinking even in linear games.

Answer 2

Simply, the game state can carry with it an index for the current level. You'll want a trigger (a function at the very least) for when the level ends, so that you can unload the current level, update the current level index, then load the (new) current level and start playing.

You could create another state for each level, but typically it's unnecessary. The data differences between "front end" and "in game" are not the same as the differences between the levels. If you wanted state-per-level, you could have another state machine in the game state, the most rudimentary form of that is an index representing the current level. :)