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.

Galaxy Raider Spring Semester 2011 Update #1

Galaxy Raider, SGD's epic 3D air/space fighter game, is off to an exciting start this semester. During the last semester, many of the core mechanics were implemented and now the team is working hard to improve and add to the existing content and codebase.

Started as a year-long project, the Galaxy Raider team is still going strong after a rough first semester, with some returning and even more new members, we can expect great things from Galaxy Raider this year. Initially using a previously programmed 3D graphics engine and terrain editor as a framework, the Galaxy Raider team began the work of building a complete game last semester.

Previous Content:
-Physics and player movement
-First weapon and damage system
-Player Ship model
-Original Music
-Original Storyline

Over winter break and during the last few weeks, Galaxy Raider has continued to progress and add new features, some of which are listed below.

New Feature List:
-Auto-targeting laser weapon
-Early stages of a particle engine
-Some basic AI
-Main menu system
-Optimized game engine


Even more features are yet to be added, stay tuned for future updates from Galaxy Raider and the rest of the SGD projects.

The Flat Red Ball game engine

Flat Red Ball is a game engine for games developed in XNA. Currently 2 SGD projects – Moves and Virtuoso - are using the engine in their projects, and one other – Colors – used it last semester. It has also been used for projects such as the Android version of Steambirds, a popular game originally developed in Flash.

One of the biggest advantages to FRB is the automatic inclusion of input methods and collision detection. Normally it is fairly difficult to handle input and collisions (especially collisions) in XNA. Flat Red Ball makes it much easier to process input from numerous methods (such as the keyboard and Xbox gamepad), as well as not only detecting collisions, but reacting to them. This makes it much easier to set up the basics of a game and getting into the meat of the development.

Another big advantage to Flat Red Ball is the amount of tools for content creation. FRB has numerous tools to create sprites, animations, tiles, and levels. This makes it much easier to integrate this content into the game – creating a level in the level editor makes an XML file with all the data, which is then read into the game.

From a programming standpoint, FRB provides two main structures, Entities and Screens, to manage all the parts of the game, as well as a way to organize these structures, known as Glue. Entities are basically FRB’s definition of an object; if there is logic for an in game object, it is an entity. The biggest difference is the inclusion of a manager, an automatically created object that handles all of the entities added to it. Screens are exactly what they sound like – objects to hold all the data in any given “screen” in your game (such as the menu, level, etc). You use screens to add all the objects and entities to the game, as well as manage some of the logic necessary for the objects in the screen to interact. Glue is an IDE much like Visual Studio, but designed specifically for FRB. It makes adding and editing entities and screens much simpler than just doing it straight from FRB, though it is not necessary to use the engine.

All of these extra tools, however, come at a cost. While entities and screens are quite useful, it definitely makes the learning curve for FRB very steep. In addition, all the extra tools are completely separate applications, not one big one. Each of these applications works differently, and each one is integrated into the game in a different way. The result is a fairly clunky combination of tools that are fairly difficult to use all at once, even if they simplify the individual components greatly.

To download the FRB engine, or to get more information on what FRB can do and tutorials on how to do it, check out their website at http://www.flatredball.com/frb/blog/.

Internship Opportunity -- TeeGee

Last night Tom Giedgowd, a student at the Darden School, came by to pitch some internship opportunities for his startup company developing customizable teddy bears.

Check out the presentation for more info on the opportunities, and send any questions or applications to GiedgowdT12@darden.virginia.edu.