Thursday, August 21, 2008

Iterations and vertical slices

Any game developed using agile makes progress using iterations. The goal of every team for every iteration should be to make progress by adding value to the game or pipeline for a customer. This might be a the improvement to a core feature for the player who buys the game or a function for the animator using the asset pipeline or a tool.

Iterations (or Sprints) are like mini projects by themselves. They often include design, coding, asset creation, tuning and debugging. However we are not always producing full vertical slices of a game every iteration. We’ll use a an example of what we might deliver for a team which is focused on creating AI behaviors: One of the most difficult aspects of AI behavior is navigation in a complex environment. The AI logic has to identify objects that will prevent the NPC from moving and calculate a path around them. Throw in some other moving characters and objects and the problem can become very complex to solve. Navigation can become the most riskiest problem to solve AI and therefore one the the riskiest problems to solve for the entire game.

Naturally we would want to solve the navigation problem as early as we could. The problem with doing this work early is that other related systems such as character animation and physics might not be developed enough to support the sprint goal of having a polished AI character walk through a complex environment. In this case, the iteration goal for the team might be to demonstrate simple cylinders navigating a complex test environment.

Does this solve all the risk associated with AI characters navigating complex environments? No. It probably addresses a big part of the problem, but there may be other problems that show up when progress is made with the animation and physics. The benefit is that those systems will have some basis to work against. If we find that our cylinders have problems navigating up stairs, then that might influence animation and physics work over the upcoming iterations.

It's a much more intractable problem when you discover your nicely animating AI character can’t climb the stairs that are duplicated in every level.

Iteration goals are prioritized based on value, cost, risk and knowledge. Addressing high risk and creating knowledge sometimes drives the highest priority stories on the backlog. A Product Owner has to understand the risks of the project as well as the value of the features when prioritizing.


Chris said...

Speaking of vertical slices, one issue my team always has with publishers is: which sprint is the vertical slice? We try to introduce the concept of iterative slices that roll in feature-by-feature, which seems to appease the producer at the start, but invariably they come asking which one is the "actual" vertical slice. Presumably they want to know so they can demo it to the big shots and evaluate risk.

Has anyone had success selling the iterative sprint method to publishers?

Clinton Keith said...


Releases are best for producing vertical slices for an external customer. A release is a number of Sprints with perhaps a stabilization/polish sprint at the end. It's meant to produce what I refer to as a "magazine demo quality" version of the game.