[MUD-Dev] Graphic MUDS/Ultima Online

Adam Wiggins nightfall at user2.inficad.com
Thu Jul 31 12:03:43 New Zealand Standard Time 1997


> On Wednesday, July 30, 1997 3:06 AM, Adam 
> Wiggins[SMTP:nightfall at user1.inficad.com] wrote:
> > Hell yeah.  My job is to write 'normal' (graphical) computer games, 
> > I am constantly frustrated by how much art holds us back from doing
> > what we really want to do.
> 
> This IS changing, though. Computer power keeps going up, and pretty 
> soon 3d hardware acceleration will be standard. If we get clever about 
> dynamic meshes and the like, we can do quite a lot with that.

Well true - I think realtime 3D is the only way to ever have as extensible
of a world as I'm envisioning, but my original comment was actually
referring to more static art.  Ie, I code this big spell system, then the
art department spends a month trying to figure out how to make all the
effects look halfway impressive and also what they are supposed to look
like.  Of course this probably also has something to do with us being
a smaller company with far less resources and art talent availible than
someone like Origin.  Still, it's as Jeff said - programmer art just
doesn't cut it anymore, which is going to limit what you can do.
Even the realtime 3d stuff can be limiting - I can't program combat maneuver
X until I have animation for the player character doing the move, and
animation for all the monsters responding to it...'tis a bit more complex
than message("%n dives to the side...").

> I hadn't ever thought of regarding equipment limits as a way of saving 
> game state. It is, of course. But naturally it has so many limitations 
> and issues with it that it doesn't really address the underlying 
> reasons to save game state in any significant way...

Possibly, but I think it is pretty signifigant.  In fact, it was one
of the things which made me start to think about world-state on a broader
scale to begin with.  My first mud was a MUX, and I wasn't impressed, at
least not with the game mechanics.  My first experience on a diku was
with a RL friend showing me around, and he pointed out some buff-ass char
with a bunch of limit-1 items on.  It boggled my mind that because *he*
had those items, no one else in the entire (real) world could have any
of them.  That's a bit of change from the single-player games I was used
to like Angband where everyone has their own Ringil or Deathwreaker.
Of course, once I heard that, I assumed there was a lot more to the game
than there actually was...

> Corpses, I'll grant. The rest of the items? I really doubt it is that 
> common, since in order to make it work with any semblance of game 
> balance, you'd have to get rid of the repop methods used by Diku-style 
> muds. What makes items go away?

Depends.  Also they usually seem to save only 'important' items - when
the ancient multihued dragon loots the black kris of power from your
character's corpse, he keeps it until someone takes it from him.  Longswords
lieing on the ground in Rome as usually not at issue.  And, as I said,
the standard thing seems to be that items 'decay' in their value*constant
number of ticks, so that a loaf of bread dropped out in the forest somewhere
isn't there three RL days later.  Plus lots of 'janitor' (scavanging) mobiles.

[world-state saving I added to a diku years ago]
> I'm curious, though, what do you do regarding the repop model in a 
> case such as this? Are you simply not repopping if the item is already 
> extant somewhere in the world state?

Yup.  Of course, that mud had two kinds of items - limited items, which
meant limit one.  Things like Stormbringer and the One Ring.  Then,
everything else, which was unlimited.  So, the mud would reboot, all
the mobs and objects would be loaded from disk just as they were, then
the normal repop code would be executed.  Of course, it would find that the
4 bar patrons in the Green Dragon already exist, so wouldn't pop those.
A reboot was the equivilent of a mud-wide repop.  I suppose if I had
gotten creative I could have saved out the zone counters, too, so that
reboots were essentially nothing at all except a pause in the game.
As a player I much prefer this; other hardened diku-types are pretty
fond of their reboots, though, so it went over less well with them.
Darn. <tries to hold back tears>

> I define static as unchanging except with manual intervention, so yes, 
> that is exactly what I was referring to (see my reply to Matt 
> Chatterley). From a "game" perspective, this is what makes the game 
> predictable. From a sim perspective, this is a major limitation on 
> what behaviors you can simulate.

Hmmm, well, since this began as a discussion about defining a mud, I still
say that most muds are *less* static than most commerical games, but
far *more* static than they really could, and IMO should, be.
So from that standpoint I completely agree with you.

> I didn't say it was hard, just that it was far more expensive. :) The 
> typical Diku footprint is tiny, and saving objects and state variables 
> will add up. I imagine that it would at least double the size of the 
> database?

I never paid attention, actually.  The mud never exceeded my 6 meg disk
quota, took up about as much memory as two copies of tcsh when running,
and took like 4% of the CPU's processor time (think it was a Sparc20 or
something, which was pretty speedy at the time), so I never even thought
much about it.

> > Can you tell us more details about this, possibly internals such as 
> the
> > messaging system, without infringing on your secrecy requirements?
> 
> My post to Matt Chatterley describes it in broad strokes; I can indeed 
> go into *somewhat* greater depth if that doesn't answer your question 
> enough... just ask.

Well, as you yourself have said, you have to replace the mechanisms
which are normally served by area resets, admin intervention, or hard-coded
quests.  I'm curious as to how possible and then what the general
mechanics are for common examples such as:

* Dragon arrives, takes up residence in nearby mountain.  Begins terrorizing
local town.  Heros arrive to take on the dragon..

In this case, do dragons 'decide' where to live, or do they just get
installed somewhere by the admin?  When they go hunting, how do they choose
targets?  Just fly until they see something tasty?  How does the town get
out word than they need some heros?

* The daughter of the orc king is kidnapped.  Bestricken with grief, he
offers a large reward for her return..

Managing populations: is there always an orc king and his daughter, who
periodically gets kidnapped?  Do the orcs elect rulers, who may have children?
Is she kidnapped by the same person every time?  If some player runs in and
grabs her, does the orc king react appropriately?

* A local shop owner is killed during an invasion of trolls.  Now her
lucrative business lies fallow; the shop collects dust.  A young
whipper-snapper with his eye on success buys the shop from the city,
dusts off the counters, and resurects it, although it was a general
leatherworks before, and he specializes in barding.

Again: is the shopkeeper predetermined, as in any of the stand-alone
Ultimas?  Can they die?  When they do, what does the game 'do' about it?
Manufacture a replacement to run the same shop?  Wait for an applicable
NPC to wander by, then have him/her set up a shop of the type they would
like and think that the local economy will support?  Can players run shops?

I guess what I'm curious about are things that are different from existing
muds, or parts of the game/system which you think are particularly cool
from a design standpoint.

> Origin didn't particularly have the idea. :) Legend did, and we'd 
> gotten as far as design docs... when we applied to work at Origin, 
> this idea with some design was literally what we put in our job 
> applications.
> 
> *toot toot* (that's the sound of someone's horn blowing) ;)

<cheers loudly> Well done.

[rest snipped, as I agree with it all and have nothing to add]




More information about the MUD-Dev mailing list