Design Patterns For Game Engine Programming.

            When looking back at my second year code, I wondered how I could improve its readability and efficiency. Then comes along this week’s lecture about design patterns to help us streamline our code, making it neater and better. My mind was blown, as these patterns could be applied to any form of software design, and maybe even more... Well let’s not go there, but wrapping my head around it (with wrappers) this was an excellent way to start our game for this year. From the lecture we learned about ways to design our code with patterns to accomplish this. 3 main design patterns stood out for me: Singleton, state, and factory, all which had a unique use.

Singleton- one class to manage

            Personally I can see this as a great way to save on memory, and organize your code a lot more! As you can guess, this design pattern involves have only a single instance of this object. This pattern is designed so that these objects will just have one memory address, and any other instance of it will just be a reference to this memory.

This pattern good for any sort of manger class, a general class which will manage a specific subsystem. Similar to managers, in real life they manage a department, and will report to any higher management. However these “departments” can also report to other “departments” and access their information if needed. A good example of a manger class would be for physics, as there should only be one class to handle all the physics within the scene. With that class, we may have an animation manager which will need some physics information for it to animate.  With this approach, subsystems communicating to each other can be streamlined, so data can flow through our game much easier.

State- a class to think

            Indirectly used in my last year game, the state pattern is versatile, and can be used as a “brain” in games. The state pattern involves having different states for an object, each giving it a different attribute. The state will only change if a certain condition (or two) is meet at a specific time. Generally a state would be represented by an enum, saved as a number variable but defined as a readable word in code.

 One great use of the state pattern is for AI, where an enemy can be set to anything from patrolling to pursing. When spawned an enemy would probably be on the patrol state, moving on a specific route until it “encounters” the player. When this happens, the enemy would change its state to purse, which would result in different behavior. This could range from a change in movement pattern (locomotion), a visual change (aesthetics or animation) or even a simple change in variables. This process will keep repeating until the enemy is dead, or the game is over.

            However the state pattern can be used for other game uses, such as is the weapon states as in doom 3. Looking at the weapon code, a weapon will have 20 possible states, ranging from holstered, reloading, to “owner died”! Each state will not just affect the weapon, but also many areas of the player. For example when the weapon is being raised, due to switching, the raising animation will affect the player’s character. Also elements of the HUD will have to be altered, due to different weapon attributes.  With the state pattern, a lot of “detail and depth” can transition from thought to the game.

Factory- a class to construct!

            If you tire of having to see different objects being made in the main code, the factory class can help you stream line. Like in any factory, it can create any thing as long as you give it the right plan and materials. In code this is basically making it inherit other class so it can make them. The point of the factory class is to allow for it to create objects of a similar type, allow for a great deal of organization.  

            One example of this last year was my enemy class, which used a similar and cruder version of this. All enemies would be created as that one initialize function, and from there they would appear in the game a wreck havoc on the player. So how would I tell the class which enemy to spawn to?  Simple give in an integer to tell which enemy for it to spawn, and all the inherited values from the other object should do the rest! This was possible since the class would inhert from my other enemy classes which I constructed earlier.

Conclusion

Designing code is a high level concept which if done right can make all the down and dirty work much easier. With these 3 software designs implemented in your game properly, you can navigate your code much easier now and hunt down those bugs easier! Don't stop with just using 3 patterns, there are dozens of them out there of solve problems which you won't have even thought of yet. In doing so, your teacher won’t have to pull a hair or two just looking at a wall of code,  and could save you a possible fail.