Game Development Methodology for Small Development Teams

Game Development Methodology for Small Development Teams

By Lorenzo Phillips

 

Introduction

 

If you have ever developed software for a company of adequate size, then you are probably familiar with the terminology used within the Software Development discipline.  If you are a game developer, then chances are good that you have found it difficult to apply traditional Software Methodologies to your project(s).  Even worse, if you are a solo developer or a small band of game developers (i.e., a pack of lone wolves), then you most likely disagree with traditional Software Methodologies (even those used in larger game development shops) and have formulated your own development style.  This article was written for the lone wolf developer and the lone wolf packs of the game development community.  It is not meant to bash the traditional development methodologies, but merely to provide a working alternative for game developers that do not have the time or the money to implement such complex structures in their projects.  In life, there is no one solution that solves every problem.  So, simply use the methodology documented in this article as a guide and modify it and cater it to fit your particular situation.

 

Software Development

      

Before we get into the actual methodology, let’s take a look at why traditional software development techniques do not satisfy the needs of the game community.  The traditional style of software development is geared towards business applications.  Business applications generally take a minimum of a year to release and work with large budgets.  In the gaming community, excess time is not an option.  Publishers attempt to release entertainment software on a regular basis throughout the year.  Why?  In the real world, businesses are not designed to change rapidly.  It costs too much money and there is too much overhead involved (i.e., upgrading all of the company’s computers, testing the upgrade to ensure it fits into the current environment and can exist with all of the other applications, and so on).

 

In the real world of the gaming community, there are times when a product can generate high volumes of sales, and therefore, more money.  Releasing entertainment software can be thought of like releasing a movie, where timing is a major factor in the success or downfall of the product.  Holidays such as Christmas or seasonal times like spring break or summer break when many young adults will be at home and will be more inclined to play games. 

 

Another strategic option that must be given serious consideration is what the competition is releasing simultaneously.  For example, if you release a product that uses an older 3D rendering technology while the competition is using a new and improved 3D rendering game engine, then the public may lean towards the game that provides the better graphics.  Another major reason why it is so difficult to use the traditional methods is because games tend to stay current with the technological advances, and thus, leaves many unanswered questions.  For example, how can you document the development effort against a new graphics card if very few people have ever used it?  You may think it will take a couple of weeks, but there is always a learning curve and new bugs to discover that cannot be accounted for in the project plan.

 

In larger gaming companies there are large development teams consisting of developers, artists, and musicians dedicated to completing the project(s). As a lone wolf developer or a small development team, it is not an option to use complex methods to get the product(s) finished.  However, game developers can still leverage some of the techniques and apply them to their specific situations and receive the benefits of the proven and more complex methodologies.  So, if you are a lone wolf game developer or a part of a lone wolf pack continue reading and discover how to successfully implement a development methodology that you can use in your game development efforts.

Business Applications vs. Game Applications

 

I always like to ask the reader this question, “Why do you develop games, instead of business applications?”  I’ll be honest, I love programming period, but I love to develop games because I feel they are superior to business applications in every way.  If you h