Categories
Game Development

Why design patterns are a good thing

So here I am for the third game needing a text manager class. Something to hold text strings for periods of time, display them in an ordered list, and handle text wrapping. The first game that needed this used DirectX so I had lots of DirectX code in the text manager. It would compute the […]

So here I am for the third game needing a text manager class. Something to hold text strings for periods of time, display them in an ordered list, and handle text wrapping.

The first game that needed this used DirectX so I had lots of DirectX code in the text manager. It would compute the length of strings, edit the list of strings to split them up, etc.

This was useless for my second game because it used a different graphics engine. I copied some parts over, but a lot was changed. One of the biggest changes was that fonts were now in a separate class, where DirectX handled them as part of the graphics engine. Also DirectX took the strings to render directly where this new engine had a manager. So a lot of code was changed.

Now for my third game I look at what I did for the second game and again see that it is useless. Faced with the prospect of rewriting something that has the same functionality for the third time I decided enough was enough. Time to actually apply some engineering principles. Browing the web and remembering what I learned in college I decided to try out a factory class with a model / viewer pattern.

At first I was hesitant to do this because it didn’t seem to solve any problems. At best, I would split up the viewer into two classes that I could have done with a simple if statement. However, as I wrote more I began to see the wisdom behind the architecture.

First, I wrote the factory. This forced me to think about what parameters I would use in advance and whether they belonged in the model or the viewer.

Second, I wrote the model – which is just a list of text strings. This was completed much faster and easier than I had done in my prior implementations because I didn’t have to think at all about how the strings would be displayed. The model is totally independent of the graphics engine.

Third, I wrote the viewer. Some parts of the viewer, such as accessors for data, have nothing to do with the graphics engine. Some parts do. So in a flash of inspiration I had the viewer Irrlicht implementation derive from the viewer base class. I then modified the factory to return an instance of the Irrlicht implementation.

Presto! Now I can use this in future games. All I have to do to switch graphics engines is to derive a new viewer. I don’t even have to change the game code because it got an instance of the base class rather than the Irrlicht Implementation. I can just change the factory for the graphics engine I want. I could even support multiple graphics engines by passing different parameters to the factory.

Leave a Reply

Your email address will not be published. Required fields are marked *