Player roles and user stories

Many game development projects don’t put much thought into the various kinds of players who buy the game. They usually add three levels of difficulty towards the end of development as a means of adding replay-ability and accommodating a range of player skills. The levels are differentiated by a simple scaling of challenges in the game such as the number of opponents, the damage from their hits or the damage your hits cause. This reflects the amount of effort we think it’s worth.

Would we benefit from considering a broader range of players and placing more importance in their roles throughout development? Some games do this, especially some online games. An example is the popular Battlefield games which allow players to equip themselves based on specialties. If you are not familiar with the games or the specialties, they are usually divided across these roles:

• Assault specialist - Equipped with an assault weapon and grenades for close quarter combat.
• Sniper - Carries a high power sniper rifle and a sight that can they can use to call in precision strikes.
• Engineer - Has a bazooka, mines and can repair vehicles.
• Special forces - Carries a light automatic weapon and C4 explosives for sneaking around behind enemy lines causing problems.
• Support - Totes a heavy automatic weapon and a radio to call in mortar strikes.

These specialties require different behavior from each player who assumes each role. They aren’t as limited as difficulty levels because players can try each specialty in any order and with any skill level. These specialties cannot be added at the end of development. They need to be developed somewhat in parallel during preproduction. They have an impact on level design and should be added well before production starts.

User stories provide a mechanism for identifying these roles and clearly communicating features related to each. The template for user stories I like is:

“As a <>, I want <> [so that ].”

A good method for identifying and differentiating goals is to phrase the user story in terms of those roles. So instead of saying:

"As a player, I would like to have a bazooka so I can blow up tanks"

the story becomes:

"As an engineer, I would like to have a bazooka so I can blow up tanks".

What's the difference? It's mainly one of value and priorities. For a generic player, the bazooka is one of a host of weapons, many of which are more important to the game. However for the engineer, the bazooka is probably the most valuable weapon. I wouldn't play the engineer without it. There's nothing more gratifying than taking out a tank with a well placed shot.

Even if your game isn't going to have specialties, like Battlefield, there is a lot of value in brainstorming the various roles of players early in development. Who is buying your game? Are you going after a largely casual market? If you are, it would benefit you to identify the "casual player" role in some of your stories. It will lead to many small decisions such as simplifying the controls or adding more checkpoints so the casual gamer doesn't become frustrated.

How Pixar Fosters Collective Creativity

HBR is posting the article free for a short period of time.

What's equally tough, of course, is getting talented people to work effectively with one another. That takes trust and respect, which we as managers can't mandate; they must be earned over time. What we can do is construct an environment that nurtures trusting and respectful relationships and unleashes everyone's creativity. If we get that right, the result is a vibrant community where talented people are loyal to one another and their collective work, everyone feels that they are part of something extraordinary, and their passion and accomplishments make the community a magnet for talented people coming out of schools or working at other places. I know what I'm describing is the antithesis of the free-agency practices that prevail in the movie industry, but that's the point: I believe that community matters.

Thanks to Clarke Ching for pointing to the article.

Overtime works with waterfall?

Many Scrum teams have found that excessive overtime reduces productivity. The frequent inspection of work done on a daily basis makes measuring productivity far easier with Scrum. One of the reasons for this is that a Scrum team can adapt their practices and see what effect those changes have on their effectiveness.

Jeff Sutherland reports that one of the companies he coaches has measured the productivity of teams using Scrum and waterfall-like practices under different overtime conditions. They produced a graph they call the Maxwell curve:


This is hardly a scientific study (e.g. I'm real curious about how they measure story point velocity in a waterfall environment) but it is a very strong visual argument for what is intuitive about how people work:

- Teams of people who take ownership of their work and make a commitment are more productive, but this high level of productivity cannot be sustained for 60 hours a week.

- When people are treated like cogs in a machine (handed estimated tasks that have to be completed to a predetermined schedule), they can indeed produce more at 60 hours a week that 40. However the productivity of cog teams is not nearly as high as committed teams because their intensity is not nearly at the same level.

Think of a runner sprinting and a jogger. The sprinter will be faster, but cannot maintain that pace as long as the jogger.

The question is "who covers the greater distance?". Does the team that "jogs" go farther in 60 hours than the team that "sprints" for 40? Maybe, but which is sustainable? Which team would you rather be on? Also, is it the same progress? Consider Jeff's comment on overtime with waterfall:

Overtime doesn't work in waterfall. It introduces technical debt. It works short term for the project leader as long as no one discovers he is damaging the code base. Velocity gets slower and slower with overtime but it may be years before management realizes they have to pay for the technical debt. By then the project leader has been promoted.

Jidoka, TDD and asset validation

Jidoka

Jidoka is a Japanese term used at Toyota which means "automation with a human touch."

It's origins lie in the early philosophy of Toyota (at the time it was called Toyoda). Part of this philosophy was to minimize labor costs by reducing labor waste. A example is the creation of "Type-G automated loom" in 1924. Before then, each loom was watched for thread breakage by a single operator. If a broken thread wasn't caught quickly, it would ruin an entire run of cloth. The entire process was very wasteful in operator time (90% waiting) and ruined cloth.

The innovation of the type-G loom is that it would automatically stop whenever the thread broke. This allowed a single operator to support dozens of machines and virtually eliminated bad production runs of cloth due to broken threads. Quality went up.

When Toyota started making cars, the philosophy of Jikoda was carried over to the manufacturing process. On the Toyota factory floor, a problem can potentially stop the entire line until it is fixed. Once the fix is identified, the standard process is improved to prevent a recurrence of it in the future.

The following diagram shows the Jikoda flow


TDD

Those of you using TDD (Test Driven Development) should recognize this flow. Unit tests are introduced for every function in the codebase. These unit tests provide validation of those functions that are run when changes are integrated into code base (by a continuous integration server).

When we discover a bug, we must solve it immediately or end up stopping the line (stopping the commits). When the bug is identified, a fix and a unit test, to catch further recurrences of that bug, are checked in and work continues.

Why solve bugs immediately?

• Bugs can cause the entire team to lose work. A build that crashes can waste hours of work across the entire team.
  
• Bugs cost the least to fix immediately after they are created. Bugs fixed months later in "alpha" can cost 10-100 times more.

The practices for TDD are well established. Tools like Cruise Control allow an easy integration of TDD into any development environment.

Asset Validation Jikoda-style

What we need are similar tools and practices for a version of asset TDD.

Unit testing for assets should:

• Catch assets which break the build
• Catch assets with naming convention errors
• Catch assets which violate budgets (texel density, memory footprints, poly counts, bone counts, etc).
• Identify and track approved assets versus unapproved assets that need art lead approval
  

Bad assets are another form of debt, like bugs. They cost more to fix later. A more automated approach to checking assets will help keep this debt, which is waste, low.


I've always been on teams that do some of these steps, but they weren't complete and they were always implemented later than they should have. It would be great to have some more standardized tools. Hey Autodesk!.....

Should the Scrum Master also be a member of the team?

This question is raised frequently. I prefer that a Scrum Master (SM) not be a member of the team, but this is not a strict rule of mine. An SM as team member can create problems:

• A focus on their own tasks over the team issues.
• Prioritizing their own impediments over those of other team mates.
• It can impede team ownership through the “Scrum Master as Team Lead” anti-pattern.

These problems are usually created subconsciously, but they do create barriers to team commitment. Sometimes there is no choice but to have the SM be a member of the team. There may not be enough teams for the SM to fully occupy their time. An SM can handle 3-4 teams before it starts becoming a full time job (your mileage may vary).

If the SM has to be a member of the team, keep an eye out for these problems. Raise them in the retrospective. It’s not easy, but it has to be done. One great way to overcome this is to rotate SM duties. If your current SM is the only one certified or experienced, they should coach the other people who rotate into the role.

Rotating the SM role has many benefits. Team members appreciate and understand the role much better after trying it.

Survey - When and where to hold next CSM class?

I've received many requests for another 2 day "Certified Scrum Master for Video Game Developers" class (the one in Austin last May filled up).

So I'd like to collect a your opinions about when and where to hold the next class. If you are interested in attending one of these, please answer a few questions in the short survey below.

Click Here to take survey

Thanks!

Agile values - Individuals and interactions over processes and tools - Part 2

Question: How does a large software project get to be one year late? Answer: “One day at a time!” - Fred Brooks

Our processes and tools to manage ever growing projects have built up over decades. Large teams have driven the creation of hierarchies of management. Project schedules and design documents attempt to predict every requirement and task necessary to make a fun game now require expensive databases to manage. All of these are considered necessary to tackle the complexity the rise from having upwards of a hundred people working on a project for years.

Game development requires developers of widely different disciplines. Take for example a cutting edge AI character that needs to walk around an environment and challenge the player in the game. The creation of this character requires the participation of animators, designers, character modelers, texture artists, programmers audio composers among others.

It’s important that these disciplines collaborate as much as possible to be the most effective. If the animator is experiencing a problem with the animation technology, then it is important for them to work with a programmer as quickly as possible to address the problem so they can continue working. Often the processes and organization will prevent that. In our example with the animation bug, the programmer may be working on a series of tasks that were assigned by a lead. This may prevent that programmer from helping out the animator without permission from their lead. This leads to a chain of conversation as shown in the following figure:

The animator has to pass the request up through the chain of command which then has to make it back down to a programmer who can solve the problem. In this example, the change involves five people and four requests! This flow is prone to failure and delay.

So what has been described?

• Over 100 people of various disciplines on one team.
• Thousands of unpredictable problems that can introduce wasted time and effort
• Detailed plans and tools to manage them that can’t predict these problems and are potentially inflexible at changing.
• Hierarchies of management that can lead to further waste.

Agile can address these issues from the bottom up. This is a major benefit from self-managing teams. They self-manage the smallest level of details, not necessarily the highest levels. They aren’t self leading teams. They unburden leadership of the role of managing minor details. They allow leadership to focus on the big picture.

When teams learn that they can take a small amount of ownership to solve the smallest problems, they start taking on larger problems. They begin to ask for more ownership in other areas:

• In creating better teams that can solve more problems by reducing external dependencies.
• In demanding more of themselves to achieve commitments they own.
• By identifying risks early and addressing them before they become problems at all.
• By growing leaders among their own ranks.

Agile values are preferences and not binary decisions. We can still have process and tools to support the team, but we value individuals and interactions more to solve most of the problems that occur on a daily basis.

Scrum Rising article posted

I've posted my February 2007 Game Developer Magazine article "Scrum Rising" here.

It's an overview of applying Scrum to game development.

Scrum makes you smarter

http://jeffsutherland.com/scrum/2008/05/scrum-makes-you-smarter.html

"Recent research shows that people who work in command and control environments actually lose a significant number of points on their IQ. They get stupider."