Design Patterns
Design patterns are nothing but proven solutions to commonly occurring problems in Software Engineering. I will try to briefly explain a couple of design patterns that I found to be very useful while working on my games. Be warned that design patterns are no silver bullets. Whether or not you find a design pattern to be useful, depends totally on the context in which you are trying applying them. My intention is not to explain the various possible ways in which these patterns could be applied, rather, I will try to explain how I implemented these patterns. Its up to decide how useful they would be from your context. I will try to explain two patterns namely,
i) singleton
ii) flyweight
Singleton:
This is the simpler of the two mentioned design patterns. This pattern is useful whenever you want only one object instance of a class to exist for the entire life time of your program. This could be achieved in two simple steps,
i) Make the constructor of the class to be private or protected.
ii) Create a static public member function that checks if an object of the class already exists, if so it returns the pointer to that object. If not, it creates a new object and returns it’s pointer.
The program should always make use of this static member function to gain access to an object pointer. This will ensure that only one object of this class is ever created. Heres a simple implementation of singleton design pattern.
Flyweight:
In games, most of the times the game objects carry around a lot of redundant data. This pattern aims to reduce the memory consumption by sharing only one global copy of the redundant data among all the objects of the same type. But this reduction in memory usage comes at the cost of increased coding complexity. This design pattern is really useful for games in which memory consumption is a primary concern.
Suppose at a particular instance of time in your game, you have say 500 infantries and 500 tanks. The simplest way to design the class hierarchy for this would be to design two classes namely InfantryInstance and TankInstance and have both of them inherit from a common base class, say, ArmyUnits class. This way ArmyUnits class can hold the common attributes of all the army units and InfantryInstance and TankInstance classes can derive from this common class. So you just instantiate 500 objects of InfantryInstance class and 500 objects of TankInstance class and you are done! This will work just fine…no design patterns..nothing! But, say you want more bang for your buck from your memory. Then this is where Fly weight pattern comes into the picture.
Using flyweight pattern, what you do is group the common attributes of all the InfantryInstance objects into a single class. For example, all the infantry objects might have the same speed, same texture, same type of weapon etc… we will simply group these common attributes into a new class called the Infantry class. Apply the principles of singleton to this class to ensure that only one object of this class is ever created. This is where we remove the redundant data. Similarly you can group the common properties of the TankInstance class into a Tank class. Now whenever one of the common properties (say the speed of a particular infantry unit) is referenced in the program, the InfantryInstance class must implement a technique to retrieve this value from the global singleton object of the Infantry class and return it back to the application. But this should be implemented in a way that is transparent to the program, as though the speed value is being returned from the InfantryInstance class itself. There are more than one ways of achieving this, one of the possible implementation is available in the source code given below,
© 2004-6 Celambarasan Ramasamy. All rights reserved.