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.
When thinking about how to create
a game’s framework from a high level, we will see that there things that have
similar features. From this we group them other, and assign them all to inherit
from 1 parent. This can be seen in many games and can be applied the simple
game of pack man as shown to the left. This way of thinking for programming is called
object centric programming, due to the fact there is a lot of polymorphism,
resulting in the huge “is a” chain.
However there are many flaws to
this way of programming, which could be devastating for large scale games. When
drawing the UML diagram, we can predict a big list to form due to the huge chain
of inheritance. From this we can predict that this method will be inefficient, whenever
we create a single object we must also create a version of the parent in the
memory. If that parent also had a parent, we would have to save some memory for that. Double Polymorphism, is another problem which can cause HUGE errors if done, one case is shown in the chart to the right. Finally if every class in the chain was modified and this resulted in errors, the question comes up, where would the source of these errors be?
