[MUD-Dev] Re: Fun vs Realism [ Was: OT: Sid Meier ]

Adam Wiggins adam at angel.com
Mon Jul 27 13:43:23 CEST 1998


On Sat, 25 Jul 1998, Leach, Brad BA wrote:
> Greg <s001gmu at nova.wright.edu> wrote:
> > Gamespot has a lovely article about the man.  A retrospective on as
> > shining of a career in game programming as one could hope for.
> > 
> >   URL http://gamespot.com/features/sidlegacy/
> > 
> > IT's fairly long, but very interesting.  Make sure to read Sid's
> > comments
> > as well.  He talks about what he feels makes a game good, and what is
> > important in game design.
> > 
> 
> The article raised a few points that interested me. 'Sid's philosophy of
> "when fun and realism clash, fun wins."' 
> <URL:http://gamespot.com/features/sidlegacy/ss.html>
> I am wondering how relevent that is to muds. It seems most of us
> are striving for increased realism with our designs - Is this at the
> cost of fun? 

Keep in mind he's talking about a completely different area of game
design.  (How many online games have failed, so far, because they think
that "online game" just means taking a single-player PC game and giving it
network capability?)
IRC is not even slightly fun in and of itself, yet millions of hours get
logged on it.  Many, and in fact probably most, of the muds I've played
wouldn't have held my attention for five minutes without the presense of
other players.

I do, however, think that Sid's quote still applies.  The ultimate goal is
entertainment; but in the case of the kind of games we discuss on this
list, "fun" covers a hell of alot more than the games that Sid creates.
His games, like all single-player games, must satisfy the very basic
requirement of "anything the player does should result in an obvious and
satisfying effect."  An online world designed this way would be very
shallow indeed - witness Merc.  Does this make it more immediately "fun"?
Hell yeah - which is why Merc probably has more players than any other
codebase combined.  Does this mean that this is the only which a mud
developer can aspire to?  Certainly not.

> Maybe Sid's philosophy can explain why the older diku/lp/etc
> muds have been so successful? They were (by today's standard), 
> fairly simple, but yet they were fun. (for me at least :-) ).I
> personally am going back to my design to check how much fun my "game" is.

I think I once gave a rough catalogue of what the more specific categories
of "fun" are, which as I recall went something like this:

Social - Interacting with others; you get this for 'free' with good lines
of communication.  Politics, romance, and other sorts of fun stuff all
stem from this - you can encourage it by building your game properly, but
in the end the players provide it to each other.

Action/Reaction - The most common sort of "fun", used heavily by all sorts
of arcade and PC games. I fire my ship's gun at my enemy and they blow up.
I cast a heal spell and cause my friend's wounds to magical close up.  I
place the key in the door and it opens.

Advancement - A slightly more subtle, time-delayed version of the above.
Used heavily by tactical and strategic games, including most of Sid's
stuff and most Dikus.  I purchase better tires and get better traction
with my vehicle.  I train my soliders and they fight more effectively.  I
get X experience, gain a level, and can now perform most tasks slightly
better.

Discovery - Learning new things about a game's world.  In arcade games
it's a simple as reaching a new level and seeing a new set of enemies and
a new background.  In a more freeform would it includes general
exploration (finding new areas, new creatures, new toys to play with) as
well as discovering new game mechanics (spells, skills, neat tricks you
can do with physics or other world phenomenon).

Competative - Satisfaction gleaned from besting one or more opponents.
This is obviously greatly enhanced when opponents are real people instead
of AIs.

Immersion - This can be achieved in a number of ways.  An enthralling
storyline, attractive visuals, good music and sound effects, well-written
area descriptions, emotive characters, and all sorts of other devices can
contribute to overall player immersion.  This is a more passive sort of
"fun", the same sort experienced while watching a good movie or reading a
good book.

Did I miss anything?

> Another point that was raised is known as the "Covert Action Rule" -
> "Don't try to do too many games in one package."
> <URL:http://gamespot.com/features/sidlegacy/interview12.html>
> Are we putting too much into muds, at the cost of gameplay itself?

The nice thing about muds is that players can choose to ignore whatever
aspects they find unintersting.  There are limits to this, of course,
since things can end up affecting you even if you ignore them (PK is the
ubiquios example here), but the size and scope of muds allows them to
include many different types of "gameplay" which players can choose to not
approach.  Ie, if you don't enjoy battling smelly orcs, stay the hell away
from the orc camp.  If you don't like alchemy, you don't have to go into
the forest and collect herbs.  If you aren't interested in spellcasting,
don't wander the land in search of spellbooks.  Etc.

Single-player games can do this to a certain extent (ie, you could quite
easily play Master of Orion and *completely* ignore the whole diplomacy
phase of the game, although that would make the game extremely difficult),
but it's not really worthwhile for them.  I think it is quite worthwhile
for muds to include more gameplay than any one player might be interested
in.

> Where do we draw the line of what is neccessary versus un-necessary?

Now *there's* an important question.  This is one that can only adequetly
be answered by each game designer for each project.  A game including
intense and realistic combat would be consider limb-management code quite
important for handling equipment and damage.  A game which is not
interested in combat would probably find code to keep track of a player's
limbs to be completely superfluous.  This comes down to the designer's own
personal goals: when creating each element in the game, they should ask
themselves the question, "What major goal does this element contribute
towards?"  If the only answer they can come up with is, "Uh...well I just
think it's cool" it's probably superfluous.

> I have recently envisioned the "ultimate" mud as something that allows
> you to interact with everything... every brick in that wall, every grain
> of dirt in that mound, etc. If that complexity is indeed added in the 
> future (as I dont think the average Joe/Mary has that sort of 
> storage/computing power now), will it actually detract from the game 
> itself?

If done properly, no one that doesn't care will ever have to worry about
it.  Look at our own world - although everything I interact with on a
daily basis is made of atoms, I don't think about this much, and it really
has no particular relevancy with anything I do.  There are, however,
scientists and engineers whose life's work involves staring through a
powerful microscope to manipulate individual atoms.  It is *quite*
relevant for them.

I guess elements in your game can be divided into two categories: required
and optional.  A well-written mud, IMO, will include very few required
categories and very many options categories.  I think perhaps one of the
key points in the Killers Have More Fun thread is that combat is not
optional on most muds.  I agree that this is definitely something that
should go into the optional category, although this is easier said than
done given the combat-centricness of muds (and indeed, most games,
on the computer or not) through the years.

> This leads to another point - if you dont have more and more detail, how
> do you make the world challenging (assuming challenging = fun) to the 
> seasoned mud'er?

I am still of the mind that giving many intertwined elements will keep
that sort of player entertained for far longer than any artificial stuff
that typically makes its way into video games - making tougher and tougher
enemies by giving them more and more hitpoints.

Adam






More information about the mud-dev-archive mailing list