GameDevBlog

Two Weeks to the IGDA Leadership Forum

Wow, I can't believe it's almost upon us.

If you haven't signed up yet, it's not too late.

This year we've got:

John Vechey, founder of PopCap!  (And recently featured in Inc. magazine!)

Laura Fryer, GM of WB studios Seattle!

And many more!

And - there's a charity dinner, Friday night, where John Romero, creator of Doom, will interview Will Wright, creator of The Sims.

http://www.igda.org/leadership/

 

Industry Broadcast Redux

Looking for podcasts to listen to with your new iphone? Ryan Wiancko and Industry Broadcast have just rebooted and are putting some of my old Manager In A Strange Land articles up in easy-listening-format...and I agree with at least 80% of the stuff the old me says.

http://www.industrybroadcast.com/

Scheduling Mistake #37

This one's going to be obvious to most people, but I have read a book that says to do the opposite, so:

A lot of the scrum / agile guys advise against splitting your schedule up by resource:  don't have a bunch of "QA" tasks that are estimated separately from your "Designer" tasks that are estimated separately from your "Coder" tasks, and are all tracked independently, because that creates an us-against-them mindset.  "We desinger types are done with our responsibilities, it's you coder types that are holding us back."  It should be one-for-all, all-for-one: if you're falling behind, your designers and QA guys and whatnot should find ways to help in whatever way they can, even if it's just getting coffee for and giving back massages to those poor coders.  *Agile Estimating And Planning* is one book that recommends this practice.

"Man, that's beautiful," I thought, when I read this.  And that's how I scheduled Schizoid, lumping the art tasks and the code tasks and the music tasks into one big pile.  Of course, in reality, there's no way James Chao, once he was done making his beautiful art, was going to help me fix network play bugs.  Even if he did want to roll up his sleeves and start programming.  (Or get me coffee and give me back massages.)

So, for games anyway, don't do that!  Typically what we do - Schizoid being the exception - is schedule in a matrix that looks something like this:

Code Art Design

Main Menu 2 5 0

Eyeball Enemy 5 8 3

We're still using a lot of techniques from *Agile Estimating* - such planning poker, fibonacci-size numbers, estimation in generic work-units instead of days, and a serious aversion to Gantt charts.  But the result we end up with gives us a better idea of how many coders vs. artists we need, and let's us track velocity separately.

But is tracking velocity separately a good thing?  Some would say it divides the team.  (And there's often a rift between coders and artists to begin with.)  But it's probably worth knowing whether art or code is behind and by how much, so you can adjust staff and cut features accordingly!  At least you're not singling out individuals.

Interestingly, Clinton Keith told me recently that he now works specialization into his agile consulting and training.  I wonder how his approach works?

Risk Vs. Risk

Although I have no spare minutes these days I am going to dash off this thought quickly:

Your project usually has one big fat risk, right, which is - will we finish all this crap on time and be able to ship something and keep our agreement with our publisher and get our milestone payments and keep our company in business and hopefully turn a profit for our publisher and ourselves?

And then there usually some other big risks, like:  Will we be able to get network play working?  Will this game mechanic or mode actually be fun?

The agile manifesto would say that you should deal with that first big risk by getting your project to release quality early and often.  Make something you could ship - then decide if you want to add stuff to it.

But with things like 'network play' and 'fun' - if you push towards something barely shippable (hey, it passes all of TCR and doesn't crash!) - and then decide, "Yeah, it really needs network play" - you may be somewhat screwed.  Network play is something usually worth doing first, because it brings with it a host of engineering decisions that have ramifications everywhere.  It's really hard to take a single-player game and add network play;  it's much easier to take a network game and make a single-player mode.  (Other things like 'save anywhere' have similar ramifications.)  I think there may have been more than one retail game that came out in the past couple of years that were originally intended to have network play, used somewhat agile development methodologies, where the team then realized that network play would be very expensive to retrofit in.

What's the right answer?  I don't think there's a rule-of-thumb for this.  In fact, I think this is a place where rules of thumb break down.  The agile "Get it to shippable as soon as possible" may not work;  likewise, "always mitigate risks" or "get multiplayer done first" might be wrong if your game is pretty darn fun single player.

Quick Follow Up On IGDA Leadership Forum

Ok, I'm a bad guy, I said I'd write more about the forum and didn't.  I'll just quickly lay down what were highlights for me and you can dig them up yourself - the talks I saw that I dug the most were the ones by:

- Chris Hecker (as I mentioned)

- David Edery

- Kane Minkus

- Scott Crabtree

- Chris Satchell

Because I just can't seem to find a spare minute to blog anymore.

IGDA Leadership Forum Almost Upon Us

When I was first promoted to management, back at Mindcraft Software, I thought to myself, "Finally!  Now we can start doing this project right."

Nevermind that I was 26 and didn't know the first thing about management, having never managed anything ever...I'd never taken a seminar, never even read a single book on the subject.  All I managed to do was piss other people on the team off before the company fortunately went bankrupt, saving me from the embarrassment of not having shipped anything when I was supposed to.

If only the IGDA Leadership Forum was available then.  I don't know if I could have talked my boss into sending me, but it's a lot cheaper than DICE ($350 if you're an IGDA member and you get the early rate, available until September 9th) and it's a great opportunity both to attend lectures on beginning and advanced topics in managing game development and to--perhaps more importantly?--just talk to other managers about how they handle things.  Something I've found over the last two years is we tend to have a lot of the same problems...maybe not all families are unhappy differently after all...

Mindcraft would still have gone bankrupt but my career might have turned out differently.  It was many years before someone trusted me with management responsibilities again.

And - if you're a project manager or an executive - send your leads.  Particularly if they're green.  If I had a dime for every time I saw somone promoted to management with no training who then had to be fired or demoted back to rank-and-file, I'd have a couple bucks by now.

I realize it's tough in a recession year, but the cost is paltry compared to the salaries you're paying these people, and the benefits...

Hell, if you don't send them to the Leadership Forum, at least send them to something.  Get them some trianing of some kind.

Here's the info:  http://www.igda.org/leadership/

Clarification: Quatloos vs. Man-Days

Couple questions answered about the last post:

Quatloo is from Star Trek: TOS, "The Masters of Triskelion" later parodied on the Simpsons when Burns bets quatloos on the newcomer.  Not intended to be pejorative:  I still measure projects in quatloos myself (well, "Torpex Work Units", I call them), multiplying by various fudge factors to try and get a date and budget.

When I say scrum doesn't measure velocity in quatloos, that's from Cohn's *Agile Estimating And Planning* - they measure the whole project, or the release burndown, in story points, but each sprint they re-estimate the tasks in man-days, and that's what they track velocity in.  Double checking:  yes, it's in Schwaber's book too:  the project backlog burndown chart uses coarse-grained estimates multiplied by a fudge-factor, then each sprint re-estimates. 

Looking it up, I just noticed Schwaber does suggest using the project burndown chart to estimate when the project will complete (p. 11 of Agile Project Management With Scrum), so it is the quatloo-velocity that really matters to him too, it seems.  But that's the velocity that I find flattens out over time.

And...I don't know what to say about Gregg's experience.  I'm jealous, and maybe should go work with him.

'Theory of Drag' detractors

I've been thinking about the kind of people who disagree with the 'theory of drag' - the idea that as a project progresses your velocity slows down, the 'pushing a snowball up a hill' metaphor - and wondering what their beef is when it's, well, so obviously true. 

I've rarely met these people in person, though I do have anonymous feedback from talks I've given - but I have a couple of theories about who these people might be.  

One is the 'go team!' producer.  I heard a producer say the other day that the primary number-one job of a producer is to make the team feel like they can ship.  Keep the morale up.  "We can do this!  Go team!"

The 'theory of drag'...which, summed up, says 'Your project is more screwed than you think it is' isn't what that kind of producer wants to hear, or spread to the rest of the team.  

I don't know if that sort of producer is as wrong as they sound.  An optimistic, happy team will be more productive than a "we're doomed!" team.  Like JFK saying we would put a man on the moon within the decade:  you can galvanize a team that way.  

But the ideal is to embrace "the Stockdale paradox" from Good to Great:  always have faith that you're going to make it while simultaneously being able to confront the brutal facts of your current situation.  And someone embracing the stockdale paradox would want to always keep drag in mind.

Another kind of detractor is the scrum guy.  I was talking to a scrum expert, and I told them that in my experience velocity always decreases as a project goes along, and they said, "Really?  In my experience, velocity always increases, as the team gets more used to their tools and technology."

Frankly, I think it isn't becuase they're mastering their tech--seriously, in my experience the gains from mastering tech are always buried by feature creep and the drag from project bloat--but because scrum has some dishonesty built into the scrum process.  When doing scrum, you have the project backlog for the entire release, which is estimated in arbitrary time units...let's call them quatloos.  And each sprint, when a team commits to the work they'll do for the sprint, they more rigorously estimate the tasks they're about to undertake, in man-hours or man-days.  The thing is, scrum guys measure their velocity in terms of these man-hours or days that they re-estimate every month, so what I think is happening is this.

Sprint 1:  team takes on a chunk of work.  It takes a little longer than expected.  Their velocity comes out at, say, .9.

Sprint 2:  team consciously takes on a smaller chunk of work.  Because of drag, it takes a little longer than expected, but because it's a smaller chunk, their velocity appears to go up to say .95.

Sprint 3:  team consicously takes on a still smaller chunk of work.  Etcetera.

I think you'd find if you looked at the velocity in quatloos, you'd find it was continually decreasing, as they both got fewer quatloos done due to drag and added more quatloos to the project due to feature creep.  They're committing to fewer quatloos every sprint.

Measuring a project in quatloos obviously sucks, because it's so damn hard to predict how long a feature is going to take a year down the road, and that's part of the reason drag increases near the end of a project.  But I think if you want to be honest about your velocity it's the only option.  Also, if you're a contractor who needs to promise a certain feature set by a certain date, it's all that really matters.  You can't go to your client or publisher and say, "Well, we've gotten to the last sprint and discovered that we can't commit to all the backlog we originally promised.  Sorry, but we're doing scrum, so that's how it goes."

Instead, if you measure every project in quatloos, although those first couple of projects may shock you with the massive amounts of drag you experience, after a while you'll start to expect it and be able to bid accurately on contracts - and cheesy rules of thumb like "try to be 90% done 50% of the way through the project"--in other words, get 90% of those quatloos done at the halfway point--may save your ass.

And if you haven't seen my posts on the theory, here they are plus.

Folder Hierarchies

One of the guys on our project wanted to change the way sound folders are organized, and I realized I have fairly strong feelings about the subject.  Most of this is just curmudgeonly ranting, it is not Truth, but still:

My experience is keeping folder hierarchies flattish cuts down on minor daily annoyances, both with source control and navigating: say you’re editing the raw content data in one folder, then you go to save, so you have to click up, up, then down, down to get to the proper destination directory;  whereas scrolling through a long list of files usually just requires a keypress or three.

To make this work, when using Explorer, everyone will want to do View->Details, otherwise sure, the screenfuls of icons would be overwhelming.

Keeping the raw content separate from the cooked (content you're actually going to ship in the distribution) is important, to simplify not just the authoring/final build process but the process of giving publishers, associates, marketers builds.

One idea that occurs to people frequently is to use the directory structure to describe the files.  So instead of zombieAttack.qrx and zombieIdle.qrx you'd have a \zombie folder that contains Attack.qrx and Idle.qrx.  This is appealing at first but it's nice to know if you've accidentally dragged the zombie attack sound into the yeti folder.  And if the code can assume that every sound name is unique that can gives you an advantage - you can use the asset name as a unique ID.  (I don't believe there's any reason any more to have an asset manager that builds .h files with asset codes baked into them - maybe I'll post on how we get around that someday.)

It's not *that* hard to rearrange your hierarchy later (though source control can make it harder) so don't fix a theoretical problem now ("This might get messy");  wait for it to become an actual problem.  

When would I start subdividing a folder?  When it hits around 500 files, or when all of the files of a subcategory no longer fit in a couple of pagedowns.  That is, once you've got enough zombie_xxx files that it isn't just a keypress to find the one you want.

One last thing:  I don't use spaces in file and folder names, I use underscores or intercaps.  Using the command line to do things with files has become vanishingly rare, but typing in those quotes to find a file with a space in the name is still annoying on those rare cases where I need to do it.

Curmudgeonly ranting over.

Industry Broadcast Hits 50

Industry Broadcast, the podcast for the games industry, has hit 50 articles at this point - about 16 hours of industry wisdom.  That means if you have a half-hour commute you'll soak it up in about 3 business weeks.  I'm in there, as I've mentioned before, and lately they've got guys like Noel Llopis and Soren Johnson, both bloggers I like to read.  Pretty cool.

http://www.industrybroadcast.com/