[MUD-Dev] (fwd) mud.design.ideas

Nathan Fenenga Yospe yospe at hawaii.edu
Wed Mar 22 11:21:04 CET 2000


Interesting.  Shall we email him a little mud-dev promo?

He's got a ways to go, but certainly there's potential...

-- forwarded message --
Sender: Mystran the Dark-Elf <mystran at darkelf.mystran.softa.net>
From: mystran at fiiu.org
Subject: mud.design.ideas
Newsgroups: alt.mud,alt.mud.programming,rec.games.mud.admin,rec.games.mud.misc


Here are some mud design ideas from my mud.
(It's still in design stage after all.)


Basic principle is to have only one kind of entities. These entities can be
rooms, objects, items, players, NPC.. TinyMUSE uses flags to identify
these.. basicly you could have a player that's room at the same time :)
(No I have not tried !)

I'd still make rooms be rooms, and objects, exits and characters all be
different types. Ofcourse if we use C++ we can inherit them all from 
the same parent :) Now we can have a pointer to an entity be a pointer to
an object, to an exit or to a character. We need this for location-system
below. But let's make dynamic descriptions first.

I would have <tags> something like this to 

The street looks <WEATHER rain="wet in the rain" sun="hot in the sunlight">.

We could also add a default:

<WEATHER rain="It's rainy" sun="Sun shines" default="The weather is
strange"> on the beach.

If default is omitted it's same as "".

Now we could have a room description as follows:

This is a generic room. <WEATHER rain="It's rainy outside the window>.

So here we got dynamic descriptions.

Other thing to improve is locations inside a room.

Now we could have a character have three location variables. One pointer to
room player is in, one pointer to an object players location is relative to
and the a variable describing how it is relative (eg. "next to", "under").
Then we would have 4th variable describing players state (eg. "standing",
"sitting", "lying"). Now we could make descriptions like:


<ROOM DESCRIPTION HERE>

Felier is sitting on the table.
Wizard is lying next to the door.
You are standing near Wizard.


Compare this with the following:


<ROOM DESCRIPTION HERE>

Felier is here.
Wizard is here.


What do you think ? Isn't it better. Now here is a imaginary screen capture
from an imaginary mud:

-------

> north

You are in a small office. There is only one door and one window.
Through the window you can see that it's rainy outside.

There is a table here.

Felier is sitting on the table.
Wizard is lying next to the door.
You are standing near Wizard.

> move table under window

You move the table under the window.

> look

You are in a small office. There is only one door and one window.
Through the window you can see that it's rainy outside.

There is a table under the window.

Felier is standing next to you.
Wizard is lying next to the door.
You are standing near the table.

>

-------

Nice, isn't it ? And not hard to make.
Default location would be "here", so if Felier is relative to nothing, 
we'd just say: "Felier is standing here."

Felier's player ofcourse would not get a message like 
"You are standing here." but "You are standing." instead.

Another thing to be noticed is that if "Felier is hiding behind a crate."
you will not be printed any message of Felier's presence.

Ofcourse every object would have a bitmask used to check if a player can be
on, under, behind or in the object.

Only problems raising, is that when something in the room moves, whole room
has to checked so that nobody is relative to the player or object moving, or
if something is, then it must be changed not to be. This can quite a lot CPU
power in a room with a lot of stuff and people.



As I was designing a fireweapon combat system, I decided to make it almost
like close combat. The only mayor differences would be as follow:

 1) Fireweapons use ammunition. (What a surprise !)
 2) You can shoot to another room through an exit.
 3) To engage in close combat with "Enemy" you need to "go to Enemy".

Ofcourse if you say "attack Felier", you would automagically "go to Felier"
first. The point is that if Felier shoots you ie. there is a combat, it
might not be that easy to "go to Felier".

If again "Felier is hiding behind a crate." and shoots you, you would see
"Felier shoots you from behind the crate." and after that you would know his
presence and see the "Felier is hiding behind a crate." message every time
you "look" around.

Now when "Felier is hiding behind a crate." it hard for you to shoot him.
A crate might be defined as hard cover, so it would give quite good
protection for Felier. Different things could be defined as either hard,
soft or no cover. Ofcourse the less Felier can see you the less you can
see him. And the more he lies still behind the crate the harder for you
to shoot him. You should get the point.



Room would have list of players, players each have pointer to their room.
Room would also have list of rooms that there is an exit between (even if it
was one way only) so sounds can be set to spawn specific number of rooms.

If we had a map like this:

 A1--A2--A3
 |   |   |
 B1--B2--B3
 |   |   |
 C1--C2--C3

We could say that when somebody shouts something it would have range of 2.
Now, if Felier shout something in A1, everybody in A1, A2 and B1 would hear
it. If Wizard shot Felier with a shotgun with sound that has range of 3,
everyone in A1, A2, A3, B1, B2 and C1 would hear it.

What if exit from A1 to A2 is just a window and not allow moving but still 
pass sound. We could also make each exit have a "sound pass rating" or
something (excuse my English) eg. a wooden door might have rating of 3. Now
when a sound with volume of 5 comes to the door, 3 is substracted from the
volume, so to the other room goes sound with volume of 2. An open door would
ofcourse have the default rating of 1 so if normal talk was volume 2, it
would be useful to close doors to make it impossible to hear a secret
discussion from the other room.

We could also make a limit such that each character would have a "hearing"
ability. Now if Felier had hearing of 3, he'd here everything with volume of
3 or more. This opens the possibility of someone hearing something others
cannot hear. One could also specifically "listen" to improve his chance to
hear something.

If we want to make it perfect we also count noise for each room. If
everybody is speaking loud in a tavern there is no change to hear someone
whispering in the corner.

Ofcourse we would use the volume levels to customize the printed messages
too (eg. A loud voice in kitchen says: "Don't drink water !").

Only problem with this kind of system is that it takes a lot of CPU to
process each sound. If somebody has ideas of how to do this quickly I'd
love to hear them.




--
  -- Mystran the Dark-Elf
-- end of forwarded message --

--

Nathan F. Yospe - Born in the year of the tiger, riding it forever after
http://www2.hawaii.edu/~yospe  nathan.yospe at isearch.com yospe at hawaii.edu
Don't mind me, I'm just insane... there's someone else here in my brain.



_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
http://www.kanga.nu/lists/listinfo/mud-dev



More information about the mud-dev-archive mailing list