A video game, like any other computer program, consists at a basic level of a finite number of "states", each of which results in a particular set of outputs. The current state changes based on user input and program instructions.
For example, our recent Pong homage had many distinct states. Most of them exist within easily identifiable categories, or phases of the game:
- splash screen
- menu
- gameplay
- win screen
Note that each of these categories theoretically contain a large number of states. The splash screen, for example, had a state for each opacity level of the logo. The menu had a state for each selection, one for each tick of the volume scale, and another for the instructions screen. The gameplay had a huge number of states, corresponding to every possible combination of ball/paddle locations, directions, and velocities.
Most states are not handled explicitly, but by restrictive parameters. Each update, the ball is moved and its location is compared to the boundaries of the board. If it has moved past a certain threshold, its direction is changed to keep it in play. However, because we are only checking restrictive parameters, we leave ourselves vulnerable to conditions that extend past our acceptable states before we are able to make a correction. In this case, as the ball increases in speed, it moves greater distances each update, eventually resulting in it extending past the boundaries of the board before its direction is corrected. This is a case of allowing the game to enter undesireable states due to incorrect boundary checking. A better solution would have been to check the boundaries prior to changing the ball's position, and factoring in any "bounce" at that time. In a more complex game, a problem like this could cause some serious bugs.
Obviously it's not feasible to write code specific to every possible state in a game. Many modern developers have learned to rely on "engines", often written by third parties, to constrain the states in which their game can exist. They frequently include things like physics rules, collision detection, rendering techniques, and so on.
That seeems like a pretty good idea for first person shooters and other games with 3D environments, but what about simpler fare, like puzzle or arcade-style games? With a much-limited number of significant states, how feasible is it to write state-based code for them?
I'm considering a code design that focuses on the current value of a single state-category variable for most of its decision making. It tells the game which screen to display, what interface elements to overlay on it, and what options are available to the user. It wouldn't have all the details, the position and movement of play elements wouldn't be included, but it might contain enough information to determine, for example, the following:
- the game is in play on level 4
- player 1 is a blue mage
- player 2 is a green warrior
- player 1 has their inventory screen open
Whether this data is contained within a single variable or an object or structure of some kind is not as important as how it is checked. In this design, the code branches out like a tree into each state layer. First it determines what screen is being displayed - in this case, it's level 4 of the game screen. Then it finds out who the active players are (and thus knows which interface elements to display for health and other information). Finally it finds any special overlays to be shown on the screen, like an inventory management or options menu.
The player input is passed directly to the portion of the code that deals with that specific game state. All input checks are made _after_ the game has decided where it is, and so it already knows what is and is not valid under those conditions. This helps avoid "spaghetti code", in which it's often hard to tell where decisions are being made.
Another thing I'd like to incorporate into this generalized design is output elements. Especially in a 2D game, a set of graphical elements associated with each state-category seems like an easy way to save work in the long run. So if you wanted to have a particular graphical or audio or force-feedback element to be produced when the game was in a particular state-category, you just add it to that category's collection of outputs.
Some basic code iterating over a collection would need to be written, and there would have to be some way of adding special instructions to each output element - what "layer" images should be drawn on, how a sound should be handled if it's already playing, and so forth. Some care also needs to be taken in selecting an appropriate storage data structure.
If such a framework could be constructed, could it streamline creation of this type of game and encourage rapid development? Maybe we can find out.
