[MUD-Dev] Retention without Addiction?

[Daniel.Harman at barclayscapital.com]

Brian Hook wrote
> Daniel Harman wrote

>> I've always partly attributed Blizzard's success to only
>> releasing a game when its thoroughly polished. ... The 'its ready
>> when its ready' philosophy seems to lie behind a lot of the great
>> games. Is it possible with MMORPG style budgets?

> Okay, small aside, but this just isn't true as a general rule.  A
> very small handful of companies regularly release games
> astronomically late and still have them not suck.  Blizzard is one
> of them.  id software is another -- although they traditionally
> have had some insanely short development cycles compared to the
> industry at large (DOOM3 is taking the longest, by far, of any
> game in their history).

> "it's ready when it's ready" is 99% of the time a euphemism for
> "we're clueless, poorly managed, and have no idea what we're
> doing, but thankfully we have enough money to keep muddling
> along".  It's possible to suffer from the latter and still deliver
> a great game if you have the time to keep trying new stuff until
> you stumble on something great.

I agree that in general, most games that slip are on a death
spiral. My point was more about the exceptional few that slip and
are all the better for it. It just seems that a high percentage of
the all time greats have suffered from monumental slippage.

Of course I suppose its fair to say that a high percentage of the
all time worst games have also suffered monumental slippage.

> Network code evolves significantly for each order of magnitude of
> player base you have to support.  The code required for 1-vs-1
> changes a lot when scaled to 10 players.  Then it changes again at
> 100 players, then that changes again at 1000 and then 10000
> players. Blizzard has really good code for managing lobbies and
> for managing games of small amounts of people, but that knowledge
> is difficult to leverage into something that works fine for 1000
> simultaneous players.

> I'm not saying it's particularly difficult, just that it's not
> like you can just #define MAX_PLAYERS 10000, recompile, and go.
> Quake3 style networking absolutely doesn't scale to 1000 players.

Absolutely, but Quake3's network protocol was both pretty inspired
and unobvious. Frankly you aren't likely to stumble onto that type
of design without first trying the superficially simpler and
actually more scalable alternatives.

Don't get me wrong, I'm not saying that writing these things is
easy, but its not so difficult that only a veteran could do it. If
you look at the packet structure etc. used by EQ, its hardly an
elaborate scheme, although perhaps there is some wonderfully elegant
code for serialising it etc. which I've never seen not being privvy
to the source (I've just looked through the SEQ source to see how it
worked).

>> If its in balancing gameplay dynamics, I'd argue they are
>> experts. Warcraft, Starcraft and Diablo all show that they are
>> really pretty good at balancing diverse ability sets and creating
>> an interesting and rewarding game.

> But once again, different styles of play with different
> expectations.  They seem to have really good designers, but in the
> end, it's still a different game with different
> expectations. Making a great single player or limited multiplayer
> game doesn't necessarily scale to larger numbers of players or new
> genres.

Absolutely, I just don't think they are as likely to fail as the
original post postulated, and I'm fairly confident that they won't
release it until its good.

Apologies for coming across as a Blizzard fanboy!

Dan
_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev