How many of you use Design Patterns?
Currently I'm reading Head First Design Patterns, and so far I think it's great. I'm wondering how many of you use Design Patterns when creating your games, and what are the commonly used ones?
I'm using the factory pattern in my final year project for game objects or some random objects creation. It's in C++, so I can't use reflection stuff like in Java or in .NET.
In each dll, I exported a function which returns a factory interface, then the main factory can enumerate each dll and ask if it support some class or to get a list of supported classes.
I think Unreal and Half Life 2 uses it for similar things.
In each dll, I exported a function which returns a factory interface, then the main factory can enumerate each dll and ask if it support some class or to get a list of supported classes.
I think Unreal and Half Life 2 uses it for similar things.
I find myself using the following:
Abstract Factory and Factory Method for instantiating objects in a scene,
Hierarchal Visitor for things like rendering a scene, applying the results of a physics calculation to a scene, updating animations in a scene, and updating particles in a scene, and
Strategy Pattern for picking which render method should be used on a scene object, how an animation should be applied to a scene object.
Putting everything into a MVC framework has proved to be useful as well.
Abstract Factory and Factory Method for instantiating objects in a scene,
Hierarchal Visitor for things like rendering a scene, applying the results of a physics calculation to a scene, updating animations in a scene, and updating particles in a scene, and
Strategy Pattern for picking which render method should be used on a scene object, how an animation should be applied to a scene object.
Putting everything into a MVC framework has proved to be useful as well.
I'll use a lot without even thinking about them. For instance I've used things like factory, strategy, observer, (singleton??? What? Don't look at me like that!!!), and lots of others.
I don't tend to reference pattern books when coding or designing code, but I do suggest reading them (at least the group of four).
I don't tend to reference pattern books when coding or designing code, but I do suggest reading them (at least the group of four).
Absolutely, design patterns save me a LOT of time designing, especially when my code goes above 10k lines. I don't know what I'd do without UML + design patterns. Head First Design Patterns was also my first design patterns book, and it's an excellent basic coverage of the subject. :)
I use them quite extensively in a lot of places.
Patterns provide proven solutions to common problems, but they do have a downside - sometimes things can be done more elegantly in another fashion, and in some rare cases one can read from the code that at a place patterns have been used just to use patterns, not to solve a problem.
The GoF (Design Patterns - Elements of re-usable, object-oriented software; Gamma et al.) is a must-read though for aspiring developers, IMO.
Dealing with the subject not only broadens your problem-analyzing and -solution skills, but it makes you think about object oriented design and really changes the way you think about designing software.
The result is usually a much sleaker and cleaner design.
The only mistake that you shouldn't make is designing your problems around patterns - a lot of peoply do so when they get in contact with the material for the first time ;)
Patterns provide proven solutions to common problems, but they do have a downside - sometimes things can be done more elegantly in another fashion, and in some rare cases one can read from the code that at a place patterns have been used just to use patterns, not to solve a problem.
The GoF (Design Patterns - Elements of re-usable, object-oriented software; Gamma et al.) is a must-read though for aspiring developers, IMO.
Dealing with the subject not only broadens your problem-analyzing and -solution skills, but it makes you think about object oriented design and really changes the way you think about designing software.
The result is usually a much sleaker and cleaner design.
The only mistake that you shouldn't make is designing your problems around patterns - a lot of peoply do so when they get in contact with the material for the first time ;)
Anyone who has been programming for a reasonable period of time or are making programs of significant size will tend towards implementing things in a pattern because that's what works. The 'movement' has merely been recognizing them and giving them names so that programmers can more easily talk with one another at a high level.
Looking through GoF, my hobby game makes use of most all of the patterns listed except the singleton. The composite and observer patterns tend to show often for me.
Looking through GoF, my hobby game makes use of most all of the patterns listed except the singleton. The composite and observer patterns tend to show often for me.
Quote:The only mistake that you shouldn't make is designing your problems around patterns - a lot of people do so when they get in contact with the material for the first time
QFE
As you work with more, larger projects, you'll eventually start using patterns anyway. It's not a "will or won't" situation. Reading books like GoF's Design Patterns will simply open up your little world of "design tricks" to the larger expanse of knowledge on the subject. It can also give you some ideas of how to do things differently that you may already be doing yourself.
I use observers, states/strategies, pluggable factories and other factories often. I also use composition much more. I used to have an aversion to it because it means more typing, but it works better much of the time.
Object Factory, observer pattern and many others are very common. I use them in almost all the games I've created. I also use something similar to a flyweight pattern mixed with something like a Prototype pattern but not really, and a lot more complex.
Once you start designing larger projects design patterns just make sense for certain situations. I recommend learning the basic ideas and when they are applicable in programs. This will help when you are coding and run along a situation where your confused, and if you know a pattern to solve it then it makes things easier.
Just a hint, the singleton is never necessary (as is true for most patterns). It doesn't really solve problems like you might think it would. You can learn by mistake if you wish and try it. Much like communism it looks good on paper until it's implemented.
Once you start designing larger projects design patterns just make sense for certain situations. I recommend learning the basic ideas and when they are applicable in programs. This will help when you are coding and run along a situation where your confused, and if you know a pattern to solve it then it makes things easier.
Just a hint, the singleton is never necessary (as is true for most patterns). It doesn't really solve problems like you might think it would. You can learn by mistake if you wish and try it. Much like communism it looks good on paper until it's implemented.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement