Agile Game Development

In article <10pld9ef5j0jab3@news.supernews.com>,
John Roth <newsgroups@jhrothjr.com> wrote:
>I wouldn't be so sure about that. There's quite a bit of evidence
>that you can't work more than about six hours doing straight-out
>TDD and pairing. If you try to, you start making so many many
>mistakes from mental fatigue that it isn't worth it.

There's quite a bit of evidence that there's a limit without
XP. Usually a bit higher (and depends on the person), but still under
the number of hours worked during crunch mode on games. Once you work
past a certain number of hours, productivity goes negative as you
have to spend time cleaning up after the mistakes of yesterday.

You can argue this point till you're blue in the face. But, when
management doesn't care, then XP, non-XP, whatever you want to call
your development process is irrelevant. XP is *NOT* a silver bullet
for working sane hours. It's tangential to the real issue.

Nathan Mates
--
<*> Nathan Mates - personal webpage http://www.visi.com/~nathan/
# Programmer at Pandemic Studios -- http://www.pandemicstudios.com/
# NOT speaking for Pandemic Studios. "Care not what the neighbors
# think. What are the facts, and to how many decimal places?" -R.A. Heinlein

"Nathan Mates" <nathan@visi.com> wrote in message
news:419abbb1$0$236$a1866201@visi.com...
> In article <10pld9ef5j0jab3@news.supernews.com>,
> John Roth <newsgroups@jhrothjr.com> wrote:
>>I wouldn't be so sure about that. There's quite a bit of evidence
>>that you can't work more than about six hours doing straight-out
>>TDD and pairing. If you try to, you start making so many many
>>mistakes from mental fatigue that it isn't worth it.
>
> There's quite a bit of evidence that there's a limit without
> XP. Usually a bit higher (and depends on the person), but still under
> the number of hours worked during crunch mode on games. Once you work
> past a certain number of hours, productivity goes negative as you
> have to spend time cleaning up after the mistakes of yesterday.
>
> You can argue this point till you're blue in the face. But, when
> management doesn't care, then XP, non-XP, whatever you want to call
> your development process is irrelevant. XP is *NOT* a silver bullet
> for working sane hours. It's tangential to the real issue.

In that sense, you're quite right. If you've got that issue, there
are a number of formal studies (beginning with some at the
US DoD) that demonstrate that error rates go sky high as
fatigue sets in.

The medical community doesn't seem to have learned this either,
from how they schedule interns and residents.

John Roth
>
> Nathan Mates
> --
> <*> Nathan Mates - personal webpage http://www.visi.com/~nathan/
> # Programmer at Pandemic Studios -- http://www.pandemicstudios.com/
> # NOT speaking for Pandemic Studios. "Care not what the neighbors
> # think. What are the facts, and to how many decimal places?" -R.A.
> Heinlein

Nathan Mates wrote:

> There's quite a bit of evidence that there's a limit without
> XP. Usually a bit higher (and depends on the person), but still under
> the number of hours worked during crunch mode on games. Once you work
> past a certain number of hours, productivity goes negative as you
> have to spend time cleaning up after the mistakes of yesterday.
>
> You can argue this point till you're blue in the face. But, when
> management doesn't care, then XP, non-XP, whatever you want to call
> your development process is irrelevant. XP is *NOT* a silver bullet
> for working sane hours. It's tangential to the real issue.

Not working long hours is the silver bullet for working long hours.

Studies (by game shops) have shown that if you actually track velocity, it
does not go up as the hours get longer.

I suggested "design code and finish one level at a time". I'm not sure, but
I suspect games grow breadth-first.

Just like working sane hours, there are people who will reject such radical
ideas simply because they have never been done.

Look to "lean hardware design", aka lean manufacturing. You delay decisions,
and empower the workers who collected the raw data about things.

--
Phlip
http://industrialxp.org/community/bi...UserInterfaces

Phlip <phlip_cpp@yahoo.com> loquated like no one had ever loquated before
with:

> Nathan Mates wrote:
>
>> Reading some of the recent postings, it seems that the sweatshop
>> mentality at EA comes from a management attitude of "you will work
>> long hours." [I can't comment on the validity of those assumptions,
>> just presenting my limited understanding of them.] The number of
>> hours worked seems to be irrelevant to XP-- it can be combined with
>> few or many hours. A manager of a company using XP could very easily
>> turn it into a sweatshop. Or, the employees could do it to
>> themselves-- giving dirty looks to people who leave early.
>>
>> Don't use hours worked as a plus/minus for XP. It's tangential,
>> and irrelevant. Silver bullets are usually tarnished.
>
> Suppose, instead of rescuing those meek programmers from their tyrant
> bosses, or proving XP is good for everything, we instead set a goal of
> "rapidly produce awesome games, and kick our competition's butt."
>
> How would you (plural) target that goal?

You're missing Nathan's point Philip. If XP was a magic bullet, and you
gave it to EA, they'd just double their game output and continue to work
people into the ground. Hours are 'tangential' to software methodology in
EA's case (copyright NM 2004)

WTH

WTH wrote:

> > Suppose, instead of rescuing those meek programmers from their tyrant
> > bosses, or proving XP is good for everything, we instead set a goal of
> > "rapidly produce awesome games, and kick our competition's butt."
> >
> > How would you (plural) target that goal?
>
> You're missing Nathan's point Philip. If XP was a magic bullet, and you
> gave it to EA, they'd just double their game output and continue to work
> people into the ground. Hours are 'tangential' to software methodology in
> EA's case (copyright NM 2004)

Good management, in general, might help EA-style projects.

Pure XP would help too - the practice called variously "40 hour weeks",
"sustainable pace", and "energetic work" forbids chronic overtime.

Whether or not XP is a magic bullet, if EA did XP with chronic overtime then
it wouldn't be XP.

However, some folks see "agile" or "XP", don't read any farther, and then
assume someone thinks they have a magic bullet.

I don't know about EA's management, but managers who can be helped are
advised to read /Slack/ by Tom DeMarco.

--
Phlip
http://industrialxp.org/community/bi...UserInterfaces

In article <7d209056.0411161204.2a46e653@posting.google.com >,
plunket@gmail.com says...
> Paul Sinnett responding to Phlip:
> > > (A studio simultaneously shipping two games generates trade
> > > literature headlines.)
> >
> > I'm not sure where you got this impression. It does happen. (And
> > probably more than you realise precisely because it does not
> > generate trade literature headlines when it does?)
>
> November 2004 issue of Game Developer.

Oh please, that's an article submitted by the developer,
not a news item.

As Game Developer postmortems go, it's a particularly
vacuous one, and reads mostly like an ad for the
developer. (GD really needs to change the format of
the postmortem articles -- many don't contain any
interesting info at all. IMO.)


Christer Ericson
Sony Computer Entertainment, Santa Monica

Nathan,

> The number of hours worked seems to be irrelevant to XP -- it can
> be combined with few or many hours.

That's an odd statement. One of the very first things that attracted me
to XP was its officially recommended practice "Sustainable Pace", which
at the time was named "Forty Hour Week".

It seemed good to me that the method, considered as a contract, should
include such a provision. If I had at some point struck a bargain with
my management that we were going to use XP, then there would be
something in there to cover overtime. Unlike previous occasions, I would
have an early line of defense before it came to "Work harder or we fire
you."

Since then, my position has shifted a bit - in all circumstances I make
my own hours, as appropriate for the situation at hand - but being
encouraged by XP to reason through the issue has been a valuable aid
along the way.

Laurent

Phlip wrote:
> What top three problems would you list? Be brutal - many shops
> grow accustomed to some situations, just as ones eyes grow
> accustomed to the dark.

Okay, my top three would be:

1. Like the music and movie industry, it is now dominated by a few
massive companies that routinely eat up independents or starve
them out of existence by leaving little room for competition.

2. Again, like the big movie and music companies, what they produce
is largely celebrity vehicles, licenses, sequels, and "me too"'s.
And this tripe outsells vastly superior original games.

3. The people management is ridiculous. This means a low quality of
life for developers and a high staff turnover. For huge companies
this is increasingly unsustainable. (As EA is finding out.)

Your responses here are very insightful. I'll just do a bit of
nit picking.

John Roth wrote:
> I suspect that the norm is to use an existing engine to crank out
> mid-level games quickly. It's only the real high end games where
> the intention is to push the state of the art where you really
> want to do wholesale revisions to existing engines.

That was broadly correct a few years ago. However, as the gaming
public started detecting this, game-o-matic engines started to
decline. (At the same time, original games started re-using more
from existing code.) Today, most games are built on at least some
legacy code. Some of that evolved into middleware, some is still
kept proprietary. I don't know of any recent games that where
built from the ground up (although the ground is very well
known at it probably wouldn't take so long if they did!)

> I don't necessarilly think of this as bad. While I've heard of
> XP teams that are larger than about a dozen people, the
> "conventional wisdom" seems to put an upper limit on
> an effective team that is somewhere around that point.
> Beyond that, you need a strategy to coordinate multiple
> teams, or operate in some other fashion.

That's right. And in games they are usually divided by job
category rather than along other lines. There are a number of
reasons for this that have to do with the practicalities of
making games; it's not an arbitrary decision and could not
be split another way without addressing many of those issues.
However, that's probably an article in itself.

> IMO, crunch mode usually comes from not having a production
> quality deployable at frequent intervals throughout the
> development process.

IME that's not the case. Even games teams that are crunching
like mad still produce high quality builds from very early in
the development, right up to the final master. In fact, the
only thing that makes it the final master is that you've run
out of time.

> For me, the question simply comes down to:
>
> "Would you rather be able to ship a bug-free product that's
> missing a couple of levels that you had on the storyboards
> in time for Christmas, or would you rather ship the complete
> game your designers had in mind and miss the Christmas
> shopping window?"
>
> This is simply one of the basic XP questions, with the blanks
> filled in from the game development lexicon.
>
> However, the question only makes sense if the process is
> capable of producing that production quality deployable
> every couple of weeks, with a new level or two, fixes
> for previous levels from the play testers, game engine
> enhancements and so forth.

Broadly speaking, that is what happens. The game you buy in the
shops at Christmas is indeed the planned game minus levels and
so forth.

If you've read the recent EA story, you'll know that it is
fairly common for projects that are on time and within budget
to be crunching like mad for the duration. It's not that they
are trying to catch-up. It's that they are trying to cram in
as much as possible. (The irony being, that by pacing them-
selves, they'd probably get more done anyway!)

> The basic issue is: which feedback loop needs tweaking? The
> only way you tell that is to find the bottlenecks and work on
> them. In this example, it sounds like gameplay engine change
> requests weren't a bottleneck.
>
> On the other hand, they may well have been. I can very
> easily envision a scenario where the engine people were
> being burried under a load of change requests for constants
> that didn't actually do anything. Externalizing that would
> have removed the change request queue.

Yes. The changes were becoming a bottleneck. Or at least, an
annoyance. Once instant feedback was available - that is, you
could make edits while playing the game - it was no longer a
bottleneck. However, the paradox is that without the bottle-
neck, there were no more changes.

It reminds me of when I first tried to write using a WYSIWYG
word processor. I wrote a heading and a couple of paragraphs,
and then spent the next few hours fiddling with fonts and
sizes and layout. Writing then became a constant struggle of
resisting the temptation to fiddle. Now I don't bother. Most
of what I write, I write in plain text.

I'm guessing that my customer felt the same way. Once he had
the ability to fiddle he realized that it just got in the
way of doing any real work; and so stopped doing it.

Your responses here are very insightful. I'll just do a bit of
nit picking.

John Roth wrote:
> I suspect that the norm is to use an existing engine to crank out
> mid-level games quickly. It's only the real high end games where
> the intention is to push the state of the art where you really
> want to do wholesale revisions to existing engines.

That was broadly correct a few years ago. However, as the gaming
public started detecting this, game-o-matic engines started to
decline. (At the same time, original games started re-using more
from existing code.) Today, most games are built on at least some
legacy code. Some of that evolved into middleware, some is still
kept proprietary. I don't know of any recent games that where
built from the ground up (although the ground is very well
known at it probably wouldn't take so long if they did!)

> I don't necessarilly think of this as bad. While I've heard of
> XP teams that are larger than about a dozen people, the
> "conventional wisdom" seems to put an upper limit on
> an effective team that is somewhere around that point.
> Beyond that, you need a strategy to coordinate multiple
> teams, or operate in some other fashion.

That's right. And in games they are usually divided by job
category rather than along other lines. There are a number of
reasons for this that have to do with the practicalities of
making games; it's not an arbitrary decision and could not
be split another way without addressing many of those issues.
However, that's probably an article in itself.

> IMO, crunch mode usually comes from not having a production
> quality deployable at frequent intervals throughout the
> development process.

IME that's not the case. Even games teams that are crunching
like mad still produce high quality builds from very early in
the development, right up to the final master. In fact, the
only thing that makes it the final master is that you've run
out of time.

> For me, the question simply comes down to:
>
> "Would you rather be able to ship a bug-free product that's
> missing a couple of levels that you had on the storyboards
> in time for Christmas, or would you rather ship the complete
> game your designers had in mind and miss the Christmas
> shopping window?"
>
> This is simply one of the basic XP questions, with the blanks
> filled in from the game development lexicon.
>
> However, the question only makes sense if the process is
> capable of producing that production quality deployable
> every couple of weeks, with a new level or two, fixes
> for previous levels from the play testers, game engine
> enhancements and so forth.

Broadly speaking, that is what happens. The game you buy in the
shops at Christmas is indeed the planned game minus levels and
so forth.

If you've read the recent EA story, you'll know that it is
fairly common for projects that are on time and within budget
to be crunching like mad for the duration. It's not that they
are trying to catch-up. It's that they are trying to cram in
as much as possible. (The irony being, that by pacing them-
selves, they'd probably get more done anyway!)

> The basic issue is: which feedback loop needs tweaking? The
> only way you tell that is to find the bottlenecks and work on
> them. In this example, it sounds like gameplay engine change
> requests weren't a bottleneck.
>
> On the other hand, they may well have been. I can very
> easily envision a scenario where the engine people were
> being burried under a load of change requests for constants
> that didn't actually do anything. Externalizing that would
> have removed the change request queue.

Yes. The changes were becoming a bottleneck. Or at least, an
annoyance. Once instant feedback was available - that is, you
could make edits while playing the game - it was no longer a
bottleneck. However, the paradox is that without the bottle-
neck, there were no more changes.

It reminds me of when I first tried to write using a WYSIWYG
word processor. I wrote a heading and a couple of paragraphs,
and then spent the next few hours fiddling with fonts and
sizes and layout. Writing then became a constant struggle of
resisting the temptation to fiddle. Now I don't bother. Most
of what I write, I write in plain text.

I'm guessing that my customer felt the same way. Once he had
the ability to fiddle he realized that it just got in the
way of doing any real work; and so stopped doing it.