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.
No comments:
Post a Comment