[MUD-Dev] Retention without Addiction?

[Koster]

From: bradley newton haug
> Raph Wrote:
 
>> At MMORPG scales, it is. Harder than 4-16 players games,
>> certainly. Harder than 250-player games too.
 
> Again with the arm-waving declaration about how hard a MMOG server
> is.  Are you trying to warn people off, or are you really under
> the impression this is some holy grail.  If you still think this
> is a 'difficult new thing', I suggest you hire some more network
> engineers and fewer designers.

I feel ornery. What's with people misreading me lately? I try to
choose words somewhat carefully. I stated it was "harder." Not that
it was "some holy grail." Not even that it was "hard." Just
"harder."

It's not *new.* Outside of games it has been done many, many
times. Within games, it has been done several times (not many,
though). It is undeniably harder than a mud server to handle 250
players, which is also undeniably harder than a 4-32 player game.

To a company that has never done it before, it is also a difficult
obstacle.  A robust multiserver implementation that is scaleable and
easily managed in a live environment is easily several months of
work in an area that the company likely has no prior
expertise. There's not much to buy off the shelf yet, and while
there are plenty of resources to go looking for outside of the
industry there aren't many that apply directly to the specific
problem--what's more, often the architecture must vary depending on
the game design. At the very lest, I would not want to attempt it
without staff who has at least worked on a mature platform of the
kind, if not someone who has previously architected one from start
to finish and deployed it.

So I'll make the statement more clearly: for a company that has only
made 32 player games, jumping to sustaining 1500-3500 is, yes,
HARD. Not impossible.  Just hard.

> Now I'm not saying this is the case, but whenever I see marketing
> or sales personnel in the retail shrink-wrap industry waving their
> hands and saying how hard something is, there is usually a team of
> 'engineers' in some dark room somewhere that are regarded as
> 'beyond reproach', and 'unfathomably brilliant' doing work no one
> could have possibly come up with or done better than.  When in
> truth, it's just because they are having a hard go of it.  I ran
> into a lot of this when I worked at Microsoft.

I am not a marketer or salesperson in the retail shrink-wrap
industry.

Someone like that is who I would expect to think that a company that
has never made a massively multiplayer online world before can do it
with ease simply because they have made successful single-player or
small-scale multiplayer titles. Well, now that we've watched
companies that have that sort of track record, billion-dollar
companies, in fact the dominant companies in the industry, fail not
once, not twice, but up to three times in a row WHILE having such
expertise in-house, I would have hoped that that sort of naivete had
evaporated.

> It's code, it's network, it's a state sync machine, I'd wager a
> guess every single algo I've used in my engine has been used
> before.

Sure. You can generally find a solution for any given technical
problem somewhere out there in the world. That doesn't mean you even
have enough understanding of the problem to know how to use the
tool.

>> Yep, and that only leaves persistent economies, customer service,
>> ongoing content addition, ongoing forms of narrative, and
>> multiple playstyle support as tough nuts they haven't cracked.
 
> Agreed, none of these have been done correctly, on either the
> code, or design level.

My point is more that any company that has not done this before
doesn't even know how to do it incorrectly. Do not understimate the
learning curve here.  Again, I say this with utmost repsect towards
all my friends and colleagues at Blizzard. I happen to believe they
are smart enough to know that they don't know anything, and I
certainly hope they are approaching the problems with the
appropriate attitude.

>> Trust me, to developers used to single-player or even hybrid
>> retail-and-Net-play games, creating and running a persistent
>> world game is a whole new ballgame, easily ten times harder.
 
> Now here I'm getting confused, is it hard to design, or is it hard
> to code.  There is a big difference.  Example of hard to design,
> easy to code: " in game language".  Example of hard to code, easy
> to design, "Player Economy System".

"Yes."

It is an alien mode of thinking to single-player or even multiplayer
designers.

It is a new level of bulletproofing and engineering for
single-player game programmers.

And you left out "running the game" which is easily 90% of the REAL
problem; leaving out this piece is the biggest reason why new online
world developers fail.

> What is your definition of 'developer' is that a guy that writes
> documents that engineers have to turn into reality or is that a
> code-slinger?

I am so used to more collaborative teams than that, that your
question makes no sense to me. :) All of them are developers, of
course. And the dev who just writes docs with no awareness of the
broader issues is doomed to fail.  The code-slinger who writes the
code with no awareness of the broader issues is also doomed to
fail. Unless you've got a hell of aproject manager who can keep
everyone in synch. But with games this big, it's getting to be
impossible for one person to keep it all in their heads.

-Raph

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