[MUD-Dev] CGDC dinner
Koster
Koster
Thu Mar 16 11:14:57 CET 2000
> -----Original Message-----
> From: J C Lawrence [mailto:claw at kanga.nu]
> Sent: Wednesday, March 15, 2000 8:46 PM
> To: mud-dev at kanga.nu
> Subject: Re: [MUD-Dev] CGDC dinner
>
>
> On Sat, 11 Mar 2000 22:14:02 -0800
> Joe Andrieu <joe at andrieu.net> wrote:
>
> >> [J C Lawrence]
>
> >> -- The various levels of bandwidth consumption among the
> >> commercial games, and what trade-offs were made to get there
> >> (mostly in terms of what is dynamically streamed from the server,
> >> and what is stored statically on the client-side).
>
> > Wow. I missed that. What are the levels of bandwidth on these
> > systems? I've always wondered...
>
> It wasn't a long discussion, more a passing commentary by Raph in
> the discussion of streaming world contet (the talk ranged so widely
> it was tough to spend much time, or depth, on anything in
> particular).
>
> Perhaps Raph could chime back in?
Well, EQ shows you their bandwidth usage per player while you are playing,
so you can do some math on that front. It's around 1K per user per second.
At peak times, they get over 50,000 simultaneous users. EQ however relies,
as does UO, on a very static map which is looked up on the client side.
(UO's bandwidth usage is less than half that btw, partly as a result of the
movement system and partly as a result of the camera perspective). AC has
technology to stream the whole map on the fly, but in practice doesn't do
that most of the time. Their bandwidth usage appears to be a bit more
efficient than EQ's overall. We talked about streaming the UO map at one
point; it would have doubled our bandwidth usage, which then would have had
significant effect on the game's profit margin.
AC seems to have the best technology platform of the big three right now, in
that they have nifty stuff like dynamic load balancing, map streaming, etc.
The single biggest variable cost for running one of these sorts of massive
games is the bandwidth. You pay for all of it. You therefore struggle to
*reduce* the average hours played per session, whilst still offering enough
gameplay to persuade people to come back and keep paying month after month.
This is contrary to the classic approach, which desires the high usage
numbers for the sake of hourly fees or (in the case of non-profit muds)
addiction. Current numbers for UO and apparently also for EQ are way up
there: average player spends 20 hours a week online (UO's is actually a
little bit higher).
This leads to a game design challenge. For example, knowing that now, I
never would have done a use-based system for skill advancement in UO. It
encourages remaining online. My ideal customer is one who keeps paying but
doesn't actually log in. Not a normal mindset for a game designer--usually
we want people to actually PLAY after all. :)
At the same time, the best tactic for accomplishing a reduction is to stream
as little as possible, as infrequently as possible. This leads to lots of
problems, including the fact that static data sucks--it's easily
reverse-engineered, mapped, documented, distributed, and beaten, plus it
takes a long time to generate versus how long it takes for players to
accomplish the above; and the fact that there are thresholds below which you
cannot go without incurring choppiness or other artifacts resulting from
lack of information.
-Raph
_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
http://www.kanga.nu/lists/listinfo/mud-dev
More information about the mud-dev-archive
mailing list