[MUD-Dev] Bay Area Press re: UO, the good the bad and the Ugly.

[Dave Rickey]

-----Original Message-----
From: Raph Koster <rkoster at austin.rr.com>
To: mud-dev at kanga.nu <mud-dev at kanga.nu>
Date: Saturday, June 03, 2000 10:21 PM
Subject: RE: [MUD-Dev] Bay Area Press re: UO, the good the bad and the Ugly.


>
>Consider leaving in your time-consuming mechanics, as above, but put in
>other mechanics and forms of play that do not require time. For example,
>allow offline mass production for crafting skills, or ways of doing guild
>management via a website, etc. These will tend to drive down your average
>while leaving all the other mechanics intact and able to addict. Some
>players will play for these other mechanics exclusively, and even the
>addicted players will likely use them to some extent, reducing the time
>spent online. Some play sessions will consist entirely of doing these brief
>activities.

    Consider leaving out your time-wasting mechanics completely.  I see no
purpose in designing a game that is flat-rated, but designed to make the
player spend 3/4+ of his time doing *absolutely nothing*.  Nothing he really
cares about, anyway.  My opinion on macroing in games is simply this: If a
major portion of your gameplay is so repetitive it can be performed by
simply looping the same mouse-clicks over and over, you already screwed up.

    At least combat, although repetitive, is fun.  Churning out thousands of
worthless items, or holding your place in line for your chance to get the
Sword of Lambada, is *not* fun.  Deliberately including things that are not
fun in your game is stupid.
>
>All of those things could be done without actually reducing hours per
>week--in fact, the availability of half-huor quickie things to do in the
>game might well push UP the hours per week.

    I agree.  Timewasters are generally one or more of three things:
Leftover tricks from when the idea was to maximize the hours played by any
means possible because fees were hourly, a way to *keep* the players from
doing fun things because your system can't handle all of them doing the fun
things at the same time, or a sign of failure of imagination on the part of
a designer.


>>     Anyway, it's eventually going to be a moot point.  The amount of
>> physical hardware and consistant bandwidth needed to run one of
>> these games
>> is not going to rise nearly as fast as the cost of that equipment and
>> bandwidth is going to drop.  Right now those costs eat up the lion's
share
>> of subscription fees, in 10 years they'll be trivial.
>
>Demand for bandwidth worldwide, last I heard, was rising a lot faster than
>physical infrastructure construction. This would, eventually, lead to
higher
>costs for bandwidth (likely not to the end user but to people higher up the
>chain). Anyone have recent figures on this?

    They've been predicting a bandwidth crisis within 3-6 months on the
basis of those figures since '94, probably earlier (many old Usenet hands
were similarly blase about the doom-crying then).  The reason it has never
happened is simple: The figures for "planned infrastructure construction"
are so much bull.  *No* major NAP wants their competition to know just how
much new capacity they're really going to have, so they announce only *new*
trunks, and never say anything at all about upgrades to old ones, or the
emergency capacity they keep in reserve.  And peer-to-peer ISP links carry
nearly as much of the network traffic as the backbones, and those aren't
counted at all.

    The resulting analysis is trotted out as proof we're going to have
metered bandwidth "Real Soon Now" every few months.  Recently the rise of
Cable and DSL with their huge internal cross-country pipelines has been even
more of a factor, we've actually got more excess capacity right now than
we've ever had before, and that statement has been true for the last 6 years
at least.
>
>>     I once calculated that EQ's bandwidth costs could have been cut by
>> 2/3...by halving the population per server and running twice as many.
>
>It could be cut by 2/3 by just sending less needless data, I suspect. :)
>
    Yeah, the client prediction and network code could be a hell of a lot
better integrated, a lot of bandwidth is wasted making up for the
shortcomings there.  When you look at how much Tribes keeps track of with
<1/10th of a second tolerances, and compare it to either UO or EQ, it's
pretty sobering.  But halving the population would also reduce camping time
by at least an equivalent factor, which would be a good thing in itself,
IMHO.

--Dave Rickey




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