Saturday, February 19, 2011

The Onion Development Model

Everyone who's been in SGD for more than a year has seen or been on a failed project, and most every repeat director has had at least one dud in their history. There are a number of different reasons for this:
  • Director is lazy or distracted
  • The development environment sucks
  • The project idea fails to motivate people to work hard
  • The project is reliant on a single feature or person
  • Project has too large of a scope
When preparing to compete at the 2011 Rosetta Stone Game Jam, we started thinking about ways to mitigate these problems on a 36 hour scale. Frankly, an SGD project also condenses into about that scale over the course of the semester. We felt we had pretty good methods of dealing with the first four issues. So, we looked for a way to ensure success despite the 5th one.

We say despite, because in our experience there is no such thing as a project with a perfect scope. The onion model accounts for that, and allows the project to succeed regardless. Basically, you start with the smallest possible vision of your game that would still be playable, fun, and still "your game". So if you were making a space shooter, you would say that your onion was flying around, firing and destroying enemies.

With the onion, you don't spend any time on any aspect of the game that does not fall into the core of the onion until those parts are complete. For example, you wouldn't work on enemies shooting back at you, or multiple types of AI, until all those basics were in.

After the core of the onion is complete, you designate a set of features as the next layer and repeat the process. This guarantees two important things. First, if your project is cut off (such as at the End of Semester Expo), you are sure to have a fun and playable game. Secondly, you ensure that the features most important to your game receive the most testing, polish, and attention.

If there's a small problem with your firing code that causes the game to crash 1% of the time, if it's added at the end, you may never see the bug. But if it's added first, you'll be sure it gets the testing it needs.

The Onion model may or may not make sense for larger project, because the engine needs to be ready to accommodate the small features from the beginning. However, we think that for SGD it is a great way to secure a good showing by the end of the semester.

No comments:

Post a Comment

Although this organization has members who are University of Virginia students and may have University employees associated or engaged in its activities and affairs, the organization is not a part of or an agency of the University. It is a separate and independent organization which is responsible for and manages its own activities and affairs. The University does not direct, supervise or control the organization and is not responsible for the organization’s contracts, acts or omissions.