The Rubygame Book Part 5
From Kibabase
| Home | Beginning | Back | Next | End |
|---|---|---|---|---|
| Back to Table of Content | Jump to Beginning | Back | Next | Jump to End(Part 7) |
Rationale:
The foundation of any game is the game loop and the management of game flow to make a game cohorent and funcitional. Without such management, all part of the games are mere isolated proccesses that doesn't do much. Without a game loop, the game would be limited to only textual, turn based games. It would also be impossible to display graphics smoothly.
It is also improtant to access how event management and game loops are used and built so that we can avoid tangling with the game logics to the point where it become unbearable to test.
The event system consists of four parts:
- The main game loop
- Modes
- Controllers
- Event
Contents |
The Main Game Loop
Just about everything will need to run in an indefinte loop of some kind. This is pretty much true for almost any games, with the possible exception of textual games. However, all rubygame graphics operation must run in a loop. In addition, a loop will contain event processing code so that we can control the flow of the games with event.
Modes
Modes are somewhat difficult to describe. They are like separate entity for different primary functions and wraps all the small functionality to do that primary functions. Examples of modes can be title screen, prefereances modes, etc.
All modes are managed by the mode manager, which manage the switching of modes and set the conditions for doing so.
There also exists minor modes, which complement modes with features that span across modes. In relation to modes, they are organized sequentically by the programmer.
Controllers
Modes are really a collection of controllers which act in concert with each other to do a major task. Contollers controls what happens and how models will acts, as well send information and intrepret information from each other. Sometime, controllers control more than one models, but often, they control only one.
In addition to managing objects and information flow, it also intreprets keyboard events.
Relation to View and Models
All controllers will control an object of the view class or the models class. Each view and models are operational on its own but does not work on its own. The controllers synchronizes what's happening in models to view.
Events
Finally, we have events. Events serves as information package as well serve as commands. This is what controllers use to deliever information and tells controllers what to do.
Conclusion
Before we can construct more of the event system for our game, we will learn unit testing in Part 6.
