[MUD-Dev] Graphic MUDS/Ultima Online
Wed Jul 30 12:51:05 New Zealand Standard Time 1997
On Tuesday, July 29, 1997 6:46 PM, Matt
Chatterley[SMTP:root at mpc.dyn.ml.org] wrote:
> On Tue, 29 Jul 1997, Koster, Raph wrote:
> > Does it have the amount of language input? Absolutely not. It is
> > far more lacking in environmental adaptability, because it's plain
> > harder to make a limited graphical tileset adapt to circumstance
> > it is to make text do so. Those who are used to the flexibility,
> > yes, greater options (certainly less man-hours per nifty effect),
> > text provides will find it to be a shallower experience in that
> > sense.
> I can certainly imagine all of this being somewhat predominant in
> 'limitations' stake (although perhaps less so if you had a
> engine more than a tile set system.. ie something which could
> drawings on the fly. A lot more demanding though, one would
Well, there's a couple of other approaches. When we started out, the
choice was basically between tileset graphics or pseudo-3d engines,
and tileset seemed to offer greater flexibility and variety. Now that
3d hardware acceleration is the industry norm, I imagine choosing
anything other than a full 3d engine for a mass-market product would
be far riskier.
> I think the market for graphical games lies not so much within
> enthusiastic textmudders, but within those who have not discovered
> or who found text an instant turn off (ie: me before I got some
> reading glasses!).
Absolutely. Then again, remember that the majority of the text mud
audience is not "enthusiastic textmudders" either. :) Diehard text
lovers are relatively few and far between compared to the number who
play text muds because there are no reasonable alternatives in the
> Right. I think what Adam aimed at is that nowadays characters are
> less static, although the world may reset - you keep your level, or
> whatnot. There are probably still games where this does not apply,
> somewhere! But on the whole it does, and it is this way with UOL
> it not? :)
UO saves full world state, yes. :)
> > Many muds do not have a changing environment *save as a social
> > construct among players*. Their database is static. They use
> > systems for NPC repopulation. Even in the case of
> > models, such as MUSHes, the database is often static because of
> > concerns (workload, for one!). TinyTIM is a marvel of
> > but it does not change much once something is added. I don't know
> > publicly released mud architectures that are not essentially
> > this manner.
> Hmm. I'd suggest the social environment to be very relevant here -
> really does effect gameplay. While many MUSH servers may seem that
> those which allow or encourage player creation of objects and/or
> certainly not, several new things which influence gameplay could pop
> apparently 'random'.
Of course the social environment is very relevant; it's crucial. It is
also one of the things that oddly enough, we can take for granted.
Provide enough environment (far LESS environment than a mud offers, in
fact, cf IRC, ICQ, heck, ham radio, etc) and the social aspect will
follow inevitably. My argument was that in terms of dynamic evolution,
most muds settle for solely this one thing, the one thing they didn't
have to do any work to get. :)
> > These aren't done much by anyone far as I know. Then there's that
> > middle layer, of developing, changing, and evolving
> > storylines/creatures/etc. And this is quite within technological
> > reach, and has been for some years. Almost nobody does it, of
> > Boy, should they. I'd love to see more discussion of this on the
> > list.
> Yes. One way I reach towards some sort of development is with a
> 'tribes' of monsters which behave like real population groups might.
> enough time to go into depth now, though.
What we do is have what we call a "resource model" in which everything
is defined in terms of a basic hierarchy of desires taken from
organizational behavior theory. Subsistence, shelter, luxuries. Then
we have generalized AI routines and basic decision trees to satisfy
these needs, hoard if you can, band together if you are so inclined,
defend if you must...
> No comment on dikus ;)
Tch tch. Let's not forget the great strength of Dikus, which is also
their great weakness. They are template-based architectures. They are
therefore far more user-friendly to set up, maintain, and develop.
They don't take a programmer or a programmer's mindset, necessarily.
Because of this, many Diku-architecture muds are more creative in
certain ways, because there is less of a barrier to the creative mind.
Also because of this, shclocky crappy templates are common because
they are relatively easy tomake, and the overall quality of the worlds
built with the architecture suffers a lot. This is really a thread of
its own though.
> True - but really for 'revolutionary'.. not a very good word, itll
> muds now (modern?) the concept of 'virtual world' rather than 'game'
> far more desirable target.
Obviously, I agree. :)
> At the risk of sounding like a Star Wreck extra: Combat is
> You can be a mud with no combat system.
Oh, certainly. :) Defining "what is a mud" wasn't however the sole
topic in Jeff's post. :)
> Caffeine relies upon the state of limbs, damages all objects,
> fatigue (among other things), relies on speed (using an
> coordinated system for maneuverable tactics), weight, range, and god
> what else. The player gets relatively little control over many
> though, which makes you wonder how worthwhile it is to have them.
> control, I should say.
Well, I work with Richard Garriott fairly closely. He favors
simplicity in his design. (Which may seem contradictory given how
complex Ultimas are). But in general, he prefers simplicity for
interface and also simplicity for underlying systems, as much as
possible. My own approach is that you need a simple interface, of
course, but that given the power of computers, you should go ahead and
make a system more complex (read: capable) than you think you'll need,
because if not, you'll regret it later. This is only one of the places
where I am not quite compatible with commercial game development.
> Hence the virtual world concept mentioned above - building a 'game'
> longer a valid project, IMHO. Been there, done that, bought the
> and lost the badge.
:) I don't even recall when I ever saw it as only building a game. I
share the same experience others had when they first checked out muds.
For me it was Worlds of Carnage, which had a Crete area. A friend told
me, "Hey, there's this way on the Internet to log into Europe and like
walk around it, described in text!" She was totally wrong, but that
has set how I saw muds, from day one.
> > You can't modify the environment on MOST muds. :P You can
> > some objects in limited fashions.
> You can modify the environment semi-permanently on many games, and
> temporarily on others.
My point was that even saving world state doesn't mean much if the
state isn't very different. And I count item location as not very
different. Now, if that items *significance* had changed in some way
(beyond what significance players attach to it). If say, it resulted
in changing economic conditions, differing NPC behaviors, etc--actual
change in that middle layer I mentioned earlier--then maybe I'd term
that altering the environment.
Keegan's paper in the newest JOMR terms full-reset-based muds
"Groundhog Day" muds. Cute term (though I think Ken Grimwood's novel
"Replay" was ripped off by the movie.) but it serves to underscore
You make an item.
It either spawns back when destroyed, or isn't destroyed, depending on
world-state model (repop versus save-state).
But when does it EVOLVE? Now, some may say that in mud architectures
which permit dynamic attachment of scripted behaviors by players,
stuff evolves. To get back to my example of TinyTIM, that clock or
whatever it is at the entrance that by now is massively huge. But that
isn't evolving by itself. That's just more functionality slapped on it
by a builder of some sort. It is not dynamic; it is static save for
outside intervention. It is therefore predictable.
For muds to evolve, they need to become unpredictable.
More information about the MUD-Dev