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

Nathan F Yospe yospe at hawaii.edu
Sat Jul 25 12:39:44 CEST 1998


On Sat, 25 Jul 1998, Markku Nylander wrote:

:Caliban Tiresias Darklock wrote:

:> Yes. I keep saying this. Realistic is fun to watch. Realistic is 
:> not fun to play. If I wanted realistic, I would stay in the real
:> world instead of playing a game.

:> >Are we putting too much into muds, at the cost of gameplay itself?

:> Yes. I keep saying this, too. Most of the new servers I hear 
:> about would be fun to hang out and go "Oooh" at, but would absolutely
:> suck to try and play. 

:> Severely. Stop and think. How much fun is it to interact with a grain of
:> dirt or a brick?

:> >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?

:	Brad and Caliban have an excellent point here. I'd like to turn the
:	question around and ask this: How do you make _creating_ the world
:	challenging (= fun) to the _seasoned coder_ (implementor, game
:	designer, whatever)? The reason I ask is because I've followed the
:	discussion on this list and to me it seems people are aiming for
:	more and more complex (internal) designs (total world persistence,
:	object behaviour simulating laws of physics etc.)... how do you
:	hide all that behind the user interface and keep the game playable?

More to the point... at least for me, with my physics models and long term
updates and thread/memory/location tree... how do I hide it from my coder/
builder/creator types? The inner guts... the heart of the mud... are stuff
for a senior thesis project, not a newbie coder. OK, so LPC handles this a
little... but they have sloppy code at the top level as a result. This has
been a major issue for me. I ended up taking my cue from NeXT and AppBuild
concepts... Two birds with one stone. A common interface, and simpler code
and building for the top level. All the "coding" is GUI driven now... even
my own top level coding is GUI driven. Not anything like Rational Rose, in
execution, but... there is a similarity in intent. Builders get to play at
creating new elements of the universe, scripting sequential behaviors as a
series of loops... but it's all tapped right to heart code, and the levels
that they play with are seamlessly tied to "what the universe will let the
physical objects do"...

But for the issue of players...

:	If you coded an intricate and ingenious MUD engine that simulates
:	the real world perfectly, would you want to plop a simple Diku
:	interface on top of it, i.e. if a player was carrying a plate mail
:	and wanted to wear it when carrying a torch and a sword, would you
:	let a player to do Dikuish 'wear plate' or would they have to
:	'drop plate; extinguish torch; put torch into backpack; sheathe
:	sword; remove backpack; drop backpack; remove belt; drop belt;
:	remove chainmail; take plate; wear plate;	take backpack...'? 

It depends on the client for that... and the client I'm working on takes a
command and parses it into most probable intent... which in this case is a
series of actions... the player would see something along the lines of:
    > wear plate
    The plate mail armour looks like it would fit over your head. You take
    your torch and stick it into a crevice in the wall, the glance around.
    Seeing nothing obviously hostile, you sheath your sword and take a look
    at the plate mail. There are buckles around the back, but it won't fit
    over your backpack. You remove your backpack, then slide your arms into
    the armour's straps. The fit is ackward; you'll have to have someone
    tighten the straps later. You grab your backpack, sling it on over your
    shoulders, remove the torch from the wall, and draw your sword.

The message about the plate mail chafing over the chain mail would come
later.

:	Does it keep you motivated if the players go "OOooh" over the
:	twinkie ANSI color coded auction channel that took you five
:	minutes to code, but think the event-queued-limb-hit-and-damage-
:	permanent-injury-and-scarring based	combat system you spent	three
:	months implementing sucks big time?

No players on the current version yet, so I'm not sure... but I suspect the
people that would *want* an ANSI color coded auction channel would hate the
level of detail presented by my client.
--

Nathan F. Yospe - Aimed High, Crashed Hard, In the Hanger, Back Flying Soon
Jr Software Engineer, Textron Systems Division (On loan to Rocketdyne Tech)
(Temporarily on Hold) Student, University of Hawaii at Manoa, Physics Dept.
yospe#hawaii.edu nyospe#premier.mhpcc.af.mil http://www2.hawaii.edu/~yospe/






More information about the mud-dev-archive mailing list