Rethinking Rooms
Paul McInnes
This is in response to a thread where various people were debating the
best way of extending the way in which space is handled in a mud. Perhaps
one alternative would be to do away with "rooms" for the handling of the
highest level of spatial relationships?
i) Every MOB, PC and significant object would have x,y coordinates,
and a grid could be used to store information about the more general
features of that space: terrain type, vegetation etc.
ii) Each grid square could cover quite a large amount of space (5 km
on a side ot so). This would allow the builders to construct
appropriately large areas.
iii) grids that were similar could be grouped into named regions (e.g.
"western drath forest") with a region-level description provided. This
would save having to reinvent the same basic description for hundreds of
dimilar "Rooms". There could be an option for a line or two of added
detail for grids to add detail to those parts of the region that were
significant. You would have a "region" command that would give you the
high level description.
iv) the significant places within this space would be defined by
their extent (perhaps a simple rectangle?) and then a more conventional
room-based sub-system used to detail this important and interesting
place.
v) lineal features of the landscape (e.g. roads and rivers) could be
handled as a series of lines linked together. There would be commands
that would allow the character to "follow road" (a kind of autopilot
really).
vi) Characters would have much greater freedom over their movement in
terms of direction (360 degress if you wanted). To make things easier,
you would need a command that moved you towards a specified point or
place.
vii) You would also need a command that allowed characters to join
together as a group, and "follow the leader", but this would be easy.
There are obvious advantages and disadvantages for this scheme. The
biggest bonus would be that builders could focus their attention on the
most important bits of thier regions, without having to create large
numbers of "empty" rooms. Thos reflects that fact that the room system
handles dungeons and buildings well but larger spaces more akwardly. It
would also do away with many of the unrealistic and arbitary borders that
builders have to place on their creations (e.g. forest that is so dense
it cannot be traversed).
The most obvious disadvantage is that the code now needs to handle
colision-detection and proximity detection in a much more complex way.
With large numbers of objects, MOBs and characters the most obvious
solution is "order n squared", because each object etc needs to be
checked against all of the others. There are some ways of reducing the
performance penalty, but it would still be slower than just checking for
those things in the same room at the same time.
Another disadvantage (which might actually be an advantage) is the need
to present spatial relationships to the player. In otherwords, using a
cartesian coordinate system the player needs to have a map. This is not
necessarily a bad thing, but it means that there would have to be a
MUDclient that had support for providing a simple character-centred map.
It is do-able, but would presumably be easier for a windows-based system
than a unix system (unless X-windows stuff provides the solution?).
The main point of all of this would be to enable builders to do what
every good writer should do; describe the important things and let the
reader's imagination take care of the rest.
As always any comments would be appreciated.
Paul
Ho-Sheng Hsiao
I have given thought to an alternative to grid-based "rooms". In essance,
a "cluster" of rooms. A single cluster that "owns" a homogenous (or
heterogenous?) set of rooms, and possibliy other clusters. (A tree
structure, if you will).
Consider a street with an overhanging balcony. The person on the balcony
technically can see the folks on the street, and vice versa. Jumping off
the balcony, though hazardous, lands that person on the street. One can
aim weapons from the balcony at the people on the street, (but not
necessarily close enough to grab/steal other people's items).
The street itself might be wide enough to have two side (say, east and
west) and the center of street itself. One might walk from one side to
another, can see and hear all of the people on the entire street, but not
necessarily close enough for other actions.
One might consider the street as a cluster of rooms (east-side, center,
west-side). Within that particular cluster, certain actions (talking,
yelling, air-borne attacks) might affect everyone in the cluster. Other
actions, (getting an item, stealing, backstabing, hiding, etc.) would be
localized to a room contained in a cluster.
The cluster of these three rooms constituting a street section might also
be contained under a higher-level cluster--- this one with the balcony.
Now, the most obvious disadvantage (for me) is the shear complexity of
setting up a cluster of rooms, and a cluster of clusters. Would a cluster
be grid based (a sort of a compromize... rooms of grids)? How would one
integrate the recursion of cluster within a cluster?
Well, thanks for reading this far. I would appreciate any comments you
might have on this. (Thanks in advance).
--
---hhh (Qaexl)
The truth shall set you free only to be fettered again; grin and bear it [G]
"Everything is real unless declared an integer." --- Modified saying from
Rick Cook's Wizardry Compiled
The Anomaly
Hmm, it's certainly an interesting thought. I'm going to assume you're
talking about a diku mud, because it's easiest for me to think about it
in that light. An lp would do it totally different than what I'd propose.
Consider the way diku remembers everything. Linked lists. They're not
easy, but they are the best way to store it in the memory. Now, we're
using single linked lists. What if you made, instead of a single linked
list, a hybrid, with pointers from one room to another not necessarily
next to each other in the list. Then you could define clusters by what
pointers they have to each other. Instead of trying to rewrite the code,
you could add on and give the effect of clusters, even though technically
in the code they aren't clusters. Then you could consider certain affects
would check what clusters the room is in by checking where it's pointing.
You could limit affects by the size of the room.
Jeff
--
Jeff Schwaber,
ano...@voicenet.com
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
http://www.voicenet.com/~anomaly/sig.html/
Ho-Sheng Hsiao
The Anomaly (ano...@voicenet.com) wrote:
: On 12 Aug 1996, Ho-Sheng Hsiao wrote:
: > I have given thought to an alternative to grid-based "rooms". In essance,
: > a "cluster" of rooms. A single cluster that "owns" a homogenous (or
: > heterogenous?) set of rooms, and possibliy other clusters. (A tree
: > structure, if you will).
: Hmm, it's certainly an interesting thought. I'm going to assume you're
: talking about a diku mud, because it's easiest for me to think about it
: in that light. An lp would do it totally different than what I'd propose.
Either is fine, though I think in terms of LP.
: Consider the way diku remembers everything. Linked lists. They're not
: easy, but they are the best way to store it in the memory. Now, we're
: using single linked lists. What if you made, instead of a single linked
: list, a hybrid, with pointers from one room to another not necessarily
: next to each other in the list. Then you could define clusters by what
: pointers they have to each other. Instead of trying to rewrite the code,
I originally envisioned a tree structure, each node of the tree being
though of as a cluster. I am not familiar with Diku code, though, so I
can't varify that. However, I do remember building on a ROM with OLC. How
would a builder define a cluster, then? Since there is no recursive
cluster in a cluster, I am thinking that would narrow the applications used
by the builder. I do remember that Dikus have the rooms partitioned into
areas. This linked-list, it would be something like a sub-area, right?
Sebastian Andersson
In <320E56...@student.uq.edu.au> Paul McInnes <s10...@student.uq.edu.au> writes:
[snip]
>As always any comments would be appreciated.
Try to find some papers about Mosaic by Pip Cordrey, which has some of
these features.
Some text about Mosaic can be found in Richard Bartles' mud report:
ftp://parcftp.xerox.com/pub/MOO/papers/mudreport.txt
There are newer versions of that paper and there are html versions of it
but I don't have the URLs handy.
/Sebastian
--
---> Play DUMII! (http://www.ts.umu.se/~dum/) <---
Money wants to be free! Give them to me and I'll liberate them!
OB DISCLAIMER: Pepsi, the Devil, made me do it.
The Anomaly
On 14 Aug 1996, Ho-Sheng Hsiao wrote:
> The Anomaly (ano...@voicenet.com) wrote:
> : On 12 Aug 1996, Ho-Sheng Hsiao wrote:
> : > I have given thought to an alternative to grid-based "rooms". In essance,
> : > a "cluster" of rooms. A single cluster that "owns" a homogenous (or
> : > heterogenous?) set of rooms, and possibliy other clusters. (A tree
> : > structure, if you will).
>
> : Hmm, it's certainly an interesting thought. I'm going to assume you're
> : talking about a diku mud, because it's easiest for me to think about it
> : in that light. An lp would do it totally different than what I'd propose.
>
> Either is fine, though I think in terms of LP.
>
> : Consider the way diku remembers everything. Linked lists. They're not
> : easy, but they are the best way to store it in the memory. Now, we're
> : using single linked lists. What if you made, instead of a single linked
> : list, a hybrid, with pointers from one room to another not necessarily
> : next to each other in the list. Then you could define clusters by what
> : pointers they have to each other. Instead of trying to rewrite the code,
>
> I originally envisioned a tree structure, each node of the tree being
> though of as a cluster. I am not familiar with Diku code, though, so I
> can't varify that. However, I do remember building on a ROM with OLC. How
> would a builder define a cluster, then? Since there is no recursive
> cluster in a cluster, I am thinking that would narrow the applications used
> by the builder. I do remember that Dikus have the rooms partitioned into
> areas. This linked-list, it would be something like a sub-area, right?
As for OLC, I wouldn't worry about that -- define it once you've got
the underlying code in. Yes, you could certainly think of it as a
sub-area, you could even define it that way, have a list of areas within
the area, and then define each room as within a sub area, or multiple sub
areas.
Travis S Casey
Ho-Sheng Hsiao <hsh...@freenet.columbus.oh.us> wrote:
>I have given thought to an alternative to grid-based "rooms". In essance,
>a "cluster" of rooms. A single cluster that "owns" a homogenous (or
>heterogenous?) set of rooms, and possibliy other clusters. (A tree
>structure, if you will).
>
>technically can see the folks on the street, and vice versa. Jumping off
>the balcony, though hazardous, lands that person on the street. One can
>aim weapons from the balcony at the people on the street, (but not
>necessarily close enough to grab/steal other people's items).
>
>The street itself might be wide enough to have two side (say, east and
>west) and the center of street itself. One might walk from one side to
>another, can see and hear all of the people on the entire street, but not
>necessarily close enough for other actions.
>
>One might consider the street as a cluster of rooms (east-side, center,
>west-side). Within that particular cluster, certain actions (talking,
>yelling, air-borne attacks) might affect everyone in the cluster. Other
>actions, (getting an item, stealing, backstabing, hiding, etc.) would be
>localized to a room contained in a cluster.
>
>The cluster of these three rooms constituting a street section might also
>be contained under a higher-level cluster--- this one with the balcony.
>
>Now, the most obvious disadvantage (for me) is the shear complexity of
>setting up a cluster of rooms, and a cluster of clusters. Would a cluster
>be grid based (a sort of a compromize... rooms of grids)? How would one
>integrate the recursion of cluster within a cluster?
A cluster of rooms could be an object itself; indeed, on an LP, it
might be a "room" which contains the rooms which are its members.
Messages which are supposed to go to all rooms in a cluster could
be sent to the cluster "room", which would then propogate them to
all the members of the cluster.
A cluster could be set up so as to contain either rooms or other
clusters; the sub-clusters would look like rooms to the cluster.
In this way, a message could be sent to a cluster and its subclusters
simply by sending it to the cluster.
>Well, thanks for reading this far. I would appreciate any comments you
>might have on this. (Thanks in advance).
I've begun implementing a similar idea on a mud I'm working on;
something I call transparent walls. A transparent wall is a join
between two rooms through which objects and actions in the next
room can be seen. For example, a description might look like this:
---
You are standing in the north end of a large open field; daisies and
daffodils cover the ground.
A glowing orb is here.
To the south, a small blue box is visible.
---
The room to the south looks like this:
---
You are standing in the south end of a large open field; daisies and
daffodils cover the ground.
A small blue box is here.
To the north, a glowing orb is visible.
---
Things can only automatically be seen from one room away under this
scheme. However, there still exist peer, lpeer, etc. commands for
looking at distant objects in the normal way.
Where this scheme truly comes into its own is for long series of
rooms. For example, lets take a street made up of ten rooms in
a line:
A - B - C - D - E - F - G - H - I - J
If we were to cluster them all together, then things in A would
see things going on in J... which we probably don't want.
However, the clustering scheme makes it difficult to make
boundaries of that sort--where people in each room can see
things going on in adjacent rooms, for example. The scheme
of transparent walls can handle that situation easily.
Of course, there are also things that clustering can handle
that transparent walls can't... ideally, a mud would have
several strategies for "joining" rooms available.
--
|\ _,,,---,,_ Travis S. Casey <ca...@cs.fsu.edu>
ZZzz /,`.-'`' -. ;-;;,_ System Administrator, FSU CS department
|,4- ) )-,_..;\ ( `'-' (904) 644-7339; Room 011 Love
'---''(_/--' `-'\_) No one agrees with me. Not even me.
rec.games.design FAQ: http://www.cs.fsu.edu/~casey/design.html
Scott Anderson
>i) Every MOB, PC and significant object would have x,y coordinates,
>and a grid could be used to store information about the more general
>features of that space: terrain type, vegetation etc.
Absolutely. I don't think the question is how to store this
information, but what detail to store it in and then how to enter it
and later display it.
[snip]
>The most obvious disadvantage is that the code now needs to handle
>colision-detection and proximity detection in a much more complex way.
>With large numbers of objects, MOBs and characters the most obvious
>solution is "order n squared", because each object etc needs to be
>checked against all of the others. There are some ways of reducing the
>performance penalty, but it would still be slower than just checking for
>those things in the same room at the same time.
The system you state makes perfect sense (of course) - it's the one
used by any program attempting to model a spacial world in some way,
from NASA's flight simulators to Doom on a home PC. Since a 386 can
run Doom just fine, I think it's likely that a Sun can handle a
similar system on a MUD. Of course, it's still a matter of the
proper coding and such.
>Another disadvantage (which might actually be an advantage) is the need
>to present spatial relationships to the player. In otherwords, using a
>cartesian coordinate system the player needs to have a map. This is not
>necessarily a bad thing, but it means that there would have to be a
>MUDclient that had support for providing a simple character-centred map.
>It is do-able, but would presumably be easier for a windows-based system
>than a unix system (unless X-windows stuff provides the solution?).
This was my main dilema. All of this is good and well, but trying
to describe it in both an interesting and informative manner in a
small amount of space via simple text is easier said than done, and
I couldn't think of anything short of building a pseudo-room
description based on nearby objects, which is a large amount of
processor and code investment to achieve what is basically the same
thing as the current room descriptions, only more dynamic and less
interesting (lacks the emotion and writing style a human builder adds).
>The main point of all of this would be to enable builders to do what
>every good writer should do; describe the important things and let the
>reader's imagination take care of the rest.
Yeah. Well, from a practical standpoint, you would just describe
the objects in a physical manner (material, shape, size, color,
cleanliness, etc...) and eschew specific descriptions altogether.
The MUD would build those dynamically. But as I stated before, this
is both hard to code and will end up seeming a tad sterile. So I
personally have opted to stay with rooms, mobs, and objects
basically as they currently stand, with a lot of major changes to
make them more flexible and interesting.
Brandon Joseph Rickman
In article <320E56...@student.uq.edu.au>,
Paul McInnes <s10...@student.uq.edu.au> wrote:
>iii) grids that were similar could be grouped into named regions (e.g.
> "western drath forest") with a region-level description provided. This
>would save having to reinvent the same basic description for hundreds of
>dimilar "Rooms". There could be an option for a line or two of added
>detail for grids to add detail to those parts of the region that were
>significant. You would have a "region" command that would give you the
>high level description.
Basically there needs to be more flexibility in the way a player sees
a room/area. This shouldn't just be dictated by the standard out-of-
character brief/verbose option, it should account for whatever in-character
options your mud has, environmental conditions, and so on. There needs to
be a way to make even those uninteresting locations interesting. Being
able to generate blocks of text that can be glued together to describe
locations is something of an expert systems problem, but even a small
amount of detail would be preferable to what is currently being done.
>iv) the significant places within this space would be defined by
>their extent (perhaps a simple rectangle?) and then a more conventional
>room-based sub-system used to detail this important and interesting
>place.
If your areas are scalable then you can simply plug in an area with a
different scale. If one of your 5x5km squares needs more detail make a
grid of .1km sided squares. Make your areas scalable. When you get down
to the small details, like buildings and interior locations, use the
conventional rooms.
>There are obvious advantages and disadvantages for this scheme. The
>biggest bonus would be that builders could focus their attention on the
>most important bits of thier regions, without having to create large
>numbers of "empty" rooms. Thos reflects that fact that the room system
>handles dungeons and buildings well but larger spaces more akwardly. It
>would also do away with many of the unrealistic and arbitary borders that
>builders have to place on their creations (e.g. forest that is so dense
>it cannot be traversed).
What I am interested in is creating an area where the actions of
non-builders (usually the largest part of a mud population) help to
define some of those uninteresting "empty" rooms. Perhaps an example
is the best way to describe this:
Make a large area of tropical jungle. Put a town somewhere in the north,
another town to the south, and connect them with a road. When players go
from one town to another the road is about 3 "rooms" long. Somewhere to the
east, hidden in the dense jungle, is the entrance to King Solomon's Mines.
Someone decides to make a pile of stones on the road halfway between the
two towns.
Now a player leaving town A goes though about 3 empty rooms before arriving
at the stones. Town B is another 4 exits to the south. Since we have
added a landmark to the road we want to create some sense of distance between
the towns and the stones. Optionally a player can skip those empty rooms and
zip from A to the stones to B in only 2 stops.
One brave hero decides to search for the legendary entrance to the Mines.
One room south of the stones he wields his machete and hacks a path due east.
The more often he takes this path, and the more people follow suit, the more
obvious the path will become to the casual traveller. But those people that
like to zip from A to B won't be paying attention to all those empty rooms
and won't discover the new path until it becomes fully obvious.
Other things should make sections of the road, and parts of the jungle,
interesting. A battleground with corpses of monsters would be an interesting
stop, at least until someone burns the corpses or they are otherwise
recycled.
What will [hopefully] happen is that the jungle will eventually become filled
with rooms, all of which are places of some interest. As paths get overgrown
and objects get lost in the jungle players can continue to explore.
>Another disadvantage (which might actually be an advantage) is the need
>to present spatial relationships to the player. In otherwords, using a
>cartesian coordinate system the player needs to have a map. This is not
>necessarily a bad thing, but it means that there would have to be a
>MUDclient that had support for providing a simple character-centred map.
>It is do-able, but would presumably be easier for a windows-based system
>than a unix system (unless X-windows stuff provides the solution?).
A client can make navigating those big empty areas easier, but I think we
still have to have a way to determine what would be of interest to the
player and turn that into a destination. The freedom of motion of Cartesian
coordinates isn't particularly vital to solving the problems of creating
interesting locations.
- Brandon
as...@oxy.edu
gryphon
On 12 Aug 1996, Ho-Sheng Hsiao wrote:
| the balcony, though hazardous, lands that person on the street. One can
| aim weapons from the balcony at the people on the street, (but not
| necessarily close enough to grab/steal other people's items).
|
| The street itself might be wide enough to have two side (say, east and
| west) and the center of street itself. One might walk from one side to
| another, can see and hear all of the people on the entire street, but not
| necessarily close enough for other actions.
I would say that the easiest way to achieve this is by defining different
locations within a single room. You can look from one location to the
other and even, within certain restrictions, interact between locations.
I.e. in your example the balcony would be a special location within the
room, that is defined to be 'above' the main room, possibly a certain
amount, so you need special skills to travel to and from the location.
Exits would lead into the main room (base location) unless explicitely
stated otherwise. Naturally you would hear/see others do things in the
room, just like you would in a normal mud situation, but those in
different locations would have that name prefixed to the text.
E.g. while standing on the balcony with your friend picard you would
see 'On the street a drow warrior arrived from the market square'.
But on the balcony you would see 'picard says: "looks like we've got
an invasion in town"'
But perhaps that's nearly identical to what you were suggesting.
Marian
Bjoern Wesen
In article <960816.23...@bobcat.cc.oxy.edu>, as...@oxy.edu says...
>Basically there needs to be more flexibility in the way a player sees
>a room/area. This shouldn't just be dictated by the standard out-of-
>character brief/verbose option, it should account for whatever in-character
>options your mud has, environmental conditions, and so on. There needs to
>be a way to make even those uninteresting locations interesting. Being
>able to generate blocks of text that can be glued together to describe
>locations is something of an expert systems problem, but even a small
>amount of detail would be preferable to what is currently being done.
What I've been working on for our new mudbase, is something along these lines.
Basically you have a room-free outdoor representation (technically - the
player still moves in discrete steps of course) based on x,y positions,
vegetation, topology, interesting places etc. When you move between positions
you get auto-generated "difference" messages and if you explicetely look you
get an autogenerated description of the surroundings where you stand.
The builder can define places of interest at x,y coordinates. These are simply
additional texts, that gets displayed should the player walk near enough.
Objects and other characters and houses etc work the same way, you "see" them
when you get close enough.
Houses and stuff work by placing normal "diku" zones at x,y coordinates in the
"geography" zones. These zones have the normal room layout, and also named
entrances/exits from/to the surrounding landscape.
Someone talked about the possibility to let players machete through a jungle -
I agree that would be really cool. I like dynamic worlds, where the players
take part in the shaping. I'd like the builders real task to be to design
these landscapes and the basic towns etc. The players can then shape the
wilderness - cut through some woods, make a clearing, build a house there. If
then this isn't visited often, the path and clearing WILL grow lush and thick
again up to the point of hiding it completely - then it will require
'macheting' and explicit adventuring there to find it again.
Imagine the coolness of some players accidentally discovering the lost temple
of some player-clan who stopped playing an RL year ago - still full with the
loot and mandatory ghosts.
This is the future of mudding I think - dynamic In Character player-world
interactions. Not building through explicit @create commands etc, but shaping
the world through IC skills/tools etc and it will STAY that way over a reboot.
You can't really let any player design actual _text_ to put in houses etc. But
for the first stage we can just let them pick from premade houses when
choosing to build a house in a forest for example (sort of like in WarCraft).
Bjorn
Ben White
Bjoern Wesen wrote:
>...
> Someone talked about the possibility to let players machete through a jungle -
> I agree that would be really cool. I like dynamic worlds, where the players
> take part in the shaping. I'd like the builders real task to be to design
> these landscapes and the basic towns etc. The players can then shape the
> wilderness - cut through some woods, make a clearing, build a house there. If
> then this isn't visited often, the path and clearing WILL grow lush and thick
> again up to the point of hiding it completely - then it will require
> 'macheting' and explicit adventuring there to find it again.
>
> Imagine the coolness of some players accidentally discovering the lost temple
> of some player-clan who stopped playing an RL year ago - still full with the
> loot and mandatory ghosts.
>
> This is the future of mudding I think - dynamic In Character player-world
> interactions. Not building through explicit @create commands etc, but shaping
> the world through IC skills/tools etc and it will STAY that way over a reboot.
> You can't really let any player design actual _text_ to put in houses etc. But
> for the first stage we can just let them pick from premade houses when
> choosing to build a house in a forest for example (sort of like in WarCraft).
>
This definately sounds good, though I think players could
have their own descriptions for buildings that they build. In
a mud I used to play (LP variant), it was possible for players to
create their own taverns, and enter in a description from them.
Players could also make money when other players bought stuff from
their taverns.
Perhaps there could be a builder, who the players could pay some
money to, and would then get the type of building they want built. This
fits in with some previous discussions, which were
talking about player driven economies.
A couple of years ago someone also posted something about some
simulations they performed on an entire ecosystem, eg you model
plants, herbivores, and carnivores, and have the numbers of each
fluctuating when things such as a herbivore eats some plants, etc.
I reckon it would be way cool to model just about everything, and
have very little created randomly. For example, you could have a
given number of type x creatures that just wander around the jungle,
and sometimes you might happen to meet one. You could also have a
set amount of metal about the place, and players (or npcs) would
have to mine it and refine it to make weapons, etc. Alternatively,
they could just find a band of roaming orcs, kill them, and take their
weapons. Or, if the players were killed, then the orcs would steal
their weapons.
If the mud had lots of players, you could just about get rid of NPCs
altogether, and only have players doing things such as the shops, etc.
Of course, you would need some mechanism where the player wouldn't
need to be in attendence to run the shop (perhaps NPCs are needed
after all). You would still need computer controlled creatures,
monsters, etc.
You could also have players govern themselves. This way, players who
have been playing for the longest would be the most powerful, and
have the most important positions. Players could even have
occupations, where some player pays another player to perform some
task, such as a guard, mercenary, or miner etc.
I think the end point is that I would like to see a mud with the
"completely in charge of my destiny" attitude of LP/PK muds, and the
"player interaction" aspects of more social muds. I think it really
expands the game when the players can interact with each other and
the environment a lot more.
Just some ideas.. Please comment :)
Ben.
Scott Anderson
>> Someone talked about the possibility to let players machete through a jungle
>> take part in the shaping. I'd like the builders real task to be to design
>> This is the future of mudding I think - dynamic In Character player-world
>> interactions. Not building through explicit @create commands etc, but shaping
>> the world through IC skills/tools etc and it will STAY that way over a reboot
>
>have their own descriptions for buildings that they build. In
>a mud I used to play (LP variant), it was possible for players to
>create their own taverns, and enter in a description from them.
>Players could also make money when other players bought stuff from
>their taverns.
Yeah, the main problem with this is that people will make room
descriptions like:
Fifi the Poodle of Death OBLITERATES you with her bite!
Fifi the Poodle of Death OBLITERATES you with her bite!
You wish your wounds would stop BLEEDING so much!
Fifi the Poodle of Death OBLITERATES you with her bite!
You are DEAD! R.I.P.
Or more likely, they just won't fit in with the mud, either
gramatically or contextually.
>Perhaps there could be a builder, who the players could pay some
>money to, and would then get the type of building they want built. This
>fits in with some previous discussions, which were
>talking about player driven economies.
What you'd really want is to hire some construction workers: thus
creating a new tavern would be expensive and time-consuming. The
construction workers could be players or not, of course, and might
build differently depending on how you hire. The dwarves might
build it out of stone, while the humans out of wood panneling, or
whatever.
>A couple of years ago someone also posted something about some
>simulations they performed on an entire ecosystem, eg you model
>plants, herbivores, and carnivores, and have the numbers of each
>fluctuating when things such as a herbivore eats some plants, etc.
>I reckon it would be way cool to model just about everything, and
>have very little created randomly. For example, you could have a
>given number of type x creatures that just wander around the jungle,
>and sometimes you might happen to meet one. You could also have a
>set amount of metal about the place, and players (or npcs) would
>have to mine it and refine it to make weapons, etc. Alternatively,
>they could just find a band of roaming orcs, kill them, and take their
>weapons. Or, if the players were killed, then the orcs would steal
>their weapons.
Absoultely. The problem with this is that it tends to be rather
all-or-nothing: you have to keep track of _all_ the plants, _all_
the creates (from dragons down to earthworms), every little detail
about temperature, clime, soil content, foliage, etc etc etc. Leave
out one part of this and the system will end up being lopsided.
>If the mud had lots of players, you could just about get rid of NPCs
>altogether, and only have players doing things such as the shops, etc.
>Of course, you would need some mechanism where the player wouldn't
>need to be in attendence to run the shop (perhaps NPCs are needed
>after all). You would still need computer controlled creatures,
>monsters, etc.
This would, I suppose, be the real future of multi-player gaming.
It would just take a shitload of players to be able to get rid of
any player-controlled characters and still have a full world; plus,
who really wants to play a fat hobbit grocer, or a gopher?
>You could also have players govern themselves. This way, players who
>have been playing for the longest would be the most powerful, and
>have the most important positions. Players could even have
>occupations, where some player pays another player to perform some
>task, such as a guard, mercenary, or miner etc.
Yes; and what's more, these "positions" wouldn't be hard-coded. A
miner would just be someone who has certain skills and tools which
allow him or her to extract minerals from the earth, then sell them
for a profit.
>I think the end point is that I would like to see a mud with the
>"completely in charge of my destiny" attitude of LP/PK muds, and the
>"player interaction" aspects of more social muds. I think it really
>expands the game when the players can interact with each other and
>the environment a lot more.
The main stumbling block is simply resources. It's hard to keep
track of all of this, consider the kind of RAM and processor power
most MUDs have availible. On top of this, someone has to come in
and build/code all of this stuff so that it works well together.
Of course, I would consider the "ultimate" MUD engine to be one
where no building is actually necessary. You just make a ball of
rock and drop some single-celled life forms on it and step back.
Eventually evolve upwards and onwards, without ever needing any more
intervention from the creators. If the world you created initially
were enough like earth however many billions of years ago, you'd
eventually end up with a history very similar to ours. :) If not,
you'd end up with something completely different (chaos theory, ya
know). This would kick ass but I don't see it happening anytime
soon. I suppose you could get something similar without going to
quite that extreme by just tossing a bunch of naked humans onto a
planet with an existing ecosystem, then let them figure out how to
create fire, extract minerals and other resources and turn them into
tools, weapons, clothing, shelter, and so on...