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.

Comments

[Drealmer]

I think the development effort that goes into multiplayer for games that would be just fine without is out of proportion. I don't remember where I've read this, but it seems that the amount of players who don't even try going online with most games they buy is rather large.

[Fargo]

I'm of two minds about this. On the one hand I've played some great single player only games, on the other hand some of those games would only benefit from some form of multi. On the gripping hand I've played some games that had multi shoved in later where it didn't add any value because it was either broken or designed only in the loosest of ways.

I will say that multiplayer games are a big deal for me, but not the random online match kind of play. Almost all of the games I play regularly I play to keep in touch with my friends that live far far away. It beats the hell out of a phone call.

[Rusty Shackleford]

When I read something like this, I can't help but think you're doing it wrong.

Agile principles suggest that even in your first iterations, you should have something that acts like (as closely as possible) the final product.

If you can't "fit something in" yet, that doesn't mean you chop it off and pretend it's not part of the product you're making. If you can't at least give it a naive implementation, you could fake it out.

[allangering]

I want to say i have played some games that had multi shoved in later where it didn't add any value because it was either broken or designed only in the loosest of ways.
_________________

Michael Jackson Game

[Clinton Keith]

"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."

I think you could say the same for a number of games regardless of the methodology. When your game enters an alpha state with everything at 90% and you only have 2 months left, then schedule and risk often determines what is shipped, not value to the product.

Managing risk is one of the things that determines prioritization of the backlog. You, the smart CTO have to tell the PO (maybe you're the same, which means you're talking to yourself) and say: "Hey PO! If you want online, we better do some work earlier than later because retrofitting network code into a game is a big hassle!"

I wrote a lot more about this subject here:
http://tinyurl.com/yg3cs75

Clint

[Keith]

Thanks for the post.
http://www.rapidsharemix.com