Recent Resources
-
GLSL 4.0: Discarding Fragments to Create a Perf...
-
GLSL 4.0: Using Subroutines to Select Shader Fu...
-
Building a Complete Board-based Puzzle Game wit...
-
JIRA: Programming Workflows
-
.NET Generics 4.0: Container Patterns and Best...
-
Raw Meat: Game Design Tips from Team Meat's...
-
Sedge: An Automated Error Reporting Tool
Controller
By Zachary Booth Simpson | Published Jun 19 2001 10:18 PM in General Programming
© 2000 - Zachary Booth Simpson. Copied with permission from http://www.mine-control.com/zack. If you find any of this work useful, please sign Zack's guest book: http://www.mine-cont...i/gbook-zbs.cgi.
Intent
Problem
Solution
Structure
Issues and Risks
Related Patterns
Intent
Update a Model's state based on circumstance.
Problem
Controllers implement the rules of a game. They determine how objects behave given a circumstance, and isolate these rules from the objects themselves. This makes both the controllers and models more reusable and maintainable.
Solution
Controllers relate to Models and Views as follows:Controllers are often associated with only one model instance. For example: animation, AI, pathfinding. In these cases the controller instance is usually created and destroyed synchronously with the associated model.
- Models are read-writeable by Controllers.
- Controllers are created and destroyed by Models, but are otherwise invisible.
- Views are invisible to Controllers and vice-versa.
Some Controllers inherently have more than one associated Model. For example: multi-body physics, target tracking (heat seeking missiles, etc). These controllers often maintain Model references which must be notified / garbage collected when the referenced object dies. This is called the "model death problem". The creation and deletion of these multi-owner controllers is usually done by some primary owner.
Controllers are often implemented as "processes" in a mini cooperative multi-tasking kernel. (See Mini-kernel) but may also be implemented as "hard wired updates" in the main loop, especially for large multi-model controllers like physics.
Some simple Controllers are stateless. For example, a homing missile controller may just compute the direction to the target and apply force as necessary. Most controllers, however, are state-aware. For example, an animation tracks progress through the animation and changes states accordingly; e.g. if (frame > 10) state = STOP_WALKING.
State-aware controllers often become significantly complicated with large switch statements. (See State Machine Controller.)
Structure
Not available at this time.
Issues and Risks
None at this time.
Related Patterns
Mini-kernels aggregate Controllers, giving each controller some time to work. Controllers modify Model's states.
Views may translate Model state with an Appearance Map.
Complicated state-aware controllers may use a Controller State Machine.


















