In the last chapter, we discussed the Component Object Model. Giving an entity a behavior is now as simple as just creating a new component and having that control the game object.

Whenever someone starts to make a game, they begin by writing gameplay code. That is the fun stuff. Everyone wants to see graphics and physics take effect on screen. Things such as a pause screen, options menu, or even a second level are an afterthought. The same happens for organizing the behaviors of a player. Programmers are excited to make a player jump and make a player dash, but with each new ability a player has, there are combinations that you may want to disallow. For example, the player might not be allowed to dash while jumping, or may only be able to dash every 3 seconds. The State pattern solves these problems.

By coding the Game State Manager first, the problem of switching to a menu or pausing is solved. By coding finite State Machines as a component for the game object, the problem of complex behavior or a player or enemy is solved. By adding multiple State Machines to the same game object, complex behavior can be created with very simple code, as is seen in many games, and is a widely used feature built into the Unreal Engine and given visual editors in Unity using Hutong Games LLC's popular Playmaker extension.