This kind of compatibility is rather useful for gaming where hundreds of programmers work on assembling a single product. This may introduce different styles and methodologies, some which may clash with one another. This kind of phenomenon could be especially present between different languages on the same project , like the people in charge of server/network code don't agree with those coding AI logic, or standard toolsets. If the team agrees on specific design patterns for implementing their various sections of a game then it can aid in debugging, make communicating ideas easier and save loads of time. Of course, it's not all positives.
There are drawbacks to using design patterns, especially when it comes to creative problems. A specific design pattern may not be best suited for one particular problem, and may actually be inflating the amount of work you really need to do. They may limit your creativity when it comes to figuring out a solution, and that does not bode well for games. Games are unique problems that usually require a personalized approach. For all the good they provide, design patterns are not the only way to solve the problem. You have to take into consideration that it just may be easier to solve it yourself rather than using a design pattern.
Singleton
The singleton pattern is your answer to global variables and declaring things globally which could be very dangerous. It ensures that only one instance of a class is created when needed. Where would this come in handy? In game development engines are a collection of interlocking systems working in tandem. You have your graphics system and it has a renderer, or window manager. You only want one renderer generally as it controls the flow of information pertain to graphics, which is of particular importance when it comes to games and controls the largest portion of memory (meshes, textures). Having multiple instances would not only eat up memory quickly, but also create a huge mess in code and for the compiler.
Using the singleton will ensure that you have only one instance of a class, the particular one you want to access, with a global point of access so all your subclasses can access the data. This is especially useful when you have classes outside the Gamestate that want to access information in the game state (like physics system calculating one frame before passing it off to the renderer), when your gameState class is the central one, the one that holds the core update function that you need to be able to send information easily.
Facade
The facade pattern at its core is a manager class. It is an interface or a manger to a large collection of related subclasses. Within the facade the details of the subsystems are hidden away, so as to simplify the interface for the user. You can have multiple facades interacting with one another, and this enables the management of the subsystems to be less tedious, by reducing all of the interdependencies you would otherwise have.
Facades are useful for doing things like creating an interface to a collection of classes making up a software library. This can reduce the dependencies of external code on the inner parts of the library, instead just interacting with the facade, providing more flexibility. It can also be used to wrap a poorly designed collection of API's to suit your needs, for gaming this could be wrapping useful external libraries that do things like texture or sound manipulation, or some function that is not inherent to your engine already. If you really think about it,a good analogy could be you are the client, and the computer is a facade. You interact with the facade which contains subsystems that control things like processor, memory allocation, hard drive etc.
State
State patterns are a familiar beast. For the first couple of years in gamedev we relied on state patterns to control how our game transitioned from things like the main menu, to gameplay, to other levels. They are easy enough to implement at first, using switches and enums, because they are logically thought out. As you add states though, things get out of hand and it can become a maintenance nightmare. So how do you fix it?
Use objects to represent logical states! That's right, when in doubt just abstract it to a class. A manager class , a state manager specifically. The manager can take over all the state logic and you can share functionality between states through inheritance. This could be useful in the future when we look into implementing AI systems, and controlling switching for behavior control. Best of all it gets rid of all the conditional checks and switch statements that pollute the codebase!
Factory
The factory pattern deals with the creation of objects, and it is present to some extent in our game already. The idea is to have one central class that can create instance of multiple objects, all you need is to pass in an id of some sort. This is present in my gui when creating widgets for an overlay. You create an object of type widget and then in parameters specify what kind of object it is (be it textbox, or button) and that specific object gets created and attached to the pointer for a widget.
This can provide great extensibility, by allowing you to add new functionality without changing much code. If you are using containers to keep a track of certain objects, like a overlay and all of its parts, it's much easier to use the factory pattern because during development the design varies and goes through constant iteration. This change does not affect an implementation of the factory pattern and will save you precious time and headaches without having to worry about all the specifics.
So are design patterns good? It depends on the situation you are using them for. Usually they can help inspire your solution or get you on the right track providing effective solutions to common problems; and if you ever need to take a different approach, you're always free to deviate.
No comments:
Post a Comment