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

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.

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.

Commentaires

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.

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 :)