Design Pattern - Function Layer | 1 vote(s)
Par Emmanuel Deloget, mercredi 7 mai 2008 à 14:00 :: Architecture Orientée Objet :: permalien #131
This ticket is the first in my Design Pattern series. This series (in English, sorry for those who don't speak this language) focuses on business-oriented design patterns. The intended audience is the game development community, although I hope that others will also find some useful information. Be aware that it's a Work in Progress - some patterns may need refinement before being usable.
Function Layer
Context
A game screen is built using a large number of operations.
Problem
When building a game screen, the management of the different entities that need to be updated and/or displayed is more and more complex. Subttle bugs occur. It is difficult to maintain the correct execution of the different operations that are needed to build the game screen. You may want to change the order in which operations are executed but doing so has a large impact on the code.
Forces
- Game screens are often built from separate operations (main game representation, HUD, GUI etc).
- It is desirable to have separate code for separate operations.
- The code of a particular operation can rely on the execution of another operation.
- On the contrary, the code of a particular operation can be independent of the code for all other operations.
- If the code of these operations is not carefully designed, major maintenance problems will happen.
- Adding or removing a particular operation may have consequences on other unrelated operations.
- Modifying the state of a particular operation may have some impact on other unrelated operations.
Solution
Transform the operation into a set of function objects. Arrange these functions into an sorted list, and run through the list to create the game frame. The order in which you run through the list depends on your goal - the function update order can differ from the drawing update order.
Consequences
- You break down the game screen into smaller entities that can be easily used (force 1, 2, 5).
- The ordering of operations is easier to control (force 3)
- You allow the programmer to manage the different functions independently (force 4, 7).
- Addition and removal of operations is simple (force 6).
Structure

The calling program creates concrete layer instances and add them to the layer collection. When it calls LayerCollection::Function(), the layers are sorted following a programmer-specified order and their Layer::Function() are called in sequence.
Here is a sample LayerCollection::Function():
void LayerCollection::Function()
{
this->Sort();
for (IteratorType it = list.begin(); it != list.end(); ++it)
{
it->Function();
}
}
Known usage[1]
This pattern has its roots in the design of the XNA game components, thus every XNA game that use them also use this pattern to some extent. Additionally, games that display some kind of HUD - or any kind of graphical user interface on the top of the game screen - would benefits of the Function Layer pattern.
Taxonomy and relation to other patterns
The Function Layer is an behavioral pattern that operates on objects[2]. It uses the Strategy pattern to implement layers and the Iterator pattern[3] to iterate through the layer list.
Notes
[1] If you happen to know a game that uses this pattern, please drop a word.
[2] see Design Patterns: Abstraction and Reuse of Object Oriented Design by Gamma et al., ECOOP'93 Conference Proceedings, 1993
[3] for both pattern description, see Design Pattern: Elements of Reusable Object Oriented Software, by Gamma and al, Addison-Wesley, 1995.
Commentaires
Aucun commentaire pour le moment.
:: Fil rss des commentaires de ce billet ::
Ajouter un commentaire