Game Programming Concepts
In the first chapters we explored the low-level libraries used to create multimedia and interact with hardware.
In the following chapters we are going to explore higher-level concepts of game programming. These will be patterns and solutions applied to common problems found in games.
Most of the ideas we will explore are common in game programming and you can find more about them in standard literature. The solutions, however, will sometimes be different. Also, some situations will be very specific to functional languages and to Haskell, and we will visit additional constrations due to purity and how to circumvent them.
Most games need to address many of the following concerns:
- Asset management (locating assets, loading them, using them, freeing them, recovering from errors loading assets, showing info about loading progress).
- Physics and collisions (simulating a realistic world)
- Error handling (reporting useful information while keeping the game running).
- Cameras (projections, interaction).
- Asynchronicity (communciation of different threads running different subcomponents).
- Audio (background music, sound effects, audio synchronisation).
- Menus (configuring preferences, jumping to specific parts of the game, resuming the game).
- Preferences.
- Animations.
- Backgrounds and scrolling effects.
- Z-axis (in 2.5, parallax or 3D).
- Reconfigurable input devices.
- Saving or interrupting the game.
- Time transformations and alterations: pausing
- Testing.
- On-screen HUDS.
- Network communication.
- AI.
During gameplay, your game transitions over several states. At the beginning, it should load all assets, possibly showing a loading splash screen to let users know there should be a delay. Then, it should probably show a menu and let users select and configure input devices, audio and video quality, possibly save or load a game, see the records, and select a level, adjust other game settings (difficulty, appearance, characters, enemies, etc.) and start playing.
During gameplay, your game can be loading a level, playing, paused, showing won/game over screens, or depending on the kind of game, waiting for you, or other players, to make a move.
It is easy to see then that your game is, at some level, a state machine. Simple state machines can be described by a diagram of states with directed links between them, indicating which states can be reached from others.
States are often labeled with inputs, or some information about the events that would make the machine transition from one state to the next. The initial state can be marked with an arrow
