Gamasutra is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.


Gamasutra: The Art & Business of Making Gamesspacer
Beyond Scrum: Lean and Kanban for Game Developers
View All     RSS
June 28, 2022
arrowPress Releases
June 28, 2022
Games Press
View All     RSS
If you enjoy reading this site, you might also want to check out these UBM Tech sites:


 

Beyond Scrum: Lean and Kanban for Game Developers


November 11, 2008 Article Start Previous Page 4 of 6 Next
 

Time-boxing

Time-boxing is something that every developer using Scrum recognizes. A Sprint is a two to four week time-box. We hold firm on the amount of time in a sprint and only vary the functionality we can deliver. The benefit of this is to create a predictable heartbeat of value being added to the game.

In production we take this a step further. We start time-boxing each stage of the value stream. For example, we might give the audio designers 10 days to add audio to a specific zone. This is different from tasks in Scrum where the audio designer would estimate their own work and tell the customers what they are willing to commit to.

In production this changes, because we have learned in pre-production how long audio design for a zone should take. Quality becomes the variable you control with time-boxing assets. We are not forcing artists to meet a set quality with a fixed amount of time.

The input is the time-box (which is the cost we are willing to pay for the asset). The output is quality that the artist is able to provide within the constraint of time.

The key to time-boxing assets is to find the correct time box size. If you choose too short of a time-box, then quality will suffer. For example, if the time-box for hi-res level geometry is set to one day, the artists would give us a level filled with untextured cubes! This would be a lower quality than what the customer wants.

On the other hand if the time-box for the zone were two months, we might end up with a zone with intricately detailed geometry everywhere. It would be absolutely beautiful, but that beauty would come at too great of a cost to the customer. It's the job of the customer (the product owner in Scrum) to be responsible for the Return on Investment (ROI) for the production assets being created.

The product owner has to consider what the player expects from the assets in the game. When I was working on driving games, I would tell our artists to focus on making "90 mile-per-hour art". The quality bar should be set based on what the player sees when they are driving at full speed. If we sink 40 hours into creating a picture perfect fire-hydrant, the extra cost would be wasted on the player passing it at 90 miles per hour!

The product owner must keep the cost/value curve in their mind at all times:

 

 

This shows that the value to the customer is not a straight response to the cost of creating the asset. When you spend too little on an asset (e.g. cube city) the value to the customer will be too low. The driver might notice yellow cubes on the side of the road pretending to be fire hydrants.

Beyond a certain cost, the ROI will diminish (e.g. 1000 poly fire hydrants in a racing game). We are not relating quality to cost. We are relating value to the customer (player) to the effort we spend. We don't want to "deliver caviar to customers who want Big Macs".

 

 

Leveling Workflow

Time-boxing allows us to employ a very powerful aspect of Kanban. The cards in each column represent capacity for each stage of the value stream. As we see above, each stage can only handle one zone at a time. That is the capacity of each stage, if we have one person working at each stage.

Time-boxing is the first step in beginning to find a balanced flow for our value stream as visualized on our Heijunka board. However, one problem exists. Each stage of effort in the stream will require a different length time-box. This can cause gaps and pileups.

For example, if our level designer can lay out a level in a week, but the high res artist requires two weeks, then a lot of work can pileup for the high res artist. Conversely, if the concept artist requires two weeks to complete the concept art for each zone, the level designer might be waiting for work with nothing to do:

We have to find ways to balance this workflow smoothly so that everyone has work to do every day. One way of doing this is to balance the effort on each stage to achieve the same flow through the system.

For example, if we want to get a zone through the stream every 10 days, we start be looking at the time-boxed effort for every stage for each member of the team working on each stage:

Stage People days per zone
Script 5 days
Concept
10 days
Level design
20 days
Hi-res art
30 days
Audio design
10 days
Tuning pass
7 days


Article Start Previous Page 4 of 6 Next

Related Jobs

Treyarch
Treyarch — Playa Vista, California, United States
[06.27.22]

Tools Engineer - Treyarch
Treyarch
Treyarch — Playa Vista, California, United States
[06.27.22]

Audio Engineer - Treyarch
Build a Rocket Boy Games
Build a Rocket Boy Games — Edinburgh, Scotland, United Kingdom
[06.27.22]

Lead Physics Programmer
Build a Rocket Boy Games
Build a Rocket Boy Games — Edinburgh, Scotland, United Kingdom
[06.27.22]

Lead UI Programmer





Loading Comments

loader image