[MUD-Dev] Graphic MUDS/Ultima Online

[Koster]

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 
also
> > far more lacking in environmental adaptability, because it's plain 
> > harder to make a limited graphical tileset adapt to circumstance 
than
> > it is to make text do so. Those who are used to the flexibility, 
and
> > yes, greater options (certainly less man-hours per nifty effect), 
that
> > text provides will find it to be a shallower experience in that
> > sense.
>
> I can certainly imagine all of this being somewhat predominant in 
the
> 'limitations' stake (although perhaps less so if you had a 
graphical
> engine more than a tile set system.. ie something which could 
adjust
> drawings on the fly. A lot more demanding though, one would 
imagine.)

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 
muds,
> or who found text an instant turn off (ie: me before I got some 
good
> 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 
genre.

> Right. I think what Adam aimed at is that nowadays characters are 
more or
> 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 
too, is
> 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 
respawn
> > systems for NPC repopulation. Even in the case of 
world-state-saving
> > models, such as MUSHes, the database is often static because of 
other
> > concerns (workload, for one!). TinyTIM is a marvel of 
interactivity,
> > but it does not change much once something is added. I don't know 
any
> > publicly released mud architectures that are not essentially 
static in
> > this manner.
> Hmm. I'd suggest the social environment to be very relevant here - 
it
> really does effect gameplay. While many MUSH servers may seem that 
way -
> those which allow or encourage player creation of objects and/or 
rooms are
> certainly not, several new things which influence gameplay could pop 
up at
> 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 
course.
> > 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 
system of
> 'tribes' of monsters which behave like real population groups might. 
Not
> 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 
do,
> muds now (modern?) the concept of 'virtual world' rather than 'game' 
is a
> far more desirable target.

Obviously, I agree. :)

> At the risk of sounding like a Star Wreck extra: Combat is 
irrelevant.
> 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, 
handles
> fatigue (among other things), relies on speed (using an 
experimental
> coordinated system for maneuverable tactics), weight, range, and god 
knows
> what else. The player gets relatively little control over many 
factors
> though, which makes you wonder how worthwhile it is to have them. 
Direct
> 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' 
is no
> longer a valid project, IMHO. Been there, done that, bought the 
T-Shirt
> 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 
manipulate
> > 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 
something fundamental:

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.

-Raph