07 mai 2008

Design Pattern - Function Layer

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

  1. Game screens are often built from separate operations (main game representation, HUD, GUI etc).
  2. It is desirable to have separate code for separate operations.
  3. The code of a particular operation can rely on the execution of another operation.
  4. On the contrary, the code of a particular operation can be independent of the code for all other operations.
  5. If the code of these operations is not carefully designed, major maintenance problems will happen.
  6. Adding or removing a particular operation may have consequences on other unrelated operations.
  7. 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

Structure of the Function Layer design pattern

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

1. Le dimanche, décembre 21 2008, 11:13 par cyclopio

c'est terrible ton blog, toujjours aussi interesant! :)

2. Le mercredi, octobre 28 2009, 19:36 par TheNohDirector

I think this one is more related to the composite pattern. And maybe using the full extent of the composite pattern, you can better arrange/reuse the layers/sublayers. Of course you can add other methods for the ordering or for other needed behaviour.

3. Le mercredi, novembre 18 2009, 16:58 par Emmanuel Deloget

The pattern that is explained here is a WIP ; it lacks an important part: the sorting strategy. But you're right: as for now, it's more or less a composite pattern. However, I have the feeling that it's a bit more than just that, and I plan to find out why :)

4. Le mercredi, janvier 6 2010, 22:34 par web design miami

wow ! really interesting !thx for sharing !

5. Le vendredi, janvier 8 2010, 18:26 par Emmanuel Deloget

So much enthusiasm! Thnaks for your support ;)

6. Le jeudi, juillet 1 2010, 21:52 par Ekinox

Est-ce normal qu'il manque beaucoup d'images ? Tous les diagrammes UML sont illisibles, depuis le début des archives du blog ... Serait-il possible de les récupérer ?

En tout cas, je lis avec plaisir ce blog depuis une semaine ou deux, mais les diagrammes me manquent :'( (au passage, bonne continuation :) )

Ajouter un commentaire

Les commentaires peuvent être formatés en utilisant une syntaxe wiki simplifiée.

Fil des commentaires de ce billet