Design patterns commonly used in game development

Using design patterns to improve the reuse of libraries is a must for large program development projects. However, in the "Gang of Four" design pattern Overview mentioned 23 standard design patterns, not only difficult to remember, and some design patterns more suitable for application development, the game Project engine design is not a lot of use value. Based on experience, after a fine selection, du Zhi is here to record some of the design patterns that they consider to be useful, so that they can be used later in their design.

One: Viewer Observer

The Observer's design intent and function is that it creates a dependency between the object and the object, and when one of the objects changes, it notifies the object that it created the relationship, enabling automated notification updates.

the applicable environment for the viewer in the game is :

The 1:ui control management class. When all of our GUI controls are using the Observer pattern, any user interface-related actions and changes will notify their associated objects-----Our UI event machine.

2: Animation manager. Most of the time when we play an animation frame, we have a lot of interest in it, when we set up a Framelister object to monitor it, it is necessary to get the events we care about.

Observer pseudo-code :

//-------------------------------------------------------------------------------------------------------

Target class of the object being observed

Class Subject

{

BIND an observer Attach (Observer) to this goal;

Unbind an observer from Deleteattach (Observer);

This goal has changed, informing all the observers, but not passing what was changed

Notity ()

{

For (... Traverse the entire observerlist ...)

{Pobserver->update ();}

}

The interface exposed to the observer allows the observer to obtain any changes in this class GetState ();

}

//-------------------------------------------------------------------------------------------------------

Observer/Listener Class

Class Observer

{

A function exposed to the object's target class, which invokes this function to notify the observer when the listener object has changed

Void Update ()

{

Psubject->getstate (); Get what happened to the listener object

Todo:disposefun (); Depending on the state, different treatments are given

}

}

//-------------------------------------------------------------------------------------------------------

non-procedural language description :

A is a good friend of B and very concerned about B's behavior. b to go out, at this time a gave B an alarm, told B said: "If you have something, immediately press this alarm to tell me." ”。 Result B in trouble outside, press the alarm (Update ()), b know a out of the problem, so the investigation of B in the end of what Trouble (GetState ()), when know B is because the person was beaten, so immediately to deal with Disposefun (), Sent a group of men to help B fight.

Of course the person who cares about a can be more than one, c,d may also be concerned about a, so a here to save a list of all those who care about it, when in trouble, take turns give everyone a notice.

Two: Single-piece mode singleton

The design intent and function of a single-piece mode is to ensure that a class has only one instance, and that only one global access point is provided that accesses it.

the game is suitable for single-piece mode :

1: All the manger. In most of the popular engine there is its shadow, such as Soundmanager, Particemanager and so on.

2: Most of the factory base classes. This is still not seen in most of the engines, and in fact our parent factory uses a unique instance, which is also very handy when we extend our subclasses.

single-piece mode pseudo-code :

//-------------------------------------------------------------------------------------------------------

Class Singleton

{

Static Mysingleton; A single-piece object, globally unique.

Static Instance () {return Mysingleton;} External Exposure interface

}

//-------------------------------------------------------------------------------------------------------

Three: Iterator iterator

The iterator design intent and purpose is to provide a way to access individual elements within a composite aggregation object without exposing the internal representation of the object class.

The game applies to the iterator pattern : Because of the popularity of the STL, this design has been widely known, we are in any form of resource management, we will inevitably aggregate it, or list, or vector, we all need a tool to access it, Iterators are undoubtedly a tool.

iterator Pseudo-code :

//-------------------------------------------------------------------------------------------------------

Iterator base class

Class Iterator

{

Virtual first ();

Virtual Next ();

Virtual End ();

Virtual CurrentItem (); Returns the current item information

}

//-------------------------------------------------------------------------------------------------------

Base class for Aggregates

Class itemaggregate

{

Virtual Createiterator (); Create an iterator that accesses itself

}

//-------------------------------------------------------------------------------------------------------

Instantiated Project Aggregates

Class Instanceitemaggregate:public Itemaggregate

{

Createiterator () {return new instanceiterator (this);}

}

//-------------------------------------------------------------------------------------------------------

Four: Visitor mode visitor:

Visitor Design Intent and function is : When we want to add a function to a struct object, we can define a new operation on its element without affecting the structure. (In fact, we just split the operation of the element into each element's own class implementation)

The game applies to the visitor pattern : Any more static complex structure class is suitable for a single visitor. Here the "more static complex structure class" means that the structure of the class elements are numerous and complex, and the corresponding operation is more, but the class is rarely changed, we can be, the structure of the elements of the operation Independent, to avoid polluting these element objects.

1: For example, the scene manager manages the scene node, is very numerous, and the kind is different, for example has the root in the ogre, the Irrchit in the camera, the light, the Mesh, the Bulletin edition, the sound all as a kind of scene node, each node type is dissimilar, although everybody has the common paint ( ), Hide () methods, but the implementation of the method is different, when we call the need for a unified interface, then we may need to need such code

Hide (Object)

{if (Object = = Mesh) Hidemesh ();  if (Object = = Light) hidelight (); ... }

At this point, if we need to add an object to a new type, we have to fix the function. And we can do this, let mesh,light they all inherit from object, they all implement a function hide (), then it becomes

Mesh::hide (Visitor) {visitor.hide (Mesh);}

Light::hide (Visitor) {visitor.hide (light);}

We only need Object.hide (Visitor) {return visitor.hide (Object) when calling;}

The Advantage of this is that we eliminate the correction of the important function, Object.hide (Visitor) {} function we can be permanent, but the disadvantage is also very obvious, because the method from the object collection structure to pull out, It means that each additional element, which must inherit from an abstract accessor class, implements all its functions, which is a lot of work.

Therefore, the visitor is only suitable for a large container to load different objects, but at the same time requires that the element node of the container should not have a large change to use. In addition, a word of nonsense, the visitor destroys Oo thought.

Visitor Pseudo-code :

//-------------------------------------------------------------------------------------------------------

//