GameDevBlog

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?

Too Much Randomness?

I should have mentioned that the Bejeweled Blitz leaderboards are reset weekly;  so the fact that PopCap guys are at the top of my list is not because they played a lot back in the day and once got a really good score - it's because they get really good scores every week.  So while they may play more each week than you or me (hey, it's their job, after all) it's still pretty impressive.  (Others think they must be cheating - to which I say, "Think that if you want.  Whatever helps you sleep at night.")

Still, Jeremy argues that they're too random, and the very fact that he perceives the randomness to outweigh his skill, that he doesn't think it's worth investing his time, may go to show that they overdid it...or maybe it just goes to show that you can't please everybody...

Permanent leaderboards, by the way, are not a good thing.  Not for the longevity of a game, anyway - right away, some awesome player will stake out some awesome score and 99.9% of other players will decide it's not even worth competing.  Even if it's just a friends list competition - the deltas between friends are high enough to drive people away.

Notes on Bejeweled Blitz

I'm not the biggest fan of plain old ordinary Bejeweled, but if you take Bejeweled and:

- shorten the session length to 1 minute

- add friends leaderboards

- add a somewhat random incidence of score multipliers

then you've found my digital crack.

Friends' leaderboards are obviously compelling - but what about those other two things?  Are they obvious?

First - session length.  If you like a game, wouldn't a longer session be better?  Nope.  All other things being equal, a shorter session length is better than a longer one.  If you like the game, you can always play it again, and the lower your time commitment, the more likely you're going to re-up.  So go ahead, take your game, make it shorter, see what happens.  You'll probably find that you have balance issues - those 'guns vs. butter' decisions you were making early on thrown out of whack.  But that can be fixed, and the tighter game loop is probably worth it.

So why did it need random multiplier gems?  I've heard hardcore guys say it takes the skill out of the game, if a n00b can rack up a 150000 point score just from a lucky draw - and people who invest more time are more likely to get the big payouts, so don't multiplier gems wreck the game?  Nope.  I'm more or less quoting Richard Garfield here:  "Everyone says they want their games to be less random, but nobody really does."  Paraphrasing, rookies want to be able to win occasionally, otherwise they won't play, and the skilled players will have nobody to play against.  (Also, a lot of players who think they're skilled aren't as good as they think - a highly variant game lets those players feel like a badass when a less variant game like chess might throw their actual lack of skill into stark relief.)

And there's another thing going on with the multiplier gems and that's a slot-machine schedule of reinforcement.  For a tiny investment (one minute of your time) you might get that big payout.  Behaviors that are reinforced intermittently are resistant to being extinguished - check that out, I did learn something with my psych major.

When I find myself drawn back to Blitz, I feel about like those wirehead laboratory rats of legend, the ones who would continually pull the lever to get the electrical stimulus until they starved.  It makes one ask if maybe Blitz is a bit unethical - are we being manipulated by PopCap?  All I can say is that since guys who work at Popcap are continually at the top of my leaderboards, at least they're drinking the kool aid too.

And the fact that the PopCap guys are always at the top shows that there is still skill involved, despite the variance.  It's hard to put that skill into words - the ability to see the matches is paramount, and that seems to be something you can only learn by practice.  There are also strategies, to be sure, but most of the strategies seem to be less important than just being able to make a lot of fast matches.

Is GameFly Really Worth It?

I tend to have GameFly games out for a while.  I wondered to myself - is this really worth it?  If I just bought used games, would I not only spend about the same amount of money but also get to keep the games?

Turns out GameFly lets you look at your rental history.  So I did.  Turns out, for games I actually finish, I tend to have them out 4-5 weeks.  So that's a cost of $16-$20 or so in Gamefly time.  These are games that are still fairly recent releases, that I could buy for around $35.  

Factor in that some games I discover I hate and return immediately, and the savings goes up considerably.

And although sometimes I like to have the games for my collection, the truth is I almost never, never, ever go back and play those games again.  So there is just about zero value to me to keep the games.  

So.  Yes.  GameFly really is worth it.  And no, they didn't pay me to write this.

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.