[MUD-Dev] 3D graphics (Was: The impact of the web on muds)

[coder at ibm.net]

On 27/01/98 at 12:28 AM, Caliban Tiresias Darklock <caliban at darklock.com>
said:

>You could always just have the user download any new models as soon as he
>connects, and send animation sequences in some coded method... for
>example, you might have a model of a warrior who swings his sword around.
>You could time-stamp the model and the animation sequences, and have the
>user download them (in the background, ideally) when first connecting to
>the game. When the user encounters the new creature, the model is loaded
>locally. There could also be a 'generic' model, say a greyish-white
>humanoid, which would be used for anything the user hasn't downloaded.
>When the user encounters such a creature, the client would display the
>generic model while the real model and its animation frames downloaded.
>Any errors in description and action (the generic model swings a sword
>while the client reports the bear clawing at you) would be temporary, and
>more amusing than disturbing.

ie Just-In-Time graphics with strong acceptant for latency...  <<Me
smelleth an acronym under there>>  Not a bad idea at all.  You essentially
convert the client side into a partial and unverifiable DB repository of
the world as that client has seen it -- which contains nothing that client
has never seen.  it solves many of the update problems (not all alas),
removes the requirement for multi-hundred Meg mass D/L's etc.

The idea that the more you play the better the game will appear, and the
more responsive (less bandwidth dedicated to DB updates) it will be is a
curious one, especially its effects on adaptive behaviour on the player
side:

  > say I bet Boffo has never seen XXX.
  Ok.
  > go XXX
  You go to the XXX.
  > summon Boffo
  Boffo is here.
  > kill boffo
  Boffo is dead.
  > say Boffo's bandwidth was tied up downloading the images etc for XXX, 
    which made his reactions slower and gave me the advantage during 
    the fight.
  Ok.

Of course you could turn off such updates during critical periods, but the
domain of such critical periods is both large and difficult to define.  It
is also fairly easy to envision instances where the real graphics provide
the key to resolving the critical period -- make their bandwidth expense
during that time valid.

>Yes, it would devastate the competition if you did
>everything fantastically, and the world would fall at your feet, but you
>have to be realistic.

On this list?

>Another thing to consider, a bit of wisdom from John Carmack of id
>software: when designing a game, design for the system that will be the
>norm at release time, not the norm now. The industry will advance, and
>ideally your game will effectively use the things that people will expect
>from their hardware *then*. Which means right now, we need bigger and
>faster machines than most people have, and we have to imagine that these
>willl be the norm later.

So y'all are going to be sporting 1GigHz DEC Alpha's in a year or two eh?

--
J C Lawrence                               Internet: claw at null.net
----------(*)                              Internet: coder at ibm.net
...Honourary Member of Clan McFud -- Teamer's Avenging Monolith...