Requirements, Maintanence, and Games

Looking back on one of the first game projects I worked on, I realize now, more than ever, how important good requirements are, how important good communication and best practices are in designing and developing a software system. My words are not to reflect badly on my employer or the state of their work, as all of it was student based and originally done by one person. It is to instead talk about what was wrong, why it was wrong, and the outcome because of it.

When I started work with the company, it was to focus on the implementation of a centralized game for their project. This game was already planned and was supposed to have good documentation. The first ten weeks of work was to be developing the game, while the last ten weeks was to be polish and maintenance, with extended testing and development as could be offered. However, after coming onto the project, it became quickly evident that the project was not as well planned as we had hoped or thought it would be.

The project had been written mainly by a single programmer, who also was responsible for most of the artwork. For the application, there was very little use of the XNA framework, as when the application was originally made, XNA did not have nice features such as model loading, texture loading, etc. Because of this, it had a very interesting architecture, based around working with the loading of COLLADA files and their only implemented game, a space shooter where you shoot meteors and protect friendly ships. While there did exist an architecture to extend the game, to allow for the centralized colony simulation and other mini games to come on, everything was so tightly coupled to everything else that working off of that base would have been, for lack of a better phrase, nigh impossible.

So, what should have been simple development and integration became the designing of and implementing of a game architecture that would allow for mini-games, a centralized game, and ways of communicating information between them. Along with this, it had to support the original mini-game and also somehow incorporate the particle engine that had been written for the mini-game. This process took approximately 5 weeks to build, and over the course of development for the last 5, the whole time to check maintenance-wise. And with that, came the game development.

Now, there were many ideas for the mini-game the side team was developing, and many ideas for the main game. However, there were no true requirements as to what the games should be. Some said "like SimCity, but in space!". Others were more like Railroad Tycoon in the way the transport systems should work, but they failed to mention what should be transported and how this related to the game system and mechanics. This led to what was, more or less, 5 weeks of prototyping with trying to find the mechanics and requirements that would match the game that our producer wanted, while allowing for what could be a fun and reasonable game. Looking back on this, we could have probably used the full 10 weeks just to get nice requirements and create a strong architecture, but often in industry there isn't that sort of time, nor that kind of foresight.

A result of this process, or lack thereof, has led to many problem during maintenance. Many issues that were not covered have come up, leading to some people implementing improper quick fixes. Another serious issue is, as things have built up, the lack of communication has created severe issues with how issues are handled, which has resulted in some less than sufficient or necessary changes to the project, which have further delayed the beta release.

All in all, requirements, nice, solid, good requirements and good communication would have solved many of these issues. With games, as with any software, the gauge of success and problems often can be traced back to the requirements, or lack thereof.

School and Work

On 12/31, I ended my 6 month co-op with the Autism Collaborative. However, I promised to stay on working on a few minor details that needed polishing and provide support where I could for the project.

The project was a game project aimed at Autistic children, between the ages of 10 - 14 (if my memory serves me), with symptoms similar to but possibly greater than those with Asperger's Syndrome.

The game followed a structure in which a large scale game, called the Colony Simulation, served as the center for a set of other "mini games" or "missions" to branch off of. The Colony Simulation would allow players to build a colony in deep space, allowing them to mine for ore, build residential (housing, entertainment) and commercial (stores, factories, mining plants) structures, and link them via a series of "tubes", one for each type of structural connection. This was designed this way based on our producer's experience with Autistic children and their fascinations with machines and mechanical structures. Hence, the simulation was to act like one large machine, when connected.

Each of the mini games or missions are accessible within the Colony Simulation. They can either be selected or they are generated for the user to play. The missions encapsulate many typical and interesting Autism tests, which are used within both a lab setting and data collection setting to collect information about the player.

During this period, I participated in the design, development, and currently the maintenance of the Colony Simulation. My roles primarily included task tracking, completing various tasks, and requirements elicitation (getting ideas and feedback from our producer and my co-workers). I became responsible for many of the user interactions, especially those through the GUI, which I ended up designing the framework and specifications for, since C# does not have a natural GUI implementation for XNA.

Overall, I found the experience very rewarding. Not only does it look great on my resume, but it has helped me figure out many "dos and don'ts" when it comes to games. Also, it's nice to know that what you worked on will help people.

Aside, the maintenance side has come at a hefty price, mainly personal patience and frustration. Since December, I have been enrolled back in school, finishing my Software Engineering degree. It has been difficult to perform maintenance functions, as I have been overloading for the past two quarters (20 credit hours), in order not to only finish my degree, but to also take some of the classes I want to before I graduate.

Overall, the passed several months have been hectic. We're finally at a mid alpha-beta release for the full game, which makes me happy. I am finishing testing on part of the game I have been touching up (score screens and in game artwork). I will post something when we have a release, as well as a means on how to download it.