new project + roleplaying in muds
my...@my-dejanews.com
on ways to encourage role playing. There'll be a strong political theme to
the mud, with emphasis on team work and helping your clan/guild expand.
Obviously I don't want the code to dominate the players, but the addition of
facilities which would help encourage clan/inter-clan politics, etc. can only
help create a better role playing environment. There will be no experience
full stop. Skills and stuff will get better as you use them or do research
on how to use them etc., and the more exercise you do, the fitter you'll
become. So the only reason you'd go out killing "monsters" would be to
practice your sword skills on a proper oponent. This means real power will
come from your political power and standing within your clan.
Of course, occasionally it'll be necessary to pick up your sword and defend
your home from an invading band of goblins, or to hunt down a spy from one of
the other guilds.
I won't give away anything else, so that I don't inhibit your thinking. If
you have any ideas/concepts which could help me then please mail away!
Oh, the map will be user editable, so if you want to go and build a house, get
the tools, and build away.
Regards,
Chris
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum
Terrence Reidley
Clan's etc and getting income from that territory, Where each piece of
land generates it's own income depending on many factor's.. Like If
there was a war around lower income etc etc..
A major way I've tried to implement RP, is not making a PC when they
die automaticly being trans'd to the Temple, or Clan Temple, they'd
have to have their corpse Recovered by someone else or a piece of corpse
recovered.. And takin it back to the Temple/Clan temple for a little
ceremony.. This would make peopel have to work together, so the guy
runnin aroudn Pkilling everythign woudl soon find himself with no
friends and no-one to pick up his corpse...
I have a tonne more, just can't think at the moment, Just woke up...
Terrence Reidley
my...@my-dejanews.com
of escaping from actually being killed. I still need to think about that a
lot more, but certainly the way death is treated is central to players
attitudes towards killing and hence to roleplaying. If death is treated
lightly then it will happen all the time which would probably inhibit
roleplaying as death should be the last resort as it wouldn't always further
your cause.
I'm also toying with the idea of building this new mud around an experimental
engine I wrote a while back which represented the map in a style similar to
the old moria and nethack games using ascii graphics to show a 2D map of the
players location. You could then jump in and out of command mode and
movement mode so you can use the keypad to move around quickly and single key
presses to open doors and such like, and then enter complex commands like
chanting out the appropriate syllables for a spell while holding the correct
spell components. If lag wasn't a problem and a good enough interface could
be built then I think it would work very well, and allow for more complicated
geographical settings, while retaining the command line and optional area
descriptions for certain rooms etc (appearing in a text box above the map) to
enhance the role playing side of the game. I'd be very interested in what
people think of this, as while I know it'd work very well for a hack'n'slash
mud, I'm not sure it would work quite so well for role playing.
I'd also probably write a java client which would cut down on net traffic by
storing more information locally (like long room descriptions) and by
compressing map information so that long cursor escape sequences don't need
to be sent all the time. It runs very smoothly locally under telnet, but I
haven't tried it over the net yet although I imagine lag would be a problem.
Although the more I think about it, the worse I think it'd be for a role
playing environment where descriptions are more important than 2D space.
Then again the flexibilty of the moria like map for allowing real time
editing by all players of the environment around them could open up many
interesting possibilities.
Anyway, it'd start off with three human 'cities', each having their own self
imposed and enforced political structure, with anyone murdering being hunded
down and tried and put to death if guilty etc. There'd also be a band or
several bands of outcasts, who don't live in any of the cities and instead
live in the wilderness. They may make alliances with one of the cities so
that in exchange for food and weapons they make regular attacks on one of the
other cities, etc.
The environment around these cities would be very hostile, and mobs would
behave more like real animals where they'd have motivations (current hunger,
hit points, thirst, curiosity, aggression, etc factors) and places they like
and dislike going (maybe someone attacked them in a certain grove and while
they survived they were badly hurt and are now scared of that area) but
aren't tied to a particular area. They'd also be capable of breeding, thus
increasing their numbers, and of being killed off outright, never to be seen
on the face of the world again. So if there was a particularly nasty tribe
of goblins living near one of the cities which was proving to be a major
headache to the inhabitants, they could mount a full scale assault and
permanently destroy the goblin tribe.
"Combat" will also be heavily stylised so that while a tough warrior could
kill several goblins quite easily, if a couple of lucky hits from the goblins
get through, then the warrior may be hurt enough so that he's not as
effective in combat, and the goblins could then swamp him in shear numbers.
Thus team efforts, hence group interaction, hence roleplaying, can be
encouraged as while they may hurt one warrior, the other one could fend them
off while the injurred warrior pulls out his precious potion of healing
before joining in again.
I think the biggest thing I want to achieve is having no set way of being the
best at anything. I want all the characters to be different in every way.
From computer generated descriptions based on what someone looks like, what
they're wearing etc. through to the choices people make about how it's best
to gain power.
Please send as much feedback to me as possible so I can design as much as
possible before even sitting down at my keyboard. The biggest problem I can
see with my plans is the cpu time it's going to eat on the server. But
hopefully by the time it's finished i'll have my own computer on the net so I
won't have to worry about cpu hogging or using too much ram. I want every
mob to be a seperate entity, permanently active (although they'll need to
sleep - convieniently halving cpu time, and they can do repetative actions
like eating for long periods). I hope I can make it all work!
Anyways, send all ideas to me or the list. I'll try and check in tomorrow and
see what you've sent.
Chris
In article <35BCEE82...@tkar.com>,
Richard Woolcock
you are planning.
my...@my-dejanews.com wrote:
>
> Hmmmm.... I was acutally thinking about making death permanent, but with ways
> of escaping from actually being killed. I still need to think about that a
> lot more, but certainly the way death is treated is central to players
> attitudes towards killing and hence to roleplaying. If death is treated
> lightly then it will happen all the time which would probably inhibit
> roleplaying as death should be the last resort as it wouldn't always further
> your cause.
I use a permanent body-death system; if you die, your soul lives on (OOC name,
total exp, authorisation, etc) but you are required to create a new body and
go around re-learning skills from other players (although you do at least start
with a % of your soul's experience points with which to train up skills/stats).
> I'm also toying with the idea of building this new mud around an experimental
> engine I wrote a while back which represented the map in a style similar to
> the old moria and nethack games using ascii graphics to show a 2D map of the
> players location. You could then jump in and out of command mode and
> movement mode so you can use the keypad to move around quickly and single key
> presses to open doors and such like, and then enter complex commands like
> chanting out the appropriate syllables for a spell while holding the correct
> spell components. If lag wasn't a problem and a good enough interface could
> be built then I think it would work very well, and allow for more complicated
> geographical settings, while retaining the command line and optional area
> descriptions for certain rooms etc (appearing in a text box above the map) to
> enhance the role playing side of the game. I'd be very interested in what
> people think of this, as while I know it'd work very well for a hack'n'slash
> mud, I'm not sure it would work quite so well for role playing.
Interesting - although it might well end up like a text-based 'gauntlet' style
game if you're not careful. I have an ascii-map option, but it only shows the
surrounding few rooms (no mobs or objects).
> I'd also probably write a java client which would cut down on net traffic by
> storing more information locally (like long room descriptions) and by
> compressing map information so that long cursor escape sequences don't need
> to be sent all the time. It runs very smoothly locally under telnet, but I
> haven't tried it over the net yet although I imagine lag would be a problem.
>
> Although the more I think about it, the worse I think it'd be for a role
> playing environment where descriptions are more important than 2D space.
> Then again the flexibilty of the moria like map for allowing real time
> editing by all players of the environment around them could open up many
> interesting possibilities.
You could still allow players to modify their environment - the problem is
trying to cater for room descriptions. The room description should update
itself to reflect the fact that the forest has been chopped down, that the
plains have been dug up, and so on. I'm still having trouble trying to get
my mud to create 'artistic' rather than simply 'accurate' room descriptions,
but if you stuck purely to a map you shouldn't have much trouble (this would
still leave you wiht the roleplaying problem you mentioned, however).
> Anyway, it'd start off with three human 'cities', each having their own self
> imposed and enforced political structure, with anyone murdering being hunded
> down and tried and put to death if guilty etc. There'd also be a band or
> several bands of outcasts, who don't live in any of the cities and instead
> live in the wilderness. They may make alliances with one of the cities so
> that in exchange for food and weapons they make regular attacks on one of the
> other cities, etc.
>
> The environment around these cities would be very hostile, and mobs would
> behave more like real animals where they'd have motivations (current hunger,
> hit points, thirst, curiosity, aggression, etc factors) and places they like
> and dislike going (maybe someone attacked them in a certain grove and while
> they survived they were badly hurt and are now scared of that area) but
> aren't tied to a particular area. They'd also be capable of breeding, thus
> increasing their numbers, and of being killed off outright, never to be seen
> on the face of the world again. So if there was a particularly nasty tribe
> of goblins living near one of the cities which was proving to be a major
> headache to the inhabitants, they could mount a full scale assault and
> permanently destroy the goblin tribe.
This is *very* difficult to balance correctly. How do you ensure that the
goblins don't get wiped out within a couple of hours by GoPers? How do you
ensure that the goblins themselves don't destroy the cities?
> "Combat" will also be heavily stylised so that while a tough warrior could
> kill several goblins quite easily, if a couple of lucky hits from the goblins
> get through, then the warrior may be hurt enough so that he's not as
> effective in combat, and the goblins could then swamp him in shear numbers.
> Thus team efforts, hence group interaction, hence roleplaying, can be
> encouraged as while they may hurt one warrior, the other one could fend them
> off while the injurred warrior pulls out his precious potion of healing
> before joining in again.
I've still not finished my combat system, but I'm trying to create something
similar to what you describe. So far my combat system allows players to split
their combat 'dice' between attack, parry and dodge. Every quarter of a second
each player gets an extra dice (up to their maximum according to fighting
ability). Upon the ATTACK dice reaching a certain point (specified by the
player), they begin to execute an attack (just a standard attack for now, although
I intend to add a huge range of different types). The attack takes an amount of
time to connect depending on various aspects of the fighter, and the target gets
a parry or dodge (whichever is higher - although if you are unarmed you can only
parry an unarmed attack). Most people pump all of their dice into attack and
either parry or dodge - there is no point having both unless you are fighting a
group (or a *very* fast attacker - or you've customised your dice to only refill
your attack pool). If you attempt to kick someone, it will use however many
dice you currently have spare in your attack pool (so people who kick a lot might
for example choose to have 5 attack dice, and use 4 per attack - meaning that
they always have at least 1 die spare for a kick - worthwhile if your opponent
is concentrating on one form of defence and pumps their entire defence pool into
each parry/dodge). In addition to this, wound penalties subtract directly from
your total fighting dice, there are 120 different fighting stances which boost
various areas of skill, and weapons with different difficulties to hit and bonus
damage dice, making combat a little more interesting than most diku's. Bare in
mind that the characters ability in combat is the combination of 4 attributes
and 2 abilities (of which a starting character can match most long-term characters),
which means that the results of combat are much more in the hands of the players
rather than the characters.
> I think the biggest thing I want to achieve is having no set way of being the
> best at anything. I want all the characters to be different in every way.
I've tried to have no set way of being the best at EVERYTHING rather than
anything - players can choose to max out in a few areas, but they'll suffer
when it comes to other areas.
The difficulty is in doing it without setting artificial restraints. My players
have an overall cap within each type of attribute and ability, but that's almost
as unrealistic as level-based equipment in terms of it's method of limitation.
> From computer generated descriptions based on what someone looks like, what
> they're wearing etc. through to the choices people make about how it's best
> to gain power.
I have computer generated descriptions, and they work out quite well IMO. A
particularly nice advantage of this system is that if a player transforms into
a wolf (for example), his/her description is altered to reflect the new form.
Equally, mobs are given the same sorts of descriptions as players, blurring
the different significantly - which has unfortunately resulted in two newbies
throwing themselves onto my blade so far, thinking I was a mob *sigh*.
> Please send as much feedback to me as possible so I can design as much as
> possible before even sitting down at my keyboard. The biggest problem I can
> see with my plans is the cpu time it's going to eat on the server. But
> hopefully by the time it's finished i'll have my own computer on the net so I
> won't have to worry about cpu hogging or using too much ram. I want every
> mob to be a seperate entity, permanently active (although they'll need to
> sleep - convieniently halving cpu time, and they can do repetative actions
> like eating for long periods). I hope I can make it all work!
I think it's a great idea (but then I'm trying to do exactly the same thing).
I don't think you'll have much trouble with cpu usage, except possibly for the
mobs - but there are many ways to get around this.
> Anyways, send all ideas to me or the list. I'll try and check in tomorrow and
> see what you've sent.
KaVir.
Richard Woolcock
>
> Replying mainly comments about my mud, because it's very similiar to what
> you are planning.
I might as well flame myself before someone else does it for me.
Apparently my grammar is as poor as my spelling ;)
KaVir
Terrence Reidley
Hosting it.. *drools* It sounds like you haven't just woken up and
said, Oh hey.. I'm goign to build a new style of MUD today etc..
Can you keep us informed on any developments etc? Even possibly
Developing your Own style and posting the Source for others to Develop
as well..
But I think you get my point, I WANT IN!!!!
Terrence Reidley
<BIG SNIP>
my...@my-dejanews.com
Richard Woolcock <Ka...@nospam.dial.pipex.com> wrote:
> Replying mainly comments about my mud, because it's very similiar to what
> you are planning.
:) Appology accepted about the grammar :) Mine's worse though.
> my...@my-dejanews.com wrote:
> >
> I use a permanent body-death system; if you die, your soul lives on (OOC name,
> total exp, authorisation, etc) but you are required to create a new body and
> go around re-learning skills from other players (although you do at least
start
> with a % of your soul's experience points with which to train up
skills/stats).
Certainly a good halfway house, but there's still the roleplaying problem of
players holding a grudge on their killer and wanting to get revenge. Which
isn't really very good roleplaying. All things considered. But as far as I
can see, there isn't a solution to that without imposing very artificial
constraints on not letting the player kill their murderer at all. And that's
not acceptable really.
> > [big snip of stuff I wrote]
> Interesting - although it might well end up like a text-based 'gauntlet' style
> game if you're not careful. I have an ascii-map option, but it only shows the
> surrounding few rooms (no mobs or objects).
That's my biggest fear. While it may make a fun game, it'd hardly have depth
of play or lastability, etc. So I'd rather make a mud than a networked
text-based gauntlet.
I don't suppose just decreasing the frequency of mobs and increasing how tough
they are would help?
Hopefully by increasing the complexity of the environment, and actively
encouraging political rather than physical power, then it won't end up just
another hack'n'slash gauntlet game.
> > [Snip]
> > Although the more I think about it, the worse I think it'd be for a role
> > playing environment where descriptions are more important than 2D space.
> > Then again the flexibilty of the moria like map for allowing real time
> > editing by all players of the environment around them could open up many
> > interesting possibilities.
>
> You could still allow players to modify their environment - the problem is
> trying to cater for room descriptions. The room description should update
> itself to reflect the fact that the forest has been chopped down, that the
> plains have been dug up, and so on. I'm still having trouble trying to get
> my mud to create 'artistic' rather than simply 'accurate' room descriptions,
> but if you stuck purely to a map you shouldn't have much trouble (this would
> still leave you wiht the roleplaying problem you mentioned, however).
In my experience of computers they're much better at being 'accurate' than
'artistic' which is where the map would come into it's own. You could cast
an earthquake spell, dislodging some rocks and permanently block off a
corridor, or fill in the corner of a room. Getting a computer to alter a
room description to reflect that would be next to impossible.
> > Anyway, it'd start off with three human 'cities', each having their own self
> > imposed and enforced political structure, with anyone murdering being hunded
> > down and tried and put to death if guilty etc. There'd also be a band or
> > several bands of outcasts, who don't live in any of the cities and instead
> > live in the wilderness. They may make alliances with one of the cities so
> > that in exchange for food and weapons they make regular attacks on one of
the
> > other cities, etc.
> >
> > The environment around these cities would be very hostile, and mobs would
> > behave more like real animals where they'd have motivations (current hunger,
> > hit points, thirst, curiosity, aggression, etc factors) and places they like
> > and dislike going (maybe someone attacked them in a certain grove and while
> > they survived they were badly hurt and are now scared of that area) but
> > aren't tied to a particular area. They'd also be capable of breeding, thus
> > increasing their numbers, and of being killed off outright, never to be seen
> > on the face of the world again. So if there was a particularly nasty tribe
> > of goblins living near one of the cities which was proving to be a major
> > headache to the inhabitants, they could mount a full scale assault and
> > permanently destroy the goblin tribe.
>
> This is *very* difficult to balance correctly. How do you ensure that the
> goblins don't get wiped out within a couple of hours by GoPers? How do you
> ensure that the goblins themselves don't destroy the cities?
A big problem. But what if the goblins do destroy one of the cities? That
just increases inter-city role playing potential. And if someone manages to
destroy the goblins within a couple of hours (something I hope to prevent in
the combat engine) then so be it. But what if a couple of the goblins
survive, and form a new and unknown goblin city.
I hope to have enough flexibility in the system to have a virtual world,
rather than a series of rooms which reset every 15 minutes. It's going to be
hard though, and may fail.
Very interesting ideas. The combat system I was designing takes some of the
better ideas from the, albeit unfinished and imbalanced, Dark Heart combat
engine. Every limb on the body is treated independantly, and can attack at
different rates, (parrying, dodging etc slows down the time before you can
next attack). It worked on a points based system, where it takes so many
points to attack, so many to block etc. Every round every limb would gain x
number of points based on the characters skills, abilities, and attributes.
When they had enough to attack, that limb would pay it's x number of points
and then make an attack roll (i want to devise a new attack roll system,
rather than rely on a tweaked AD&D system like every other mud). If it gets
a hit in, then your oponent has a chance to parry or dodge your attack and
pay the appropriate points. Failing that then damage is dealt out as usual.
On very good attack rolls you had a chance to cut off a limb from your
opponent etc.
The combat system also took into account the size of weapons, size of the two
combatants, and the current distance between them. For example if a knight
was to attack a dragon using a sword and a dagger as his two weapons, then
the dragon could us it's size to drive him back out of attacking distance,
and attack him from range. However if the knight managed to dodge the
dragons attack he could charge up close to the dragon before it had chance to
back away. At such close quarters the dragon would find it hard to attack the
night and maneuver to dodge attacks and the knight would stand a chance
(until it breathed or took off). Again, if two knights with swords and
daggers were to attack, then while standing off and attacking from a distance
using the swords they couldn't reach their opponent with the daggers, they
could still use these second weapons to parry incomming sword blows.
It all got hideously over complicated and never quite worked right, but if
planned properly it **could** work well.
> > I think the biggest thing I want to achieve is having no set way of being
the
> > best at anything. I want all the characters to be different in every way.
>
> I've tried to have no set way of being the best at EVERYTHING rather than
> anything - players can choose to max out in a few areas, but they'll suffer
> when it comes to other areas.
>
> The difficulty is in doing it without setting artificial restraints. My
players
> have an overall cap within each type of attribute and ability, but that's
almost
> as unrealistic as level-based equipment in terms of it's method of limitation.
Yeah, I misphrased that. I meant everything, not anything. Although it
would be good if you could make some skills so complicated that noone would
ever truely master every aspect of them. Hmmmm.... that gives me an idea.
I'll get back to you on that.
> > From computer generated descriptions based on what someone looks like, what
> > they're wearing etc. through to the choices people make about how it's best
> > to gain power.
>
> I have computer generated descriptions, and they work out quite well IMO. A
> particularly nice advantage of this system is that if a player transforms into
> a wolf (for example), his/her description is altered to reflect the new form.
> Equally, mobs are given the same sorts of descriptions as players, blurring
> the different significantly - which has unfortunately resulted in two newbies
> throwing themselves onto my blade so far, thinking I was a mob *sigh*.
Heh. That's the plan (not the newbie killing bit though :)
I was also trying to think of ways to increase the scope for this by not
automatically assigning names to people. Thus blurring mobs and players even
more, and making disguising yourself all the more fun. Players could then
assign names to certain descriptions, and the computer could make checks to
see if someones appearance is close enough to fool them as to who they were.
That needs a lot more thought though (and a hell of a large number of
combinations of descriptions making up what someone looks like).
> > [Snip]
> [Snip]
> > Anyways, send all ideas to me or the list. I'll try and check in tomorrow
and
> > see what you've sent.
>
> KaVir.
John Adelsberger
: an LP mud, or really used one properly so I don't know how close that
: description is to being like an LP).
I suggest you learn more about MudOS and/or DGD... what you're proposing
sounds like an incredible duplication of effort. I haven't looked at it
in awhile now, but Cold might be more to your liking if you've a
background in muds built around database engines. Regardless, even if
you _do_ have a legitimate need to put parts of your game into the
hardcoded engine(I bet you don't, but I don't know for sure...) it'd be
easier to start with one of these than to write your own from scratch,
by far...
--
John J. Adelsberger III
j...@umr.edu
"Civilization is the process of setting man free from men."
- Ayn Rand
my...@my-dejanews.com
John Adelsberger <j...@umr.edu> wrote:
> In rec.games.mud.admin my...@my-dejanews.com wrote:
>
> : an LP mud, or really used one properly so I don't know how close that
> : description is to being like an LP).
>
> I suggest you learn more about MudOS and/or DGD... what you're proposing
> sounds like an incredible duplication of effort. I haven't looked at it
> in awhile now, but Cold might be more to your liking if you've a
> background in muds built around database engines. Regardless, even if
> you _do_ have a legitimate need to put parts of your game into the
> hardcoded engine(I bet you don't, but I don't know for sure...) it'd be
> easier to start with one of these than to write your own from scratch,
> by far...
From what I've seen of MudOS (which isn't that much I'll admit), it doesn't
do quite what I want, uses up too much of the systems resources compared to
what I need, and would probably take me as long to rework as it would to
write from scratch. Especially as I'd have to learn a new system on a mud
I'd never played before with a new way of doing things with it's own quirks
and oddities.
But it's worth a thought I guess.
Cheers,
dk...@hearst.com
now. I figured that I can share some thoughts.
In article <6pnbjn$ksm$1...@nnrp1.dejanews.com>,
my...@my-dejanews.com wrote:
> Hmmmm.... I was acutally thinking about making death permanent, but with ways
> of escaping from actually being killed. I still need to think about that a
> lot more, but certainly the way death is treated is central to players
> attitudes towards killing and hence to roleplaying. If death is treated
> lightly then it will happen all the time which would probably inhibit
> roleplaying as death should be the last resort as it wouldn't always further
> your cause.
One of my thoughts about death is. You will never stop people from trying to
get revenge. If you make death permanent, you will have completely unrelated
characters chasing others around just because someone killed his/her last
incarnation. My idea is to make the penalty death brings so tough that people
will think 14-15 times before going to some real dangerous place. More than
that I think that the penalty should be more and more tough with rising in
power, meaning that a newbie should be able to recover from death rather
quickly but a baron or king should lose a lot for getting himself killed.
>
> I'm also toying with the idea of building this new mud around an experimental
> engine I wrote a while back which represented the map in a style similar to
> the old moria and nethack games using ascii graphics to show a 2D map of the
> players location. You could then jump in and out of command mode and
> movement mode so you can use the keypad to move around quickly and single key
> presses to open doors and such like, and then enter complex commands like
> chanting out the appropriate syllables for a spell while holding the correct
> spell components. If lag wasn't a problem and a good enough interface could
> be built then I think it would work very well, and allow for more complicated
> geographical settings, while retaining the command line and optional area
> descriptions for certain rooms etc (appearing in a text box above the map) to
> enhance the role playing side of the game. I'd be very interested in what
> people think of this, as while I know it'd work very well for a hack'n'slash
> mud, I'm not sure it would work quite so well for role playing.
>
I would say I don't really like this 2D idea. I don't think it will enhance
RP in any way and it will make a mess of MUD client config. It could be a
good idea if there was an option to print map of places where you have been,
but I dont think allowing to walk through it is a good idea.
Jeld
Dont flame me too hard
Christopher L Tompkins
is out there now does not offer quite the quality, nor the variety, of
'role-playing' that I seek. So I have decided to create it myself.
This conversation has brought many interesting ideas, not to mention
encouragement. It is good to see others out there that have the same
opinions about the current scene that I have. Anyway...
< About - "DEATH">
Having DEATH as a final state is such a harsh setup, but I feel it is
almost neccessary, for it does encourage caution over carelessness, and
groups and/or clans to band together more often than not toward common
goals. But how easily should complete death be for an individual? Why can't
you have players decay away just like the mobs? Just provide some sort of
time delay in which help could arrive to heal, or resserect the body before
it decomposes. Also throw in some sort of diety factor, through actions
and/or donations for their god/ess, the player recieves faith points, and
this is used for help from the diety when needed. Anything from alerting
nearby players of the same faith that you need help, to teleporting you to
safety just before you die, to the diety actually bringing you back to life
himself/herself, All depending on the points you have earned through your
adventures. Being actions in the name of the diety, sacrifices, donations,
converting others toward the diety, or even holy quests. This will help
players avoid DEATH as much as possible without being so unrealistic or out
of the fantasy context. But if DEATH were to come and the player were to
decay, then, DEATH should be final, THE END.
< About - "FLEXIBLE ROOM DESCRIPTIONS">
This idea has also crossed my mind, though actually implementing it is
quite a challenge and there are some questions as to should it be done or
not. The way most MUD's are now, the room description is static and never
changes. What if weather or actions of players could affect the room and
the description could change accordingly. Such as, when it rains, puddles
are now on the ground, the trees are wet, and the dirt is now mud. Or as
someone mentioned earlier, if a player chops down the trees, this should be
noted in the description for other players to see. But though this seems
the realistic way to go, should it be done? Many players map the lands and
use certain descriptions as landmarks or key points to guide by, if the
descriptions change while the players are wandering around, the confusion
and/or frustration that the players experience might turn them away. Like a
player who knows the path to the hidden cave is marked by an old oak tree
standing within a pine forest. If someone were to chop the old oak tree,
that landmark has now been destroyed. Again, it would be the realistic
thing to happen, but will it hurt the MUD rather than help it?
< About - "FLEXIBLE PLAYER DESCRIPTIONS">
This is also an interesting idea that has mixed opinions on whether or
not it should be done. I have been contemplating testing a system where all
creatures, being players and mobs, have a generic title that is displayed
when you see them in a room. Such as - In this room is a short,
dark-skinned man, a slender, robed woman, and a giant warrior riding a
warhorse. These 3 people could be other players, mob creatures, or NPC's
from the local town. They are all strangers and they are just as you see
them. These titles would be based on there current clothing or appearance.
They could be altered at a local tailor or similar place. You could then
have an INTRODUCE command which would introduce you to them, or could also
be used for you to introduce two people to each other, encouraging
conversation and role-playing. Once you have met someone, you always see
them as their name, instead of their title. Helping you recognize familiar
faces in a croud of strangers. Also allowing for possible skills for
thieves like disguises and/or impersinations. All that would be needed to
keep track of who knows who would be a 2-dimensional array of flags. Does
player 1 know player 235? If you wanted, this could be extended to actually
classify people you have met, labeling them as acquaintances, good friends,
mortal enemies, etc... And when you encounter them, the text is altered
accordingly. In the room you see John, your friend Bob, your blood-brother
Michael, and that evil-swine Robert. You get the idea.
Anyway that is all for now, my fingers are tired.
Thanks,
Christopher.
Richard Woolcock
>
> I am in the process of making my own MUD too. I am at mudlib design stage
> now. I figured that I can share some thoughts.
>
> In article <6pnbjn$ksm$1...@nnrp1.dejanews.com>,
> my...@my-dejanews.com wrote:
> > of escaping from actually being killed. I still need to think about that a
> > lot more, but certainly the way death is treated is central to players
> > attitudes towards killing and hence to roleplaying. If death is treated
> > lightly then it will happen all the time which would probably inhibit
> > roleplaying as death should be the last resort as it wouldn't always further
> > your cause.
>
> get revenge. If you make death permanent, you will have completely unrelated
> characters chasing others around just because someone killed his/her last
> incarnation.
Ah, but with an introduction system, how would you *know* who killed you? You
could probably find out, but it would require a fair bit of effort.
> My idea is to make the penalty death brings so tough that people
> will think 14-15 times before going to some real dangerous place. More than
> that I think that the penalty should be more and more tough with rising in
> power, meaning that a newbie should be able to recover from death rather
> quickly but a baron or king should lose a lot for getting himself killed.
But that doesn't get around the main purpose of permanent death in roleplaying
muds - the realism aspect. How do you explain the fact that the person you
just killed is back on their feet and wandering around? You could probably
think up a few different reasons - but the very fact that people can come back
will spoil a lot of roleplaying potential, for example what is the point in
arranging the assassination of your guildmaster (so that you can take his place)
if he'll just come back?
> > I'm also toying with the idea of building this new mud around an experimental
> > engine I wrote a while back which represented the map in a style similar to
> > the old moria and nethack games using ascii graphics to show a 2D map of the
> > players location. You could then jump in and out of command mode and
> > movement mode so you can use the keypad to move around quickly and single key
> > presses to open doors and such like, and then enter complex commands like
> > chanting out the appropriate syllables for a spell while holding the correct
> > spell components. If lag wasn't a problem and a good enough interface could
> > be built then I think it would work very well, and allow for more complicated
> > geographical settings, while retaining the command line and optional area
> > descriptions for certain rooms etc (appearing in a text box above the map) to
> > enhance the role playing side of the game. I'd be very interested in what
> > people think of this, as while I know it'd work very well for a hack'n'slash
> > mud, I'm not sure it would work quite so well for role playing.
> >
>
> I would say I don't really like this 2D idea. I don't think it will enhance
> RP in any way
Debatable - but having a realistic, well laid-out map is hardly going to detract
from roleplaying either.
> and it will make a mess of MUD client config. It could be a
Good! I don't want people botting in a roleplaying mud.
> good idea if there was an option to print map of places where you have been,
> but I dont think allowing to walk through it is a good idea.
All a matter of opinion. There are enough muds that do it the old way, I don't
see what loss there is in someone trying a new approach.
KaVir.
Richard Woolcock
>
> I also have started building a MUD-type game from scratch, feeling what
> is out there now does not offer quite the quality, nor the variety, of
> 'role-playing' that I seek. So I have decided to create it myself.
> This conversation has brought many interesting ideas, not to mention
> encouragement. It is good to see others out there that have the same
> opinions about the current scene that I have. Anyway...
>
> < About - "DEATH">
[snip as I agree]
> < About - "FLEXIBLE ROOM DESCRIPTIONS">
[snip]
> the realistic way to go, should it be done? Many players map the lands and
> use certain descriptions as landmarks or key points to guide by, if the
> descriptions change while the players are wandering around, the confusion
> and/or frustration that the players experience might turn them away. Like a
Some 'landmarks' never change, such as mountains, etc. With a map layout,
players can visualise their surrounding area which makes it easier to make
their way around. I don't really see what is wrong with having no set
landmarks - would you consider a mud 'bad' if it constantly removed old
areas and added new ones, forcing players to constantly explore?
The only problem I see with dynamic room descriptions is that you cannot
get the same 'artistic' level of room description.
> < About - "FLEXIBLE PLAYER DESCRIPTIONS">
>
> This is also an interesting idea that has mixed opinions on whether or
> not it should be done. I have been contemplating testing a system where all
> creatures, being players and mobs, have a generic title that is displayed
> when you see them in a room. Such as - In this room is a short,
[snip]
> thieves like disguises and/or impersinations. All that would be needed to
> keep track of who knows who would be a 2-dimensional array of flags. Does
An array is not the best way to do it - I'd recommend a linked list.
> player 1 know player 235? If you wanted, this could be extended to actually
> classify people you have met, labeling them as acquaintances, good friends,
> mortal enemies, etc... And when you encounter them, the text is altered
> accordingly. In the room you see John, your friend Bob, your blood-brother
> Michael, and that evil-swine Robert. You get the idea.
Nice idea, certainly better than my "(Like)"/"(Dislike)"/"(Hate)"/etc flags :)
KaVir.
Lewis Zephyr
<Ka...@nospam.dial.pipex.com> wrote:
>dk...@hearst.com wrote:
>>
>> I am in the process of making my own MUD too. I am at mudlib design stage
>> now. I figured that I can share some thoughts.
>>
>> In article <6pnbjn$ksm$1...@nnrp1.dejanews.com>,
>> my...@my-dejanews.com wrote:
>> > Hmmmm.... I was acutally thinking about making death permanent, but with ways
>> > of escaping from actually being killed. I still need to think about that a
>> > lot more, but certainly the way death is treated is central to players
>> > attitudes towards killing and hence to roleplaying. If death is treated
>> > lightly then it will happen all the time which would probably inhibit
>> > roleplaying as death should be the last resort as it wouldn't always further
>> > your cause.
>>
>> One of my thoughts about death is. You will never stop people from trying to
>> get revenge. If you make death permanent, you will have completely unrelated
>> characters chasing others around just because someone killed his/her last
>> incarnation.
>
>Ah, but with an introduction system, how would you *know* who killed you? You
>could probably find out, but it would require a fair bit of effort.
Possible solution to this is if killed by a player get a flag to
release their info unless they were sneaking and killed you in one
blow. Like an asassin job.
I do also think that at some point a person should not be able to come
back from the dead. This would allow for caution.
>
>> My idea is to make the penalty death brings so tough that people
>> will think 14-15 times before going to some real dangerous place. More than
>> that I think that the penalty should be more and more tough with rising in
>> power, meaning that a newbie should be able to recover from death rather
>> quickly but a baron or king should lose a lot for getting himself killed.
>
>But that doesn't get around the main purpose of permanent death in roleplaying
>muds - the realism aspect. How do you explain the fact that the person you
>just killed is back on their feet and wandering around? You could probably
>think up a few different reasons - but the very fact that people can come back
>will spoil a lot of roleplaying potential, for example what is the point in
>arranging the assassination of your guildmaster (so that you can take his place)
>if he'll just come back?
A possible skill for an asassin is to do a non revivable death. ie
after death mutilate the corpse, or a special weapon that sucks the
soul. (one time use only) etc.
>
>> > I'm also toying with the idea of building this new mud around an experimental
>> > engine I wrote a while back which represented the map in a style similar to
>> > the old moria and nethack games using ascii graphics to show a 2D map of the
>> > players location. You could then jump in and out of command mode and
>> > movement mode so you can use the keypad to move around quickly and single key
>> > presses to open doors and such like, and then enter complex commands like
>> > chanting out the appropriate syllables for a spell while holding the correct
>> > spell components. If lag wasn't a problem and a good enough interface could
>> > be built then I think it would work very well, and allow for more complicated
>> > geographical settings, while retaining the command line and optional area
>> > descriptions for certain rooms etc (appearing in a text box above the map) to
>> > enhance the role playing side of the game. I'd be very interested in what
>> > people think of this, as while I know it'd work very well for a hack'n'slash
>> > mud, I'm not sure it would work quite so well for role playing.
>> >
>>
>> I would say I don't really like this 2D idea. I don't think it will enhance
>> RP in any way
>
>Debatable - but having a realistic, well laid-out map is hardly going to detract
>from roleplaying either.
Agreed
>
>> and it will make a mess of MUD client config. It could be a
>
>Good! I don't want people botting in a roleplaying mud.
>
>> good idea if there was an option to print map of places where you have been,
>> but I dont think allowing to walk through it is a good idea.
>
>All a matter of opinion. There are enough muds that do it the old way, I don't
>see what loss there is in someone trying a new approach.
>
>KaVir.
Again, agreed.
Richard Woolcock
>
> On Mon, 03 Aug 1998 19:46:20 -0700, Richard Woolcock
> <Ka...@nospam.dial.pipex.com> wrote:
>
> >dk...@hearst.com wrote:
> >>
> >> I am in the process of making my own MUD too. I am at mudlib design stage
> >> now. I figured that I can share some thoughts.
> >>
> >> In article <6pnbjn$ksm$1...@nnrp1.dejanews.com>,
> >> my...@my-dejanews.com wrote:
> >> > of escaping from actually being killed. I still need to think about that a
> >> > lot more, but certainly the way death is treated is central to players
> >> > attitudes towards killing and hence to roleplaying. If death is treated
> >> > lightly then it will happen all the time which would probably inhibit
> >> > roleplaying as death should be the last resort as it wouldn't always further
> >> > your cause.
> >>
> >> get revenge. If you make death permanent, you will have completely unrelated
> >> characters chasing others around just because someone killed his/her last
> >> incarnation.
> >
> >Ah, but with an introduction system, how would you *know* who killed you? You
> >could probably find out, but it would require a fair bit of effort.
>
> Possible solution to this is if killed by a player get a flag to
> release their info unless they were sneaking and killed you in one
> blow. Like an asassin job.
Well actually I was referring to the anonymity of the introduction system as
an advantage - if someone kills you, you *shouldn't* know who they are with
your next character.
> I do also think that at some point a person should not be able to come
> back from the dead. This would allow for caution.
I don't think people should be able to come back at all in a roleplaying mud,
with very rare exceptions for certain themes.
KaVir.
Erin Mulder
idea. There's nothing magical about introductions. There's no reason they
should have to have a command and be reciprocal in order to work.
I much prefer:
You are in a tavern. There is a short dwarf standing here.
>look dwarf
This short, redbearded dwarf looks rather belligerent.
>label dwarf Redbeard
The short dwarf will now be known as "Redbeard"
>look
You are in a tavern. Redbeard is standing here.
This way, you can recognize someone even if you've never spoken to them, so
long as you've gotten a good look at them. Also, if two people introduce
themselves, they can simply label each other with the names they exchange
(which allows a player to give a false alias). If they don't spend the time to
do that, then they likely won't recall each other again very easily.
Hey.. it's how real memory works. In my game, your memory is limited as well.
In the beginning, you can recall the descriptions of people you've recently met
or who you've seen often (or made an effort to remember). Over time, if you
haven't seen someone in a while, you start forgetting details, until you
finally get to the point where you won't recognize them unless you see them (no
recall allowed). Eventually, you can forget someone altogether.
Meara
Christopher L Tompkins wrote:
> I also have started building a MUD-type game from scratch, feeling what
> is out there now does not offer quite the quality, nor the variety, of
> 'role-playing' that I seek. So I have decided to create it myself.
> This conversation has brought many interesting ideas, not to mention
> encouragement. It is good to see others out there that have the same
> opinions about the current scene that I have. Anyway...
>
> < About - "DEATH">
>
> Having DEATH as a final state is such a harsh setup, but I feel it is
> almost neccessary, for it does encourage caution over carelessness, and
> groups and/or clans to band together more often than not toward common
> goals. But how easily should complete death be for an individual? Why can't
> you have players decay away just like the mobs? Just provide some sort of
> time delay in which help could arrive to heal, or resserect the body before
> it decomposes. Also throw in some sort of diety factor, through actions
> and/or donations for their god/ess, the player recieves faith points, and
> this is used for help from the diety when needed. Anything from alerting
> nearby players of the same faith that you need help, to teleporting you to
> safety just before you die, to the diety actually bringing you back to life
> himself/herself, All depending on the points you have earned through your
> adventures. Being actions in the name of the diety, sacrifices, donations,
> converting others toward the diety, or even holy quests. This will help
> players avoid DEATH as much as possible without being so unrealistic or out
> of the fantasy context. But if DEATH were to come and the player were to
> decay, then, DEATH should be final, THE END.
>
> < About - "FLEXIBLE ROOM DESCRIPTIONS">
>
> This idea has also crossed my mind, though actually implementing it is
> quite a challenge and there are some questions as to should it be done or
> not. The way most MUD's are now, the room description is static and never
> changes. What if weather or actions of players could affect the room and
> the description could change accordingly. Such as, when it rains, puddles
> are now on the ground, the trees are wet, and the dirt is now mud. Or as
> someone mentioned earlier, if a player chops down the trees, this should be
> noted in the description for other players to see. But though this seems
> the realistic way to go, should it be done? Many players map the lands and
> use certain descriptions as landmarks or key points to guide by, if the
> descriptions change while the players are wandering around, the confusion
> and/or frustration that the players experience might turn them away. Like a
> player who knows the path to the hidden cave is marked by an old oak tree
> standing within a pine forest. If someone were to chop the old oak tree,
> that landmark has now been destroyed. Again, it would be the realistic
> thing to happen, but will it hurt the MUD rather than help it?
>
> < About - "FLEXIBLE PLAYER DESCRIPTIONS">
>
> This is also an interesting idea that has mixed opinions on whether or
> not it should be done. I have been contemplating testing a system where all
> creatures, being players and mobs, have a generic title that is displayed
> when you see them in a room. Such as - In this room is a short,
> dark-skinned man, a slender, robed woman, and a giant warrior riding a
> warhorse. These 3 people could be other players, mob creatures, or NPC's
> from the local town. They are all strangers and they are just as you see
> them. These titles would be based on there current clothing or appearance.
> They could be altered at a local tailor or similar place. You could then
> have an INTRODUCE command which would introduce you to them, or could also
> be used for you to introduce two people to each other, encouraging
> conversation and role-playing. Once you have met someone, you always see
> them as their name, instead of their title. Helping you recognize familiar
> faces in a croud of strangers. Also allowing for possible skills for
> thieves like disguises and/or impersinations. All that would be needed to
> keep track of who knows who would be a 2-dimensional array of flags. Does
> player 1 know player 235? If you wanted, this could be extended to actually
> classify people you have met, labeling them as acquaintances, good friends,
> mortal enemies, etc... And when you encounter them, the text is altered
> accordingly. In the room you see John, your friend Bob, your blood-brother
> Michael, and that evil-swine Robert. You get the idea.
>
Erin Mulder
my...@my-dejanews.com
Richard Woolcock <Ka...@nospam.dial.pipex.com> wrote:
> Lewis Zephyr wrote:
> >
> > On Mon, 03 Aug 1998 19:46:20 -0700, Richard Woolcock
> > <Ka...@nospam.dial.pipex.com> wrote:
> >
> > >dk...@hearst.com wrote:
> > >>
> > >> I am in the process of making my own MUD too. I am at mudlib design stage
> > >> now. I figured that I can share some thoughts.
> > >>
> > >> In article <6pnbjn$ksm$1...@nnrp1.dejanews.com>,
> > >> my...@my-dejanews.com wrote:
with ways
> > >> > of escaping from actually being killed. I still need to think about
that a
> > >> > lot more, but certainly the way death is treated is central to players
> > >> > attitudes towards killing and hence to roleplaying. If death is
treated
> > >> > lightly then it will happen all the time which would probably inhibit
> > >> > roleplaying as death should be the last resort as it wouldn't always
further
> > >> > your cause.
> > >>
to
> > >> get revenge. If you make death permanent, you will have completely
unrelated
> > >> characters chasing others around just because someone killed his/her last
> > >> incarnation.
> > >
> > >Ah, but with an introduction system, how would you *know* who killed you?
You
> > >could probably find out, but it would require a fair bit of effort.
> >
> > Possible solution to this is if killed by a player get a flag to
> > release their info unless they were sneaking and killed you in one
> > blow. Like an asassin job.
>
> Well actually I was referring to the anonymity of the introduction system as
> an advantage - if someone kills you, you *shouldn't* know who they are with
> your next character.
>
> > I do also think that at some point a person should not be able to come
> > back from the dead. This would allow for caution.
>
> I don't think people should be able to come back at all in a roleplaying mud,
> with very rare exceptions for certain themes.
>
> KaVir.
>
I agree whole heartedly. It would certainly aid the roleplaying if people
weren't sure who killed them. That way they couldn't hold a grudge.
But I propose taking the introduce thing a little further. I agree with
using a lable like command to lable players with names, so you can use any
personal alias you choose for them, but as I will be using generated
descriptions of people, rather than just store a player number store what
their description is, and have memory fade over a long time of not seeing
them. So you could have things like "you see someone who you think is Peter,
but you're not too sure". That way if someone has a particularly bad fight
and ends up with a nasty scar then you may have problems recognising them.
You can then update your memory of them using the lable command a second
time.
Righty then, back to death. I believe strongly in permanent death, but I
think it should be hard to kill people out right. In the combat engine I
want to develope, most attacks will be blocked, or will hit your armour
damaging it, but a particularly good hit, or a hit on an unprotected part of
the body will result not in a few hit points being knocked off, but that part
of the body being severly injurred or maybe cut off completely. And if
anyone wants to argue about it then I'll happily ram a dagger into their arm
and ask if it feels like 1d4 points of damage :)
I want to try to balance it so it's very hard to hit a properly protected and
skilled fighter, but if you do hit them, then they're in trouble as they're
going to get hurt. One good slice across the neck should kill anyone, no
matter how many levels (which I'm not implimenting I hasten to add) they
have. At the same time if a dog charges at you and you club it one with your
mace, it'd either die, get knocked out, get enraged, or run away. Thats the
kind of thing I want to have in my mud. Not these silly 17 mud hour long
fights between an appretice warrior and some rabid dog he found in a gutter
somewhere.
[insert from another post]
> > I would say I don't really like this 2D idea. I don't think it will enhance
> > RP in any way
>
> Debatable - but having a realistic, well laid-out map is hardly going to
> detract from roleplaying either.
And it gives more importance to placing in 2D space. If you use the say
command, maybe everyone in a 5 square radius can hear you, but use the
whisper command then maybe only people within 2 squares will be able to hear.
Thus the thief hiding in the corner of the room could hear two people
talking, but when they say a really important bit of information, one may
whisper to the other, just as a precaution, thus the thief cannot make out
what was said.
Area attacks on spells and ranged attacks with spells and missle weapons can
also be greatly enhanced. And the potential for people building their own
homes and such like is there as you don't have to police them to check people
aren't writing stupid room descriptions. They can just build their home and
live in it.
> > and it will make a mess of MUD client config. It could be a
>
> Good! I don't want people botting in a roleplaying mud.
botting would be virtually impossible, thank god, but the only other problem
would be with clients not supporting ansi properly, and more specifically
cursor movement via ansi control codes. If the mud is successful though, I
will try and get in touch with people like the makers of zMud to work
something out so their clients will work 100% in that respect.
> > good idea if there was an option to print map of places where you have been,
> > but I dont think allowing to walk through it is a good idea.
I'm taking a guess, but you probably haven't tried anything like it before.
Try out either moria or nethack or a game like it. I think the map works
really well, and the thought of it being multiplayer with a lot of mud
features and a huge map etc. sounds really appealing to me.
> All a matter of opinion. There are enough muds that do it the old way, I
> don't see what loss there is in someone trying a new approach.
>
> KaVir
I couldn't agree more. There's enough people out there doing the old
"everyone else does it like this, so we'll fall in line" bit, so I want to go
against the flow.
John Adelsberger
: From what I've seen of MudOS (which isn't that much I'll admit), it doesn't
: do quite what I want, uses up too much of the systems resources compared to
: what I need, and would probably take me as long to rework as it would to
: write from scratch.
I've seen a modern MudOS lib running 15-25 users on a 486 25Mhz machine
in 16 megs of RAM, with the cost of a user running somewhere around
50k of memory and the CPU sitting idle about a third of the time. If you
get an interpreter going that can come anywhere close to MudOS's
performance, I'll be downright amazed. (Without using tricks like JIT
and dynamic profile directed optimization(read: HotSpot,) the Java
crowd has yet to do it, and they've got more time and money than you do:)
What you saw was most probably an old driver running a crappy lib. In
order to get the kind of performance I note above, you'd need a custom lib,
since the one I saw is not available, but if you have the skill to build
your own interpreter, a mudlib should be easy, and far less time
consuming than starting from scratch...
Lewis Zephyr
>In article <35C697...@nospam.dial.pipex.com>,
<<snip>>
>I agree whole heartedly. It would certainly aid the roleplaying if people
>weren't sure who killed them. That way they couldn't hold a grudge.
>
>But I propose taking the introduce thing a little further. I agree with
>using a lable like command to lable players with names, so you can use any
>personal alias you choose for them, but as I will be using generated
>descriptions of people, rather than just store a player number store what
>their description is, and have memory fade over a long time of not seeing
>them. So you could have things like "you see someone who you think is Peter,
>but you're not too sure". That way if someone has a particularly bad fight
>and ends up with a nasty scar then you may have problems recognising them.
>You can then update your memory of them using the lable command a second
>time.
A question.... Lets say your new to the supposed mud. You come into
a room with multiple individuals (PC) and you do a look command.
how would the, say 8 people be listed in the response?
man1
man2
man3
woman1
woman2
elf man 1 etc etc..... so when conversation started I could tell
each from the other?
I'm sure it is just semantics but would like to see some view points.
<<snip>>
>
>> All a matter of opinion. There are enough muds that do it the old way, I
>> don't see what loss there is in someone trying a new approach.
>>
>> KaVir
>
>I couldn't agree more. There's enough people out there doing the old
>"everyone else does it like this, so we'll fall in line" bit, so I want to go
>against the flow.
>
>Chris
>
Right there with both of you.... Change is not always good, but sure
is nice to look at for a while.
Lewzephyr
Barry Zubel
I'd like to raise:
<DEATH>
Yep, its a big problem. Dying in muds in extremely commonplace, however. How
many players of Muds can actually say they have a character who has NEVER
died? I suspect a minute proportion of you might be able to answer 'yes' -
Is this going to attract new players, making sure that before they learn
what 'con' is, they've died and had to start again with a new char?
I don't have a solution, I wish I did.. but I agree with the fact that dying
and simply repopping at the Temple isn't realistic....
HOWEVER.......
<REALISM>
*WHY* are we discussing the level of realism in a mud? - when was the last
time you 'teleported' to work, instead of taking the bus or car? When was
the last time you paralyzed the barman of your local and got your own
drinks? When was the last time you felt a little bit down, so you cast 'cure
light' ? - MUDS are *NOT* realistic... I do agree that muds do need an
element of realism.. but lets not get bogged down with it. Yeah - you need
to eat, you need to sleep.. (and on that theme, have your mud characters
ever used the bathroom?)
but do we really need to code in arguments with mud-spouses... or female PCS
that suffer from 'that time of the month' ? (hmm.. digress.. it could give
them attack bonuses like frenzy... *scribble in notepad* )
I'm not looking to get flamed here, but I do think that a MUD is designed to
be escapism from the real world. I'm totally for revamping the way muds
run - too many stock muds around that don't offer anything new, but trying
to code in a mud that mirrors real life in all ways would be.. well..
pointless
<NETHACK>
All I can say is WOW. I can remember playing 10rogue, nethack, and omega
many years ago, and loving it. If Quake can be run over the internet, then
why not something a lot less bandwidth hungry, and a lot more sociable. If
you need coders, I'm definately in on this one.
I do believe, however, that the generic clients around nowadays would have
*big* problems with it. I am guessing that you would need some kind of
custom client, or heavily modified client to handle that sort of server. But
hey, ever seen anyone playing Quake using telnet as a client?
My first thought was that you wouldn't get the kind of custom 'feel' of the
place as you do with a text-based description mud. You wouldn't get
different 'flavours' of area (i.e. an ocean, or a desert) - but then I cast
my mind back to Omega. (I dont know if anyone is familiar with this game,
its pretty old.) They handled it with a two stage map, where, for example,
on the large area map, a city would be replaced by a single character, which
you moved over and 'entered' which brought you to a more detailed map of the
city itself. The large area had different ascii characters for dfferent
types of terrain on the large map, (a . for a road, a ~ for water etc.) and
the 'zoomed' map was more lacking in terrain, but made up in detailed "d
buildings, etc. etc. Yeah... the more I think of it, the more I like the
idea.
Just my couple of points on this thread.
Barry Zubel
Penfold
joynt.vkresearch.com:4000
my...@my-dejanews.com wrote in message <6q6j28$g5k$1...@nnrp1.dejanews.com>...
my...@my-dejanews.com
Well I was working on the idea of running a map made of 100 by 100 sectors.
Each sector would be 100 by 100 squares. This would make for, uncompressed,
a total map of near enough 100 Mb, if 1 byte was all you needed per square.
I reckon I can make the map run ok with 1 byte per square permanently stored,
but for all the run time effects and overlays I want, I was looking at closer
to 9 bytes per square. So that's 100 Mb of disc space + 9 times that while
loaded into memory. Sectors could be dynamically loaded quite easily so only
a few need be active at a time, but when you've got thousands of mobs running
around, like I hope, then you can hopefully see how it's going to quickly
consume a lot of resources. Add to that a large game engine, and I think all
in all it'd be better to write a custom server from scratch. Especially with
the length of time it'd take me to learn mudos and then modify it etc.
Cheers anyway,
Richard Woolcock
>
> Having played on a MUD with an introduce command, I think it's a rather silly
> idea. There's nothing magical about introductions. There's no reason they
> should have to have a command and be reciprocal in order to work.
>
> I much prefer:
>
> You are in a tavern. There is a short dwarf standing here.
>
> >look dwarf
>
> This short, redbearded dwarf looks rather belligerent.
>
> >label dwarf Redbeard
>
> The short dwarf will now be known as "Redbeard"
>
> >look
>
> You are in a tavern. Redbeard is standing here.
I actually implemented this, then removed it. Having gone to great
lengths to try and separate IC and OOC (giving players a mud-generated
IC first/surname), I found that people would just tag each other with
that persons OOC name. This is one situation in which I decided that
my mud would benefit from a lack of realism. Players can now introduce
themselves by forename, surname, or both (they speak it out loud, so
everyone in the room knows).
[snip rest]
KaVir.
Richard Woolcock
>
> Whew.. Big thread, and extremely interesting. I do have a few points that
> I'd like to raise:
>
> <DEATH>
>
> Yep, its a big problem. Dying in muds in extremely commonplace, however. How
> many players of Muds can actually say they have a character who has NEVER
> died? I suspect a minute proportion of you might be able to answer 'yes' -
> Is this going to attract new players, making sure that before they learn
> what 'con' is, they've died and had to start again with a new char?
In a good roleplaying mud, you should be able to prosper without having to
ever engage in combat. If you want to fight, that should be an option - if
you then die, that's your own fault. Those who live by the sword, etc...
> I don't have a solution, I wish I did.. but I agree with the fact that dying
> and simply repopping at the Temple isn't realistic....
>
> HOWEVER.......
>
> <REALISM>
>
> *WHY* are we discussing the level of realism in a mud? - when was the last
> time you 'teleported' to work, instead of taking the bus or car? When was
> the last time you paralyzed the barman of your local and got your own
> drinks? When was the last time you felt a little bit down, so you cast 'cure
> light' ? - MUDS are *NOT* realistic... I do agree that muds do need an
That is an extremely poor argument, and one which often seems to crop up in
this sort of thread. In most muds, magic exists, therefore - within the
theme of the mud - casting spells *is* realistic. If the mud has a modern
day theme, then teleporting/etc might well be 'unrealistic' - equally, in
most muds, catching the bus would be 'unrealistic'.
> element of realism.. but lets not get bogged down with it. Yeah - you need
> to eat, you need to sleep.. (and on that theme, have your mud characters
> ever used the bathroom?)
I like to make my mud as realistic as possible within its theme (which happens
to be modern day, and no, you can't cast spells) as long as the code doesn't
detract from the gameplay. No, my players don't have to go to the bathroom.
> but do we really need to code in arguments with mud-spouses... or female PCS
> that suffer from 'that time of the month' ? (hmm.. digress.. it could give
> them attack bonuses like frenzy... *scribble in notepad* )
Sure, realism can be taken too far, but you are taking it to an extreme. I
could just as easily take the argument the other way - how about coding:
1) If a player opens a door, there is a 1% chance of a huge foot coming down
from the sky and squashing them flat - this can be avoided by wearing a
helmet with a spike on the top.
2) Every time a player gains a level, a stampede of elephants charge across the
mud, trampling anyone and anything in their way - except players riding giant
mice.
3) The most powerful item in the mud is, in fact, a rather small turnip - which
can be discovered by simply saying "wibble" while riding a yak in midgaard.
4) You never need to eat, sleep or drink, can consume as much alchohol as you
wish, and can never fall below 1hp (for convenience).
5) Bananas cannot be eaten, but make great weapons - sliced grapefruit and
small grapes are also quite effective.
Would you code any of those features into a (serious) roleplaying mud? If
not, why not? They are no less realistic than magic... but, unlike magic,
they (probably;) don't fit into the theme of most muds.
> I'm not looking to get flamed here, but I do think that a MUD is designed to
> be escapism from the real world. I'm totally for revamping the way muds
> run - too many stock muds around that don't offer anything new, but trying
> to code in a mud that mirrors real life in all ways would be.. well..
> pointless
That is why many muds choose a fantasy theme, in which magic IS realistic.
If you want a light-hearted mud, try a non-roleplaying mud; most roleplaying
muds try to be as realistic as possible within their themes to help players
feel as if they are playing in a believable alternate reality.
KaVir.
Lars Duening
> Whew.. Big thread, and extremely interesting. I do have a few points that
> I'd like to raise:
>
> <DEATH>
>
> Yep, its a big problem. Dying in muds in extremely commonplace, however. How
> many players of Muds can actually say they have a character who has NEVER
> died? I suspect a minute proportion of you might be able to answer 'yes' -
> Is this going to attract new players, making sure that before they learn
> what 'con' is, they've died and had to start again with a new char?
>
> I don't have a solution, I wish I did.. but I agree with the fact that dying
> and simply repopping at the Temple isn't realistic....
I favour the arcade game solution: you start out with n >= 3 lives, and
every 1000 points you get one life more to waste.
--
Lars Duening; la...@cableinet.co.uk
Peteris Paikens
>a room with multiple individuals (PC) and you do a look command.
>how would the, say 8 people be listed in the response?
I guess that it would be like in some LPMuds e.g
a tall hairy male dwarf,
a fat black-eyed female human,
a beautiful skinny elf called Galadriel (I don't remember this part, but
something like that.)
etc.
Xiad Ommeri
If you are a good programmer and you could halfway jusge whats going on with
code from watching cause and effect then you will have a hay day with this
mud.
Also I have yet to find a better one anywhere. (Though my attempt at
creating my own MUD wont even begin for another 6 months)
Dragonrealms has about everything anyone could have in a text based mud
which makes it difficult for me to create a MUD comparible to it.
For the past 2 years I have been playing it and have come to some
understanding of the basic structure of that particular Mud (Which for all
of my understanding is not a main-stream MUD, but a very well developed
custom job with rave reviews and Kudos from other areas as well.
An open request for any programming code relating to anything found in
Dragonrealms www.dragonrealms.net .
Thanks,
Xiad Ommeri
visi...@uswest.net
Christopher L Tompkins wrote in message
<01bdbeea$f3ca7b80$49201e26@brujah>...
my...@my-dejanews.com
Richard Woolcock <Ka...@nospam.dial.pipex.com> wrote:
> Erin Mulder wrote:
> >
> > Having played on a MUD with an introduce command, I think it's a rather
silly
> > idea. There's nothing magical about introductions. There's no reason they
> > should have to have a command and be reciprocal in order to work.
> >
> > I much prefer:
> >
> > You are in a tavern. There is a short dwarf standing here.
> >
> > >look dwarf
> >
> > This short, redbearded dwarf looks rather belligerent.
> >
> > >label dwarf Redbeard
> >
> > The short dwarf will now be known as "Redbeard"
> >
> > >look
> >
> > You are in a tavern. Redbeard is standing here.
>
> lengths to try and separate IC and OOC (giving players a mud-generated
> IC first/surname), I found that people would just tag each other with
> that persons OOC name. This is one situation in which I decided that
> my mud would benefit from a lack of realism. Players can now introduce
> themselves by forename, surname, or both (they speak it out loud, so
> everyone in the room knows).
>
> [snip rest]
>
> KaVir.
>
I dunno if it will work, but I was thinking about everyone logging on using a
user name, and then log on as a player from there. So their player name and
user name are seperate. That way they can choose a decent player name, yet
still have their favourite login name and password. That way they can also
have a first name and a surname for their character. Reckon it'd help at
all?
Larnen
>
> Barry Zubel wrote:
> >
> > HOWEVER.......
> >
> > <REALISM>
> >
> > *WHY* are we discussing the level of realism in a mud?
> Sure, realism can be taken too far, but you are taking it to an
> extreme. I could just as easily take the argument the other way -
> how about coding:
>
>
> 2) Every time a player gains a level, a stampede of elephants charge
> across the> mud, trampling anyone and anything in their way -
> except players riding giant mice.
>
Sounds an excellent idea to me!!!
Larnen (from Elephant Mud) :)
my...@my-dejanews.com
"Xiad Ommeri" <Nos...@mymail.now> wrote:
> I reccomend out of my experience to check out:
>
> www.dragonrealms.net
>
> If you are a good programmer and you could halfway jusge whats going on with
> code from watching cause and effect then you will have a hay day with this
> mud.
>
> Also I have yet to find a better one anywhere. (Though my attempt at
> creating my own MUD wont even begin for another 6 months)
>
> Dragonrealms has about everything anyone could have in a text based mud
> which makes it difficult for me to create a MUD comparible to it.
>
> For the past 2 years I have been playing it and have come to some
> understanding of the basic structure of that particular Mud (Which for all
> of my understanding is not a main-stream MUD, but a very well developed
> custom job with rave reviews and Kudos from other areas as well.
>
> An open request for any programming code relating to anything found in
> Dragonrealms www.dragonrealms.net .
>
> Thanks,
> Xiad Ommeri
> visi...@uswest.net
I think you missed the point of the original post. It wasn't a post asking
how muds currently do things, but how they should be done in a perfect world
and how to best achieve those perfect goals using current and future mud
technology. I haven't checked the mud, so I can't pass judgement on it, but
to be brutally honest I'm not really interested in how things are done, but
how they should be done.
Sorry, but I was looking for ideas, not info on which mud I should be playing
:)
What I would be interested in though, is the details of how the roleplaying
environment is special in that mud, and why you think it is the best that
could be achieved.
John Adelsberger
: Christopher L Tompkins wrote:
: > thieves like disguises and/or impersinations. All that would be needed to
: > keep track of who knows who would be a 2-dimensional array of flags. Does
: An array is not the best way to do it - I'd recommend a linked list.
Why do Diku people ALWAYS use linked lists? Do you guys simply not KNOW
of any other structures? Are you too lazy to code them? Whats up, guys?:)
This is an _obvious_ candidate for per-player hash tables or trinary search
trees...
mwi...@my-dejanews.com
Richard Woolcock <Ka...@nospam.dial.pipex.com> wrote:
> 1) If a player opens a door, there is a 1% chance of a huge foot coming down
> from the sky and squashing them flat - this can be avoided by wearing a
> helmet with a spike on the top.
>
the
> mud, trampling anyone and anything in their way - except players riding
giant
> mice.
>
which
> can be discovered by simply saying "wibble" while riding a yak in midgaard.
>
> 4) You never need to eat, sleep or drink, can consume as much alchohol as you
> wish, and can never fall below 1hp (for convenience).
>
> 5) Bananas cannot be eaten, but make great weapons - sliced grapefruit and
> small grapes are also quite effective.
Damn, KaVir! You gave away all my secrets! Now I'm gonna hafta redo the
whole mud. Bastard.
-Mickelian dines on strange governing bacon with a small green fish.
my...@my-dejanews.com
It's rather embarassing to admit it, but I've never ever implimented a trinary
search tree. In fact, it's years since I implimented a binary one, as I've
always tended to go for hash tables or in true diku programmer style a linked
list. So John, this is your big moment to show off. Teach us how to use a
trinary tree in this case, and why it's best.
TTFN
Chris
Xiad Ommeri
let me say then that particular mud is the way a mud SHOULD be done. =)
Xiad Ommeri
my...@my-dejanews.com wrote in message <6q9gpd$frp$1...@nnrp1.dejanews.com>...
>>
>> www.dragonrealms.net
>>
>> If you are a good programmer and you could halfway jusge whats going on
with
>> code from watching cause and effect then you will have a hay day with
this
>> mud.
>>
>> Also I have yet to find a better one anywhere. (Though my attempt at
>> creating my own MUD wont even begin for another 6 months)
>>
>> Dragonrealms has about everything anyone could have in a text based mud
>> which makes it difficult for me to create a MUD comparible to it.
>>
>> For the past 2 years I have been playing it and have come to some
>> understanding of the basic structure of that particular Mud (Which for
all
>> of my understanding is not a main-stream MUD, but a very well developed
>> custom job with rave reviews and Kudos from other areas as well.
>>
>> An open request for any programming code relating to anything found in
>> Dragonrealms www.dragonrealms.net .
>>
>> Thanks,
>> Xiad Ommeri
>> visi...@uswest.net
>
>how muds currently do things, but how they should be done in a perfect
world
>and how to best achieve those perfect goals using current and future mud
>technology. I haven't checked the mud, so I can't pass judgement on it,
but
>to be brutally honest I'm not really interested in how things are done, but
>how they should be done.
>
>Sorry, but I was looking for ideas, not info on which mud I should be
playing
>:)
>
>What I would be interested in though, is the details of how the roleplaying
>environment is special in that mud, and why you think it is the best that
>could be achieved.
>
Richard Woolcock
>
> ok Im sorry,
> let me say then that particular mud is the way a mud SHOULD be done. =)
Why? Who defines the way a mud should or shouldn't be written? If it is
the perfect solution, then why do people play other muds - and why don't all
other muds try to immitate it (and why haven't I ever heard of it)?
If you think it has some good roleplaying features, please add them to the
discussion - WHAT does it have that is so special? WHAT does it have that
other muds don't have? If you want to convince us, think up a good argument
as to what the mud offers, what aspects of it are appealing, and then put
forward those ideas.
KaVir.
Richard Woolcock
>
> Richard Woolcock wrote:
> > I actually implemented this, then removed it. Having gone to great
> > lengths to try and separate IC and OOC (giving players a mud-generated
> > IC first/surname), I found that people would just tag each other with
> > that persons OOC name. This is one situation in which I decided that
> > my mud would benefit from a lack of realism. Players can now introduce
> > themselves by forename, surname, or both (they speak it out loud, so
> > everyone in the room knows).
>
> user name, and then log on as a player from there. So their player name and
> user name are seperate. That way they can choose a decent player name, yet
> still have their favourite login name and password. That way they can also
> have a first name and a surname for their character. Reckon it'd help at
> all?
Nope, you'll have exactly the same problem I had.
Connecting to Super Roleplaying Mud...
Please enter your account ID: ripper
Please enter your password: *****
Please select which of your bodies you wish to play:
[1] Joe Bloggs
[2] John Doe
[3] Wayne Kurr
:1
Entering play as Joe Bloggs.
You are standing in a boring little room.
A large, muscular man looms before you.
The man says 'Hi there, this is slayer, playing one of my other chars :P'.
: label man Slayer4
: say hiya, this is ripper!
You say 'hiya, this is ripper!'.
Slayer4 nods at you.
Slayer4 says 'okay, your label is set'.
In theory, its a good idea. In practice, it doesn't work.
KaVir.
J C Lawrence
> I favour the arcade game solution: you start out with n >= 3 lives, and
> every 1000 points you get one life more to waste.
Okay, I play very carefully, perhaps running a bot script on a mule
character in the off hours, and collect several dozen spare lives.
I'm now a formidable and even implacable oppponent that few can afford
to stand against as they can't equal the sump of lives I have in the
bank.
--
J C Lawrence Internet: cl...@null.net
(Contractor) Internet: co...@ibm.net
---------(*) Internet: cl...@under.engr.sgi.com
...Honourary Member of Clan McFud -- Teamer's Avenging Monolith...
The Wildman
froth dripped from his fangs when my...@my-dejanews.com
<my...@my-dejanews.com> said the following fighting words:
>In article <35c84...@news.cc.umr.edu>,
> John Adelsberger <j...@umr.edu> wrote:
>> In rec.games.mud.admin Richard Woolcock <Ka...@nospam.dial.pipex.com> wrote:
>> : Christopher L Tompkins wrote:
>>
>> : > thieves like disguises and/or impersinations. All that would be needed to
>> : > keep track of who knows who would be a 2-dimensional array of flags. Does
>>
>> : An array is not the best way to do it - I'd recommend a linked list.
>>
>> Why do Diku people ALWAYS use linked lists? Do you guys simply not KNOW
>> of any other structures? Are you too lazy to code them? Whats up, guys?:)
>> This is an _obvious_ candidate for per-player hash tables or trinary search
>> trees...
>>
>> --
>> John J. Adelsberger III
>> j...@umr.edu
>>
>> "Civilization is the process of setting man free from men."
>>
>> - Ayn Rand
>
>It's rather embarassing to admit it, but I've never ever implimented a trinary
>search tree. In fact, it's years since I implimented a binary one, as I've
>always tended to go for hash tables or in true diku programmer style a linked
>list. So John, this is your big moment to show off. Teach us how to use a
>trinary tree in this case, and why it's best.
>
a bit of practice to know when he's being sarcastic, but eventually you get
the hang of it. The easy rule is: If John is posting wrt Diku, he's most
likely being sarcastic.
--
The Wildman
PLEASE do NOT reply to this post! If you MUST email me, please use wildman at
microserve dot net, but a followup is preferred. If you DO reply to the
wrong address, I'll still read it but don't expect a reply. Unless you are a
spammer, in which case I will reply to your ISP.
Fight spam - http://www.cauce.org/
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCS/MU d- s: a- C++ UL+ P+ L+++ !E W-- N+++ o !K w--- !O !M V-- PS PE Y+ PGP?
t+ 5+ X R tv b++ DI+ D++ G e h---- r++++ y++++
------END GEEK CODE BLOCK------
Holly Sommer
> [3] Wayne Kurr
*LOL*
-Holly
Matthew R. Sheahan
> Okay, I play very carefully, perhaps running a bot script on a mule
> character in the off hours, and collect several dozen spare lives.
> I'm now a formidable and even implacable oppponent
something is implacable if you can't placate it -- buy it off, sing it a
lullabye, or whatever. you probably mean invincible.
chiaroscuro
John Adelsberger
In rec.games.mud.admin The Wildman <the_wil...@hotmail.com> wrote:
: On Wed, 05 Aug 1998 15:18:10 GMT, Wildman's eyes rolled up in his head and
: froth dripped from his fangs when my...@my-dejanews.com
: <my...@my-dejanews.com> said the following fighting words:
: >In article <35c84...@news.cc.umr.edu>,
: > John Adelsberger <j...@umr.edu> wrote:
: >> Why do Diku people ALWAYS use linked lists? Do you guys simply not KNOW
: >> of any other structures? Are you too lazy to code them? Whats up, guys?:)
: >> This is an _obvious_ candidate for per-player hash tables or trinary search
: >> trees...
: >It's rather embarassing to admit it, but I've never ever implimented a
: >trinary search tree. In fact, it's years since I implimented a binary
: >one, as I've always tended to go for hash tables or in true diku
: >programmer style a linked list. So John, this is your big moment to
: >show off. Teach us how to use a trinary tree in this case, and why
: >it's best.
I'll have more to say about this when the original post makes it around to
my oh-so-tasty off in the backwaters newsserver:)
: Of course, John was showing off his witty sarcasm again. I'll admit it takes
: a bit of practice to know when he's being sarcastic, but eventually you get
: the hang of it. The easy rule is: If John is posting wrt Diku, he's most
: likely being sarcastic.
Actually, while I admit that I tend to think of the vast majority of Diku
coders in much the same way that I think of freshmen and Pascal freaks,
my advice here was given quite seriously. A mud's first big problem is
the issue of finding appropriate formats for data; Diku went to fair
lengths to address this issue on disk, and stuck to the simplest, lamest
possible means in memory, and I don't understand why it has stayed that
way(I know why it started that way - when 20 players was a lot, things
like scalability just didn't matter.)
-AW
>
<snip warm fuzzy stuff :)>
> < About - "DEATH">
>
> Having DEATH as a final state is such a harsh setup, but I feel it is
> almost neccessary, for it does encourage caution over carelessness, and
> groups and/or clans to band together more often than not toward common
> goals. But how easily should complete death be for an individual? Why can't
> you have players decay away just like the mobs? Just provide some sort of
> time delay in which help could arrive to heal, or resserect the body before
> it decomposes. Also throw in some sort of diety factor, through actions
> and/or donations for their god/ess, the player recieves faith points, and
> this is used for help from the diety when needed. Anything from alerting
> nearby players of the same faith that you need help, to teleporting you to
> safety just before you die, to the diety actually bringing you back to life
> himself/herself, All depending on the points you have earned through your
> adventures. Being actions in the name of the diety, sacrifices, donations,
> converting others toward the diety, or even holy quests. This will help
> players avoid DEATH as much as possible without being so unrealistic or out
> of the fantasy context. But if DEATH were to come and the player were to
> decay, then, DEATH should be final, THE END.
Hrm... I don't agree with this entirely, but it's a good concept.
Personally, I'm considering something akin to Armageddon's death system:
"If your character dies, he is dead -- permanently.
However, it is possible to "reincarnate" your
character, by creating a new one and typing in
your old character's name and password at prompt.
Your reincarnated character will retain some of
your old character's skills and abilities, but
must be played as a completely seperate character."
> < About - "FLEXIBLE ROOM DESCRIPTIONS">
>
> This idea has also crossed my mind, though actually implementing it is
> quite a challenge and there are some questions as to should it be done or
> not. The way most MUD's are now, the room description is static and never
> changes. What if weather or actions of players could affect the room and
> the description could change accordingly. Such as, when it rains, puddles
> are now on the ground, the trees are wet, and the dirt is now mud. Or as
> someone mentioned earlier, if a player chops down the trees, this should be
> noted in the description for other players to see. But though this seems
> the realistic way to go, should it be done? Many players map the lands and
> use certain descriptions as landmarks or key points to guide by, if the
> descriptions change while the players are wandering around, the confusion
> and/or frustration that the players experience might turn them away. Like a
> player who knows the path to the hidden cave is marked by an old oak tree
> standing within a pine forest. If someone were to chop the old oak tree,
> that landmark has now been destroyed. Again, it would be the realistic
> thing to happen, but will it hurt the MUD rather than help it?
IMHO, dynamic rooms are a detriment to the creative flexibility of
the zone author. Something like this would better be done in a
graphical
mud, where changes are obvious and add to the game world. Dynamic room
desc's in a text mud would (IMO) go mostly unnoticed... and, of course,
you'd end up with thousands upon thousands of rooms with "charred tree
stumps", "shattered buildings", "upturned earth", "blackened soil", etc,
due to the destructive nature of most muds.
> < About - "FLEXIBLE PLAYER DESCRIPTIONS">
<snip>
This sounds interesting... but I can't really comment on it until
I've seen it work.
<snip>
-AW
WotMUD Project Member
http://www.dharvest.com/wotmud
...yes, we're the ones trying
to improve the quality of
Wheel of Time muds.
-AW
>
> In article <35C697...@nospam.dial.pipex.com>,
> Richard Woolcock <Ka...@nospam.dial.pipex.com> wrote:
> I agree whole heartedly. It would certainly aid the roleplaying if people
> weren't sure who killed them. That way they couldn't hold a grudge.
Yes... I personally believe that a strong RP mud would weed out any
players not mature enough to see a pk as a fact of life on a mud, and
not worth worrying about.
<snip label system>
> Righty then, back to death. I believe strongly in permanent death, but I
> think it should be hard to kill people out right. In the combat engine I
> want to develope, most attacks will be blocked, or will hit your armour
> damaging it, but a particularly good hit, or a hit on an unprotected part of
> the body will result not in a few hit points being knocked off, but that part
> of the body being severly injurred or maybe cut off completely. And if
> anyone wants to argue about it then I'll happily ram a dagger into their arm
> and ask if it feels like 1d4 points of damage :)
<grin> This sounds fun... the only problem is that one would need to be
certain to add enough balance to the mud to make it fun to play
something
like a beggar-thief, barber, healer, etc.
> I want to try to balance it so it's very hard to hit a properly protected and
> skilled fighter, but if you do hit them, then they're in trouble as they're
> going to get hurt. One good slice across the neck should kill anyone, no
> matter how many levels (which I'm not implimenting I hasten to add) they
> have. At the same time if a dog charges at you and you club it one with your
> mace, it'd either die, get knocked out, get enraged, or run away. Thats the
> kind of thing I want to have in my mud. Not these silly 17 mud hour long
> fights between an appretice warrior and some rabid dog he found in a gutter
> somewhere.
16 hour long mud fights really annoy me... a good fight should last only
20
minutes mud time, at max (IMHO).
<snip realistic map won't hurt RP>
>
> And it gives more importance to placing in 2D space. If you use the say
> command, maybe everyone in a 5 square radius can hear you, but use the
> whisper command then maybe only people within 2 squares will be able to hear.
> Thus the thief hiding in the corner of the room could hear two people
> talking, but when they say a really important bit of information, one may
> whisper to the other, just as a precaution, thus the thief cannot make out
> what was said.
*ponder* I think that at this point I'd start thinking about making a
gmud (graphical... you know). A simple, isometric, tile-based system
akin to Darksun: CS, Al Qadim, etc, with a text-parser would be
interesting.
At the least I'd trash the standard telnet client and make my own
customized
client program for the mud.
> Area attacks on spells and ranged attacks with spells and missle weapons can
> also be greatly enhanced. And the potential for people building their own
> homes and such like is there as you don't have to police them to check people
> aren't writing stupid room descriptions. They can just build their home and
> live in it.
... yet another reason why tile-based would be nice.
<SNIP>
> botting would be virtually impossible, thank god, but the only other problem
> would be with clients not supporting ansi properly, and more specifically
> cursor movement via ansi control codes. If the mud is successful though, I
> will try and get in touch with people like the makers of zMud to work
> something out so their clients will work 100% in that respect.
(see above)
<printing maps>
> I'm taking a guess, but you probably haven't tried anything like it before.
> Try out either moria or nethack or a game like it. I think the map works
> really well, and the thought of it being multiplayer with a lot of mud
> features and a huge map etc. sounds really appealing to me.
I couldn't agree more.
> > All a matter of opinion. There are enough muds that do it the old way, I
> > don't see what loss there is in someone trying a new approach.
> >
> > KaVir
>
> I couldn't agree more. There's enough people out there doing the old
> "everyone else does it like this, so we'll fall in line" bit, so I want to go
> against the flow.
>
> Chris
For the things you want to do, it seems to me that a gmud would be
better
than a plain ascii mud. Dynamic rooms, character appearances, etc,
would
seem to be much more effective done graphically, and the concept of 2d
space could be taken to its full potential.
Of course, this isn't to say that I'd ever be ambitious enough to
undertake a project as massive as a gmud. The next best thing would
seem to be a custom client program for something akin to Net Hack,
Moria, et al.
Cheers,
Xiad Ommeri
Richard Woolcock wrote in message <35C90F...@nospam.dial.pipex.com>...
>Why? Who defines the way a mud should or shouldn't be written? If it is
>the perfect solution, then why do people play other muds - and why don't
all
>other muds try to immitate it (and why haven't I ever heard of it)?
>
>If you think it has some good roleplaying features, please add them to the
>discussion - WHAT does it have that is so special? WHAT does it have that
>other muds don't have? If you want to convince us, think up a good
argument
>as to what the mud offers, what aspects of it are appealing, and then put
>forward those ideas.
>
>KaVir.
=====
There are so many but if you really want me to I will:
Distance attack: missle, pole, and melee.
Roundtimes that add a real time feel.
So many verbs that the action command is quite useless
Guild based.
Teaching skill that allows you to learn skills without the need of
working that skill (though its easier to gain skill by doing the skill)
1200+ people on at any given time with no lag (lag may occur durring
invasions but its minimal)
The rich and vast amount of detail and history, libraries in the game that
are full of interesting fiction and nonfiction (in game).
The enormous world (it takes about 1.5 hours to "walk" from the southern
most poit to the northern most point.
The large amount of magic and spell types.
The appraise skill that allows you to not only attempt to know the worth of
something but on a weapon will tell you the attrobutes of that weapon.
There are a large group of weapons, weapons skills are well distrobuted.
The world is hard enough to not hit 20th level in 2 days. I have been on
that mud for 2 years and have many charatcers, If I were to have had just
one I probably would be about 20th now after 2 years.(but I play only 5
hours a day or so)
The GMS are not PKillers, infact they really cant interact in the world
unless we call for an assist.
Being in Character is very important to the game.
To cut down on Player vs. Player they outlawed it in town and offer a
"Challenge" verb that allows fights of sport from first stun to death!
The price tag of $9.95 a month for Unlimited access is also very nice.
War mages can have familiars which is almost like having 2 characters in the
game ,
familiars can track down people and pick up small items for you and bring
them back.
You can also talk through them.
The detailed injuries are alos nice. When you are bleeding you can tend you
wounds and after a small Rondtime (depending on skill) you can clot the
bleeding for a little while untill you can get to an empath.
Empaths heal wounds and they "take" the wounds upon themselves, In turn
casting spells only on them selves to rid themselves of the wounds.
They have balance and fatigue wich all have factors in defence and offense.
Smetimes they have festivals (one is going on tomarrow I believe), and
invasions, which always gives excitment.
There are required quests, all quests are voluntary when they have them.
They have a detailed economy with a guild called traders who travel the
lands delivering goods to other towns for money,eventually you can buy items
for wholesale and start your own business, or you can get into the Elanthian
Stock market.
This is way to hard to explain every great feature, and those I described
are not like simmilar things on other muds its truly something to be
experienced.
There are also hundreds of other features that they offer in game.
If there is any MUD I would love to emulate it would be this one. Its clean
looking not jumbled. It has a wonderfully designed custom front end. it
rarely lags even with over a thousand people on.
Thats what makes it great! It has everything all other muds I have played
had and more!
I guess if you wanted make a great mud it would offer best quality, unique
goings on, and great code.
Its life like (as it can get ), I have heard many people's stories of how
they switched from graphic muds like Ultima Online to Dragonrealms because
they said and I quote one man in particular "Even though Dragonrealms is
text, its so much more colorful and beautiful than any graphical mud I have
ever played!" - Zandar
So I guess an eye for description and a good writing ability is a must for a
good mud.
Xiad Ommeri
my...@my-dejanews.com
Problem with a GMud is that it's a lot more work, and I'm not an artist. It
also causes problems with adding new graphics, long downloads, and some
people just don't want to use or can't use a client where they connect from.
How many university students would feel happy about keeping a graphical
client on their user account when mudding is banned at their university?
Telnet is also a globally used program which everyone has access to. And I
can always bolt on a gmud interface after it works as ascii :)
John Adelsberger
In rec.games.mud.admin Xiad Ommeri <Nos...@mymail.now> wrote:
: let me say then that particular mud is the way a mud SHOULD be done. =)
Except, of course, for the fact that pay-to-play text games are a
ridiculous notion. If I'm paying, I want something I can't find
elsewhere, and more than just good spelling and grammar, good
rules, a well balanced game system, and friendly admins... I can
find those things on a good free mud. More than just lots of
code to do 'cool stuff.' Good free muds do that. In fact, good
free muds do just about everything that has been thought up in
the realm of text games. Pay to play needs something more.
John Adelsberger
In rec.games.mud.admin my...@my-dejanews.com wrote:
: It's rather embarassing to admit it, but I've never ever implimented a trinary
: search tree. In fact, it's years since I implimented a binary one, as I've
: always tended to go for hash tables or in true diku programmer style a linked
: list. So John, this is your big moment to show off. Teach us how to use a
: trinary tree in this case, and why it's best.
The shortest written description I've seen that was complete and accurate
was a full length piece in Dr. Dobbs Journal that a friend showed me a
few months back. I don't feel like writing an article of that length, so
you may want to find a good reference, but the idea looks like this:
A . means there would be more to the tree, but I've omitted it. In
general, the search strategy is, take the letters in the search key
one after another, and find them. If you find one, go down the middle
branch. If the found letter is too early in the alphabet, go right.
Otherwise, go left. Only move forward through the key when you match
the current letter.
c
a___/|\___e
/|\ a /|\
c . /|\ d a f
/|\.. t .......
. t .
This tree is overly simplistic, as you might have to do a left or right
switch one or more times in the middle of a word in a real tree, but you
can see that the words 'cat' and 'act' are encoded properly, and the
rest of the tree, if my sleep deprived mind is working, follows the
rules of the search strategy. If you need more info than this to derive
the related algorithms for yourself, you need a reference, and not a
Usenet post:)
As for why, it uses less space on average than other solutions, and lookups
are faster than even in hash tables unless the hit percentage is amazingly
high(lookups that fail are usually VERY fast on trinary trees if keys are
long(which is when it usually matters, since there are a limited number of
short keys anyway) and if a hashing scheme isn't very simple, they can
be rather drawn out for the hash table.) If you're going to hit all the
time or don't care about memory usage and structure management overhead,
use a hash table instead. If your keys are really short, use a hash
table instead. If your keys and values are known in advance, use a
perfect minimal hash instead. Yadda yadda. Pointer overhead looks kinda
nasty, but cleverness can eliminate it entirely(by making the tree's
physical structure an algorithmic matter) or else you can just admit that
the thing works well anyway and get over it, since your hash table will
use plenty of them too, and your linked list's search time will more
than compensate for having a few less.
That said, hey, a linked list with 5 items is a great structure. A
linked list with 10000 items... that's pushing it:)
John Adelsberger
In rec.games.mud.admin my...@my-dejanews.com wrote:
: Well I was working on the idea of running a map made of 100 by 100 sectors.
: Each sector would be 100 by 100 squares. This would make for, uncompressed,
: a total map of near enough 100 Mb, if 1 byte was all you needed per square.
What you plan to do with 100 million places to visit being your own
business, MudOS has a mechanism designed specifically to support such
monstrosities... and I bet it works as well as whatever you're thinking
of:) (This is known as the virtual object mechanism.)
: I reckon I can make the map run ok with 1 byte per square permanently stored,
: but for all the run time effects and overlays I want, I was looking at closer
: to 9 bytes per square. So that's 100 Mb of disc space + 9 times that
: while loaded into memory. Sectors could be dynamically loaded quite
: easily so only a few need be active at a time, but when you've got
: thousands of mobs running around, like I hope, then you can hopefully
: see how it's going to quickly consume a lot of resources.
Why should thousands of mobs be active at one time, unless players are
around to see them? Dynamic loading can be done for far more than just
the map... and so can virtual objects, if you use MudOS:)
: Add to that
: a large game engine, and I think all in all it'd be better to write a
: custom server from scratch. Especially with the length of time it'd
: take me to learn mudos and then modify it etc.
What would you modify MudOS itself for? It does everything you need.
As for learning it, if you can't learn it faster than you can reinvent
the wheel, you probably can't reinvent the wheel either. I don't know
precisely what your 'game engine' consists of, but I'd bet it can be
done in LPC efficiently. I put together a simple raytracer in LPC, just
to make a point... I ought to dig it up and post it for amusement's
sake.
The point is, if you want to write a new server for the sake of doing it,
by all means, have fun, but don't pretend you have any more practical
reason to do so. You don't. You haven't mentioned a single one of
MudOS's weaknesses(it does have a couple, although you can code around
one of them and the other one is only a weakness if absolute perfection
is the standard... I'm referring, respectively, to async event support
and lack of separately threaded compiler, interpreter(of a single-threaded
LPC, I assure you:) and so forth. This would vastly improve performance
on multiprocessors. It would also be fairly easy to add in yourself.)
Christopher L Tompkins
Richard Woolcock <Ka...@nospam.dial.pipex.com> wrote in article
<35C90F...@nospam.dial.pipex.com>...
> Xiad Ommeri wrote:
> >
> > ok Im sorry,
> > let me say then that particular mud is the way a mud SHOULD be done. =)
>
> Why? Who defines the way a mud should or shouldn't be written? If it is
> the perfect solution, then why do people play other muds - and why don't
all
> other muds try to immitate it (and why haven't I ever heard of it)?
>
> If you think it has some good roleplaying features, please add them to
the
> discussion - WHAT does it have that is so special? WHAT does it have
that
> other muds don't have? If you want to convince us, think up a good
argument
> as to what the mud offers, what aspects of it are appealing, and then put
> forward those ideas.
>
> KaVir.
>
Just to inform everyone in the discussion, DragonRealms is a custom built
commercial MUD designed by a company - Simultronics. This was actually
there second project, GemStone 3 was the first. They now have 4 text-based
games on the commercial market, GemStone 3 ( fantasy theme ), DragonRealms
( fantasy theme ), Modus Operandi ( modern day spy theme ), and Hercules &
Zena ( yep, fantasy theme based on the TV series ). Anyway, they are quite
a bit successful, with a large player base, GemStone 3 being the oldest and
largest, has approx. 1700 - 2000 players at once at peak times, this alone
shows they are doing something right. But, in contrast to these numbers, it
is far from a perfect system, for I have played them all before and feel
they lack a lot of the realism and playability in which we are discussing.
Compared to the average MUD, these are great, but compared to what I am
trying to accomplish, along with the other opinions in this discussion,
they are nothing like a MUD truly should be. IMHO!
Thanks,
Christopher.
Richard Woolcock
>
[snip]
> That said, hey, a linked list with 5 items is a great structure. A
> linked list with 10000 items... that's pushing it:)
And what about a double linked list which moves the most recently accessed
piece of data to the front of the list, like mine does? Taking into account
the fact that you usually only encounter half a dozen people (at most) at
one time, the code very rarely has to go very far down the list.
KaVir.
J C Lawrence
> In rec.games.mud.admin my...@my-dejanews.com wrote:
> Why should thousands of mobs be active at one time, unless players are
> around to see them? Dynamic loading can be done for far more than just
> the map... and so can virtual objects, if you use MudOS:)
Simulation accuracy.
J C Lawrence
> That said, hey, a linked list with 5 items is a great structure. A
> linked list with 10000 items... that's pushing it:)
While they in essence degrade to trees, skip lists have a use here.
Lucas Finn
> > around to see them? Dynamic loading can be done for far more than just
> > the map... and so can virtual objects, if you use MudOS:)
>
> Simulation accuracy.
if a tree falls in the woods, and no one's around to hear it, does it make
a sound?
J C Lawrence
>> Simulation accuracy.
Partially. Does it cause an event which something else can or does
react to, which in turn may or may not cause similar cascaded events?
Its the old butterfly flapping his wings a century ago causing a
tornado today.
Lucas Finn
>
> >>> Why should thousands of mobs be active at one time, unless players
> >>> are around to see them? Dynamic loading can be done for far more
> >>> than just the map... and so can virtual objects, if you use
> >>> MudOS:)
>
> >> Simulation accuracy.
>
> > if a tree falls in the woods, and no one's around to hear it, does
> > it make a sound?
>
> Partially. Does it cause an event which something else can or does
> react to, which in turn may or may not cause similar cascaded events?
> Its the old butterfly flapping his wings a century ago causing a
> tornado today.
okay, i'll be more specific: if a tree falls on a MUD, and no one's around
to hear it, does it make a sound? ;)
while i'm no expert mud designer or developer, i know you can take up
huge amounts of memory that do little or nothing at all. you said
"simulation accuracy", but in who's sense? i'm pretty sure if you
implement it right, your players will never know the difference, but the
server sure as hell will ;).
J C Lawrence
>> >> Simulation accuracy.
>>
>> > if a tree falls in the woods, and no one's around to hear it, does
>> > it make a sound?
>>
>> Partially. Does it cause an event which something else can or does
>> react to, which in turn may or may not cause similar cascaded events?
>> Its the old butterfly flapping his wings a century ago causing a
>> tornado today.
> okay, i'll be more specific: if a tree falls on a MUD, and no one's around
> to hear it, does it make a sound? ;)
> while i'm no expert mud designer or developer, i know you can take up
> huge amounts of memory that do little or nothing at all. you said
> "simulation accuracy", but in who's sense? i'm pretty sure if you
> implement it right, your players will never know the difference, but the
> server sure as hell will ;).
Some MUDs are not written for players, but are written to be
simulations of a system in which players may or may not actively
participate. Certainly the players and their direct MUDding
experience are not always considered the most important ingredients in
a MUD.
Nathan Fenenga Yospe
<And snipped attribs: First one is JAIII, I think, and second is JCL...>
: > > Why should thousands of mobs be active at one time, unless players are
: > > around to see them? Dynamic loading can be done for far more than just
: > > the map... and so can virtual objects, if you use MudOS:)
: > Simulation accuracy.
: if a tree falls in the woods, and no one's around to hear it, does it make
: a sound?
Yes. Shockwaves still occur. :) But that's physics, and philosophy ought to
keep its nose out. ;)
Seriously, though... JCL and I have been around this bush a few times, with
interesting results. I'm one of those don't-really-simulate-what's-not-seen
types... but I get away with it by having update algorithms more suited for
a college graduate thesis in math or CS at a good uni than to a hobby. This
is a good illustration of the difference between programme's time and CPU's
time. I suppose, if I someday launch a full sized world, running Physmud, a
few hundred thousand players across distributed servers, and a graphic/text
hybrid client of the sort I've entertained thoughts on... and charged... it
might be financially worth the effort. But make no mistake, it was worth it
from a personal standpoint. And you know what? Even *with* lazy instancing,
convergent processes and threads, a lockless thread model, minimized writes
and reads to disk, and long-term projection and faux simulation... it still
bogs down the current test machine. (604e 180, 32MB, MkLinux...) It handles
quite well with only a few users, or limited action... two people in a room
talking (simulated, I don't have the client yet) uses almost no CPU... five
people running around all over the place at speeds that w(sh)ouldn't be, in
the real game, possible... triggering everything and looking at everything,
can swamp the computer. I'm thinking of flood gates on client input... that
would, along with the restrictions on character ability, elliminate similar
problems when the client is introduced. Actually, the flood gates should be
on the output, I think. The simulation was to guage the threat of a hacked,
illegal client that tried to request detail on *everything*, forcing server
resolution of everything. Detail is normally generated as-needed, and there
is a good chance most of the time a tree will remain as a 2kb reference for
a general model 99.99% of the time... and then it'll get marked, or chopped
down, or climbed... and it's size will increase a little... or maybe it may
get investigated in detail, down to every leaf, and become some 10Mb detail
mapping... might even be a good thing, if the tree were to become the prime
setting for a sub-milimeter scale player-controlled species. But where I am
simulating only what I need to, I imagine I *can* simulate a *lot* more, if
I have to, than JCL. Locally. While still representing entire planets where
no one has tread as a half dozen references to a geography model, some sets
of chemistry, and an unresolved mass/charge/density distribution spec. That
planet could easilly become more detailed, if people landed on it. (Living,
active planets are a bit larger even inactive, at least on disk, and would,
to justify their resource usage, at the very least entertain an occasional,
if infrequent, visitor.)
Oh, and before anyone says, "but generated text is boring!"... the client's
text generation may well turn out to be a little dull, though I'm using the
latest and greatest in NLP theory and writing ability to try to improve it;
but the client isn't even remotely close to done... and by the time it will
be, I think Java might be ready for use in a partially graphical client. If
it is, I'll most likely backend the (ANSI) C NLP/Neural Net stuff to it and
generate text over lightweight graphics. The text might be a little stiffer
than human generated, but most mud area writers are hams anyway... and when
a player does something, the description will dynamicly reflect it. And the
descriptions will even *ahem* be able to _accurately_ describe moods. A big
green troll jumps at you, scaring you half out of your pants! - and there's
no "but... I'm a green troll myself, and I'm wearing a dress!"
--
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/
Jon A. Lambert
>>>> are around to see them? Dynamic loading can be done for far more
>>>> than just the map... and so can virtual objects, if you use
>>>> MudOS:)
>
>>> Simulation accuracy.
>
>> if a tree falls in the woods, and no one's around to hear it, does
>> it make a sound?
>
>react to, which in turn may or may not cause similar cascaded events?
>Its the old butterfly flapping his wings a century ago causing a
>tornado today.
>
Let's say it issues a sound event of given strength that is used to
calculate the neighborhood surrounding the treefall. All objects
within that neighborhood would receive sound events. Assuming no
players are within that neighborhood, no sound is heard. However a
small group of elk just within the neighborhood are spooked into
stampeeding northeastward, entering Bubba the hungry troll's range of
vision. Bubba manages to bring down a good-sized buck and manages
to stave off certain death by starvation.
It's certainly an interesting proposition, although I don't view
treefalls as particularly important to any of my simulations. I do
view growth, depletion and migration of certain flora and fauna
resources as something trackable in this manner. Nathan Yospe's
forward in time calculations on demand (or temporal approximating
algorithms? :) is another valid solution to a simulation problem.
Perhaps a mixture of both methods would be useful. Highly mobile
resources might benefit from using one approach (aggressive fauna
like orcs and such) while less mobile resources may benefit from the
calculation on demand approach.
--
--/*\ Jon A. Lambert - TychoMUD Email:jlsy...@nospam.ix.netcom.com /*\--
--/*\ Mud Server Developer's Page <http://www.netcom.com/~jlsysinc> /*\--
--/*\ "Everything that deceives may be said to enchant" - Plato /*\--
Mats H. Carlberg
word lists, I like the tree known as 'tries', which basically extends each node of the
ternary tree to contain all the letters of the alphabet. I like skip-lists, too. :)
--
Mats H. Carlberg MSc., Tech. Lic.
http://www.ifm.liu.se/~macar
- Signatures can contain viruses! Spread the word!
my...@my-dejanews.com
John Adelsberger <j...@umr.edu> wrote:
> Distribution:
>
> In rec.games.mud.admin my...@my-dejanews.com wrote:
>
> linked list with 10000 items... that's pushing it:)
>
> John J. Adelsberger III
Ok, I can see what you're getting at. I'll probably even end up using it as
I'm a sucker for trying out new things :)
Cheers,
my...@my-dejanews.com
Richard Woolcock <Ka...@nospam.dial.pipex.com> wrote:
> John Adelsberger wrote:
> >
>
> [snip]
>
> > That said, hey, a linked list with 5 items is a great structure. A
> > linked list with 10000 items... that's pushing it:)
>
> piece of data to the front of the list, like mine does? Taking into account
> the fact that you usually only encounter half a dozen people (at most) at
> one time, the code very rarely has to go very far down the list.
>
> KaVir.
Very cunning! I like!
my...@my-dejanews.com
John Adelsberger <j...@umr.edu> wrote:
> Distribution:
>
> In rec.games.mud.admin my...@my-dejanews.com wrote:
>
> : Each sector would be 100 by 100 squares. This would make for, uncompressed,
> : a total map of near enough 100 Mb, if 1 byte was all you needed per square.
>
> What you plan to do with 100 million places to visit being your own
> business, MudOS has a mechanism designed specifically to support such
> monstrosities... and I bet it works as well as whatever you're thinking
> of:) (This is known as the virtual object mechanism.)
Maybe, but it's still going to take me just as long to learn every aspect of
the a new system as it would to create it from scratch.
> : I reckon I can make the map run ok with 1 byte per square permanently
stored,
> : but for all the run time effects and overlays I want, I was looking at
closer
> : to 9 bytes per square. So that's 100 Mb of disc space + 9 times that
> : while loaded into memory. Sectors could be dynamically loaded quite
> : easily so only a few need be active at a time, but when you've got
> : thousands of mobs running around, like I hope, then you can hopefully
> : see how it's going to quickly consume a lot of resources.
>
> Why should thousands of mobs be active at one time, unless players are
> around to see them? Dynamic loading can be done for far more than just
> the map... and so can virtual objects, if you use MudOS:)
I want all the mobs active all the time to make them more realistic. They
aren't assigned to areas, they are all free to go where they please, but this
means they need to be active. They will also have motivations, like hunger,
thirst, tiredness, inquisitiveness, etc. which will only work really well if
they are active all the time. To get round the cpu and ram problems
associated with having all the map loaded all the time, they will sleep for
approx 50% of the time, thus being unloaded from memory, and when they are
nowhere near a player they can be deactivated for a while, but to all extents
and purposes I want them to be awake for a lot of the time.
> : Add to that
> : a large game engine, and I think all in all it'd be better to write a
> : custom server from scratch. Especially with the length of time it'd
> : take me to learn mudos and then modify it etc.
>
> What would you modify MudOS itself for? It does everything you need.
Then why isn't my mud already out there?
> As for learning it, if you can't learn it faster than you can reinvent
> the wheel, you probably can't reinvent the wheel either. I don't know
> precisely what your 'game engine' consists of, but I'd bet it can be
> done in LPC efficiently. I put together a simple raytracer in LPC, just
> to make a point... I ought to dig it up and post it for amusement's
> sake.
It probably can be done. But it can be done equally well in C and would no
doubt run faster. The only code the mud could conceivably share with any
other mud would be the socket code. And even that would be quite different
from anything else, so it couldn't even share that.
> The point is, if you want to write a new server for the sake of doing it,
> by all means, have fun, but don't pretend you have any more practical
> reason to do so. You don't. You haven't mentioned a single one of
> MudOS's weaknesses(it does have a couple, although you can code around
I don't know MudOS so how can I know it's weaknesses. That's one of the
points. I don't know it so how can I possibly plan to use it. Ummm, I know I
think i'll use Fortran this week. Someone once said it was quite good, so I
think I'll learn it and give it a go.
> one of them and the other one is only a weakness if absolute perfection
> is the standard... I'm referring, respectively, to async event support
> and lack of separately threaded compiler, interpreter(of a single-threaded
> LPC, I assure you:) and so forth. This would vastly improve performance
> on multiprocessors. It would also be fairly easy to add in yourself.)
>
> John J. Adelsberger III
The thing is you don't actually know what I want and therefore cannot make an
accurate judgement on whether MudOS is the language for me or not. I haven't
yet made a detailed description of how I envisage my game engine to work.
Plus I already have the socket code, and a rudimentary version of the graphics
code working, which I can build on. However, I will take a look at MudOS and
see how easy it would be to make it do what I want.
Mats H. Carlberg
> And what about a double linked list which moves the most recently accessed
> piece of data to the front of the list, like mine does? Taking into account
> the fact that you usually only encounter half a dozen people (at most) at
> one time, the code very rarely has to go very far down the list.
It's possible it gives acceptable performance. It all depends on the particulars
of your case, and what one considers 'acceptable performance'. Before I'd claim
a data structure is ok, I'd collect and analyse data. For example, from a hash table
implementation, where the slots in the hash table contains a one-way linked list,
new items are added aat the head of the linked list, and when an item is searched for
and found, it is moved to the head of the list.
Average chain length 12.3
Average search length 1.04
would be acceptable, while
Average chain length 12.3
Average search length 5.86
would not, as the average search length is approx. half the list length. If this
happened I extend the analysis to see exactly what should be done.
John Adelsberger
In rec.games.mud.admin Richard Woolcock <Ka...@nospam.dial.pipex.com> wrote:
: John Adelsberger wrote:
: > That said, hey, a linked list with 5 items is a great structure. A
: > linked list with 10000 items... that's pushing it:)
: And what about a double linked list which moves the most recently accessed
: piece of data to the front of the list, like mine does? Taking into account
: the fact that you usually only encounter half a dozen people (at most) at
: one time, the code very rarely has to go very far down the list.
This works, but why have a specialized piece of code just for an intro
system when you can code generic hashtables, trinary trees, avls, and
so forth and just use them over and over again? I can show you a way
to use an array to the same effect, but it makes no sense to DO so:)
--
John J. Adelsberger III
John Adelsberger
In rec.games.mud.admin J C Lawrence <cl...@under.engr.sgi.com> wrote:
: In alt.mud John Adelsberger <j...@umr.edu> wrote:
: > In rec.games.mud.admin my...@my-dejanews.com wrote:
: > Why should thousands of mobs be active at one time, unless players are
: > around to see them? Dynamic loading can be done for far more than just
: > the map... and so can virtual objects, if you use MudOS:)
: Simulation accuracy.
Unlike you and Mr. Yospe, most of us are designing games. If you want
a simulator, that's cool, and more power to you, but the discussion at
hand, insofar as I can tell, is about a game which has no need of such
a simulation engine.
John Adelsberger
In rec.games.mud.admin Xiad Ommeri <Nos...@mymail.now> wrote:
(I'm reordering his list. Cope.)
: Roundtimes that add a real time feel.
: So many verbs that the action command is quite useless
: Guild based.
: Teaching skill that allows you to learn skills without the need of
: working that skill (though its easier to gain skill by doing the skill)
: The enormous world (it takes about 1.5 hours to "walk" from the southern
: most poit to the northern most point.
: The large amount of magic and spell types.
: The appraise skill that allows you to not only attempt to know the worth of
: something but on a weapon will tell you the attrobutes of that weapon.
: There are a large group of weapons, weapons skills are well distrobuted.
: The world is hard enough to not hit 20th level in 2 days. I have been on
: that mud for 2 years and have many charatcers, If I were to have had just
: one I probably would be about 20th now after 2 years.(but I play only 5
: hours a day or so)
: The GMS are not PKillers, infact they really cant interact in the world
: unless we call for an assist.
: Being in Character is very important to the game.
: To cut down on Player vs. Player they outlawed it in town and offer a
: "Challenge" verb that allows fights of sport from first stun to death!
: They have balance and fatigue wich all have factors in defence and offense.
: Smetimes they have festivals (one is going on tomarrow I believe), and
: invasions, which always gives excitment.
: There are required quests, all quests are voluntary when they have them.
All this stuff is tame and common... moving on.
: 1200+ people on at any given time with no lag (lag may occur durring
: invasions but its minimal)
Since, as I lament below, this is a pay game, this isn't particularly
meaningful; if I had $20-40k a month coming in off my game, it would soon
support such a playerbase too. This is mostly an issue of obtaining a
really fast connection and a really big machine(lots o memory, and I'd
want to go multiprocessor, which would require a few code changes...)
: The rich and vast amount of detail and history, libraries in the game that
: are full of interesting fiction and nonfiction (in game).
: Distance attack: missle, pole, and melee.
These are nice, and rather uncommon, but hardly unique features.
: The price tag of $9.95 a month for Unlimited access is also very nice.
Eew... pay to play text... no thanks. I can afford it many times over,
but I'd rather spend the money on mochas for my code sessions:)
: War mages can have familiars which is almost like having 2 characters in the
: game ,
: familiars can track down people and pick up small items for you and bring
: them back.
: You can also talk through them.
Things like this are hardly that amazing; the first mud I ever played has
them, although the names are different.
: The detailed injuries are alos nice. When you are bleeding you can tend you
: wounds and after a small Rondtime (depending on skill) you can clot the
: bleeding for a little while untill you can get to an empath.
: Empaths heal wounds and they "take" the wounds upon themselves, In turn
: casting spells only on them selves to rid themselves of the wounds.
This is a bit different, but superior only in that it fits a theme...
: They have a detailed economy with a guild called traders who travel the
: lands delivering goods to other towns for money,eventually you can buy items
: for wholesale and start your own business, or you can get into the Elanthian
: Stock market.
This is the ONE thing you've said that actually catches my eye. All in all,
this sounds like a nice game, but it hardly strikes me as an amazing
achievement, given commercial support.
John Adelsberger
In rec.games.mud.admin my...@my-dejanews.com wrote:
: In article <35c9b...@news.cc.umr.edu>,
: John Adelsberger <j...@umr.edu> wrote:
: I want all the mobs active all the time to make them more realistic. They
: aren't assigned to areas, they are all free to go where they please, but this
: means they need to be active. They will also have motivations, like hunger,
: thirst, tiredness, inquisitiveness, etc. which will only work really well if
A random encounter system with global awareness could do the same thing in
far less space and with far less effort, but to each his own.
: > What would you modify MudOS itself for? It does everything you need.
: Then why isn't my mud already out there?
This is like saying 'You can write with a pencil.' and getting the reply
'Then why didn't someone write my book years ago?'
: > As for learning it, if you can't learn it faster than you can reinvent
: > the wheel, you probably can't reinvent the wheel either. I don't know
: > precisely what your 'game engine' consists of, but I'd bet it can be
: > done in LPC efficiently. I put together a simple raytracer in LPC, just
: > to make a point... I ought to dig it up and post it for amusement's
: > sake.
: It probably can be done. But it can be done equally well in C and would no
: doubt run faster.
Yes. Rather than consuming 20% of the CPU, it might only use 10, and the
coding and maintainence investment will probably go up by an order of
magnitude... seems like a pretty lousy tradeoff to me.
: The only code the mud could conceivably share with any
: other mud would be the socket code. And even that would be quite different
: from anything else, so it couldn't even share that.
You're being silly at this point, or else you just don't know what you're
talking about. I'd guess that 95% of what MudOS provides, save the stuff
that's being phased out, would be directly useful in your project. Maybe
more.
: I don't know MudOS so how can I know it's weaknesses. That's one of the
: points. I don't know it so how can I possibly plan to use it. Ummm, I know I
: think i'll use Fortran this week. Someone once said it was quite good, so I
: think I'll learn it and give it a go.
That's how _I_ learned Fortran(and COBOL, and Pascal, and... and...:)
: The thing is you don't actually know what I want and therefore cannot make an
: accurate judgement on whether MudOS is the language for me or not. I haven't
: yet made a detailed description of how I envisage my game engine to work.
Agreed, you haven't. That said, see below for my comment.
: Plus I already have the socket code, and a rudimentary version of the graphics
: code working, which I can build on.
The graphics code is the only thing I can think of that you MIGHT want to
keep in C; the way to do that would be to wrap it up in efuns and call it
from LPC. Anything else, unless, of course, you want to be like Mr. Yospe,
which you haven't suggested, or Mr. Lawrence, which you REALLY haven't
suggested(that takes lots of cash:) will work out nicely in LPC, I expect.
: However, I will take a look at MudOS and
: see how easy it would be to make it do what I want.
You're in for a disappointment if you try to add that graphics stuff without
spending some time... that by itself is the single point at which you'd
need to work pretty hard, and even that has to be easier than writing the
whole thing from scratch in C(which, btw, is my favorite programming
language; don't get me wrong...)
This said, make sure not to confuse MudOS with software running ON MudOS,
and if you're going to bother, spend a bit of time perusing options.h in
the src directory so you can learn what the driver can be made to do with
simple changes. If you _really_ insist on low level functionality, look
at DGD; it uses a very similar dialect of LPC in most respects, but the
interface is much lower level in most cases(which, IMHO, is bad, but hey.)
Many, many people assume that because they have what they consider to be
a hog of a game in mind, they need to hardcode lots of it and custom
design it from scratch. 99.9% of them are wrong. The ones who aren't
are usually people who don't complain about the difficulty of learning
a new system:)
J C Lawrence
> : In article <35c9b...@news.cc.umr.edu>,
> : John Adelsberger <j...@umr.edu> wrote:
> : I want all the mobs active all the time to make them more realistic. They
> : aren't assigned to areas, they are all free to go where they please, but this
> : means they need to be active. They will also have motivations, like hunger,
> : thirst, tiredness, inquisitiveness, etc. which will only work really well if
> A random encounter system with global awareness could do the same thing in
> far less space and with far less effort, but to each his own.
Not if you are doing an adaptive ALife-style simulation (which some MUDs are).
J C Lawrence
> In rec.games.mud.admin J C Lawrence <cl...@under.engr.sgi.com> wrote:
>> Simulation accuracy.
> Unlike you and Mr. Yospe, most of us are designing games. If you want
> a simulator, that's cool, and more power to you, but the discussion at
> hand, insofar as I can tell, is about a game which has no need of such
> a simulation engine.
Actually, I am designing a game, as is Nathan. Simulations are not
incompatable with games -- consider SimSearth and company for one
minor example -- they are merely a flavour of game where the dividing
lines can be very blurred.
Consider a simulation which provided a reasonably compleat programming
or scripting language such that users could program their own agents
and extensions, which, operating within the confines and mechanisms of
the simulation world, performed variously autonomous or
author-dependent actions. This sounds like a bone dry simulation such
as might be done by a reasearch establishment.
Now make the world that is being simulated your typical swords and
sorcery fantasy, and the mechanics being simulated being the social
construction of the simulated population, the physical and magical
mechanics of the game world etc. All of a sudden those user
programmed agents are now golems, demons, slaves, magical spells and
other disperate contraptions.
Is it game, or is it simulation, or is it both?
Lars Duening
> John Adelsberger wrote:
> >
>
> [snip]
>
> > That said, hey, a linked list with 5 items is a great structure. A
> > linked list with 10000 items... that's pushing it:)
>
> And what about a double linked list which moves the most recently accessed
> piece of data to the front of the list, like mine does?
You may want to look at Splay trees, which show the same behaviour.
> Taking into account the fact that you usually only encounter half
> a dozen people (at most) at one time, the code very rarely has to
> go very far down the list.
Hmm, I am always suspicious of such statements - unless you can prove
it, don't assume it. But you already know that.
--
Lars Duening; la...@cableinet.co.uk
John Adelsberger
In rec.games.mud.admin my...@my-dejanews.com wrote:
: Richard Woolcock <Ka...@nospam.dial.pipex.com> wrote:
: > And what about a double linked list which moves the most recently accessed
: > piece of data to the front of the list, like mine does? Taking into account
: > the fact that you usually only encounter half a dozen people (at most) at
: > one time, the code very rarely has to go very far down the list.
: Very cunning! I like!
While Mr. Woolcock's solution is very probably workable and simple, it isn't
particularly reusable(the range of suitable applications is narrower by far
than for most structures,) and it wastes a lot of space. It is a FAR cry
better than the lists most Dikus use, and Mr. Woolcock obviously has a good
eye for how to succeed with minimal effort, but 'cunning' might be going
overboard; any good book on the subject of data structures ought to mention
this beast...
If you're not using a language that provides them premade(IE, if you're
using C, for instance:) it'd be a good idea to either obtain or create
for personal use a set of structures including at least these(some can
share code heavily):
single linked list
double linked list
double linked bump list(KaVir's list)
queue
stack
dequeue
AVL tree
trinary search tree
priority queue(heap)
hash table
This way, you don't end up doing something the wrong way because you're
too lazy to create the correct structure. If you insist on doing them
yourself, a dozen hours or so with a good book will probably do the
trick; if not, you might get them all in ten minutes:) (If you've
done them before, you can do them much more quickly than this, but
getting a couple of these right the first time you ever try is
nontrivial. In particular, pay close attention to the AVL tree.)
There are other useful structures(MANY) of course, but these tend to
get you through 99% of the daily grind. The impetus to pick from
among hundreds of structures the one that has precisely the
attributes you want is greatly decreased by two factors these days:
one, the fact that a close fit is usually good enough on modern
hardware, and two, the fact that machine time is so much cheaper
than programmer time. If it runs 'well enough' and you had it on
hand, you did it right. This, however, is no justification for
the list-only code seen in most Diku derived muds:)
Klaus Schilling
>
> If you're not using a language that provides them premade(IE, if you're
> using C, for instance:) it'd be a good idea to either obtain or create
> for personal use a set of structures including at least these(some can
> share code heavily):
>
> single linked list
> double linked list
> double linked bump list(KaVir's list)
> queue
> stack
> dequeue
> AVL tree
> trinary search tree
> priority queue(heap)
> hash table
There's a cool library that provides STL-like datastructures for plain C.
It's called glib and used for the free desktop environment 'gnome'.
Another, better documented, but less powerful lib of that is 'libretto'.
Klaus Schilling
John Adelsberger
In rec.games.mud.admin Lars Duening <la...@cableinet.co.uk> wrote:
: Richard Woolcock <Ka...@nospam.dial.pipex.com> wrote:
: > And what about a double linked list which moves the most recently accessed
: > piece of data to the front of the list, like mine does?
: You may want to look at Splay trees, which show the same behaviour.
I prefer the list, unless it is going to get really big. Splay trees are
based on an assumption of randomness that doesn't occur in the real world
in most cases, and often end up degenerating to a point almost as bad as
lists, but with more overhead.
John Adelsberger
In rec.games.mud.admin J C Lawrence <cl...@under.engr.sgi.com> wrote:
: In alt.mud John Adelsberger <j...@umr.edu> wrote:
: > Unlike you and Mr. Yospe, most of us are designing games. If you want
: > a simulator, that's cool, and more power to you, but the discussion at
: > hand, insofar as I can tell, is about a game which has no need of such
: > a simulation engine.
: Actually, I am designing a game, as is Nathan. Simulations are not
: incompatable with games -- consider SimSearth and company for one
I know, and it was poorly worded, but what I meant was that I doubt the
individual in question really wants to design a simulation on the order
of what you're talking about. Just the theory to do so and have the
result remain a believable society for any period of time is anything
but trivial, and he sounds like he's mainly in it for the game:)
Lars Duening
> Distribution:
>
> In rec.games.mud.admin Lars Duening <la...@cableinet.co.uk> wrote:
> : Richard Woolcock <Ka...@nospam.dial.pipex.com> wrote:
>
> : > And what about a double linked list which moves the most recently accessed
> : > piece of data to the front of the list, like mine does?
>
> : You may want to look at Splay trees, which show the same behaviour.
>
> I prefer the list, unless it is going to get really big. Splay trees are
> based on an assumption of randomness that doesn't occur in the real world
> in most cases, and often end up degenerating to a point almost as bad as
> lists, but with more overhead.
Sure, YMMV, but in my experiments I did not succeed in degrading my
splay trees to list-like behaviour. Of course it's been a while and all
the literature is still in one of my moving boxes...
--
Lars Duening; la...@cableinet.co.uk
Mason Deming
pounded already.
I'm a refugee from Simutronics games, i've been playing there for years and
spent umpteen thousands there back when aol was 'pay by the hour'. I have to
agree with you one a few small points. It's a beautiful world, it's got a
magnificent text parser, i love the combat and character mechanics (a straight
rolemaster ripoff - how can you go wrong?), detailed and contiguous history.
But as someone said in an earlier post .. those things aren't wholly 'unique'.
BUT .. let me detail why i quit and why i loathe pay for text games. I was one
of the more powerful wizards in the land and i gave up everything because i was
just too disgusted to go on. When a population increases to such a magnitude,
it's really a breeding ground for infection. Old players hate young players.
Young players hate old players. There's no respect. There's no honor. But all
and all, i give that the big 'whatever' - it would happen with a thousand rats
in a box as well as most other overpopulation test cases. The problem arises
due to the fact that Simu is -making money- off of the shmucks in the lands.
The apathetic gamemasters -cause- more problems than they solve. PvP is
illegal, and i've been murdered at least three times - after waiting for two
hours to speak with a gamemaster, the perpetrater had disconnected, and there
were no reparations, i lost silver/experience/time, i was told to 'chock it up
to bad luck .. school will be in session soon and most of "those" type of people
will be gone'. (assuming of course that all snerts were young folks, but i
didn't call her on this)
Ah yes, the "gamemasters" are mere puppets of the Great Simutronics who doesn't
want to do anything but watch it's bank account fatten monthly. Just 'keep them
p(l)aying'.
So if you like paying for a world populated by "those shmucks who flash their
brights in your rear view mirror and lay into the horn when there is plenty of
passing room, and then choose to zip by and cut you off so closely you flinch"
and (no offense meant to those good ones) nasty little 12 year old boys - by all
means, try it, you'll enjoy it.
Lotsa fun. ::groan:: Quitting it was like pulling a splinter from my eye.
~ Mason
Xiad Ommeri wrote:
> I reccomend out of my experience to check out:
>
> www.dragonrealms.net
>
> If you are a good programmer and you could halfway jusge whats going on with
> code from watching cause and effect then you will have a hay day with this
> mud.
>
> Also I have yet to find a better one anywhere. (Though my attempt at
> creating my own MUD wont even begin for another 6 months)
>
> Dragonrealms has about everything anyone could have in a text based mud
> which makes it difficult for me to create a MUD comparible to it.
>
> For the past 2 years I have been playing it and have come to some
> understanding of the basic structure of that particular Mud (Which for all
> of my understanding is not a main-stream MUD, but a very well developed
> custom job with rave reviews and Kudos from other areas as well.
>
> An open request for any programming code relating to anything found in
> Dragonrealms www.dragonrealms.net .
>
> Thanks,
> Xiad Ommeri
> visi...@uswest.net
>
> Christopher L Tompkins wrote in message
> <01bdbeea$f3ca7b80$49201e26@brujah>...
> > I also have started building a MUD-type game from scratch, feeling what
> >is out there now does not offer quite the quality, nor the variety, of
> >'role-playing' that I seek. So I have decided to create it myself.
> >This conversation has brought many interesting ideas, not to mention
> >encouragement. It is good to see others out there that have the same
> >opinions about the current scene that I have. Anyway...
> >
> >< About - "DEATH">
> >
> > Having DEATH as a final state is such a harsh setup, but I feel it is
> >almost neccessary, for it does encourage caution over carelessness, and
> >groups and/or clans to band together more often than not toward common
> >goals. But how easily should complete death be for an individual? Why can't
> >you have players decay away just like the mobs? Just provide some sort of
> >time delay in which help could arrive to heal, or resserect the body before
> >it decomposes. Also throw in some sort of diety factor, through actions
> >and/or donations for their god/ess, the player recieves faith points, and
> >this is used for help from the diety when needed. Anything from alerting
> >nearby players of the same faith that you need help, to teleporting you to
> >safety just before you die, to the diety actually bringing you back to life
> >himself/herself, All depending on the points you have earned through your
> >adventures. Being actions in the name of the diety, sacrifices, donations,
> >converting others toward the diety, or even holy quests. This will help
> >players avoid DEATH as much as possible without being so unrealistic or out
> >of the fantasy context. But if DEATH were to come and the player were to
> >decay, then, DEATH should be final, THE END.
> >
> >< About - "FLEXIBLE ROOM DESCRIPTIONS">
> >
> > This idea has also crossed my mind, though actually implementing it is
> >quite a challenge and there are some questions as to should it be done or
> >not. The way most MUD's are now, the room description is static and never
> >changes. What if weather or actions of players could affect the room and
> >the description could change accordingly. Such as, when it rains, puddles
> >are now on the ground, the trees are wet, and the dirt is now mud. Or as
> >someone mentioned earlier, if a player chops down the trees, this should be
> >noted in the description for other players to see. But though this seems
> >the realistic way to go, should it be done? Many players map the lands and
> >use certain descriptions as landmarks or key points to guide by, if the
> >descriptions change while the players are wandering around, the confusion
> >and/or frustration that the players experience might turn them away. Like a
> >player who knows the path to the hidden cave is marked by an old oak tree
> >standing within a pine forest. If someone were to chop the old oak tree,
> >that landmark has now been destroyed. Again, it would be the realistic
> >thing to happen, but will it hurt the MUD rather than help it?
> >
> >< About - "FLEXIBLE PLAYER DESCRIPTIONS">
> >
> > This is also an interesting idea that has mixed opinions on whether or
> >not it should be done. I have been contemplating testing a system where all
> >creatures, being players and mobs, have a generic title that is displayed
> >when you see them in a room. Such as - In this room is a short,
> >dark-skinned man, a slender, robed woman, and a giant warrior riding a
> >warhorse. These 3 people could be other players, mob creatures, or NPC's
> >from the local town. They are all strangers and they are just as you see
> >them. These titles would be based on there current clothing or appearance.
> >They could be altered at a local tailor or similar place. You could then
> >have an INTRODUCE command which would introduce you to them, or could also
> >be used for you to introduce two people to each other, encouraging
> >conversation and role-playing. Once you have met someone, you always see
> >them as their name, instead of their title. Helping you recognize familiar
> >faces in a croud of strangers. Also allowing for possible skills for
> >thieves like disguises and/or impersinations. All that would be needed to
> >keep track of who knows who would be a 2-dimensional array of flags. Does
> >player 1 know player 235? If you wanted, this could be extended to actually
> >classify people you have met, labeling them as acquaintances, good friends,
> >mortal enemies, etc... And when you encounter them, the text is altered
> >accordingly. In the room you see John, your friend Bob, your blood-brother
> >Michael, and that evil-swine Robert. You get the idea.
> >
> >Anyway that is all for now, my fingers are tired.
> >
> >Thanks,
> >Christopher.
sean...@yahoo.com
Mason Deming <mde...@activision.com> wrote:
The problem arises due to the fact that Simu is -making money- off of the
shmucks in the lands.
The apathetic gamemasters -cause- more problems than they solve. PvP is
illegal, and i've been murdered at least three times - after waiting for two
hours to speak with a gamemaster, the perpetrater had disconnected, and there
were no reparations, i lost silver/experience/time, i was told to 'chock it
up to bad luck .. school will be in session soon and most of "those" type of
people will be gone'. (assuming of course that all snerts were young folks,
but i didn't call her on this)
My response:
I couldn't agree more. After a period of playing GS3 for a number of years, I
left, despite strong attachment to a number of characters, to say nothing of
the friends I'd made "in the lands."
My enjoyment of GS and other Simutronics games, I should point out, was always
IN SPITE of the uniformly shabby GMing, poor world maintenance, and the like.
Addictive though it was, I couldn't agree more with Mason's line: "Leaving
was like pulling a splinter from my eye."
Sean Wolfe
Thierry Coutelier
John Adelsberger wrote:
> If you're not using a language that provides them premade(IE, if you're
> using C, for instance:) it'd be a good idea to either obtain or create
> for personal use a set of structures including at least these(some can
> share code heavily):
>
You can find a full set of libraries with all the data structures.I'm sorry I can't
tell you a precise one but on ftp://ftp.cdrom.com
they have nice CD's with lot's of free libraries.
---
Thierry....@remove-to-mail.prophecy.lu
http://www.prophecy.lu
http://www.mud.lu
Visit Prophecy the David Eddings MUD
telnet://mud.prophecy.lu:4000
---
John Frazer
>simulations of a system in which players may or may not actively
>participate. Certainly the players and their direct MUDding
>experience are not always considered the most important ingredients in
>a MUD.
In implementing weather, it was necessary to keep track of the current state
of the weather regardless of the presence of players so that weather would
be
consistent with reality and sensible over a period of time.
Some background processing was required to do that. I tried to keep that to
a minimum. The fun stuff (and server intensives stuff) only happens when
players
are present.
Chade Jeffers
help them perform the tasks. I've found that the GM's usually see answering
assists as more of a pain, as they are usually working on projects to
improve the world... and in that mess the world that is already created gets
lost in the shuffle.
Several of the GM's have attitudes, or a holier-than-thou approach to
things. Such 'corruption' comes with power.
Chade
Simutronics X-GM
Modus Operandi
>I couldn't agree more. After a period of playing GS3 for a number of years,
I
>left, despite strong attachment to a number of characters, to say nothing
of
>the friends I'd made "in the lands."
>
>My enjoyment of GS and other Simutronics games, I should point out, was
always
>IN SPITE of the uniformly shabby GMing, poor world maintenance, and the
like.
>
>Addictive though it was, I couldn't agree more with Mason's line: "Leaving
>was like pulling a splinter from my eye."
>
dj...@yahoo.com
> Hrmm, it's hard to say -- each GM has a set task, and people under them to
> help them perform the tasks. I've found that the GM's usually see answering
> assists as more of a pain, as they are usually working on projects to
> improve the world... and in that mess the world that is already created gets
> lost in the shuffle.
>
> Several of the GM's have attitudes, or a holier-than-thou approach to
> things. Such 'corruption' comes with power.
>
> Chade
> Simutronics X-GM
> Modus Operandi
As a former player of GS3, all I can say is that were it not a "pay-to-play"
MUD, I could accept a little corruption and holier-than-thou attitude. But as
a paying customer, I tend to think that the customer is always right. I know
that makes it hard to handle the crowds of 14-year olds with debit cards. But
a GM copping attitude to the 30+ demographic -- incidentally, the very
demographic that kept Simutronics running through their years on GEnie --
doesn't fly. And is ultimately why I left.
~Indi