Once Upon an Iteration | Filament Games

Iterative design was around long before modern software development. In fact, natural evolution provides plenty of evidence of the advantages of this approach. Nature has come up with designs that are more efficient and beautiful than those of the best and brightest scientists.

However, humans haven't always taken their cues from nature. It's taken about 25 years for the software development industry to become mature enough to understand the value of a little trial and error. Today, there is a ton of hype around Extreme Programming, agile development, and, most recently, SCRUM.

My goal with this series of short articles is to cut through the hype surrounding some of these formal processes and discuss how they can be combined to reduce the risk and cost of developing indie games.

A Typical Indie Studio

A good starting point for looking at iterative development is to consider the staff setup at a game development studio like Filament. At the top you have the management team, made up of producers and designers. They interface directly with external stakeholders, come up with the initial specifications for the product and oversee its development. Their job is to ensure that the product meets a set standard of quality, satisfies the stakeholders, and efficiently utilizes the studio's resources: time and money. However, the management team doesn't have all the specialized skills necessary to actually make the product. Instead, it must rely on a technical staff of engineers, artists, writers, and so on.

The technical staff is responsible for actually delivering the goals set forth by the management team. It's critical that there is a process in place for reviewing the product as it is being developed, and also for catching and correcting mistakes in the original design. This is where iterative development comes in.

Top Down Versus Bottom Up

There are essentially two different lenses one can use when approaching a software engineering problem. The top-down approach is used to design software starting from abstract goals and moving toward a more concrete plan. The bottom-up approach is just the opposite. A top-down design, for example, would analyze how a player might move through the game world and interact with other characters. A bottom-up design, on the other hand, would investigate how the software might translate keyboard and mouse input into spatial information, or how the game world might be drawn to the screen.

Ideally, any development approach should combine both top-down and bottom-up design. This allows the designer to work within budget and hardware constraints while keeping the wider gameplay goals in mind.

Iterative Essentials

As should be obvious from above, the management team is best suited to look at the design from a top-down approach while the technical staff is best suited to work bottom-up. An iterative approach utilizes the strengths of both teams throughout the entire project, not just at the beginning.

In a 100% top-down development model (sometimes called a Waterfall model...hence the lovely picture), the designers create an abstract plan that the technical staff tries to implement as best they can. Then, at the end of the development cycle, the product is tested and released. But, you ask, what if the product is lousy? For years, the software world didn't care all that much because there was little competition and budgets were small. Today, however, the landscape is different, and there is a need to work bottom-up design into the development process.

The basic gist of all the competing iterative approaches is this: there's a period of top-down, then a fixed period of bottom-up to address a certain set of the high level goals, and then iteration (rinse and repeat). This process mitigates much of the risk associated with design flaws as it addresses them earlier and, in theory, avoids wasted work.

Coming Up

Next time, we'll take a look at some concrete implementations of iterative development and some examples with pretty pictures!


	Fri 11 Sep 2009 - 08:15AM — Alex Stone Iterative design was around long before modern software development. In fact, natural evolution provides plenty of evidence of the advantages of this approach. Nature has come up with designs that are more efficient and beautiful than those of the best and brightest scientists. However, humans haven't always taken their cues from nature. It's taken about 25 years for the software development industry to become mature enough to understand the value of a little trial and error. Today, there is a ton of hype around Extreme Programming, agile development, and, most recently, SCRUM. My goal with this series of short articles is to cut through the hype surrounding some of these formal processes and discuss how they can be combined to reduce the risk and cost of developing indie games. A Typical Indie Studio A good starting point for looking at iterative development is to consider the staff setup at a game development studio like Filament. At the top you have the management team, made up of producers and designers. They interface directly with external stakeholders, come up with the initial specifications for the product and oversee its development. Their job is to ensure that the product meets a set standard of quality, satisfies the stakeholders, and efficiently utilizes the studio's resources: time and money. However, the management team doesn't have all the specialized skills necessary to actually make the product. Instead, it must rely on a technical staff of engineers, artists, writers, and so on. The technical staff is responsible for actually delivering the goals set forth by the management team. It's critical that there is a process in place for reviewing the product as it is being developed, and also for catching and correcting mistakes in the original design. This is where iterative development comes in. Top Down Versus Bottom Up There are essentially two different lenses one can use when approaching a software engineering problem. The top-down approach is used to design software starting from abstract goals and moving toward a more concrete plan. The bottom-up approach is just the opposite. A top-down design, for example, would analyze how a player might move through the game world and interact with other characters. A bottom-up design, on the other hand, would investigate how the software might translate keyboard and mouse input into spatial information, or how the game world might be drawn to the screen. Ideally, any development approach should combine both top-down and bottom-up design. This allows the designer to work within budget and hardware constraints while keeping the wider gameplay goals in mind. Iterative Essentials As should be obvious from above, the management team is best suited to look at the design from a top-down approach while the technical staff is best suited to work bottom-up. An iterative approach utilizes the strengths of both teams throughout the entire project, not just at the beginning. In a 100% top-down development model (sometimes called a Waterfall model...hence the lovely picture), the designers create an abstract plan that the technical staff tries to implement as best they can. Then, at the end of the development cycle, the product is tested and released. But, you ask, what if the product is lousy? For years, the software world didn't care all that much because there was little competition and budgets were small. Today, however, the landscape is different, and there is a need to work bottom-up design into the development process. The basic gist of all the competing iterative approaches is this: there's a period of top-down, then a fixed period of bottom-up to address a certain set of the high level goals, and then iteration (rinse and repeat). This process mitigates much of the risk associated with design flaws as it addresses them earlier and, in theory, avoids wasted work. Coming Up Next time, we'll take a look at some concrete implementations of iterative development and some examples with pretty pictures!