Articles

• Using Design Patterns in Game Development

  November 17, 20101 comment

  According to Johann Wolfgang von Goethe, life belongs to the living, and he who lives must be prepared for changes. This is so true for developers; which is why they need to use design patterns.

  So what is a design pattern? A lot of developers have been in the industry for so long and yet they don’t know what it is. Some know all about it but don’t implement it, ignoring the importance of implementing such techniques. There are others too who think that their codes are organized already and don’t need any design pattern.

  Design patterns are essentially described as a solution to a problem.  Inevitable problems arise during development especially large scale projects that have trivial coding that result into redundant and expensive codes.  It also serves as a means of easing up the development process and making it more reliable as an application’s foundation.

  Game development has always been at the forefront of the computer and internet revolution.  Early games were developed by a single developer but as the evolution of technology progressed exponentially, games also evolved to take advantage of such technologies and more developers were needed to develop a game.  Main stream games now usually take one to four years to develop and done by an in-house group of a few or several programmers.  Responsibilities are divided and distributed to special groups to handle specific type of logic such as graphics (hardware), level design, graphical user interface (GUI), game play, and many more.

  The key is basically this segregation of responsibilities.  Breaking down responsibilities denotes breaking up the code into pieces that, when integrated to the final stage of development, works well with other pieces.  Using design patterns will ensure the consistency of development whilst achieving flexibility for more module add-ons.  Developers that habitually go for tight coupling of modules end up scratching their heads during the crucial stages of development than developers who prefer good object oriented design and design patterns.

  What are the other factors to consider?

  • Prototyping.  In game development processes, one of the most successful methods is AGILE development, which is basically iterative prototyping.  A game is developed from a simple prototype and matures during the course of development depending on feedbacks and an increasing feature set.  As the game matures, the code also gets changed.  Sometimes these changes are expensive if they are not implemented with proper object oriented practices and design patterns.

  • Reusability. This is one of the most deliberated topics when it comes to object oriented techniques.  The notion of reusing a code or functionality is present in all aspects of programming.  Design patterns preserve a code’s functionality (depending on the pattern used).

  • Maintenance.  As projects reach deployment stage, a big chunk of the code will be hard to maintain especially when a lot of additional features have been added during development.  If a project is structured properly using a design pattern, it will be easy for new developers to extend the original design’s functionality because of its maintainability.  This is very useful when games are rebooted or gets a sequel.

  There are a lot of design patterns, each of which have its own unique purpose or solution to a problem. The commonly used one is the Model-View-Controller (MVC) pattern. For isometric games, the base patterns commonly used are the Factory and Facade pattern.  Frameworks such as PureMVC implement a multi-pattern approach which is a good candidate for developing basically any kind of application.

  Design patterns are techniques for catching up with the constant change in software design and development.  In game development in particular, change is inevitable.  Only a few games ever finish with a matching initial and final design because of requested changes.  But by using design patterns, you don’t have to worry about difficult clients or change requests. In real life or game development, nothing beats being prepared for changes.

  

  Read more...

• More Articles