[MUD-Dev] Graphic MUDS/Ultima Online

Matt Chatterley root at mpc.dyn.ml.org
Thu Jul 31 17:59:26 New Zealand Standard Time 1997

On Wed, 30 Jul 1997, Koster, Raph wrote:

> On Tuesday, July 29, 1997 6:46 PM, Matt 
> Chatterley[SMTP:root at mpc.dyn.ml.org] wrote:


> 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'm not particularly into modern graphics technology - but to give an
example of a game I think used good, appropriate graphics, Legend of Zelda
4 (on the SNES) was great fun for a few months, and not too hard on the
eyes. It was a sort of overhead view(ish) style, which I personally prefer
to 3d. This is partially related to my having the directional sense of a
dead gopher stuck up a drainpipe.
> > 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.

Textual games certainly have none of the 'volume pull' of graphical games
- but they're easier to get hooked on, IMHO. Interesting area to look
into. :)

> 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. :)

Hmm, not sure that I'd call the social development on some games 'dynamic
evolution' (devolution? ;), but I agree at least in sentiment. Actually
developing an environment that 'evolves' in another sense is certainly
tricky (heh), and not particularly attractive to many would-be admins.

> > 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. :)

I'm glad. ;) Its quite a logical progression from the first text muds,
given how other games have developed along this path, too.
> > 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. :)

True - but I think JCL summed that issue up quite well. As another issue,
is it possible to have a mud with *no* combat? I'd say no, but very simple
combat, yes. Riverworld is an intense-RP-based game, and its combat system
consists of one command: +die. If you are killed while roleplaying an
altercation of some form, you +die yourself.
> > 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.

Definitely. One cannot stress enough that having an internally complex
system does not mean you must have an externally complex game.
> > 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.

<g> I always considered muds games from the player side (not always - but
many games I have been on), but from the pointy end of the stick, I always
considered myself to be building a world of some description. Initially I
was fooling myself, and I ended up with a quite poorly set up game - this
time around I have a very successful failure as back-up knowledge.
> > > 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.

Right. You can save how the entire game is - but if its virtually the same
as before, there isn't a huge difference, obviously! If you can do
something significant, which saves indefinitely, then we're making real
> 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:

The Keegan has a talent for highlighting very topical points very well, I
think (without trying to flatter him - he probably wouldn't appreciate
that much). The day of the 'Total Reset' has gone, IMHO. While partial
resets are still used on Caffeine, we are endeavoring to make them do less
and less that significantly affects gameplay.
> 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.

Very interesting angle - although I won't comment right now.
> For muds to evolve, they need to become unpredictable.

First, they must become less predictable.

This brings to mind a phrase from Pratchett: Chaos always wins, because it
is better organised. (slightly butchered). Its a bit like a man being
faster than a horse over a short distance, because the horse has more legs
to sort out.

	-Matt Chatterley
"Doublethink means the power of holding two contradictory beliefs in one's
	mind simultaneously, and accepting both of them." -George Orwell

More information about the MUD-Dev mailing list