[MUD-Dev] Graphic MUDS/Ultima Online
Koster
Koster
Wed Jul 30 13:22:36 CEST 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,
and
> 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.
> > Diku architecture muds (ROM, Merc, Envy, blah blah blah) which
save
> > characters and equipment and the like, but do not save world
state.
> They do, just in limited ways. The main method is via equipment
limits:
> "Argh! Bubba has the sword Stormbringer, and there's only one in
the
> whole world!" Although I don't generally like equipment limits the
> way they are imlemented on Dikus, I do like this idea in general;
other
> characters affect the world instead of you just running through your
own
> private game and getting your own Stormbringer.
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...
> > Evolved Diku models which save some elements of world state (say,
add
> > player housing on a Merc). Full world-state saving a la
> > MUSH-derivatives, etc. What defines persistence?
>
> Well, any good mud saves world states. Saving location of objects
and
> player corpses is pretty standard on dikus now.
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?
> I added world-state-saving
> to a diku I was working on a few years back, which was about a 20
line
> function involving saving the location and basic state info
(health,
> position, equipment) of every mob and object on the mud, then
another
> function of the save size to load it all back up. Not too tricky,
and
> makes crashes basically irrelevant, since everyone just starts out
exactly
> where they were during the last save. (Also prevents object duping
since
> it's all saved at once.)
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?
> > Many muds do not have a changing environment *save as a social
> > construct among players*. Their database is static. They use
respawn
> The fact that they have a database at all implies that it is not
totally
> static. [snip] If you're
> refering to the database as in the 'world' stuff like room descs
and
> mobile locations, this stuff is usually under constant change,
although
> manual change, by the admin. Definitely this is an area that needs
> improvement, but none if it is really 'static'.
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.
[snipped stuff on how crashes are special cases, which of course they
are]
> > > When they return at a later time,
> > > effects of their previous visit are still in place: things they
> > have
> > > interacted with stayed that way until changed by another
character;
> > No Diku-architecture muds do this.
> Again, I disagree. Given what I said above, objects stay where you
put
> them until someone else moves them, or if you have some sort of
> artificial object-decay to keep the litter under control.
I admit to never having even seen a Diku that saved world state to the
extent of saving all items. I'm quite willing to believe they exist,
but I am skeptical of how well they could function without mechanisms
that by their nature get away from the Diku architecture. :)
> > This is only common to full world-state saving engines,
> > which are far more expensive than a Diku-style mud for this
reason,
> > among others.
> Hum, I still think that saving stupid things like objects on the
ground
> is ridiculously easy.
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?
> This, of course, allows for cool
> things like running your hero decked out in the best artifacts to
> be found in the game in on a dragon and getting slaughtered. Now
those
> artifacts are essentially out of the game unless you feel like
trying
> to either take on the dragon or plunder its hoarde. Simple
mechanics with
> a highly interesting result.
Absolutely. There is a LOT to recommend full world-state saves for
gaming environments.
> Kinda wondered about this - is it like the combat systems in Ultimas
7 and
> onwards? If so - ick. Course, it's probably not as bad
controlling
> a single character (more like Diablo?). At least when Iolo shoots
you
> in the back you can turn and swear at a real person instead of a
shoddy
> AI.
It's automated once it begins, like a mud; you can retreat, like a
mud. It doesn't have many interventionary commands, unlike all the
special combat commands typical on gaming muds. It is spatial, of
course, by the nature of the engine...
> How much, if anything, is actually offloaded to the client? Are we
going
> to be seeing Diablo or Shadow of Yserbius-style hacks before long to
make
> your characters superbuff?
Only movement prediction. And it is only prediction; we double-check
serverside, so if you hack that, all you get is "bounceback."
Everything else is serverside, like a mud. :)
> > UO has an economic system that goes from raw materials to finished
> > goods, and players can make any step of it.
>
> Awesome. Few have tackled this; only Dartmud that I can think of
right
> off hand. This is also one of the things that made the Ultima
single-player
> games so immersive.
DartMUD was influential on me, certainly--ought to have been for
everyone. I think the key problem they had was that their system
required a critical mass of players of diverse types in order to
function, and they never really achieved that mass...
> > UO also has an ecological system that handles creature
repopulation,
> > behaviors, etc.
>
> 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.
> > Both of these are intrinsic to the game, far more so than combat
or
> > spells or guilds. They are the simulation layer under that, and
> > despite repeated calls for "mud evolution" not many take up the
> > gauntlet to work on this sort of thing further.
> I agree with this very much, and having read this stuff early on
about
> it (I was playing Legend when the beta-test messages went up) I was
> very encouraged that Origin had the right idea from the start with
this
> thing -something I can't say for any other commercial endevour I've
seen
> so far.
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) ;)
> > that adding a simulation layer to muds is where the genre needs to
> > go.
> Agreed. I like to think in turns of making building blocks which
come
> together to form more combinations and possibilities than can be
'hard-coded'
> by a team of builders coming up with special-case situations and
> softcode chunks. See recent threads of herbalism/alchemy.
Absolutely. For example, a fairly easy method of getting away from
some of those static behaviors is to write a large library of
behaviors, and then not merely assign them to creatures, but actually
change them up dynamically based on the situation.
> Your game starts to build itself.
You just eloquently summarized the original design goal (something
which btw we of course fell short of, it's a really hard to reach
goal).
> You can move objects around in Quake?
Quake is actually very powerful and flexible. You can do a lot in it.
Most don't. :)
> Yes, and I've been crusading on this very fact
[affecting the game in significant ways]
> for not fewer than about
> two years now.
As have many on this list, I suspect. :)
> On the other hand, those guys at Blizzard are pretty smart - taking
a tried
> and true game design and slapping some graphics and marketing on it,
then
> dumbing it down enough to allow 'normal' folks to play it. They
deserve
> their success.
Absolutely, and for what it is, it's pretty darn good.
[snip about Legend folks involved in UO]
> Wow! No wonder it's turning out so well.
Well, let's not forget other factors. Edmond Meinfelder was with the
team for quite a while, and he ran(runs?) TooMUSH and was a founder, I
believe, of NarniaMUSH. And Scott Phillips, the other lead programmer,
is a longtime player of LPMuds, and works now on some Star Wars
variant, I believe.
> I was impressed with Legend from the very first time I played it,
which
> was quite a while ago - not sure how long you had been up at the
time,
Hm, we went up in what, '93? Maybe '94, I'd need to look it up. :)
> but usually the only other folks online when my mudding buddies and
I
> logged on were immorts. I since haven't really had time to mud, but
my
> friends have continued to play it on and off over the years, and
I'm
> constantly impressed by the continued improvements; I continued to
read
> Legendary Times long after I had stopped playing there. I always
> liked seeing what the new combat system was on a given week...:)
It's changing again. :)
> > As far as it being a good mud... well, it's I suspect, up to par
with
> > run-of-the-mill muds in most ways. In other ways it's a heck of a
lot
[This is UO I meant, btw, not Legend, I'm quite sure Legend is better
than run of the mill muds, though not as innovative as it was some
years ago by any means]
> I'd say it kicks the crap out of run-of-the-mill muds, but that's
> not necessarily saying a lot.
Well, in terms of hack n slash, I suspect UO merely does its job
competently. It doesn't do it as well as a mud with a really well
thought out combat system, in part because I find interventionary
combat to be more interesting as a player, and in part because
graphically you just can't convey quite as much as you'd like.
Socially, it doesn't do its job as well as a server design that is
oriented towards just that, either. You just have to make compromises
somewhere. :)
> > I remember arguing with Orion
> > Henry and Mike Sellers (who did Meridian 59 and is now freelance I
> > think) and others about it on the newsgroups a LONG time ago.
Like,
> Heh, yeah...that was back when I was posting out of Orion's
account.
OK, so I guess I argued it with YOU. :)
> We also exchanged email for a while, I think about the quest-system
> on Legend, but I can't remember exactly what we were talking about.
> At the time you were all excited about getting hired by Origin :)
OK, that narrows down how long we had been open at Legend, then...
around two years or so. A lot of those old posts are accessible via
DejaNews, btw, and some of them make interesting reading in hindsight.
:)
> The creation growing beyond its creator? Scary...in a good
> way!
We've been talking lately about not building a world, letting it build
itself from scratch...
> I should say you'll love our mud...if we can ever get the damn
thing
> finished *growl*
Heh, not like I can talk; look how slowly Legend is coming. :) We
STILL haven't put in our usage-based skill system and stuff, because
we all got distracted.
-Raph
More information about the mud-dev-archive
mailing list