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

[Mike Sellers]

At 03:16 PM 2/13/98 PST8PDT, coder at ibm.net wrote:
>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.
>
>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.

We originally planned to do this with M59, but dropped it due to programmer
and artist constraints.  The idea works well with a class hierarchy: every
chest is rendered first as a box, every throne as a chair, every monster as
a vaguely threatening blob or a humanoid or quadruped, etc.  The higher up
the class hierarchy you have to go to get a local model, the looser the
correspondence will be between what the user sees at first and the actual
item.  Then, if necessary, you can download the needed gfx during times of
lower bandwidth usage (e.g. chatting) so they're around when/if the user
sees that entity again.  

>>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?

I had a fascinating discussion with a guy from Intel recently.  Roughly,
their plans (consider how much advance foundry planning alone they have to
do) say that this Christmas the almost-highest-end consumer machine will be
a 300MHz Pentium II (really high end is probably a 400 or 450 or so).
Christmas 1999, probably a 450, with 800s mixed in at the very top end.
End of the year 2000 you're looking at 800s, 2001 probably 1G to 1.2GHz
machines.  Somewhere between 2000 and 2003 they go to copper-based chips
which give another burst of speed (with a simultaneous drop in power, heat,
and size), and around 2015 or so they go straight to laser-based optical
chips -- at which point we basically have no clue what computing or
computer usage will look like.  

So: if you're starting on a large project today that is expecting to ship
for Christmas of 1999 (less than a 24-month cycle), well... you probably
can't buy the equivalent target consumer machine yet.  Oh, and it's easy to
scoff at these numbers, but if you look backwards, these are completely in
line with the physics, marketing, and overall realities of computer speeds
-- Moore's Law still rules. :)  


--

Mike Sellers   Chief Alchemist -- Online Alchemy   mike at online-alchemy.com

"One of the most difficult tasks men can perform, however much others 
may despise it, is the invention of good games.  And it cannot be done 
by men out of touch with their instinctive values."  - Carl Jung