Stock muds: the my-way highway
Greg Munt
On 1 Apr 1997, john wrote:
> The problem is that there are hundreds of muds springing up all over the
> place, with very little variety, administrated by people who have all
> the power and want none of the responsibility, and would not be Gods if
> they had to code the whole mud themselves, because in short they could
> not do it. Now, some people who admin some of these cheese muds could
> program their own, given a lot of time.
> However, they've not worked for the system they've set up. They've not
> earned the right to make policy decisions for their previous mud and
> consequently they want to skip the entire question of qualifications
> and competency to make those decisions. They clone a stock mud. They
> change a few descs. They disable a few variables, or rename
> spell_points to special_points. Presto, My-WayMUD.
> (i'd love to be proven wrong - i am this jaded with mud 'development' these
> days)
I wouldn't call it development. I'd call it shovelling shit onto shit. An
extract from a report I am writing:
"Bartle's 'industry' seems
doomed to remain in a stasis of late-eighties designs and ideas, since the
community, in almost all of its entirety, seems to dwell on rewriting old code,
rather than innovation and diversification from 'the big three'. New codes are
not really new at all, but old codes renamed, or old code with its bugs fixed,
and more features added on top. Is this the Trubshaw/Bartle dream? Or
nightmare?
'Muds could evolve into a major pastime. If they do, expect organisations like
Microsoft to be running them. Are we in any state to compete with such forces
at the moment?'
-- Martin Keegan's initiation of the long-running 'Stock Muds
Considered Harmful' USENET thread.
...
To debate whether the release of code in PD would damage the community
is far too late. So late, as to be terminally pointless. To proceed, the hold
of 'the big three' over the community must be broken, and it is only the
release of substantially different code into that community, that things will
even have a chance of changing."
The scratch mud I am writing will be GPL'd. Possibly I am being a
pessimist. And possibly all I will be doing is creating more variety of
shit. But the way I see it, the more variety of shit you have, the
greater the chances that some of it might turn out to be a diamond.
OK - my time is up. You may now recommence flame warfare.
------------------------------------------------------------------------------
T H E F R O N T I E R S P R O J E C T
http://www.uni-corn.demon.co.uk telnet://linux2.cms.shu.ac.uk:9999
A planned Internet & MUD resource. YOU can contribute: see web for details.
Greg Munt
On 2 Apr 1997, Brian James Green wrote:
> So, I think even if Microsoft, et al get into MUDs, there will still be
> an interest in hobby MUDs. As I have said before, you cannot beat a
> hobby MUDs pricing strategy: free!
Given the 'free' culture of today's mudding community, I think it more
likely that Microdollar would try to sell its products off the back of an
apparently 'free' mud, rather than apply usage charges - in much the same
way as they had to make IE free, because Netscape was free, and the
Internet culture demands it, pretty much.
> >To debate whether the release of code in PD would damage the community
> >is far too late. So late, as to be terminally pointless. To proceed, the hold
> >of 'the big three' over the community must be broken, and it is only the
> >release of substantially different code into that community, that things will
> >even have a chance of changing."
>
> Pardon my ignorance, but to which "big three" are you referring to?
DIKU, LP, Tiny. If you were a newbie glancing at rec.games.mud.*, the
names of their newsgroups would tend to give marked authenticity.
Does anyone wish to give some opinions on how USENET has influenced the
growth of muds?
> >The scratch mud I am writing will be GPL'd.
> I don't think you're
> going to do anything interesting or new that an LP MUD can't already do,
> mechanics wise. Heck, even if some of the mechanical aspects aren't to
> your tastes, you can redo them all!
If you are going to redo them all, there seems little point starting with
a code base in the first place.
> I think the tough part is coming up with a good *setting*. That is what
> makes a MUD new and unique and interesting.
Agreed. Design, setting and general atmosphere of the game should be
given a higher priority than coding, imho. People dont play a game for
how well its coded.
> I don't think that it's the material we're working with. I think we
> have a bunch of charcoal sitting around. Too many people are happy to
> dust it off and put it on display as a work of art. Fewer are willing
> to dedicate the time you need to make it into a diamond.
Yes. But - writing from scratch (I'll try not to get TOO religous;) means
you have no chance of adopting any of the inherited design ideas from the
code you are using. Additionally, writing ALL the code encourages you
(but does *not* force you) to use your own design techniques and ideas.
Conversely, not writing from scratch allows you to concentrate on what
some would consider 'the game itself', rather than be bogged down with
low-level coding like socket I/O. You should be commended for making your
game design public. It would be interesting to see how the community were
to grow, if designs were as freely available as code.
Another point leading from this, is how much attention to Analysis and
Design do mud administrators pay, when developing their game? Or do they
just hack it all up (TinyMUD was 'written in a weekend', giving the
implication that little or no thought was given to A&D - any thoughts on
this, especially considering the number of muds that have been derived
from it?)? I seem to be travelling along the Analysis/QA/Design/QA/
Implementation/QA/Testing/QA route, myself; OOA -> OOD -> OOP is of
particular interest to me right now.
Brian James Green
In <Pine.LNX.3.91.97033...@uni-corn.demon.co.uk> Greg Munt <gr...@uni-corn.demon.co.uk> writes:
[snip of jaded MUD development]
>I wouldn't call it development. I'd call it shovelling shit onto shit. An
>extract from a report I am writing:
>"Bartle's 'industry' seems
>doomed to remain in a stasis of late-eighties designs and ideas, since the
>community, in almost all of its entirety, seems to dwell on rewriting old code,
>rather than innovation and diversification from 'the big three'. New codes are
>not really new at all, but old codes renamed, or old code with its bugs fixed,
>and more features added on top. Is this the Trubshaw/Bartle dream? Or
>nightmare?
>'Muds could evolve into a major pastime. If they do, expect organisations like
>Microsoft to be running them. Are we in any state to compete with such forces
>at the moment?'
> -- Martin Keegan's initiation of the long-running 'Stock Muds
> Considered Harmful' USENET thread.
Interesting.
Allow me to say a few things. :)
First, I don't think hobby MUDs will die out anytime soon. Look at
video games. There's 3 million game companies out there, yet indy
programmers still put out share/freeware games. Heck, look at the
variety of Java games out there (use your favorite search engine!)
Many nights of schoolwork have been eaten by some clever Java games on
the WWW.
So, I think even if Microsoft, et al get into MUDs, there will still be
an interest in hobby MUDs. As I have said before, you cannot beat a
hobby MUDs pricing strategy: free!
>...
>To debate whether the release of code in PD would damage the community
>is far too late. So late, as to be terminally pointless. To proceed, the hold
>of 'the big three' over the community must be broken, and it is only the
>release of substantially different code into that community, that things will
>even have a chance of changing."
Pardon my ignorance, but to which "big three" are you referring to?
>The scratch mud I am writing will be GPL'd. Possibly I am being a
>pessimist. And possibly all I will be doing is creating more variety of
>shit. But the way I see it, the more variety of shit you have, the
>greater the chances that some of it might turn out to be a diamond.
Although I'm not sure this is the whole point of your article, I ask
what is the point of re-doing the mechanical aspects? I personally have
the most experience with LP MUDs, so that is where I will comment. I
think that the whole concept of the LP MUD satisfies most of what one
needs to construct a good game. It has a programming language one can
use to create new objects to add to the game. I don't think you're
going to do anything interesting or new that an LP MUD can't already do,
mechanics wise. Heck, even if some of the mechanical aspects aren't to
your tastes, you can redo them all!
I think the tough part is coming up with a good *setting*. That is what
makes a MUD new and unique and interesting. On the development of
Demonscape, we have most of our designing on the setting of the game.
Now, with a solid setting, we are working on some of the other game
aspects (like the game definition of characters). I think too many
times people start with a "hey, here's a rough idea, let's code it!"
plan and it goes downhill from there. I think if more people were
willing to make a serious effort to design a deep, rich, consistent
world, then more games would be original.
I don't think that it's the material we're working with. I think we
have a bunch of charcoal sitting around. Too many people are happy to
dust it off and put it on display as a work of art. Fewer are willing
to dedicate the time you need to make it into a diamond.
>OK - my time is up. You may now recommence flame warfare.
Heh, heh, heh. Asbestos underwear....
"And I now wait / to shake the hand of fate...." -"Defender", Manowar
Brian Green, pch...@iastate.edu aka Psychochild
|\ _,,,---,,_ *=* Morpheus, my kitten, says "Hi!" *=*
ZZzz /,`.-'`' -. ;-;;,_ "If you two are so evil, then why don't
|,4- ) )-,_..;\ ( `'-' you just...EAT THIS KITTEN!"
'---''(_/--' `-'\_) - "The Tick", Saturday morning cartoon.
Check out: http://www.public.iastate.edu/~pchild to find out about me!
Martin Keegan
Brian James Green wrote:
> >'Muds could evolve into a major pastime. If they do, expect organisations like
> >Microsoft to be running them. Are we in any state to compete with such forces
> >at the moment?'
> > -- Martin Keegan's initiation of the long-running 'Stock Muds
> > Considered Harmful' USENET thread.
> First, I don't think hobby MUDs will die out anytime soon. Look at
Of course they won't. People will always write games for free, and
deserve our support. My point was that if muds became more popular
(and hence more profitable), then expect vast uncultured companies
to move in and make an even bigger mess than the 13yr old Circle
admins.
I was not saying that MS-style companies would put an end to free
muds, but that the current crop of muds is ill equipped to compete.
The cost of not competing will be that fewer players get to experience
the more creative muds out there, which would be a loss. Don't get
me wrong - I'm one of the converts! I couldn't give a damn if I only
ever had 3 players on my mud, but I don't want to see huge crappy
demand-driven muds disillusion potential players.
> So, I think even if Microsoft, et al get into MUDs, there will still be
> an interest in hobby MUDs. As I have said before, you cannot beat a
> hobby MUDs pricing strategy: free!
Who's to say MS would charge? If I were MS, I wouldn't. I'd offer
cash incentives to the better players.
> >To debate whether the release of code in PD would damage the community
> >is far too late. So late, as to be terminally pointless. To proceed, the hold
> >of 'the big three' over the community must be broken, and it is only the
> >release of substantially different code into that community, that things will
> >even have a chance of changing."
>
> Pardon my ignorance, but to which "big three" are you referring to?
LP, Diku, Tiny.
> >The scratch mud I am writing will be GPL'd. Possibly I am being a
> >pessimist. And possibly all I will be doing is creating more variety of
> >shit. But the way I see it, the more variety of shit you have, the
> >greater the chances that some of it might turn out to be a diamond.
>
> Although I'm not sure this is the whole point of your article, I ask
> what is the point of re-doing the mechanical aspects? I personally have
I've heard the "why reinvent the wheel" spiel a few times too. As
an LPer, you're probably a LOT more justified in saying it than others.
However, I believe stock code which you didn't write yourself
constricts what you can do in some areas, and encourages excess in
others. Most modified StockMUDs add colour, races, classes etc.
There's almost a set of 'stock additions'.
Mk
Ron Cole
Martin Keegan wrote:
[snip]
> Of course they won't. People will always write games for free, and
> deserve our support. My point was that if muds became more popular
> (and hence more profitable), then expect vast uncultured companies
> to move in and make an even bigger mess than the 13yr old Circle
> admins.
Actually, MUDs are EXTREMELY profitable right now if you
market them correctly. Take Gemstone III on AOL, for instance.
Before the big AOL price change, people paid $3.00 an hour to play
it. They were hitting about 1000 people at peak hours. Now, let's
say that Simutronics cleared $1.00 from that three (though I would
guess that they cleared more). They'd be making 1000 dollars an hour
from that game alone, not including the profits from the other networks
such as GEnie and Compuserve. Now, since Simutronics didn't remove
their game from AOL after the price change (and take a whole lot of
customers with it), they must still be making at least that much.
Probably more, now that they are peaking at 2000 users at a time.
On-line FRPGs (fantasy role-playing games) have made money for
a long time. They are MUDs, though they are not of the standard
traditions because they evolved seperately from DIKU and the rest.
They are, never the less, MUDs.
>
> I was not saying that MS-style companies would put an end to free
> muds, but that the current crop of muds is ill equipped to compete.
[rest of message snipped]
I agree with this statement, but would also like to point out
that MUDs have never really been in the same league as on-line FRPG's.
Monetary incentives pushed those code bases further and faster than
MUD code bases, and it will take A LOT of work to catch up.
-= Rindar
Narien
Yes, there are lots of crappy stock muds out there run by little
powertrippers. However, you must remember, there must be stuff that
sucks in order for there to be stuff that's cool. If all the shitty
muds were gone, the remaining cool muds would then be shitty by new
standards. Let the crappy players play the crappy muds, and let the
good players play the good muds. It all balances out.
Narien (dben...@mc.net)
"Madness is the mind's key to understanding."
Nathan F. Yospe
pch...@iastate.edu (Brian James Green) wrote:
:In <Pine.LNX.3.91.97033...@uni-corn.demon.co.uk> Greg
Munt <gr...@uni-corn.demon.co.uk> writes:
:
:>To debate whether the release of code in PD would damage the community
:>is far too late. So late, as to be terminally pointless. To proceed, the hold
:>of 'the big three' over the community must be broken, and it is only the
:>release of substantially different code into that community, that things will
:>even have a chance of changing."
:
:Pardon my ignorance, but to which "big three" are you referring to?
Diku, Tiny, LP.
:>The scratch mud I am writing will be GPL'd. Possibly I am being a
:>pessimist. And possibly all I will be doing is creating more variety of
:>shit. But the way I see it, the more variety of shit you have, the
:>greater the chances that some of it might turn out to be a diamond.
:
:Although I'm not sure this is the whole point of your article, I ask
:what is the point of re-doing the mechanical aspects? I personally have
:the most experience with LP MUDs, so that is where I will comment. I
:think that the whole concept of the LP MUD satisfies most of what one
:needs to construct a good game. It has a programming language one can
:use to create new objects to add to the game. I don't think you're
:going to do anything interesting or new that an LP MUD can't already do,
:mechanics wise. Heck, even if some of the mechanical aspects aren't to
:your tastes, you can redo them all!
OK, here is a list of the most prominent (but certainly not the only)
lacks/failings/flaws/crapouts of LP drivers, LPC, and popular libs.
No multiple threads. No distributed processing. Bad primary object model.
Poor object inheritance model. Poor control of degrees of access. Weak
typing. (this could be a "good" thing, depending on PoV) No "real"
programming skill development. Very, _very_ poor optimization. No support
for a true event model. (there are Diku clones that blow the best LP event
system away) Constrained interobject communication. Even with a complete
rewrite of the lib. That one's a flaw in the standard drivers. No impulse
communication. Hard to modify network support levels. Really cheesy
language. (Sorry, but I just _don't_ like LPC.) That having been said...
:I think the tough part is coming up with a good *setting*. That is what
:makes a MUD new and unique and interesting. On the development of
:Demonscape, we have most of our designing on the setting of the game.
:Now, with a solid setting, we are working on some of the other game
:aspects (like the game definition of characters). I think too many
:times people start with a "hey, here's a rough idea, let's code it!"
:plan and it goes downhill from there. I think if more people were
:willing to make a serious effort to design a deep, rich, consistent
:world, then more games would be original.
There is more at stake here than that. Diku, Tiny, and LP are not the only
ways of doing things, but they represent three(or more, Tiny is kinda
broad) major approaches. I know of half a dozen "original" codebases that
pretty
much use the same approach as one of the above. I know of another half dozen,
in development or running, that use approaches utterly different from the
"big three". Mine is one, as is Greg's. On top of that comes the setting.
I've done a "good setting". I used a Rom codebase, and hacked the shit out
of it, and created a totally unique and consistant world, well balanced...
but it still reeked of the Diku way of doing things.
:I don't think that it's the material we're working with. I think we
:have a bunch of charcoal sitting around. Too many people are happy to
:dust it off and put it on display as a work of art. Fewer are willing
:to dedicate the time you need to make it into a diamond.
No. Charcoal cannot be made into diamond. That's a cute myth. What we have
is an entire manufacturing base, and siting in the center of the room is
a pile of legos, with some cars and stuff already assembled, a set of
cunstrux already assembled into a few things, and one of those predesigned
erector sets. The problem is, most people go and "create" with the toys
sitting on the floor. Sure, you can create a shiny new design, but its
still going to look like its made out of legos. Then there are those other
kids over by the computers trying to make the construction robots assemble
them a new kind of construction set. One suited to the things they want to
construct.
:>OK - my time is up. You may now recommence flame warfare.
:
:Heh, heh, heh. Asbestos underwear....
Heh, heh, heh. Scuse me. Ah, yes... 30 moles tritium, 30 deuterium, 2
plutonium.... mind holding this a second, sir? Don't mind the red wires,
they're just decoration.
--
Nathan F. Yospe | There is nothing wrong with being a sociopath. Its
yo...@hawaii.edu | getting caught thats a problem. Be a mad scientist
UH Manoa Physics | Write poetry. Be an artist. Plot world domination.
Biomedical Phys. | Panthers make great pets. Muhahahahahahahahahaha!!
Nathan F. Yospe
Narien <dben...@mc.net> wrote:
:Yes, there are lots of crappy stock muds out there run by little
:powertrippers.
Lots == 80%+?
:However, you must remember, there must be stuff that
:sucks in order for there to be stuff that's cool.
Not true. I've heard this many, many times... but not everyone has to have
a basis for comparison. There are people out there who simply say "I like
this" and think no more of it. Still, there is a degree of comparison.
:If all the shitty
:muds were gone, the remaining cool muds would then be shitty by new
:standards.
Well, no. They would be average, on average. Not shitty. But... is that a
bad thing? That just means that the quality level would have to increase to
get the designation of "something really special, relatively".
:Let the crappy players play the crappy muds, and let the
:good players play the good muds.
Define "crappy player". Slow leveler == "crappy player"?
Asshole == "crappy player"? Bad RPer == "crappy player"?
There are too many stock muds out there. This has not a whit to do with the
players. The corolary of your implication would be "There are crappy players
in direct proportion to the number of crappy muds."
:It all balances out.
Uh, no. That made no sense.
In any case, there are few (aside from the purveyors of stock muds) who
feel that there is any justification for another one of the same. Most of
the people here, aside from the add men and lusers, are concerned with
creating something original, unique, and superior to what exists. However,
most of those here are also concerned with the quality and reputation of
the entire community... and crap stock muds hurt that.
Nathan F. Yospe
Greg Munt <gr...@uni-corn.demon.co.uk> wrote:
:On 2 Apr 1997, Brian James Green wrote:
:> Pardon my ignorance, but to which "big three" are you referring to?
:
:DIKU, LP, Tiny. If you were a newbie glancing at rec.games.mud.*, the
:names of their newsgroups would tend to give marked authenticity.
:
:Does anyone wish to give some opinions on how USENET has influenced the
:growth of muds?
That's an interesting question... I started Physmud++ and GURU before I
started paying attention to these NGs (I was an afper and little more for
a couple years prior), but got much of my later inspiration from a) these
ngs, and b) another similar (non usenet) forum.
:> I don't think you're
:> going to do anything interesting or new that an LP MUD can't already do,
:> mechanics wise. Heck, even if some of the mechanical aspects aren't to
:> your tastes, you can redo them all!
:
:If you are going to redo them all, there seems little point starting with
:a code base in the first place.
Not to mention, if you are going to be making statements like that, which
assume the use of LPC code modification, I could reply "I don't think you
are going to do anything interesting in LP that a good C++ mud (like my own,
or presumably Greg's) cannot. And forget about calling in the dynamic
loading.... I've got that. And a simpler internal OO language, that
happens
to be a bit cleaner than LPC, if not as deeply entrenched in the basic code
or quite as flexible. LPC is not the end all of development languages/bases.
It is nice. It is flawed. It is darn hard to fix, which makes the second
point important.
:> I think the tough part is coming up with a good *setting*. That is what
:> makes a MUD new and unique and interesting.
:
:Agreed. Design, setting and general atmosphere of the game should be
:given a higher priority than coding, imho. People dont play a game for
:how well its coded.
Well, aside from the lagging/crashing/obtaining a server that can handle
a mud that size problem, you mean... and there is also the questions of
how much support/potential the codebase offer the builders.
:> I don't think that it's the material we're working with. I think we
:> have a bunch of charcoal sitting around. Too many people are happy to
:> dust it off and put it on display as a work of art. Fewer are willing
:> to dedicate the time you need to make it into a diamond.
:
:Yes. But - writing from scratch (I'll try not to get TOO religous;) means
:you have no chance of adopting any of the inherited design ideas from the
:code you are using. Additionally, writing ALL the code encourages you
:(but does *not* force you) to use your own design techniques and ideas.
Religious? About writing from scratch? Blasphemer! To even imply that we,
the holy children of the scratch mud god, are a religion! I'll have you
excommunicated for this! (But seriously, I am in complete agreement here -
writing the code yourself allows more creativity than you would guess.
There are so many things even the most creative LP coder takes for granted...
:Conversely, not writing from scratch allows you to concentrate on what
:some would consider 'the game itself', rather than be bogged down with
:low-level coding like socket I/O. You should be commended for making your
:game design public. It would be interesting to see how the community were
:to grow, if designs were as freely available as code.
On the other hand, the socket I/O and such ammount to very little. If that
was all that was at question, I would extract the socket I/O and related
system interfaces and release that seperately as well as the Physmud++ base.
Actually, I might do just that anyway... if it would encourage more stock
muds (I hardly consider the telnet negotiation and such to be part of the
mud... and none of the big three seem to do a decent job of this, after all.)
Most of the work comes from determining your interaction and object models...
things that really seriously affect the "feel" of the game. These are
things that are hard, and could be skipped by using a modified stock
base... but it
does not change the fact that you will still have a bit of flavor residual
from the origins if you use the same loop or event model, for example.
:Another point leading from this, is how much attention to Analysis and
:Design do mud administrators pay, when developing their game? Or do they
:just hack it all up (TinyMUD was 'written in a weekend', giving the
:implication that little or no thought was given to A&D - any thoughts on
:this, especially considering the number of muds that have been derived
:from it?)? I seem to be travelling along the Analysis/QA/Design/QA/
:Implementation/QA/Testing/QA route, myself; OOA -> OOD -> OOP is of
:particular interest to me right now.
Well, I am in my fifth version now. The first version was designed to be a
hackless rewrite of Merc. It no longer exists, AFIK, though I did give away
a few copies. MUD++ reminds me strongly of Physmud++ v.1 (though I think
Smith released the first version of MUD++ about 6 months before I finished
v.1). Version 2 was an overnight hack, and it showed, ultimately. I gave away
some copies of it before I grew too dissatisfied and chucked it. The last
three versions were examples of sucessive A/D/I/T efforts, with the A&D
getting redone several times, but I&T only twice (v.5 is still in the midst
of I right now... after getting aborted halfway by another bout of
spontanious A&D while loaded on one of my caffine concoctions)
Brian James Green
>On 2 Apr 1997, Brian James Green wrote:
[snip]
>> Pardon my ignorance, but to which "big three" are you referring to?
>DIKU, LP, Tiny. If you were a newbie glancing at rec.games.mud.*, the
>names of their newsgroups would tend to give marked authenticity.
Gotcha, thanks. :)
>Does anyone wish to give some opinions on how USENET has influenced the
>growth of muds?
Good idea. However, I must admit that I got involved in playing and
designing MUD aspects LONG before I really got into the MUD newsgroups.
>> >The scratch mud I am writing will be GPL'd.
>> I don't think you're
>> going to do anything interesting or new that an LP MUD can't already do,
>> mechanics wise. Heck, even if some of the mechanical aspects aren't to
>> your tastes, you can redo them all!
>If you are going to redo them all, there seems little point starting with
>a code base in the first place.
Er....let me explain things for the non-LP inclined. :) No, I'm not an
expert, so I won't take any corrections to my post personally. :)
There are two important pieces of code for an LP: the driver and the
library (lib). The driver handles machine-level things (like socket
code, etc) and definition of the LPC language (which is what one uses to
write the lib), while the lib handles game mechanics (and some of the
interaction with the driver). What I'm designing is the lib. I don't
want to mess with socket code (I'm a CS major, but that's definitely not
my area of interest!) I'm more interested in the interaction of game
elements and how they are coded (Ah, the OO background is paying off!)
No, I'm not designing every single aspect of it. I'm hoping to use a
developing lib to get a running start, then expand and/or rewrite the
things I want to. The other designers are working on the more creative
aspects of the game (like social structures, descriptions, etc).
By coding the lib, one decides how players are determined (like stats,
levels, mechanics of races), how the different objects are defined
(damage values and to-hit rolls on weapons, protection of armour) and
how the mechanics all fit together (basically designing combat).
The problem with LPs and designing their libs are that you gotta know
LPC to get anywhere, and that takes a programming knowledge. As pointed
out in other threads, this proves daunting to the non-technical people
who are creative, but that don't want to spend time learning how to
program or learning LPC.
The benefit is that it is extremely flexible. I can rewrite combat in
the lib without having to recompile the driver. I can make changes
on-the-fly to the system (hopefully after testing them!) I can enhance
the game mechanics endlessly. I'm limited by my understanding of
programming (and LPC) and my imagination/creativity.
>> I think the tough part is coming up with a good *setting*. That is what
>> makes a MUD new and unique and interesting.
>Agreed. Design, setting and general atmosphere of the game should be
>given a higher priority than coding, imho. People dont play a game for
>how well its coded.
Exactly. So, we're striving to create a vivid game world with a set of
interesting game mechanics. Nothing too complex, but something that
people can truly interact with. The setting is getting the most
emphasis (as you can see from the start of our design document). Next
comes the mechanics and other pure game aspects.
>> I don't think that it's the material we're working with. I think we
>> have a bunch of charcoal sitting around. Too many people are happy to
>> dust it off and put it on display as a work of art. Fewer are willing
>> to dedicate the time you need to make it into a diamond.
>Yes. But - writing from scratch (I'll try not to get TOO religous;) means
>you have no chance of adopting any of the inherited design ideas from the
>code you are using. Additionally, writing ALL the code encourages you
>(but does *not* force you) to use your own design techniques and ideas.
Well, that's what newsgroup discussion is for, IMHO. I read here about
people's ideas and think how they impact on my own. I then report
whatever I might think is a good idea to the other designers. Sometimes
the ideas gets changed and put into our work, other times it's scrapped.
I think that to be unique, you have to rely primarily on your own
ideas. That way people don't take the easy way out ("Ah, let's keep the
stock areas").
>Conversely, not writing from scratch allows you to concentrate on what
>some would consider 'the game itself', rather than be bogged down with
>low-level coding like socket I/O. You should be commended for making your
>game design public. It would be interesting to see how the community were
>to grow, if designs were as freely available as code.
Socket code? See above. And, thank you for the complement. I hoped to
get feedback on our design and to inspire others to make their own
interesting MUD design and to perhaps publish it on-line as we have.
>Another point leading from this, is how much attention to Analysis and
>Design do mud administrators pay, when developing their game? Or do they
>just hack it all up (TinyMUD was 'written in a weekend', giving the
>implication that little or no thought was given to A&D - any thoughts on
>this, especially considering the number of muds that have been derived
>from it?)? I seem to be travelling along the Analysis/QA/Design/QA/
>Implementation/QA/Testing/QA route, myself; OOA -> OOD -> OOP is of
>particular interest to me right now.
Well, as far as Demonscape goes, we've been designing the world for over
a year now. We're up (using a temporary lib) and waiting for the real
lib to e finished. We're still sharpening the finer points of the
environment and starting to work out some real game mechanics. I'll
update the WWW page as we get more done. Hopefully, we'll do a lot of
testing of the mechanics before we make a final decision. :)
More info on our development can of course be found on the WWW pages
mentioned in my .signature. Follow the "Demonscape" links.
Reimer Behrends
Nathan F. Yospe (yo...@hawaii.remove.this.edu) wrote:
[...]
: OK, here is a list of the most prominent (but certainly not the only)
: No multiple threads. No distributed processing.
This is debatable. As a professor of mine once said (an expert on
distributed systems), first of all concurrency gives you a _lot_ of
problems. Part of the fun of research in that area is to solve these
problems, but I usually don't want to do research on that topic when I
try to program a virtual world, especially as most concurrent
programming techniques nowadays are about as reliable as managing memory
allocation and deallocation manually.
: Bad primary object model.
Agreed.
: Poor object inheritance model.
Agreed, although at least DGD is an improvement over what you see in
other languages such as C++.
: Poor control of degrees of access.
: Weak typing. (this could be a "good" thing, depending on PoV)
First of all, it's dynamic typing, not weak typing. LPC is strongly, but
dynamically typed (actually, DGD at least can be made to have _some_
static typing) I basically have no problem with that and have toyed with
the idea of adapting a Smalltalk engine to the needs of mudding (MOOs
are somwhat inspired by Smalltalk, but have other problems). Lack of
static typing is definitely nothing crippling.
: No "real" programming skill development.
Hmm?
: Very, _very_ poor optimization.
Depends. DGD and MudOS do some optimization, and, frankly, I have no
performance related problems with most current LP drivers.
: No support for a true event model. (there are Diku clones that blow
: the best LP event system away)
Please explain, especially as I don't know what you mean by a "true
event model". Event-based programming is certainly nothing new, and I
don't know about anything inherent in LPmuds that makes it a problem.
: Constrained interobject communication. Even with a complete rewrite
: of the lib. That one's a flaw in the standard drivers. No impulse
: communication.
Frankly, I have no idea what you are talking about. Care to explain?
: Hard to modify network support levels.
That depends on whether you _want_ network support. Not that I see
serious flaws with the existing implementations.
: Really cheesy
: language. (Sorry, but I just _don't_ like LPC.) That having been said...
I think we can agree here. LPC as a programming language has lots of
deficiencies (mostly due the fact that it didn't evolve very much ever
since its original conception).
[...]
Reimer Behrends
Martin Keegan
NFY scrote:
> players. The corolary of your implication would be "There are crappy players
> in direct proportion to the number of crappy muds."
We went through this earlier, and found that the corollary of what
I'd said in the Stock Muds Considered Microsoft Fodder thread was that
player demand drove muds to remain as close to the stock as possible
(despite my arguments leading in this direction, I find it hard to
believe)
Mk
Kal Lin
According to Reimer Behrends <behr...@student.uni-kl.de>:
>This is debatable. As a professor of mine once said (an expert on
>distributed systems), first of all concurrency gives you a _lot_ of
>problems. Part of the fun of research in that area is to solve these
>problems, but I usually don't want to do research on that topic when I
>try to program a virtual world, especially as most concurrent
As a graduate student in distributed systems, I agree. Also, don't
forget the fault tolerance aspect is another big hurdle.
--Kal
Greg Munt
On Fri, 4 Apr 1997, Martin Keegan wrote:
> We went through this earlier, and found that the corollary of what
> I'd said in the Stock Muds Considered Microsoft Fodder thread was that
> player demand drove muds to remain as close to the stock as possible
> (despite my arguments leading in this direction, I find it hard to
> believe)
I dont. IMO there are many more people out there that want a mud with
peaks of 1-200, then there are people that want to write a good mud - people
who would rather have a good mud and 20 users, than a crap, shite, (you get
the picture) StockMUD with a userbase of tens of thousands.
------------------------------------------------------------------------------
T H E F R O N T I E R S P R O J E C T
http://www.uni-corn.demon.co.uk telnet://linux2.cms.shu.ac.uk:9999
A student who changes the course of history is probably taking an exam
Nathan F. Yospe
behr...@student.uni-kl.de (Reimer Behrends) wrote:
:Nathan F. Yospe (yo...@hawaii.remove.this.edu) wrote:
:: No multiple threads. No distributed processing.
:
:This is debatable. As a professor of mine once said (an expert on
:distributed systems), first of all concurrency gives you a _lot_ of
:problems. Part of the fun of research in that area is to solve these
:problems, but I usually don't want to do research on that topic when I
:try to program a virtual world, especially as most concurrent
:programming techniques nowadays are about as reliable as managing memory
:allocation and deallocation manually.
Sorry, but not having the option is a huge handicap, considering that my
entire event locality model is based on threads. The point was that the
original author claimed that anyone who didn't use LPC was reinventing the
wheel. I disagree, and the lack of threads is a heavy motivator. Besides,
I've never had to worry about concurancy. Concurancy problems usually stem
from a non object oriented thread approach, or a bad model.
:: Poor object inheritance model.
:
:Agreed, although at least DGD is an improvement over what you see in
:other languages such as C++.
As opposed to MudOS, which is the one I'm familiar with.
:: Weak typing. (this could be a "good" thing, depending on PoV)
:
:First of all, it's dynamic typing, not weak typing. LPC is strongly, but
:dynamically typed (actually, DGD at least can be made to have _some_
:static typing) I basically have no problem with that and have toyed with
:the idea of adapting a Smalltalk engine to the needs of mudding (MOOs
:are somwhat inspired by Smalltalk, but have other problems). Lack of
:static typing is definitely nothing crippling.
Er... from what I've seen, its _weak_ typing in MudOS. Really, really,
_really_ weak typing. Dynamic typing can be strong... usually is. The
stuff I saw going on in MudOS had no type confirmation, and absolute
casting. (Well, its a 'feature', right? It made it to release, after all.)
:: No "real" programming skill development.
:
:Hmm?
C'mon. You think LPC is gonna get them one step closer to a job?
:: Very, _very_ poor optimization.
:
:Depends. DGD and MudOS do some optimization, and, frankly, I have no
:performance related problems with most current LP drivers.
Compared to what? I use C++ as a basis of comparison. LP drivers don't
even register.
:: No support for a true event model. (there are Diku clones that blow
:: the best LP event system away)
:
:Please explain, especially as I don't know what you mean by a "true
:event model". Event-based programming is certainly nothing new, and I
:don't know about anything inherent in LPmuds that makes it a problem.
Event modeling (as opposed to event based programming) allow events to
run concurrently as processes. The lack of thread support negates this
possibility.
:: Constrained interobject communication.
:Frankly, I have no idea what you are talking about. Care to explain?
Ever work on a neural net system? Turns out a crippled neural net is
an incredibly apt metaphor for dynamic interrelation of objects in a
virtual world.
:: Hard to modify network support levels.
:
:That depends on whether you _want_ network support. Not that I see
:serious flaws with the existing implementations.
No. But having it impossible to fix without gutting the driver bug me.
:: Really cheesy
:: language. (Sorry, but I just _don't_ like LPC.) That having been said...
:I think we can agree here. LPC as a programming language has lots of
:deficiencies (mostly due the fact that it didn't evolve very much ever
:since its original conception).
Reminds me of QuackC, in a certain respect. Not that its as bad a hack, but,
well... actually, it is. Just in a different way.
Tim Hollebeek
In article <Pine.LNX.3.91.97040...@uni-corn.demon.co.uk>, Greg Munt <gr...@uni-corn.demon.co.uk> writes:
> On Fri, 4 Apr 1997, Martin Keegan wrote:
>
> > We went through this earlier, and found that the corollary of what
> > I'd said in the Stock Muds Considered Microsoft Fodder thread was that
> > player demand drove muds to remain as close to the stock as possible
> > (despite my arguments leading in this direction, I find it hard to
> > believe)
>
> I dont. IMO there are many more people out there that want a mud with
> peaks of 1-200, then there are people that want to write a good mud - people
> who would rather have a good mud and 20 users, than a crap, shite, (you get
> the picture) StockMUD with a userbase of tens of thousands.
Of all the slightly modified stock MUDs I've seen, *all* have lacked anyone
with sufficient talent to substantially change things. *every* MUD that
I've seen with a talented coder looks substantially different from whatever
they started with. Lets face it; throwing up a stock MUD isn't going to
get you a large player base simply because *anyone* can do it; there are
tons of stock MUDs already.
---------------------------------------------------------------------------
Tim Hollebeek | Disclaimer :=> Everything above is a true statement,
Electron Psychologist | for sufficiently false values of true.
Princeton University | email: t...@wfn-shop.princeton.edu
----------------------| http://wfn-shop.princeton.edu/~tim (NEW! IMPROVED!)
Nathan F. Yospe
k...@cs.toronto.edu (Kal Lin) wrote:
:According to Reimer Behrends <behr...@student.uni-kl.de>:
:>This is debatable. As a professor of mine once said (an expert on
:>distributed systems), first of all concurrency gives you a _lot_ of
:>problems. Part of the fun of research in that area is to solve these
:>problems, but I usually don't want to do research on that topic when I
:>try to program a virtual world, especially as most concurrent
:
:As a graduate student in distributed systems, I agree. Also, don't
:forget the fault tolerance aspect is another big hurdle.
I've discovered, when using threads, that there are three factors that
influence difficulty.
One is the use of object oriented vs procedural languages. Procedural
languages are initially easier to implement threads in, and far too often,
people using OO languages will be tempted to simply use a main()
procedural operation to control the threads. However, if one takes the
time to create
an object based thread model, 95% of the concurency problems vanish, and
the rest are trivial.
Another major factor is the organization of thread heirarchies. A
manager thread can handle concurency for a large number of active and
inactive threads, and a heirarchy of managers can actually take care of
most any concurency problem.
The last factor applies only to muds. The last factor is thread modeling
relative to your object model. In my experience, modeling threads as a time
process inherent in the spacial model (rooms, regions, whatever) works best,
as many concurency commands are minimal if the entire region is handled by
one threaded event queue.
George Reese
:
: :Nathan F. Yospe (yo...@hawaii.remove.this.edu) wrote:
: :
: :This is debatable. As a professor of mine once said (an expert on
: :distributed systems), first of all concurrency gives you a _lot_ of
: :problems. Part of the fun of research in that area is to solve these
: :problems, but I usually don't want to do research on that topic when I
: :try to program a virtual world, especially as most concurrent
: :allocation and deallocation manually.
:
: Sorry, but not having the option is a huge handicap, considering that my
: entire event locality model is based on threads. The point was that the
: original author claimed that anyone who didn't use LPC was reinventing the
: wheel. I disagree, and the lack of threads is a heavy motivator. Besides,
: I've never had to worry about concurancy. Concurancy problems usually stem
: from a non object oriented thread approach, or a bad model.
It depends on what you are trying to build. Clearly a lot of muds do
very well without threading. In fact, in a threaded language, there
is not a whole lot you would actually thread. Concurrency in an
environment like a mud *is* a hard issue as Reimer said.
Now you state you are doingit based on locality... I assume that means
somewhere you keep track of which objects are physically proximate to
each other in the sense that physical proximity defines the universe
with which you can interact.
While that goes a long way to getting rid of some hairy issues, it
still leaves the question of what happens when you leave one
'universe' and go into another. And while I am just shoving words
into your mouth here and may not have described what you are doing at
all, such an approach has some serious limitations as to the type of
worlds you can implement.
: :: Weak typing. (this could be a "good" thing, depending on PoV)
: :
: :First of all, it's dynamic typing, not weak typing. LPC is strongly, but
: :dynamically typed (actually, DGD at least can be made to have _some_
: :static typing) I basically have no problem with that and have toyed with
: :the idea of adapting a Smalltalk engine to the needs of mudding (MOOs
: :are somwhat inspired by Smalltalk, but have other problems). Lack of
: :static typing is definitely nothing crippling.
:
: Er... from what I've seen, its _weak_ typing in MudOS. Really, really,
: _really_ weak typing. Dynamic typing can be strong... usually is. The
: stuff I saw going on in MudOS had no type confirmation, and absolute
: casting. (Well, its a 'feature', right? It made it to release, after all.)
We have already noted in other threads that your experience with MudOS
is extremely dated. You really should not talk about it in a present
day context because it has changed tremendously since then. And this
is one thing Beek has cleaned up really well.
: :: No "real" programming skill development.
: :
: :Hmm?
:
: C'mon. You think LPC is gonna get them one step closer to a job?
Uh, yes.
I would hire a good LPC coder in an instant in the real world, even if
it were the only language they knew. LPC is as real as any other
language.
By the way... it got me my first job programming.
: :: Very, _very_ poor optimization.
: :
: :Depends. DGD and MudOS do some optimization, and, frankly, I have no
: :performance related problems with most current LP drivers.
:
: Compared to what? I use C++ as a basis of comparison. LP drivers don't
: even register.
Well, that is a silly comparison basis. The proper measuring stick is
if a tool performs the job you want in a time frame that provides
reasonable feedback.
We could of course compare to machine code. The C++ would look bad.
But the point is that we do not need that speed, and we do not need
C++'s speed any more.
: :: No support for a true event model. (there are Diku clones that blow
: :: the best LP event system away)
: :
: :Please explain, especially as I don't know what you mean by a "true
: :event model". Event-based programming is certainly nothing new, and I
: :don't know about anything inherent in LPmuds that makes it a problem.
:
: Event modeling (as opposed to event based programming) allow events to
: run concurrently as processes. The lack of thread support negates this
: possibility.
Well, as has been stated many times before, this is a genuinely hard
issue. The typical example might be:
I issue the close door command in room A.
You issue the exit room command in room B.
Of course, without any synchronization method, you could walk through
a closed door. But, naturally, since this is a threaded environment,
we would grab the first event we receive (for the sake of argument,
the close door event) and start processing it... The question is on
what scale do we synchronize processing? The entire mud? Well, then
we might as well not be multi-threaded. Our two rooms? What about
other adjacent rooms? What does it mean to synchronize a room?
: :: Constrained interobject communication.
:
: :Frankly, I have no idea what you are talking about. Care to explain?
:
: Ever work on a neural net system? Turns out a crippled neural net is
: an incredibly apt metaphor for dynamic interrelation of objects in a
: virtual world.
Bah, you could do a workable neural net system in a LPMud. I have
been toying with putting in a poor man's one. I just do not know if
it is worth the time.
: :: Hard to modify network support levels.
: :
: :That depends on whether you _want_ network support. Not that I see
: :serious flaws with the existing implementations.
:
: No. But having it impossible to fix without gutting the driver bug me.
Other than blocking I/O, what do you want? Note that blocking I/O
raises significant security issues too.
: :: Really cheesy
: :: language. (Sorry, but I just _don't_ like LPC.) That having been said...
:
: :I think we can agree here. LPC as a programming language has lots of
: :deficiencies (mostly due the fact that it didn't evolve very much ever
: :since its original conception).
:
: Reminds me of QuackC, in a certain respect. Not that its as bad a hack, but,
: well... actually, it is. Just in a different way.
I think you have failed really to show anything of how LPC is
deficient. As Reimer said, it *is* deficient, mostly for historical
reasons. But with respect to building muds, it is a damn good
language. And it does in fact teach people some good things about OO
design and programming.
--
George Reese (bo...@imaginary.com) http://www.imaginary.com/~borg
i speak religion's message clear i am the prayers of the naive
i am denial guilt and fear i am the lie that you believe
-nine inch nails
Nathan F. Yospe
George Reese (bo...@visi.com) wrote:
:Nathan F. Yospe (yo...@hawaii.remove.this.edu) wrote:
I'm going to take this away from LPs... I don't like LPC, or the drivers,
and will stand by that, to anyone who says that they encompass anything
you could concievably want out of a mud. I have never been impressed by
an LP. Period. So, by implication, they are not an ideal to which I would
strive. Thus, I am writing from scratch. You guys who like LPs can write
libs, or modify libs, or whatever. I don't really care. I still don't
like them.
:It depends on what you are trying to build. Clearly a lot of muds do
:very well without threading. In fact, in a threaded language, there
:is not a whole lot you would actually thread. Concurrency in an
:environment like a mud *is* a hard issue as Reimer said.
But hardly insurmountable. It all comes down to what you want. Recall
Chris Lawrance's thread basket event system. There are a number of people
using threads, and other concepts not supported by LP drivers, in ways
that you would never think of, coming from the context of LPs. The truth
is, when you lock yourself to one paradigm, you put blinders on with
respect to all other possible paradigms, and simply end up saying "Why
would you want to do that?".
:Now you state you are doingit based on locality... I assume that means
:somewhere you keep track of which objects are physically proximate to
:each other in the sense that physical proximity defines the universe
:with which you can interact.
Well, in the sense that everything is referenced in the context of a
containment heirarchy, yes. And in the sense that transfer between one
containment and another is handled by special objects that are metaphorical
constructs of entance/exit pairs.
:While that goes a long way to getting rid of some hairy issues, it
:still leaves the question of what happens when you leave one
:'universe' and go into another. And while I am just shoving words
:into your mouth here and may not have described what you are doing at
:all, such an approach has some serious limitations as to the type of
:worlds you can implement.
I see no problem with transfer between "universes". I have mentioned on
another thread that I use a three level event scope model. Anything that
has relevancy within a greater universe will be handled by the event queue
for that greater context, and the thread thereof, and since concurency
clashes always fall in favor of the larger scope, there is no conflict. I
dunno what you mean with the limitations to possible worlds... I can see
very few limitations of the sort in my system, as it was designed in part
around the idea of creating as many impossible scenarios as I could come up
with. If you mean the limitations inherent in having to have some sort of
junction between locations, that has never created a problem for me. Every
location has these junctions, from the inside of a bag to a huge expanse of
open free fall space. They do not limit movement within local contexts, such
as drifting in space, or... well, I can't see a guy moving too much in a bag,
but he's welcome to try.
There is a bag on the ground next to the 10,000 meter precipice. The bag
squirms wildly. The bag jerks and jackknifes. The bag tumbles off the edge
of the precipice. A muffled scream escapes the bag as it falls out of sight.
> look off precipice
You edge up to the cliffside lookout and peer down. A beautiful vista
stretches out far below, green fields reaching to a distant sea. Clouds
obscure the view directly below. A small dot is barely visable directly
below you. The dot vanishes into a cloud.
(Oh, and yes, there were two rooms involved here. And yes, that's about
what it really would look like. The bag was not a room, and so took
advantage of its containing room's thread... until it fell. Then it
latched onto the thread of that huge expanse of open air.)
:: C'mon. You think LPC is gonna get them one step closer to a job?
:
:Uh, yes.
:
:I would hire a good LPC coder in an instant in the real world, even if
:it were the only language they knew. LPC is as real as any other
:language.
Well, you are biased. Though... I might too, if they passed in all other
respects and I had the time (or a responsible delegate) to train them in
C++ (or Java, or 4DC, or whatever). I would do so with a bit of hesitation,
though.
:By the way... it got me my first job programming.
Well... I guess that's fair. I got my first job programming by accident,
almost, and the job was in Fortran.
:Well, that is a silly comparison basis. The proper measuring stick is
:if a tool performs the job you want in a time frame that provides
:reasonable feedback.
OK... I tend to think big. A lot too big for LPs. If I design a system, a
mud, I want to design it so it can be scaled to handle 1000 players at
the same time at some point in the forseeable future. This means no waste.
:We could of course compare to machine code. The C++ would look bad.
:But the point is that we do not need that speed, and we do not need
:C++'s speed any more.
Er... I rather think we do. But that's a difference in opinion, I suppose.
BTW... I would not call 94% a significant loss to machine code. That's
about where clean C++ stands these days on RISC machines with modern
compilers.
:Well, as has been stated many times before, this is a genuinely hard
:issue. The typical example might be:
:I issue the close door command in room A.
:You issue the exit room command in room B.
The dragon's dinner... I've gone through this before.
:Of course, without any synchronization method, you could walk through
:a closed door. But, naturally, since this is a threaded environment,
:we would grab the first event we receive (for the sake of argument,
:the close door event) and start processing it... The question is on
:what scale do we synchronize processing? The entire mud? Well, then
:we might as well not be multi-threaded. Our two rooms? What about
:other adjacent rooms? What does it mean to synchronize a room?
Er. The close door command was executed in a higher scope. The guy from
room B got a "The door slams in your face, knocking you back!" type of
message. Or, alternatively, it didn't come that close, and the guy got
to the other room just in time to get "A door slams behind you. You bump
into MrX." This because the door slamming sets its state before it executes
the message, a standard precaution for this sort of thing.
:: Ever work on a neural net system? Turns out a crippled neural net is
:: an incredibly apt metaphor for dynamic interrelation of objects in a
:: virtual world.
:
:Bah, you could do a workable neural net system in a LPMud. I have
:been toying with putting in a poor man's one. I just do not know if
:it is worth the time.
Ever done a workable neural net, George? I hear people make noise a lot,
but on some things, that's all it is. Neural nets are usually one of them.
George Reese
:
: :Nathan F. Yospe (yo...@hawaii.remove.this.edu) wrote:
:
: I'm going to take this away from LPs... I don't like LPC, or the drivers,
: and will stand by that, to anyone who says that they encompass anything
: you could concievably want out of a mud. I have never been impressed by
: an LP. Period. So, by implication, they are not an ideal to which I would
: strive. Thus, I am writing from scratch. You guys who like LPs can write
: libs, or modify libs, or whatever. I don't really care. I still don't
: like them.
That's fine. The issue is that you are expressing that opinion in
public. So people who disagree with you will challenge those views.
: :It depends on what you are trying to build. Clearly a lot of muds do
: :very well without threading. In fact, in a threaded language, there
: :is not a whole lot you would actually thread. Concurrency in an
: :environment like a mud *is* a hard issue as Reimer said.
:
: But hardly insurmountable. It all comes down to what you want. Recall
: Chris Lawrance's thread basket event system. There are a number of people
: using threads, and other concepts not supported by LP drivers, in ways
: that you would never think of, coming from the context of LPs. The truth
: is, when you lock yourself to one paradigm, you put blinders on with
: respect to all other possible paradigms, and simply end up saying "Why
: would you want to do that?".
I and many other LPMud developers do a hell of a lot more with their
life than code LPMuds. IMHO serious multi-threading on an event level
gets you very little with an LPMud and costs you a lot in terms of
complexity. That does not mean impossible or anything like... clearly
you have done it, I have done it in a single developer environment,
and I am sure many others have done it. But the kind of mud I am
interested in lends itself to easy development by non-programmers, and
this complexity level does not lend itself to that.
[ details of the system omitted ]
: :: C'mon. You think LPC is gonna get them one step closer to a job?
: :
: :Uh, yes.
: :
: :I would hire a good LPC coder in an instant in the real world, even if
: :it were the only language they knew. LPC is as real as any other
: :language.
:
: Well, you are biased.
Biased by what? The fact that I know LPC is a serious language?
: Though... I might too, if they passed in all other
: respects and I had the time (or a responsible delegate) to train them in
: C++ (or Java, or 4DC, or whatever). I would do so with a bit of hesitation,
: though.
Naturally.
: :Well, that is a silly comparison basis. The proper measuring stick is
: :if a tool performs the job you want in a time frame that provides
: :reasonable feedback.
:
: OK... I tend to think big. A lot too big for LPs. If I design a system, a
: mud, I want to design it so it can be scaled to handle 1000 players at
: the same time at some point in the forseeable future. This means no waste.
I have not tried to scale an LPMud to that degree. I do not honestly
know if it can or cannot. How can you say for certain it cannot?
: :We could of course compare to machine code. The C++ would look bad.
: :But the point is that we do not need that speed, and we do not need
: :C++'s speed any more.
:
: Er... I rather think we do. But that's a difference in opinion, I suppose.
: BTW... I would not call 94% a significant loss to machine code. That's
: about where clean C++ stands these days on RISC machines with modern
: compilers.
The point is that you are missing what matters when you are measuring
the speed of a language.
: :: Ever work on a neural net system? Turns out a crippled neural net is
: :: an incredibly apt metaphor for dynamic interrelation of objects in a
: :: virtual world.
: :
: :Bah, you could do a workable neural net system in a LPMud. I have
: :been toying with putting in a poor man's one. I just do not know if
: :it is worth the time.
:
: Ever done a workable neural net, George? I hear people make noise a lot,
: but on some things, that's all it is. Neural nets are usually one of them.
That's certainly fair. I just know I could :)
Travis S Casey
Nathan F. Yospe <yo...@hawaii.remove.this.edu> wrote:
>behr...@student.uni-kl.de (Reimer Behrends) wrote:
>:Nathan F. Yospe (yo...@hawaii.remove.this.edu) wrote:
>:
>_really_ weak typing. Dynamic typing can be strong... usually is. The
>stuff I saw going on in MudOS had no type confirmation, and absolute
>casting. (Well, its a 'feature', right? It made it to release, after all.)
Where were you working with it? Older versions of MudOS had a bug in
type checking, and newer versions have a compile-time option to keep
that bug in place, for those too lazy to fix their mudlibs to work without
the bug. Also, there's an option for stricter type checking.
The newest drivers also have options for implicit vs. explicit type
casting of values returned from calls to other objects.
>:: No "real" programming skill development.
>:
>:Hmm?
>
>C'mon. You think LPC is gonna get them one step closer to a job?
Programming skill development != learning a marketable language.
I've learned a lot from working on the LPmuds I've worked on...
in particular, I've learned how to work on code with a group, how
to modularize with a real, working system, and how to comment my code
so other people can understand it and work with it. All of these
are very useful programming skills, in high demand in the real world.
And all of them are applicable to *any* computer language.
--
|\ _,,,---,,_ Travis S. Casey <ca...@cs.fsu.edu>
ZZzz /,`.-'`' -. ;-;;,_ System Administrator, FSU CS department
|,4- ) )-,_..;\ ( `'-' (904) 644-7339; Room 011 Love
'---''(_/--' `-'\_) No one agrees with me. Not even me.
rec.games.design FAQ: http://www.cs.fsu.edu/~casey/design.html
Martin Keegan
Greg Munt wrote:
>
> On 2 Apr 1997, Brian James Green wrote:
>
> > an interest in hobby MUDs. As I have said before, you cannot beat a
> > hobby MUDs pricing strategy: free!
>
> likely that Microdollar would try to sell its products off the back of an
> apparently 'free' mud, rather than apply usage charges - in much the same
> way as they had to make IE free, because Netscape was free, and the
> Internet culture demands it, pretty much.
This is what I think MS would do. However, when I posted my warning
about this in the first post in the SMCH thread, I was more concerned
about the possibility of something Negroponte was talking about in
some article I read. He described a company which had built an
adventure game system where you paid real money to hire equipment.
Mudding can be addictive, so the possibility of exploitation exists.
If you were a mud addict, and there were some cash reward for getting
to level 40 first, wouldn't YOU pay that extra 10c for a better weapon?
What about 50c, or a dollar or so?
Mk
Tim Hollebeek
In article <5i9f5i$gtu$1...@darla.visi.com>, bo...@visi.com writes:
> Nathan F. Yospe (yo...@hawaii.remove.this.edu) wrote:
> :
> : OK... I tend to think big. A lot too big for LPs. If I design a system, a
> : mud, I want to design it so it can be scaled to handle 1000 players at
> : the same time at some point in the forseeable future. This means no waste.
>
> I have not tried to scale an LPMud to that degree. I do not honestly
> know if it can or cannot. How can you say for certain it cannot?
I was just talking to someone the other day who hit 250 on an LP. In the
real world, keeping enough people satisfied enough that that many people
would want to play your MUD is usually harder than dealing with resource
issues.
Pär Winzell
> : :Well, that is a silly comparison basis. The proper measuring stick is
> : :if a tool performs the job you want in a time frame that provides
> : :reasonable feedback.
> :
> : OK... I tend to think big. A lot too big for LPs. If I design a system, a
> : mud, I want to design it so it can be scaled to handle 1000 players at
> : the same time at some point in the forseeable future. This means no waste.
>
> know if it can or cannot. How can you say for certain it cannot?
I have experience in this, both in artifical (but intricate, not to
mention brutal) tests, and in very large amounts of actual users. When
you start getting into the many hundreds or even thousands, you can no
longer use LPC sloppily -- that O(n) array addition in the inventory
code or user daemon or whatever starts hurting.
However, such points are not difficult to locate. My experience is that
LPC is suited to this kind of thing to a degree that surpasses even my
high expectations. Incidentally, is there an actual point to this
debate?
Zell
john
George Reese <bo...@visi.com> wrote in
article <5i9f5i$gtu$1...@darla.visi.com> :
[chopchop]
: But the kind of mud I am interested in lends itself
: to easy development by non-programmers, and
: this complexity level does not lend itself to that.
Are you comfortable with the logical result of this?
What is your intended goal for such an end-product?
I very much like the idea of Foundation - giving a solid
base to work from. Make people meet you halfway by
having to code everything else themselves - special
efuns, parent objects, combat/class/level/race/xp systems,
etc. - they are the parts which will set the mud apart from
the 'stock' that everyone else has. However, to make
available a mud that's quickly developed with minimal
effort lends itself to becoming a stock mud, whether or
not the same start area is used.
// John Greenawalt - -
// as...@pixi.com / \
// "Nothing worse than a finicky agapanthus!" -msm
David Rudy
In article 5...@cnn.Princeton.EDU, t...@franck.Princeton.EDU.composers (Tim Hollebeek) writes:
>I was just talking to someone the other day who hit 250 on an LP. In the
>real world, keeping enough people satisfied enough that that many people
>would want to play your MUD is usually harder than dealing with resource
>issues.
You don't even have to keep them happy if you can manage to keep bringing
in a lot of people on a regular basis. Hence the muds linked to AOL are
reported to have hundredS of users - because new people click on it to
try it. (I have never personally been on one, these are second-hand
reports).
I believe that it is more a matter of informing 250 people about your
mud, not just trying to keep them there. The usual "word of mouth"
approach isn't as successful as many of us would like it to be...
Advertising!
David Rudy
dar...@aule.eng.sun.com
Ron Cole
David Rudy wrote:
> You don't even have to keep them happy if you can manage to keep bringing
> in a lot of people on a regular basis. Hence the muds linked to AOL are
> reported to have hundredS of users - because new people click on it to
> try it. (I have never personally been on one, these are second-hand
> reports).
<<cough>> Ah.. no. First of all, Gemstone (now an AOL game)
consistantly has 2000+ users on during "prime" play hours. Who are
these players? They are mostly junior high/high school kids that do
this sort of thing instead of watching T.V.. Are they all kids? No..
but a good number of the old players (numbering in the hundreds)
left when all of the kids came. Granted, a number come and go.. but
Gemstone has a strong player base which remains consistant. Is this
true for other AOL games? I dunno.. but I would guess it is for some,
while your theory is correct for others.
Now, the other thing that keeps people on AOL games is that,
consistantly, they are more advanced/stable/more imaginative than
the competition (other networks, MUDs, etc..). Is this true for all
of the competition? No. I've seen two MUDs that were more advanced
than Gemstone, a number that were more advanced than DGate.. but then
it comes down to ease of access and that big word you said, advertising.
-= Rindar
J C Lawrence
: :
: : :Nathan F. Yospe (yo...@hawaii.remove.this.edu) wrote:
: : :: No multiple threads. No distributed processing.
: : Sorry, but not having the option is a huge handicap, considering that my
: : entire event locality model is based on threads. The point was that the
: : original author claimed that anyone who didn't use LPC was reinventing the
: : wheel. I disagree, and the lack of threads is a heavy motivator. Besides,
: : I've never had to worry about concurancy. Concurancy problems usually stem
: : from a non object oriented thread approach, or a bad model.
: It depends on what you are trying to build. Clearly a lot of muds do
: very well without threading. In fact, in a threaded language, there
: is not a whole lot you would actually thread. Concurrency in an
: environment like a mud *is* a hard issue as Reimer said.
The statement, "In fact, in a threaded language, there is not a whole
lot you would actually thread," is very arguable. Bolting a threaded
language implemnation on top of a classic monolithic server (why?)
does offer few reasons to thread actions. Start with an implicitly
threaded event model (simultaneous execution of events in private
threads), and it becomes a lot more attractive. Part of the
attractiveness is that it moves threads from being a very lightweight
view of process fractioning to almost being full independant processes
in their own right.
Its really approaching it via the back door. Instead of forking off
threads to handle sub- or related tasks with all its synchronisation
and management problems, it becomes "log an event to do whatever, let
the system figure out what to do with it, and just sync up down here."
This is actually what I do. Everything is event based. Events
process in their own threads. Events are handled as compleating
transactions visa vi the DB. and successful events can log (multiple)
new events and define dependancies on previously logged events
successes.
Its threads, not as process fractions, but as lightweight processes.
A very attractive proposition for MUDs.
: : Event modeling (as opposed to event based programming) allow events to
: : run concurrently as processes. The lack of thread support negates this
: : possibility.
: Well, as has been stated many times before, this is a genuinely hard
: issue. The typical example might be:
: I issue the close door command in room A.
: You issue the exit room command in room B.
Also called the "Dragon's Dinner problem". (The classic example deals
with a dragon and a fleeing player competing for the door)
: Of course, without any synchronization method, you could walk through
: a closed door. But, naturally, since this is a threaded environment,
: we would grab the first event we receive (for the sake of argument,
: the close door event) and start processing it... The question is on
: what scale do we synchronize processing? The entire mud? Well, then
: we might as well not be multi-threaded. Our two rooms? What about
: other adjacent rooms? What does it mean to synchronize a room?
Not a problem. Let the two events compete as transactions with the
results of the transaction only being commited if the event succeeds
(ie local copy data till then). Then have all other events which
attempted to reference or modify objects that the successfuly event
touched be killed and rescheduled (local copy data discarded).
cf Demo's (long silent?) project.
It works.
--
J C Lawrence Internet: cl...@null.net
----------(*) Internet: co...@null.net
..Honourary Member of Clan McFud -- Teamer's Avenging Monolith....
Felix A. Croes
J C Lawrence (co...@null.net) wrote:
>[...]
>Not a problem. Let the two events compete as transactions with the
>results of the transaction only being commited if the event succeeds
>(ie local copy data till then). Then have all other events which
>attempted to reference or modify objects that the successfuly event
>touched be killed and rescheduled (local copy data discarded).
>
>cf Demo's (long silent?) project.
I think you mean Demos'.
>It works.
How well does it work? On a full MUD, I can easily see every successful
event aborting three others. A broadcast on a chat channel might be
aborting -- or be aborted by -- an amount of events equal to the number
of players that receives the message. Is there a particular scheme to
avoid collisions, or is it left to the programmer to ensure that every
event references as few objects as possible?
By the way, is your server ftpable from somewhere?
Dworkin
john
: > > So, I think even if Microsoft, et al get into MUDs, there will still
be
: > > an interest in hobby MUDs. As I have said before, you cannot beat a
: > > hobby MUDs pricing strategy: free!
: > Given the 'free' culture of today's mudding community, I think it more
: > likely that Microdollar would try to sell its products off the back of
an
: > apparently 'free' mud, rather than apply usage charges - in much the
same
: > way as they had to make IE free, because Netscape was free, and the
: > Internet culture demands it, pretty much.
all Microsoft would need MUDs for is to keep their current users addicted,
paying their monthly fees. the turnover ratios for places like AOL,
Prodigy,
and CompuServe are insane as people get their trial accounts, fall in love
with the graphics, the free time runs out, and the customers get bored
paying the extra money once they think they've seen everything they can
be interested in on the Net. as long as the 'Microdollar' ensured the muds
were staffed with quality maintenance folk, the MUDs indeed should need
no usage charges at all.
-john (as...@pixi.com)
mor...@niuhep.physics.niu.edu
co...@null.net ("J C Lawrence") writes:
>George Reese (bo...@visi.com) wrote:
>: It depends on what you are trying to build. Clearly a lot of muds do
>: very well without threading.
agreed
>Its really approaching it via the back door. Instead of forking off
>threads to handle sub- or related tasks with all its synchronisation
>and management problems, it becomes "log an event to do whatever, let
>the system figure out what to do with it, and just sync up down here."
>This is actually what I do. Everything is event based. Events
>process in their own threads. Events are handled as compleating
>transactions visa vi the DB. and successful events can log (multiple)
>new events and define dependancies on previously logged events
>successes.
>: : Event modeling (as opposed to event based programming) allow events to
>: : run concurrently as processes.
>: Well, as has been stated many times before, this is a genuinely hard
>: issue. The typical example might be:
>: I issue the close door command in room A.
>: You issue the exit room command in room B.
This particular example doesn't seem to be that much of a problem.
You have a database that stores the state of the door. When you
try to exit through the door it checks the state of the door.
My problem is combat. Especially multi-person combat. If three
people are attacking a character the first attacker should
get the most attention in defense. Other attackers are defended against
less efficiently. In a tick system I determine the order of attack
then decriment the skill for defense against each successive attack.
I can imagine ways around the problem, but they are not very satisifying
to me.
Even plain one on one combat doesn't seem intuitively obvious to me.
<sigh>
>Also called the "Dragon's Dinner problem". (The classic example deals
>with a dragon and a fleeing player competing for the door)
>: other adjacent rooms? What does it mean to synchronize a room?
>Not a problem. Let the two events compete as transactions with the
>results of the transaction only being commited if the event succeeds
>(ie local copy data till then). Then have all other events which
>attempted to reference or modify objects that the successfuly event
>touched be killed and rescheduled (local copy data discarded).
<cough> come again? in English this time, please? :) :)
I sort of understood that but wouldn't mind an example.
Robert
specify the e-mail address below, my reply-to: has anti-spam added to it
Mor...@physics.niu.edu
Real Men change diapers
J C Lawrence
Felix A. Croes (dwo...@visi.com) wrote:
: J C Lawrence (co...@null.net) wrote:
: >cf Demo's (long silent?) project.
: I think you mean Demos'.
Yup. He's been silent a long while now, tho a few emails indicate he
still types.
: >It works.
: How well does it work?
Pretty well here in tests. I'm not going to claim any huge numbers
as my tests to date have been entirely contrived. OTOH a couple
months ago I had a few thousand mobiles wandering a 100 room land
without any troubles.
: On a full MUD, I can easily see every successful
: event aborting three others. A broadcast on a chat channel might be
: aborting -- or be aborted by -- an amount of events equal to the number
: of players that receives the message. Is there a particular scheme to
: avoid collisions, or is it left to the programmer to ensure that every
: event references as few objects as possible?
Such global events have their problems. You're right -- they are
prone to getting into endless rescheduling. My attack on that part is
two-fold:
1) Dumb ass tweaks to the scheduling algorithm and the assigment and
semantics of priority levels to try and ensure that the damn thing
compleats *somehow*.
2) Heavily encourage events to be as trivial and small as possible.
In the case of a global channel, instead of having one event
broadcast to the entire game, I'd have one event per recipient. It
chews out the event processing, but the load is pretty short lived.
: By the way, is your server ftpable from somewhere?
Nope.
Felix A. Croes
>: On a full MUD, I can easily see every successful
>: event aborting three others. A broadcast on a chat channel might be
>: aborting -- or be aborted by -- an amount of events equal to the number
>: of players that receives the message. Is there a particular scheme to
>: avoid collisions, or is it left to the programmer to ensure that every
>: event references as few objects as possible?
>Such global events have their problems. You're right -- they are
>prone to getting into endless rescheduling. My attack on that part is
>two-fold:
> 1) Dumb ass tweaks to the scheduling algorithm and the assigment and
> semantics of priority levels to try and ensure that the damn thing
> compleats *somehow*.
Presumably you want to avoid this as much as possible, since it amounts to
going into single-threaded mode for the duration of a high-priority event.
> 2) Heavily encourage events to be as trivial and small as possible.
> In the case of a global channel, instead of having one event
> broadcast to the entire game, I'd have one event per recipient. It
> chews out the event processing, but the load is pretty short lived.
Then I suppose that starting an event for a recipient does not count as
referencing the recipient? Otherwise, little would be gained.
Assuming this to be the case, doesn't it imply that two broadcasts on a
chat channel might not be received in the same order by all recipients?
It might seem a little odd if people hear DragonsDinner's shout "Ha ha,
you won't get me" <after> the informational message "DragonsDinner is
fried by the Red Dragon."
Dworkin
Chris Lawrence (Contra)
Note: co...@null.net is me too.
mor...@niuhep.physics.niu.edu wrote:
: co...@null.net ("J C Lawrence") writes:
: >George Reese (bo...@visi.com) wrote:
: >: : Event modeling (as opposed to event based programming) allow events to
: >: : run concurrently as processes.
: >: Well, as has been stated many times before, this is a genuinely hard
: >: issue. The typical example might be:
: >: I issue the close door command in room A.
: >: You issue the exit room command in room B.
: This particular example doesn't seem to be that much of a problem.
: You have a database that stores the state of the door. When you
: try to exit through the door it checks the state of the door.
Perhaps we should restate the canonical example:
--<cut>--
Consider the following problem (dubbed "Dragon's Dinner"). Assume,
in an asynchronous distributed system, that there are two room
objects (r1, r2) and a door object (d) that connects them. R1
contains a hungry dragon (hd) and r2 contains an adventurer (a).
The door is currently open, the adventurer has just fled from r1
and is about to close the door. The dragon, on the other hand,
wants to go after the adventurer. Code for the dragon is something
like:
if (d->is_open())
hd->move_to(r2);
And the code for closing the door is something like:
d->close();
Now what if the following happens: The thread that executes the
dragon's action has checked that the door is indeed open, while the
other thread which is concurrently executing on a different processor,
closes the door. This succeeds and the adventurer sees the door c
losing. However, when control returns to the dragon's thread, it still
believes that the door is open and steps through it, much to the
surprise of the adventurer who sees the dragon walking through a
closed door, before being devoured by the dragon.
--<cut>--
Its a classic race condition, and without some generalised solution
to such race conditions, its not a trivial problem.
: My problem is combat. Especially multi-person combat. If three
: people are attacking a character the first attacker should
: get the most attention in defense. Other attackers are defended against
: less efficiently. In a tick system I determine the order of attack
: then decriment the skill for defense against each successive attack.
:
: I can imagine ways around the problem, but they are not very satisifying
: to me.
:
: Even plain one on one combat doesn't seem intuitively obvious to me.
I'm not going to be able to comment as well on combat as I might, as
I'm in the middle of redesigning my entire approach to combat. Physical
attacks with weapons are being hugely devalued, and indirect attacks
via magic, mana control, mental abilities, body stealing etc are being
emphasised far more strongly than weapons.
However, I can detail the approach I was going to use for an
interactive event driven combat:
Combat is round based.
Upon initiation of a fight a local combat object is created.
It is the responsibility of the combat object to mediate the
fight, determine what happens, enforce pacing (the rounds), etc.
At the start of each round the combat packages (ie the
semi-intelligent programming for that character for fighting)
submits a combat script to the combat object.
The combat script is a list of instructions detailing what blows,
defenses, fients, reactions, and sequences to attempt during that
round.
The user has the opportunity before the round terminates to edit
the submitted script and submit the changes to the combat object.
At the end of the round the combat object resolves the various
combatant's combat scripts against each other, determines what
actions will actually take place, and then communicates that back
to the participant objects.
The various blows, defenses etc are then struck, any damage or
whatever is waged, and the whole process starts again.
Taking this model, and given the fact that the combat object
maintains the state model for the combat as it proceeds, the rest of
your problem falls out.
Note: The problem with the above model for me now is that many
otherwise innocuous actions, such as giving an object to another
player, in the context of a fight, can easily be a very very nasty
attack, or a great help. The problem is that the definition of which
it is is not only context based, but dependant on the PoV of the
player's concerned. As such I'm looking at abandoning the entire
concept of combat being some "special state" that is in some manner
different or unique or limiting as compared to more typical states.
: >Also called the "Dragon's Dinner problem". (The classic example deals
: >with a dragon and a fleeing player competing for the door)
cf above.
: >: other adjacent rooms? What does it mean to synchronize a room?
: >Not a problem. Let the two events compete as transactions with the
: >results of the transaction only being commited if the event succeeds
: >(ie local copy data till then). Then have all other events which
: >attempted to reference or modify objects that the successfuly event
: >touched be killed and rescheduled (local copy data discarded).
: <cough> come again? in English this time, please? :) :)
: I sort of understood that but wouldn't mind an example.
I think I posted an example here fairly recently. Owel. Here's a
diagram:
Events request objects from the DB.
If the object is not in the cache, the DB loads the object.
The DB replies to the event with a read-only shared reference to the
object.
The event is added to the "interested parties" list for the object.
If the event attempts to modify the object, a new local,
event-specific copy of the object is made, and the changes are made
to that. A copy of the original reference however is still kept.
The event (loosely) attempts to keep track of what members of the
object it referenced.
Upon the event terminating it compares its copy of the original object
(the local reference) with the object that's actually in the DB (may
have been changed by events commiting during the current event's
execution). Some intelligence is attempted here to only compare those
values etc which were referenced by the event.
Should the original copy and the current-in-DB copy compare OK, then
the event commits and all its changes in its written-to copies are
commited atomically. This is the Compare&Commit, or C&C.
If the C&C fail, the event is thrown away, all the copies are
released, and the event is rescheduled.
There is also some background intelligence here where the DB watches
the objects that are affected by event's C&C'ing, and will signal the
other events that are members of those object's interested party list
that they may be invalidated by the other event's C&C and so should
kill themselves and reschedule.
--
J C Lawrence Internet: co...@ibm.net
---------------(*) Internet: claw...@cup.hp.com
...Honorary Member Clan McFUD -- Teamer's Avenging Monolith...
Chris Lawrence (Contra)
Felix A. Croes (fe...@xs1.simplex.nl) wrote:
: J C Lawrence (co...@null.net) wrote:
: >Such global events have their problems. You're right -- they are
: >prone to getting into endless rescheduling. My attack on that part is
: >two-fold:
: > 1) Dumb ass tweaks to the scheduling algorithm and the assigment and
: > semantics of priority levels to try and ensure that the damn thing
: > compleats *somehow*.
: Presumably you want to avoid this as much as possible, since it amounts to
: going into single-threaded mode for the duration of a high-priority event.
Yup, there are several limits which prevent such occurring:
-- The event must be flagged as MUST-COMPLEAT
-- The event's owner or the event's source must have the authority
to set that flag.
-- It has to progress thru a standard sequence of gradated priority
levels and associated semantics (there are roughtly 20 levels as
I recall).
-- The physical length (execution time) of the event must fall
within tighter-than-normal limits.
If it gets thru all that, then I make a single attempt to execute the
event in single-threaded mode, with a sharply cut max-execution-time
limit. If none of that works, then I can the event and report the
exception.
: > 2) Heavily encourage events to be as trivial and small as possible.
: > In the case of a global channel, instead of having one event
: > broadcast to the entire game, I'd have one event per recipient. It
: > chews out the event processing, but the load is pretty short lived.
: Then I suppose that starting an event for a recipient does not count as
: referencing the recipient? Otherwise, little would be gained.
Correct. The contents of the recipient's object are never referenced,
only the ObjectID for the recipient.
: Assuming this to be the case, doesn't it imply that two broadcasts on a
: chat channel might not be received in the same order by all recipients?
Yup. Its essentially analagous to a mailing list with a message and its
replies arriving out of sequence.
: It might seem a little odd if people hear DragonsDinner's shout "Ha ha,
: you won't get me" <after> the informational message "DragonsDinner is
: fried by the Red Dragon."
True. For me this isn't a problem, but there are other cases where
the lack of guaranateed sequentiality is problemic. For those cases I
allow events to be declared as dependant on the successful compleation
of named prior events (there are lotsa limits here).
While this sort of event sequence dependancy could be used for a chat
channel, its a very heavy solution for a very lightweight problem.
Simpler would be to have all those who wish to listen to XXX channel
carry a local XXX channel object. IO messages on the channel can then
be assigned sequence numbers by the central XXX channel object. The
messages are then broadcast to the children objects carried by the
players. The child objects spool the IOs and replay them to their
carriers in sequence number order (no gaps).
Problem solved. A side benefit is that each of the child objects can
carry a history of all traffic on the channel for logging, repaly, etc.
<<Actually would be faster and lighter to leave the IOs on the master
object, and only broadcast a MESSAGE-AVAILABLE message to the children,
but the above would do for here and now>>
George Reese
mor...@niuhep.physics.niu.edu wrote:
: co...@null.net ("J C Lawrence") writes:
: >George Reese (bo...@visi.com) wrote:
:
: >: very well without threading.
:
: agreed
:
: >Its really approaching it via the back door. Instead of forking off
: >threads to handle sub- or related tasks with all its synchronisation
: >and management problems, it becomes "log an event to do whatever, let
: >the system figure out what to do with it, and just sync up down here."
:
: >This is actually what I do. Everything is event based. Events
: >process in their own threads. Events are handled as compleating
: >transactions visa vi the DB. and successful events can log (multiple)
: >new events and define dependancies on previously logged events
: >successes.
:
: >: : run concurrently as processes.
:
: >: Well, as has been stated many times before, this is a genuinely hard
: >: issue. The typical example might be:
:
: >: I issue the close door command in room A.
: >: You issue the exit room command in room B.
: You have a database that stores the state of the door. When you
: try to exit through the door it checks the state of the door.
Yes, that is the way it traditionally happens. the problem is that
you can perform the check, find the door open, have another thread
become the current running thread, that thread changes the door's
state, the initial thread becomes current and proceeds through the
door.
: My problem is combat. Especially multi-person combat. If three
: people are attacking a character the first attacker should
: get the most attention in defense. Other attackers are defended against
: less efficiently. In a tick system I determine the order of attack
: then decriment the skill for defense against each successive attack.
This is not a threading issue.
rlo...@franck.princeton.edu.composers
In article <5j8jvg$8tm$1...@darla.visi.com>, bo...@visi.com writes:
> mor...@niuhep.physics.niu.edu wrote:
> :
> : This particular example doesn't seem to be that much of a problem.
> : You have a database that stores the state of the door. When you
> : try to exit through the door it checks the state of the door.
>
> Yes, that is the way it traditionally happens. the problem is that
> you can perform the check, find the door open, have another thread
> become the current running thread, that thread changes the door's
> state, the initial thread becomes current and proceeds through the
> door.
Wait a minute. I'm just passing through this thread, but morphis's
statement that "[this] doesn't seem to be much of a problem" implies
he doesn't even know what a race condition *is*. Isn't debating the
merits of single vs. multi threadedness with such a person a waste of
time?
[Ok, ok, I know George like wasting his time, but this is ridiculous ...]
George Reese
Abigail wrote:
>
> On 18 Apr 1997 20:01:52 GMT, George Reese wrote in
> rec.games.mud.misc,rec.games.mud.admin <URL: news:5j8jvg$8tm$1...@darla.visi.com>:
> ++
> ++ Yes, that is the way it traditionally happens. the problem is that
> ++ you can perform the check, find the door open, have another thread
> ++ become the current running thread, that thread changes the door's
> ++ state, the initial thread becomes current and proceeds through the
> ++ door.
>
> Can one say "semaphores"?
>
> It's an old problem solved many moons ago.
>
> Abigail
Are you really fucking dense Abigail?
I did not say it was unsolvable. I said that it is difficult to solve
in a user friendly manner.
--
George Reese (bo...@imaginary.com) http://www.imaginary.com/~borg
ik ben de borg
Abigail
Michael Sellers
George Reese wrote:
> > Can one say "semaphores"?
> >
> > It's an old problem solved many moons ago.
> >
> > Abigail
>
>
> I did not say it was unsolvable. I said that it is difficult to solve
> in a user friendly manner.
Ugh, George. Put a sock in it. You give new meaning to public
boorishness.
No amount of technical knowledge (self-proclaimed or otherwise)
compensates for such continued abrasiveness.
(Now where did I put that kill file...?)
--
Mike Sellers Internet Game Designer msel...@ricochet.net
"If you're not confused, you don't know what's going on."
-- could have been said about the online entertainment industry
Abigail
On Sat, 19 Apr 1997 04:32:00 -0500, George Reese wrote in
rec.games.mud.misc,rec.games.mud.admin <URL: news:335891...@imaginary.com>:
++ Abigail wrote:
++ >
++ > On 18 Apr 1997 20:01:52 GMT, George Reese wrote in
++ > rec.games.mud.misc,rec.games.mud.admin <URL:
++ > news:5j8jvg$8tm$1...@darla.visi.com>:
++ > ++
++ > ++ Yes, that is the way it traditionally happens. the problem is that
++ > ++ become the current running thread, that thread changes the door's
++ > ++ state, the initial thread becomes current and proceeds through the
++ > ++ door.
++ >
++ > Can one say "semaphores"?
++ >
++ > It's an old problem solved many moons ago.
++ >
++ > Abigail
++
++ Are you really fucking dense Abigail?
Well, well, well, did you lose your blankie again?
++ I did not say it was unsolvable. I said that it is difficult to solve
++ in a user friendly manner.
I didn't say you said it was unsolvable.
And I don't think it's difficult to solve. Just go to your local
library, look up 'semaphores' and implement whatever algorithm you find
useful. Or course, it will require a different approach for your
wizards, but that's the price you have to pay for a multi-threaded
server.
Abigail
George Reese
Michael Sellers wrote:
>
> George Reese wrote:
> > > Can one say "semaphores"?
> > >
> > >
> >
> > Are you really fucking dense Abigail?
> >
>
> boorishness.
>
> No amount of technical knowledge (self-proclaimed or otherwise)
> compensates for such continued abrasiveness.
>
> (Now where did I put that kill file...?)
In case you have not noticed, I could not post a 'the sky is blue' post
without Abigail countering with some sort of tangential argument. I am
getting tired of it.
And it looks like you are joining that crowd too.
--
George Reese (bo...@imaginary.com) http://www.imaginary.com/~borg
ik ben de borg
Greg Munt
On Sun, 20 Apr 1997, George Reese wrote:
> Michael Sellers wrote:
> >
> > George Reese wrote:
> > > > Can one say "semaphores"?
> > > >
> > > > It's an old problem solved many moons ago.
> > > >
> > > > Abigail
> > >
> > > Are you really fucking dense Abigail?
> > >
> > > I did not say it was unsolvable. I said that it is difficult to solve
> > > in a user friendly manner.
> >
> > Ugh, George. Put a sock in it. You give new meaning to public
> > boorishness.
> >
> > No amount of technical knowledge (self-proclaimed or otherwise)
> > compensates for such continued abrasiveness.
> >
> > (Now where did I put that kill file...?)
>
> In case you have not noticed, I could not post a 'the sky is blue' post
> without Abigail countering with some sort of tangential argument. I am
> getting tired of it.
You are getting tired with people disagreeing with you? That's not like
you, George.
If everyone agreed with everyone, it would be a very boring world. I
personally found Abigail's "semaphore" reply to be mildly inflammatory.
But George, you are getting a very bad reputation for maintaining
incredibly long flame wars. Quite frankly, we are sick of it all.
In recent times, I have seen a few people attack you, precisely because
of this reputation. You profess great knowledge (particularly in the Java
field), but, unfortunately, use that as a weapon against your opponents
on this group. There are some who would argue that if your knowledge is
as great as it is, you would not need to be as combative as you appear.
But it is not for me to comment on that.
Mike's viewpoint is shared by many. This is a newsgroup devoted to
discussion concerning the administration of muds. However (and
unfortunately), your intelligent and incisive posts are interspersed with
language that does not inspire mature debate. "Are you really fucking
dense" is simply one of the more recent examples.
I found, for example, your post comparing Java vs C, as the
implementation language of a mud, most interesting and thought-provoking.
But you spoil all this by what I can only call your 'arrogant attitude'.
When people complain about you, they are not complaining about anything
you have said, or the thoughts behind them. They are complaining about
the way you present yourself, and the way you present your ideas. In
particular, they are complaining about how you deal with people who
present a different, or varying, point of view from your own.
Your comments on this group do lead me to the conclusion that you think
everyone on it, bar yourself, is a complete moron.
I would be most interested to hear your own comments on this conclusion
that I have made.
------------------------------------------------------------------------------
T H E F R O N T I E R S P R O J E C T
http://www.uni-corn.demon.co.uk telnet://linux2.cms.shu.ac.uk:9999
I'll stay out of animals' way if they'll stay out of mine
"Hey you, get off my plate"
Petri Virkkula
>>>>> "Abigail" == Abigail <abi...@fnx.com> writes:
Abigail> I didn't say you said it was unsolvable.
Abigail> And I don't think it's difficult to solve. Just go to your local
Abigail> library, look up 'semaphores' and implement whatever algorithm you find
Abigail> useful. Or course, it will require a different approach for your
Abigail> wizards, but that's the price you have to pay for a multi-threaded
Abigail> server.
I think it is practically too big job to add mt support to old
mud with large codebase. You always forget something, make
small bugs, etc. There are problems when starting from the
scratch too. It is too easy to block all threads by a
malicious code.
And if the gd automatically handles critical sections there
are even bigger problems with deadlocks. Deadlock prevention
algorithms are not that easy. A person (don't remember who it
was) posted solution to this: record all variable changes,
save all outputs etc. until the whole execution of a command
ends. That might solve the problem, but the solution requires
extra memory, is not trivial to implement etc.
I would make the gd internally multi threaded: multiple
compiler threads, a thread for hname/addr_server, threads for
player input/output handling, but only one thread for
evaluation of LPC code. That would be simplest way (easiest
way to make bugfree code) to support multiple threads.
Petri
George Reese
Greg Munt wrote:
>
> On Sun, 20 Apr 1997, George Reese wrote:
>
> > Michael Sellers wrote:
> > >
> > > George Reese wrote:
> > > > > Can one say "semaphores"?
> > > > >
> > > > > It's an old problem solved many moons ago.
> > > > >
> > > > > Abigail
> > > >
> > > > Are you really fucking dense Abigail?
> > > >
> > > > I did not say it was unsolvable. I said that it is difficult to solve
> > > > in a user friendly manner.
> > >
> > > Ugh, George. Put a sock in it. You give new meaning to public
> > > boorishness.
> > >
> > > No amount of technical knowledge (self-proclaimed or otherwise)
> > > compensates for such continued abrasiveness.
> > >
> > > (Now where did I put that kill file...?)
> >
> > In case you have not noticed, I could not post a 'the sky is blue' post
> > without Abigail countering with some sort of tangential argument. I am
> > getting tired of it.
>
> You are getting tired with people disagreeing with you? That's not like
> you, George.
That's not what I said. Please go back and reread it.
> If everyone agreed with everyone, it would be a very boring world. I
> personally found Abigail's "semaphore" reply to be mildly inflammatory.
> But George, you are getting a very bad reputation for maintaining
> incredibly long flame wars. Quite frankly, we are sick of it all.
Her semaphore reply was in character with way too many she has made over
time.
> In recent times, I have seen a few people attack you, precisely because
> of this reputation. You profess great knowledge (particularly in the Java
> field), but, unfortunately, use that as a weapon against your opponents
> on this group. There are some who would argue that if your knowledge is
> as great as it is, you would not need to be as combative as you appear.
> But it is not for me to comment on that.
I really do not care whether you see that or not. What I do care about
is getting replies like Abigail's which:
* ignore the fact that I was not at all stating what she was arguing
against
* treats me as if I am some idiot who does not know what he is talking
about... I could be wrong on this or any other issue, but I am not an
idiot
> Mike's viewpoint is shared by many. This is a newsgroup devoted to
> discussion concerning the administration of muds. However (and
> unfortunately), your intelligent and incisive posts are interspersed with
> language that does not inspire mature debate. "Are you really fucking
> dense" is simply one of the more recent examples.
I still think that was an appropriate response to what was IMHO an
intentionally provacative post. My mistake was perhaps in not simply
ignoring it. It gets hard to do that, however, when a certain small
group of people make it their life goal to contradict everything I say
in public.
I suppose from now on I will just killfile Abigail.
> I found, for example, your post comparing Java vs C, as the
> implementation language of a mud, most interesting and thought-provoking.
> But you spoil all this by what I can only call your 'arrogant attitude'.
Oh well. I am not in this newsgroup to make friends with mudders.
> When people complain about you, they are not complaining about anything
> you have said, or the thoughts behind them. They are complaining about
> the way you present yourself, and the way you present your ideas. In
> particular, they are complaining about how you deal with people who
> present a different, or varying, point of view from your own.
There are two things here. First, yes, they are complaining about the
way I present myself. Big fucking deal. Like I said, I am not here to
make friends with mudders. I am here because I am interested in mud
technology. My attitude derives from my complete lack of respect for a
large portion of my peers in this community.
No with respect to differing or opposing viewpoints, that is a complete
and total fantasy conjured up by people without any debating skills.
There are plenty of situations where, even in this newsgroup, I have
been swayed to a different opinion by a *well-made* argument.
> Your comments on this group do lead me to the conclusion that you think
> everyone on it, bar yourself, is a complete moron.
Not everyone... but most.
> I would be most interested to hear your own comments on this conclusion
> that I have made.
Like I said, with the exception of your belief that I have a problem
seeing other points of view, I agree with your conclusion 100%.
Nathan F. Yospe
Petri Virkkula <pvir...@iki.fi> wrote:
:Abigail> useful. Or course, it will require a different approach for your
:Abigail> wizards, but that's the price you have to pay for a multi-threaded
:Abigail> server.
: I think it is practically too big job to add mt support to old
: mud with large codebase. You always forget something, make
: small bugs, etc. There are problems when starting from the
: scratch too. It is too easy to block all threads by a
: malicious code.
This, I find believable. Trying to add threads to a design that
was not centered around them in the first place is futile, not
only because of the difficulty, but because it will undoubtably
save little to nothing in the way of resources without a complete
gutting. This is a contributing (but hardly the most significant)
factor in my decision to start from scratch.
: And if the gd automatically handles critical sections there
: are even bigger problems with deadlocks. Deadlock prevention
: algorithms are not that easy. A person (don't remember who it
: was) posted solution to this: record all variable changes,
: save all outputs etc. until the whole execution of a command
: ends. That might solve the problem, but the solution requires
: extra memory, is not trivial to implement etc.
Actually, with good heirarchal design, deadlock prevention is almost
laughably easy. I'll refer to my thread handling scheme again:
Network Process Shell Handling Process Primary Game Process
(Net Thread Pool) (Shell Thread Pool) G A R
| | | | | | | | | | | | | | | L R OOM POOL
Net Connections Shell Accounts O E
B A POOL
A
L POOL
The Primary game is the one in question here. Threads run the Event
processor, which handle Events as they ripen in whatever scope the
Event is scheduled as. A global Event freezes the process while it
executes, an area Event freezes all local Room Threads, and room
scoped Events never interface with each other except by passed values.
A passed value can be handled at the convenience of the recipient, or
even refused. This means that nothing ever happens outside of the
priority heirarchy of the system. Incidentally... when I refer to
a "Thread" I am talking about a Thread class object, which is a
container/handler for an actual thread. The threads are checked out of
the thread pool as needed by the Threads.
: I would make the gd internally multi threaded: multiple
: compiler threads, a thread for hname/addr_server, threads for
: player input/output handling, but only one thread for
: evaluation of LPC code. That would be simplest way (easiest
: way to make bugfree code) to support multiple threads.:
Often, multiple processes are better here... provided you have an OS
that can handle it. (Growl aimed at MacOS and Win32, and the occasional
hicough that makes a vital process forget to swap onto the processor.)
What you describe is not in any way to "support multiple threads". It
is use of multiple threads, but not support. The perspective, not
surprisingly, of an LPC mud designer is molded by the way LPs drivers
are constructed. It is not as universal and versitile as you might
think. Not that I intend to do it one better on its own ground, mind
you... I've never understood having core level features written in an
internal language. (parsers, for example) I'll settle for a powerful
internal language, in the context of the mud only, and a powerful C++
library that can be swapped for any OS at the core.
--
Nathan F. Yospe | There is nothing wrong with being a sociopath. Its
yo...@hawaii.edu | getting caught thats a problem. Be a mad scientist
UH Manoa Physics | Write poetry. Be an artist. Plot world domination.
Biomedical Phys. | Panthers make great pets. Muhahahahahahahahahaha!!
Michael Sellers
George Reese wrote:
> Michael Sellers wrote:
> > Ugh, George. Put a sock in it. You give new meaning to public
> > boorishness.
> >
> > No amount of technical knowledge (self-proclaimed or otherwise)
> > compensates for such continued abrasiveness.
> >
> > (Now where did I put that kill file...?)
>
> In case you have not noticed, I could not post a 'the sky is blue' post
> without Abigail countering with some sort of tangential argument. I am
> getting tired of it.
>
I don't think I'm joining any particular crowd... nor have I seen you
post anything like an uncontroversial post in either tone or content or
both. Try not being abrasive in your posts for awhile and see what
happens. You might be surprised.
And yeah, the Dragon's Dinner problem is solvable, with some overhead.
Abigail
On Sun, 20 Apr 1997 09:05:01 -0500, George Reese wrote in
rec.games.mud.admin <URL: news:335A228D...@imaginary.com>:
++
++ I suppose from now on I will just killfile Abigail.
++
Is that a promise?
Abigail
Kris Van Hees
George Reese <bo...@imaginary.com> wrote:
<< Lots of quoting which is highly irrelevant removed >>
: I still think that was an appropriate response to what was IMHO an
: intentionally provacative post. My mistake was perhaps in not simply
: ignoring it. It gets hard to do that, however, when a certain small
: group of people make it their life goal to contradict everything I say
: in public.
This sounds more like paranoia than anything else. Since it is likely
that I am considered part of that small group of people, I'd like to
meantion that no, I definitely don't even care about contradicting things
you say, George, unless they seem (or are) wrong. Honestly, I would doubt
anyone really spends any reasonable amount of time on trying to contradict
your postings. No one is worth that much attention.
: There are two things here. First, yes, they are complaining about the
: way I present myself. Big fucking deal. Like I said, I am not here to
: make friends with mudders. I am here because I am interested in mud
: technology. My attitude derives from my complete lack of respect for a
: large portion of my peers in this community.
There is this well-known concept of gaining respect by giving respect.
Better not hope for much respect from people, given your complete lack
of respect for the majority of the people in this newsgroup.
: > Your comments on this group do lead me to the conclusion that you think
: > everyone on it, bar yourself, is a complete moron.
: Not everyone... but most.
Read the above about respect, maybe. Contrary to what people may think, I
don't consider you a 'moron' or anything insulting like that. Although, with
reading comments from you as the one above, I am tempted. But still, your
lack of knowledge on some fields other people know more about is not something
I would abuse to call you a 'moron'. I'd rather see you as taking risks with
what you post (apart from the abusive language which, as has been mentioned,
indeed is completely inappropriate in discussions in an open forum).
Aedil
Kris Van Hees
In rec.games.mud.admin Petri Virkkula <pvir...@iki.fi> wrote:
: I think it is practically too big job to add mt support to old
: mud with large codebase. You always forget something, make
: small bugs, etc. There are problems when starting from the
: scratch too. It is too easy to block all threads by a
: malicious code.
Adding multi-threaded support to an existing mud is something I would never
even consider.
Starting a new mud with multi-threaded code execution is actually not that
much of a problem provided you have coders who understand the concepts of
multi-threading and synchronization constructs (or by having some way of
automated multi-threading resolution [see next paragraph]). My main view
on multi-threading in e.g. LPC is more along the line of non-mud use though.
With more generic drivers, languages like LPC come within the reach of a
larger variety of applications.
: And if the gd automatically handles critical sections there
: are even bigger problems with deadlocks. Deadlock prevention
: algorithms are not that easy. A person (don't remember who it
: was) posted solution to this: record all variable changes,
: save all outputs etc. until the whole execution of a command
: ends. That might solve the problem, but the solution requires
: extra memory, is not trivial to implement etc.
Using an optimistic approach using local copies until you can do a global
commit is fairly expensive, especially when you have a high degree of
concurrent accesses. In e.g. database systems where this is a common
technique, the problem isn't that big because the degree of concurrent
accesses is quite low: even with many simultaneous users, the amount of
data accesses done in one transaction is pretty small.
If you look at how muds work, a seemingly basic action such as movement
results in a decent amount of objects being accessed. And since multi
threading is used, multiple users are having commands be executed (and
some threads will be handling timed events, etc...). This increases the
amount of data that must be stored in local copies until a commit to the
actual data can be done. Unfortunately, if one thread changes data behind
the back of another thread, the option is to give an error or to restart
the operation. This means that e.g. movement could take twice or more as
long as it would take in a single-threaded system.
: I would make the gd internally multi threaded: multiple
: compiler threads, a thread for hname/addr_server, threads for
: player input/output handling, but only one thread for
: evaluation of LPC code. That would be simplest way (easiest
: way to make bugfree code) to support multiple threads.
Since e.g. LPC drivers do not genrally compile that much code once they
have been up and running for a few hours, you do not really gain much by
using multiple compiler threads. Same for address resolving (many muds
use an external process for this anyhow, so there is already concurrency
there). As long as the LPC code execution is single threaded, the average
response time the users will get isn't going to be much better. After all,
the LPC code being executed is the majority of the work that goes on.
Aedil
Kevin M. Gilbert
*Alot of bullshit removed for you pansies who whine about spam*
: You are getting tired with people disagreeing with you? That's not like
: you, George.
: If everyone agreed with everyone, it would be a very boring world. I
: personally found Abigail's "semaphore" reply to be mildly inflammatory.
: But George, you are getting a very bad reputation for maintaining
: incredibly long flame wars. Quite frankly, we are sick of it all.
^^^^^^^^^^^^^^^^^^^^^
Who are we?? I happen to enjoy this debating about stuff. What are
you? A socialist? *note I did not use communist, to outdated.*
: In recent times, I have seen a few people attack you, precisely because
: of this reputation. You profess great knowledge (particularly in the Java
I would love to have a reputation like that......Especially on the
newsgroups, but alas, I am not on as much as some of you.
: field), but, unfortunately, use that as a weapon against your opponents
: on this group. There are some who would argue that if your knowledge is
: as great as it is, you would not need to be as combative as you appear.
: But it is not for me to comment on that.
: Mike's viewpoint is shared by many. This is a newsgroup devoted to
: discussion concerning the administration of muds. However (and
: unfortunately), your intelligent and incisive posts are interspersed with
: language that does not inspire mature debate. "Are you really fucking
: dense" is simply one of the more recent examples.
: I found, for example, your post comparing Java vs C, as the
: implementation language of a mud, most interesting and thought-provoking.
: But you spoil all this by what I can only call your 'arrogant attitude'.
: When people complain about you, they are not complaining about anything
: you have said, or the thoughts behind them. They are complaining about
: the way you present yourself, and the way you present your ideas. In
: particular, they are complaining about how you deal with people who
: present a different, or varying, point of view from your own.
:
: Your comments on this group do lead me to the conclusion that you think
: everyone on it, bar yourself, is a complete moron.
: I would be most interested to hear your own comments on this conclusion
: that I have made.
Blah Blah blah,
--Kevin
mor...@niuhep.physics.niu.edu
bo...@visi.com (George Reese) writes:
>mor...@niuhep.physics.niu.edu wrote:
>: co...@null.net ("J C Lawrence") writes:
>: >George Reese (bo...@visi.com) wrote:
>:
>: >: It depends on what you are trying to build. Clearly a lot of muds do
>: >: very well without threading.
>:
>: agreed
>: >: Well, as has been stated many times before, this is a genuinely hard
>: >: issue. The typical example might be:
>: >: I issue the close door command in room A.
>: >: You issue the exit room command in room B.
>: This particular example doesn't seem to be that much of a problem.
>: You have a database that stores the state of the door. When you
>: try to exit through the door it checks the state of the door.
>Yes, that is the way it traditionally happens. the problem is that
>you can perform the check, find the door open, have another thread
>become the current running thread, that thread changes the door's
>state, the initial thread becomes current and proceeds through the
>door.
put a lock on the data bit that is not released until the action is
done. (he say rather blythely... well how hard is that to do?)
Martin Keegan
Kevin M. Gilbert wrote:
> : But George, you are getting a very bad reputation for maintaining
> : incredibly long flame wars. Quite frankly, we are sick of it all.
> Who are we?? I happen to enjoy this debating about stuff. What are
> you? A socialist? *note I did not use communist, to outdated.*
Leave the politics out of it! This is an international medium; the
notion of "socialist" or "liberal" as political swearwords is
largely restricted to the US. In *this* country (UK), far from
conjuring up notions of stifling all discussion, "socialist" suggests
schismatic arguing and interminable debate! :)
(BTW, I too dislike the "Can everyone stop arguing" mentality - it's
too easy a ploy for a guilty party to use to avoid losing an argument)
Mk
--
http://cyburbia.net.au/~martin/
http://cyburbia.net.au/~martin/mudtree.html
Martin Keegan
mor...@niuhep.physics.niu.edu wrote:
> put a lock on the data bit that is not released until the action is
> done. (he say rather blythely... well how hard is that to do?)
One, Two, Three, SEMAPHORE! (A nicer interjection than Abigails,
methinks :) )
Chris Lawrence (Contra)
Abigail (abi...@fnx.com) wrote:
: On 18 Apr 1997 20:01:52 GMT, George Reese wrote in
: rec.games.mud.misc,rec.games.mud.admin <URL: news:5j8jvg$8tm$1...@darla.visi.com>:
: ++ Yes, that is the way it traditionally happens. the problem is that
: ++ you can perform the check, find the door open, have another thread
: ++ become the current running thread, that thread changes the door's
: ++ state, the initial thread becomes current and proceeds through the
: ++ door.
: Can one say "semaphores"?
Yes, I can. And just how do you intend to handle deadlocks? Sempahores
are a very partial, and very expensive solution.
: It's an old problem solved many moons ago.
Codswhallop. Take a busy MUD, say 1,000 active players. Assume an
average of 1 transaction per player every 5 seconds (fairly
reasonable). Now assume that each transaction affects at least two
objects (eg the door affects both itself and the rooms on either side).
Now make each one of those transactions semaphore controlled.
Hurm.
That ranks up to 800 semaphore transactions (set and release) per second
assuming zero contention.
Nahh.
There's a reason that multi-user database systems don't use semaphores for
record locking (which is essentially what we are dealing with if you take
a locking approach).
Chris Lawrence (Contra)
Nathan F. Yospe (yo...@hawaii.remove.this.edu) wrote:
: Actually, with good heirarchal design, deadlock prevention is almost
: laughably easy. I'll refer to my thread handling scheme again:
: Network Process Shell Handling Process Primary Game Process
: (Net Thread Pool) (Shell Thread Pool) G A R
: | | | | | | | | | | | | | | | L R OOM POOL
: Net Connections Shell Accounts O E
: B A POOL
: A
: L POOL
: The Primary game is the one in question here. Threads run the Event
: processor, which handle Events as they ripen in whatever scope the
: Event is scheduled as. A global Event freezes the process while it
: executes, an area Event freezes all local Room Threads, and room
: scoped Events never interface with each other except by passed values.
: A passed value can be handled at the convenience of the recipient, or
: even refused. This means that nothing ever happens outside of the
: priority heirarchy of the system. Incidentally... when I refer to
: a "Thread" I am talking about a Thread class object, which is a
: container/handler for an actual thread. The threads are checked out of
: the thread pool as needed by the Threads.
Err, no. All you have actually done ie rigidly enforced a specific
resource ordering schema to reduce the ordered graph to the trivial
case, and then overlain that with enforced single-threading for your
heirachy. Its not a bad approach, but its definitely a least-case
simplification with some pretty heavy trade offs.
You've also not exactly handled the race condition problem however
(or at least how you've explained it):
What happens when a global event freezes a room or area event (already
exeuting), and they both attempt to reference or modify the same
attribute?
mor...@niuhep.physics.niu.edu
rlo...@franck.Princeton.EDU.composers () writes:
>In article <5j8jvg$8tm$1...@darla.visi.com>, bo...@visi.com writes:
>> mor...@niuhep.physics.niu.edu wrote:
>> : This particular example doesn't seem to be that much of a problem.
>> : You have a database that stores the state of the door. When you
>> : try to exit through the door it checks the state of the door.
>> Yes, that is the way it traditionally happens. the problem is that
>> you can perform the check, find the door open, have another thread
>> become the current running thread, that thread changes the door's
>> state, the initial thread becomes current and proceeds through the
>> door.
>Wait a minute. I'm just passing through this thread, but morphis's
>statement that "[this] doesn't seem to be much of a problem" implies
>he doesn't even know what a race condition *is*. Isn't debating the
>merits of single vs. multi threadedness with such a person a waste of
>time?
I have a wide range of spotty knowledge, one of the reasons I read
this group is to fill in the missing bits about mud programming.
Somebody else was kind enough to explain in some detail his sol'n
to the problem.
Unlike some people I do not claim overwhelming
expertise (and would probably look like a fool if I did) but coming
from a VMS background I have some general knowledge of similar problems
that are solved using locks. However my knowledge isn't deep enough
to see how well that would apply here. I am guessing that the
semaphores mentioned by Abigail are somewhat related, but that is,
as noted, guessing.
Robert
(just hanging around asking questions and trying to learn a few things)
Ron Cole
Gras BJ wrote:
>
[snip]
>
> Oh no. Not /another/ George Reese thread.
>
> Grow up you bunch of.. of.. ..of morons!
>
> =Ben
I would have used stronger language, but my feelings are
the same ;) This newsgroup is almost to the point where I ignore
long threads because a certain few people turn them into flame
wars. I suggest that everyone just ignore most of the barbs tossed
out by certain people and get on with writing decent messages.
Either that or take this discussion to one of the alt.mud groups..
I hear alt.mud.cellars and alt.mud.flame need messages :/
-= Rindar
mor...@niuhep.physics.niu.edu
bo...@visi.com (George Reese) writes:
>mor...@niuhep.physics.niu.edu wrote:
>: co...@null.net ("J C Lawrence") writes:
>: >This is actually what I do. Everything is event based. Events
>: >process in their own threads. Events are handled as compleating
>: >transactions visa vi the DB. and successful events can log (multiple)
>: >new events and define dependancies on previously logged events
>: >successes.
[big snip]
>: My problem is combat. Especially multi-person combat. If three
>: people are attacking a character the first attacker should
>: get the most attention in defense. Other attackers are defended against
>: less efficiently. In a tick system I determine the order of attack
>: then decriment the skill for defense against each successive attack.
>This is not a threading issue.
It is an issue of how to handle multi-person combat in an event based
system rather than a strictly tick based. Which is what J.C. is talking
about and which has come up elsewhere recently. It is related to threads
but mostly I think it is probable a problem of approaching the problem
with a mind that is used to rounds.
mor...@niuhep.physics.niu.edu
re: how to handle separate threads contending over objects:
Alternatively one could make the door shutting code wait .1 second after
closing the door then check to see if anybody slipped through the door
in the last .3 seconds in which case it writes:
"You shut the door just as the Dragon slips through."
For the humor impaired:
Yes, I know it isn't easily generalizable, and has incredible amounts of
overhead. It's a joke, folx! a JOKE!
Petri Virkkula
>>>>> "Kris" == Kris Van Hees <ae...@melgor.ny.fnx.com> writes:
Kris> Starting a new mud with multi-threaded code execution is actually not that
Kris> much of a problem provided you have coders who understand the concepts of
Kris> multi-threading and synchronization constructs (or by having some way of
This exactly my view (I might have not stated it clearly
enough). However, I would not leave the synchronization to
hands of invidual wizards. Partly because I am not sure if
they can do it correctly, partly because there is always some
wizards to whom I would not give such power to block execution
of other threads.
Kris> the back of another thread, the option is to give an error or to restart
Kris> the operation. This means that e.g. movement could take twice or more as
Kris> long as it would take in a single-threaded system.
That's true.
Kris> Since e.g. LPC drivers do not genrally compile that much code once they
Kris> have been up and running for a few hours, you do not really gain much by
Kris> using multiple compiler threads. Same for address resolving (many muds
There are many races in BatMUD. Sometimes one wants to make a
modification to an object which requires that all races must
be recompiled. In such case it would be uselful to have a
separate thread(s) doing the compilation. Currently BatMUD is
frozen for a short time when such compilation is done.
Another idea is to automatically update certain objects if the
source file newer.
Kris> there). As long as the LPC code execution is single threaded,
Kris> the average response time the users will get isn't going to be
Kris> much better. After all, the LPC code being executed is the
Kris> majority of the work that goes on.
You are right. But let me explain why I want to have multiple
threads. There is lots logging being done in BatMUD as well as
save_object() is called quite often (not often it used to
be). That led in the past to situation where the driver was
unable to utilize all CPU time, because it was waiting a I/O
request to be finished.
The problem was solven by adding caching to log_file(), by
using Solaris tmpfs for save_object() storage and other such
"improvements".
I'd like utilitize all CPU time that is available. I see
following possible targets: player input reading and dividing
to input lines, background compilation.
Sooner or later BatMUD will have dual-processor machine (it
used to have one before the second CPU broke). Currently there
is one 200MHz UltraSPARC CPU. It will be replaced with faster
UltraSPARCs (250MHz or 300MHz) when they are available and are
cheap enough. Another solution is to get second CPU. That's
why I am thinking ways to divide the driver threads (or
processes). If there is multiple CPUs, anything that helps
to utilize them is a good thing.
Petri
George Reese
mor...@niuhep.physics.niu.edu wrote:
>
> bo...@visi.com (George Reese) writes:
> >Yes, that is the way it traditionally happens. the problem is that
> >you can perform the check, find the door open, have another thread
> >become the current running thread, that thread changes the door's
> >state, the initial thread becomes current and proceeds through the
> >door.
>
> done. (he say rather blythely... well how hard is that to do?)
This is Abigail's dumbass semaphore remark. Except that when Abigail
made it, I knew she knew full well that I know what a semaphore is.
Again, whether this is possible or not is not the issue: in
multi-threaded environments, this is actually fairly trivial.
The issue, however, is this... when player 1 shuts the door, when need
to, using your terms, lock down the door state. This way any other
thread coming through that might need or change that door state will
have to wait until the door-close event is complete.
In Java, for example, we would do this:
in the player...
void action(String cmd) {
Command ob = Command.find(cmd);
ob.execute(this, cmd);
}
void go(Room room) {
Door door = getEnvironment().getDoor(room);
if( door != null ) {
synchronized( door ) {
if( door.isClosed() ) {
// don't allow movement
return;
}
move(room);
}
}
else {
move(room);
}
}
in the go command...
void execute(Player player, String cmd) {
String direction = getDirection(cmd);
Room room = player.getEnvironment().getRoom(direction);
player.go(room);
}
Simple enough codewise... make sure you lock down the door (no pun
intended) for the event that relies on the state of the door.
One complicating factor, however, if the move() code...
void move(Room room) {
Room environment = getEnvironment();
synchronized( environment ) {
synchronized( room ) {
setEnvironment(room);
environment.removeItem(this);
room.addItem(this);
}
}
}
You have a potential race condition here. Specifically, if another
event attempts to lock the environment while the thread here is locking
the door, then that thread attempts to lock the door, you end up with
the other thread waiting for you to release the door lock and your
thread waiting for it to release the environment lock. Mud frozen.
Yes, you can avoid this by providing a local context object on which to
synchronize. But the problem I wish to illustrate first is that you
have just given an area creator a way to lock up your mud.
The next issue is how complex it is to deal with this issue for a
creator who barely understands what they are doing when they write an
area. According to the LPC paradigm, there is no way for the driver to
know a thread context. Therefore it is impossible in a language like
LPC to hide concurrency issues from the end developper. IMHO, Java has
done a wonderful job at making threads accessible *to developers*, but
it is not the sort of accessibility that enables a non-programmer to
write multi-threaded systems.
You could of course have a driver which understands events and contexts.
At this point you have built into your driver the nature of your mud.
Among other things, this does seriously limit your interaction across
contexts and the type of muds which might be developed with a server.
Martin Keegan
Ron Cole wrote:
> Either that or take this discussion to one of the alt.mud groups..
> I hear alt.mud.cellars and alt.mud.flame need messages :/
Given that Cellars started out as "Campaign to Annihilate Nemesys MUD
Server", running on tower.york.ac.uk (no less!), I think
alt.mud.cellars and alt.mud.flame should merge :)
BTW, even taking the "Nemesys seeking missiles" and Nemesys effigies
with nearby knives marked "You feel an urge to cut up the dummy with
it" into account, Cellars is quite a fun game to explore.
Nemesys
Kris Van Hees
In rec.games.mud.admin George Reese <bo...@imaginary.com> wrote:
: mor...@niuhep.physics.niu.edu wrote:
: > bo...@visi.com (George Reese) writes:
: > >Yes, that is the way it traditionally happens. the problem is that
: > >you can perform the check, find the door open, have another thread
: > >become the current running thread, that thread changes the door's
: > >state, the initial thread becomes current and proceeds through the
: > >door.
: >
: > put a lock on the data bit that is not released until the action is
: > done. (he say rather blythely... well how hard is that to do?)
: This is Abigail's dumbass semaphore remark. Except that when Abigail
: made it, I knew she knew full well that I know what a semaphore is.
It's always dangerous to assume things. And besides, it might really be
nice if you could maybe take the initiative to lower your weapons. It
would help you earn some respect actually.
: Again, whether this is possible or not is not the issue: in
: multi-threaded environments, this is actually fairly trivial.
: The issue, however, is this... when player 1 shuts the door, when need
: to, using your terms, lock down the door state. This way any other
: thread coming through that might need or change that door state will
: have to wait until the door-close event is complete.
However, something which people do not seem to think about is that when
you model something like this, it's not a matter of: see if door is open,
if so start moving through the door, ... The granularity of such actions
is much more dense resulting in the check on the door being open and the
actual movement being one single activity. After all, when you walk through
a door you don't stop checking whether it is open or closed? As such, the
state of the door is a constant constraint on the movement.
In more low level sense this can be accomplished using an exception
mechanism, which would interrupt the movement thread if the state of the
door changes (and then the appropriate exception handling should take
care of any user interaction). As such, moving through the door doesn't
mean that the door is not allowed to close (locking the door state), but
rather that movement can only succeed if the door remains open for the
entire time of the movement.
Most problems of this kind can be refined towards an exception model
rather than the less correct locking strategy.
<< Java code removed >>
: You have a potential race condition here. Specifically, if another
: event attempts to lock the environment while the thread here is locking
: the door, then that thread attempts to lock the door, you end up with
: the other thread waiting for you to release the door lock and your
: thread waiting for it to release the environment lock. Mud frozen.
: Yes, you can avoid this by providing a local context object on which to
: synchronize. But the problem I wish to illustrate first is that you
: have just given an area creator a way to lock up your mud.
This is a well known problem in the field of concurrency, and in fact
can be avoided in a way where you do not open yourself to anyone causing
a deadlock (not trying to be a pain, but actually if you had just said
that this caused a deadlock problem, you could have saved yourself some
typing). Creating what you call a 'local context object' (guessing a bit
what you mean by this, haven't encountered anything by that name in any
literature on OO and concurrency so far) sounds like a hack. Well known
deadlock prevention schemes would work pretty well here, by using a priority
system. In this context, you can define the environment/inventory relation
as a priority scheme, thereby properly avoiding deadlocks like the one you
described.
: The next issue is how complex it is to deal with this issue for a
: creator who barely understands what they are doing when they write an
: area.
This is one of the nicest aspects of a MUD these days, but by no means
is it a requirement. Actually quite some MUDs seem to be depending on
a decent core of quite good programmers. It's hard to predict how this
will evolve in the future, but so far it seems to continue along that
line. Especially as more and more advanced features get introduced.
According to the LPC paradigm, there is no way for the driver to
: know a thread context. Therefore it is impossible in a language like
: LPC to hide concurrency issues from the end developper. IMHO, Java has
: done a wonderful job at making threads accessible *to developers*, but
: it is not the sort of accessibility that enables a non-programmer to
: write multi-threaded systems.
Two issues here: First of all, there is not much of a LPC paradigm. There
is hardly any language standard, and even less a programming methodology.
So saying that there is no way for a driver to know a thread context isn't
very useful. I can happily find out alot of the thread context e.g. by
investigating the calling stack.
Whether one can hide concurrency from the end developer is still to be
seen, and seems to be the major issue in this thread (except for the mud
slinging and name calling). I happen to be one of the people who believe
that *up to a reasonable point* concurrency issues can be hidden from the
end developer, and furthermore that most if not all can be handled in a
fairly simplified way.
Second, using Java as a comparison is pushing things pretty far. Java's
concurrency mechanism is like you say definitely not designed to be used
by an unskilled programmer. Anyhow, Java and LPC are incomparable in my
opinion (apart from the fact that Java implements concepts which already
existed in LPC years ago).
: You could of course have a driver which understands events and contexts.
: At this point you have built into your driver the nature of your mud.
: Among other things, this does seriously limit your interaction across
: contexts and the type of muds which might be developed with a server.
I think you are disregarding the principle of a mid-layer between the mudlib
and the driver. E.g. currently this concept is used in order to let older
MUDs run on DGD (already done for 3.1.2-alike MUDS with IgorMUD, and I am
currently converting a MudOS based MUD to DGD). But nothing prevents one
from writing a layer on top of a multi-threaded driver which hides part of
the implementation details and offers a system which understands the context
of code which is executing.
Nothing prevents the driver from still being completely generic.
Aedil
Ron Cole
<<Blink>> You mean THAT is what cellars is? You know how long I've
wondered what that newsgroup was really for? Wow, learn something
new every day. And yes, maybe they should combine.. the combined
newsgroup would probably get about 3 messages a month, 1 if you
didn't count SPAM.
-= Rindar
Nathan F. Yospe
claw...@cup.hp.com (Chris Lawrence (Contra)) wrote:
:Nathan F. Yospe (yo...@hawaii.remove.this.edu) wrote:
:: The Primary game is the one in question here. Threads run the Event
:: processor, which handle Events as they ripen in whatever scope the
:: Event is scheduled as. A global Event freezes the process while it
:: executes, an area Event freezes all local Room Threads, and room
:: scoped Events never interface with each other except by passed values.
:: A passed value can be handled at the convenience of the recipient, or
:: even refused. This means that nothing ever happens outside of the
:: priority heirarchy of the system. Incidentally... when I refer to
:: a "Thread" I am talking about a Thread class object, which is a
:: container/handler for an actual thread. The threads are checked out of
:: the thread pool as needed by the Threads.
:Err, no. All you have actually done ie rigidly enforced a specific
:resource ordering schema to reduce the ordered graph to the trivial
:case, and then overlain that with enforced single-threading for your
:heirachy. Its not a bad approach, but its definitely a least-case
:simplification with some pretty heavy trade offs.
It is a process vs memory tradeoff... with memory being a priority, I
choose to adopt a solution that is tasking on the process, ie forces
conflict into a single process, rather than one which uses memory
resources, ie copies and/or semaphores.
:You've also not exactly handled the race condition problem however
:(or at least how you've explained it):
:What happens when a global event freezes a room or area event (already
:exeuting), and they both attempt to reference or modify the same
:attribute?
When an attribute is modified, it makes a mark in a watchdog counter. As
I mentioned before, global events take priority. The local event will
abort and throw an exception. The exception may attempt to reschedule the
local event.
David Rudy
In article 80E9...@imaginary.com, George Reese <bo...@imaginary.com> writes:
>Greg Munt wrote:
>> In recent times, I have seen a few people attack you, precisely because
>> of this reputation. You profess great knowledge (particularly in the Java
>> field), but, unfortunately, use that as a weapon against your opponents
>> on this group. There are some who would argue that if your knowledge is
>> as great as it is, you would not need to be as combative as you appear.
>> But it is not for me to comment on that.
>
>I really do not care whether you see that or not. What I do care about
>is getting replies like Abigail's which:
>* ignore the fact that I was not at all stating what she was arguing
>against
>* treats me as if I am some idiot who does not know what he is talking
> about... I could be wrong on this or any other issue, but I am not an
> idiot
1. George gets upset when treated like an idiot. He vows he is not one.
>> When people complain about you, they are not complaining about anything
>> you have said, or the thoughts behind them. They are complaining about
>> the way you present yourself, and the way you present your ideas. In
>> particular, they are complaining about how you deal with people who
>> present a different, or varying, point of view from your own.
>
>There are two things here. First, yes, they are complaining about the
>way I present myself. Big fucking deal. Like I said, I am not here to
>make friends with mudders. I am here because I am interested in mud
>technology. My attitude derives from my complete lack of respect for a
>large portion of my peers in this community.
>> Your comments on this group do lead me to the conclusion that you think
>> everyone on it, bar yourself, is a complete moron.
>
>Not everyone... but most.
2. Most everyone except George is a complete moron.
Last time I checked, "moron" and "idiot" were terms with almost equal
definitions. George has blanket-stated that he considers most of the people
in the mudding community to be morons. Yet he himself gets very upset
when HE is called similar names.
Summary: he can dish it out but can't take it.
Just give up fighting him. Remember, he's here because he is "interested
in mud technology". But all of us are idiots, so he probably isn't here to
listen to us. Rather, he is most likely here to bless us with his devine
knowledge and superior coding skills.
I of course have my own personal opinions - that his true interest is to
keep the mudding community fragmented by advocating a "with me or against me"
type of mentality. Or using the more common words: "Either you see that I am
correct and I am not an idiot, or you are a complete moron."
Anyone who assumes that a large portion of computer-literate people are
morons with such a general statement must be an idiot.
David Rudy.
mor...@niuhep.physics.niu.edu
George Reese <bo...@imaginary.com> writes:
>mor...@niuhep.physics.niu.edu wrote:
>> bo...@visi.com (George Reese) writes:
Before going on I want to thank George (and some other people who
have been discussing this) for having some patience with me and taking
time to explain what the problems are.
>> >Yes, that is the way it traditionally happens. the problem is that
>> >you can perform the check, find the door open, have another thread
>> >become the current running thread, that thread changes the door's
>> >state, the initial thread becomes current and proceeds through the
>> >door.
>> put a lock on the data bit that is not released until the action is
>> done. (he say rather blythely... well how hard is that to do?)
>Again, whether this is possible or not is not the issue: in
>multi-threaded environments, this is actually fairly trivial.
>
>The issue, however, is this... when player 1 shuts the door, when need
>to, using your terms, lock down the door state. This way any other
>thread coming through that might need or change that door state will
>have to wait until the door-close event is complete.
>In Java, for example, we would do this:
>in the player:
> Door door = getEnvironment().getDoor(room);
> if( door != null ) {
> synchronized( door ) {
>in the go command...
>void execute(Player player, String cmd) {
> String direction = getDirection(cmd);
> Room room = player.getEnvironment().getRoom(direction);
> player.go(room);
>}
>Simple enough codewise... make sure you lock down the door (no pun
>intended) for the event that relies on the state of the door.
>One complicating factor, however, if the move() code...
>void move(Room room) {
> Room environment = getEnvironment();
> synchronized( environment ) {
> synchronized( room ) {
> setEnvironment(room);
> environment.removeItem(this);
> room.addItem(this);
>You have a potential race condition here. Specifically, if another
>event attempts to lock the environment while the thread here is locking
>the door, then that thread attempts to lock the door, you end up with
>the other thread waiting for you to release the door lock and your
>thread waiting for it to release the environment lock. Mud frozen.
Hmmm,
>But the problem I wish to illustrate first is that you
>have just given an area creator a way to lock up your mud.
Ok, so the problem is that there are two different attempts to set
locks that are overlapping in their coverage? Presumably if they both
tried to set the same exact lock one or the other would get there
first (assuming a single cpu).
>Yes, you can avoid this by providing a local context object on which to
>synchronize.
by this do you mean that you have an object that the first thread
to grab has precedence or an object that actively sorts out who
has precedence or ...?
>The next issue is how complex it is to deal with this issue for a
>creator who barely understands what they are doing when they write an
>area.
[the author goes out on a limb...]
It seems to me that part of the problem is that many muds have room (and
area) programs, rather than programs for individual objects. I am sure
that having room programs that control the mobs and traps in the room
simplifies control and general programming, but reduces flexibility
and causes some other problems as well.
But I suppose at some point if you have locks you are likely to
have some overlap that needs to be resolved...
>You could of course have a driver which understands events and contexts.
>At this point you have built into your driver the nature of your mud.
>Among other things, this does seriously limit your interaction across
>contexts and the type of muds which might be developed with a server.
hmmm.
thanks again.
Robert
Martin Keegan
Ron Cole wrote:
>
> <<Blink>> You mean THAT is what cellars is? You know how long I've
> wondered what that newsgroup was really for? Wow, learn something
the address is cellars.teeny.org 4000. It was run from a student account
on tower.york.ac.uk, until I started making rumbling noises about the
derogatory material in the database. Suspiciously, it then moved to
Oregon. Coincidence? :)
At any rate, I played it last month, but it seems to be gone now.
Good riddance to it.
> new every day. And yes, maybe they should combine.. the combined
> newsgroup would probably get about 3 messages a month,
Whoo-hoo ... one per player :)
If anyone has any info about where the database has gone, I'd like
a copy, as it had great atmosphere, even if it WAS a little nasty.
A salutory warning to all immortals planning quest upgrades!
Mk
--------
A sample:
telnet tower.york.ac.uk 6666
Trying 144.32.128.6 ...
Connected to tower.york.ac.uk.
Escape character is '^]'.
cAnMuDcAnMuDcAnMuDcAnMuDcAnMuDcAnMuDcAnMuDcAnMuDcAnMuDcAnMuD
Welcome to the Campaign to Anhialate NemeSys MUD server.
If you already have a character then type,
'Connect <name> <password>'
If you are a new character then type,
'Create <name> <password>'
This MUD was created on 6th March 1996 by:
Steve Price - 'Wizard' and 'ShayDn'
Chris Gilbert - 'Gilb'
Complaints are punishable by death.
Login:>^]
telnet> close
Connection closed.
and:
Relaxation Room
The white walls and the quiet soothing music relax you the moment you
walk
into this room. It would be easy to loose yourself for hours here.
Especially
considering the fact that there are a bunch of cool weapons and a dummy
here.
Contents:
Bazooka
Small Note
Katana
Large Spiked Mace
ACME Nemesys Dummy
The exits are:
west;wes;we;w
--> examine dummy
The contents of this game are original. Any similarities with real life
are
purely coincidence.
Owner: Foxheart
--> read dummy
The contents of this game are original. Any similarities with real life
are
purely coincidence.
--> read note
If any of you have a wish list for weapons you would like to try then
leave a
note in Foxheart's Study and I'll get round to
it.
Cheers, Foxheart.
--> read bazooka
A lovely weapon, contains one shining "NemeSys Homing Shell".
--> read katana
The blade shines in the overhead light. It is beautiful. You get the
urge to c
ut the dummy up with it.
--> read mace
A HUGE black mace with big spikes on. Try clubbing the dummy with it for
a
little relaxation.
--> save
Tell me how to implement it and I'll reconsider. (Type "help")
--> quit
Please call again soon...
Connection closed by foreign host.
Abigail
On 21 Apr 1997 20:18:35 GMT, Chris Lawrence (Contra) wrote in
rec.games.mud.misc,rec.games.mud.admin <URL: news:5jgi2r$bj8$1...@hpax.cup.hp.com>:
++
++ Abigail (abi...@fnx.com) wrote:
++ : On 18 Apr 1997 20:01:52 GMT, George Reese wrote in
++ : rec.games.mud.misc,rec.games.mud.admin <URL:
++ : news:5j8jvg$8tm$1...@darla.visi.com>:
++
++ : ++ Yes, that is the way it traditionally happens. the problem is that
++ : ++ you can perform the check, find the door open, have another thread
++ : ++ become the current running thread, that thread changes the door's
++ : ++ state, the initial thread becomes current and proceeds through the
++ : ++ door.
++
++ : Can one say "semaphores"?
++
++ Yes, I can. And just how do you intend to handle deadlocks? Sempahores
++ are a very partial, and very expensive solution.
One way to deal with it is too have the thread fail if it waits for
a semaphore too long (releasing all the semaphores it has locked),
in the same way as currently a thread fails it it takes too many
ticks. Not a nice solution, but you don't want the player to wait
too long anyway, even if there was no deadlock.
++ : It's an old problem solved many moons ago.
++
++ Codswhallop. Take a busy MUD, say 1,000 active players. Assume an
++ average of 1 transaction per player every 5 seconds (fairly
++ reasonable). Now assume that each transaction affects at least two
++ objects (eg the door affects both itself and the rooms on either side).
++ Now make each one of those transactions semaphore controlled.
++
++ Hurm.
++
++ That ranks up to 800 semaphore transactions (set and release) per second
++ assuming zero contention.
That looks like a lot, but it's only a fraction of your costs. Setting
and release a semaphore is just a simple function call, releasing a
semaphore might trigger a continue() call in a waiting process.
You have 200 transactions per second; each transaction typically
contains 5 writes, 2 calls to this_player() -> query_name(), 1 call
to present() scanning a list, a call to short(), etc, etc. Not to
mention the gazillion of init()s being run.
++ There's a reason that multi-user database systems don't use semaphores for
++ record locking (which is essentially what we are dealing with if you take
++ a locking approach).
Well, you basically have to wait till the other transaction(s) is
finished. Just like a semaphore does. What's the difference?
And look what
<http://www.sybase.com/products/system11/sqlserver11_whitepaper.html> says:
>> The SQL Server 11 Parallel Lock Manager (PLM) improves the efficiency
>> and scalability of the locking subsystem by removing contention on the
>> lock manager. The PLM replaces the single lock semaphore with separate
>> semaphores for each type of lock resource. These semaphores are used by
>> the PLM to serialize access to the data structures associated with
>> address locks, table locks, and page locks. Concurrency is controlled
>> for each type of resource rather than a single concurrency point for
>> all types of lock structures.
Abigail
Chris Lawrence (Contra)
Abigail (abi...@fnx.com) wrote:
: On 21 Apr 1997 20:18:35 GMT, Chris Lawrence (Contra) wrote:
: ++ Abigail (abi...@fnx.com) wrote:
: ++ : On 18 Apr 1997 20:01:52 GMT, George Reese wrote:
: ++ : ++ Yes, that is the way it traditionally happens. the problem is that
: ++ : ++ you can perform the check, find the door open, have another thread
: ++ : ++ become the current running thread, that thread changes the door's
: ++ : ++ state, the initial thread becomes current and proceeds through the
: ++ : ++ door.
: ++
: ++ : Can one say "semaphores"?
: ++
: ++ Yes, I can. And just how do you intend to handle deadlocks? Semaphores
: ++ are a very partial, and very expensive solution.
NB I spent the last couple months working on high volume realtime
transaction servers (6,000+ messages per second). Semaphores are not a
great solution.
: One way to deal with it is too have the thread fail if it waits for
: a semaphore too long (releasing all the semaphores it has locked),
: in the same way as currently a thread fails it it takes too many
: ticks. Not a nice solution, but you don't want the player to wait
: too long anyway, even if there was no deadlock.
Which then leads to the problems of how you handle the rollbacks.
The standard (expensive) solution (which I use) is to operate on local
data only (which also removes the need for semaphores at all).
Otherwise you end up with the logical consistancy problem:
Event A modifies attribute X.
Event B references attribute X.
Event A attempts to lock resource Y and fails.
Event A waits on the lock/semaphore.
Event B compleats sucessfully.
Event A finally times out.
What is the correct state of attribute X?
Of course you can resolve this by requiring all events to do their
resource locking during their initialisation, but that has other
non-trivial expenses.
Semaphores are a partial solution that introduce as many problems as
they purport to solve.
: ++ : It's an old problem solved many moons ago.
: ++
: ++ Codswhallop. Take a busy MUD, say 1,000 active players. Assume an
: ++ average of 1 transaction per player every 5 seconds (fairly
: ++ reasonable). Now assume that each transaction affects at least two
: ++ objects (eg the door affects both itself and the rooms on either side).
: ++ Now make each one of those transactions semaphore controlled.
: ++
: ++ Hurm.
: ++
: ++ That ranks up to 800 semaphore transactions (set and release) per second
: ++ assuming zero contention.
: That looks like a lot, but it's only a fraction of your costs. Setting
: and release a semaphore is just a simple function call, releasing a
: semaphore might trigger a continue() call in a waiting process.
: You have 200 transactions per second; each transaction typically
: contains 5 writes, 2 calls to this_player() -> query_name(), 1 call
: to present() scanning a list, a call to short(), etc, etc. Not to
: mention the gazillion of init()s being run.
Ignoring the LP specific (I'm not an LP fan), yup, you do. Its a big
challenge to make your transaction overhead low. Loosing the list scans,
losing the semaphores, defaulting the indirect references etc can do a
lot to help.
: ++ There's a reason that multi-user database systems don't use semaphores for
: ++ record locking (which is essentially what we are dealing with if you take
: ++ a locking approach).
: Well, you basically have to wait till the other transaction(s) is
: finished. Just like a semaphore does. What's the difference?
Most of the big guys actually don't lock. They use the local data copies
and then compare and commit (C&C). Its machine expensive on RAM and copy
time, but its cheap on race condition, deadlock, pre-transaction analysis,
and contention management.
: And look what
: <http://www.sybase.com/products/system11/sqlserver11_whitepaper.html> says:
: >> The SQL Server 11 Parallel Lock Manager (PLM) improves the efficiency
: >> and scalability of the locking subsystem by removing contention on the
: >> lock manager. The PLM replaces the single lock semaphore with separate
: >> semaphores for each type of lock resource. These semaphores are used by
: >> the PLM to serialize access to the data structures associated with
: >> address locks, table locks, and page locks. Concurrency is controlled
: >> for each type of resource rather than a single concurrency point for
: >> all types of lock structures.
Yup. Read the whole article and look at what they actually said. Its not
that impressive. Instead of having a single semaphore control all
write/commit access to the records, they now have staggered semaphores for
component data. They lose a lot of contention by making the grain a lot
finer. You can do the same thing with C&C and get most of the same gains
without the semphore.
Jon A. Lambert
Abigail <abi...@fnx.com> wrote in article <E91tF...@nonexistent.com>...
> On 21 Apr 1997 20:18:35 GMT, Chris Lawrence (Contra) wrote in
> rec.games.mud.misc,rec.games.mud.admin <URL: news:5jgi2r$bj8$1...@hpax.cup.hp.com>:
>
> a semaphore too long (releasing all the semaphores it has locked),
> in the same way as currently a thread fails it it takes too many
> ticks. Not a nice solution, but you don't want the player to wait
> too long anyway, even if there was no deadlock.
>
I use a simple mutex in my implementation, it may be more or less
efficient than Chris's solution.
There is an added overhead of maintaining the semaphore counter.
I have found no reason to use them in intra-process applications.
However I understand they do have their use in inter-process
communications. Or quite possibly you are referring to the FSU
PThreads package?
>
> ++ There's a reason that multi-user database systems don't use semaphores for
> ++ record locking (which is essentially what we are dealing with if you take
> ++ a locking approach).
>
> Well, you basically have to wait till the other transaction(s) is
> finished. Just like a semaphore does. What's the difference?
>
>
> And look what
> <http://www.sybase.com/products/system11/sqlserver11_whitepaper.html> says:
> >> The SQL Server 11 Parallel Lock Manager (PLM) improves the efficiency
> >> and scalability of the locking subsystem by removing contention on the
> >> lock manager. The PLM replaces the single lock semaphore with separate
> >> semaphores for each type of lock resource. These semaphores are used by
> >> the PLM to serialize access to the data structures associated with
> >> address locks, table locks, and page locks. Concurrency is controlled
> >> for each type of resource rather than a single concurrency point for
> >> all types of lock structures.
Forgive me if I'm wrong but this application is based on inter-process
communication and not intra-process communication with which we are
talking about. Database, table or record locking is NOT maintained using
semaphores in Sybase in any event. This white-paper refers to the CODE that
implements the lock manager not the locks themselves. They have just implemented
concurrent lock manager code in place of the synchronous code. A slight
improvement to be sure but this in no way is an endorsement of semaphores.
Semaphores happen to be the one of the better choices for process-to-process
communications.
I would bet that Chris's implementation will outperform the
above software by a large factor for different reasons.
Hip hip :-)
George Reese
Britton wrote:
>
> David Rudy (dar...@Eng.Sun.COM) wrote:
>
> : >There are two things here. First, yes, they are complaining about the
> : >way I present myself. Big fucking deal. Like I said, I am not here to
> : >make friends with mudders. I am here because I am interested in mud
> : >technology. My attitude derives from my complete lack of respect for a
> : >large portion of my peers in this community.
>
> : >> Your comments on this group do lead me to the conclusion that you think
> : >> everyone on it, bar yourself, is a complete moron.
> : >
> : >Not everyone... but most.
>
> : definitions. George has blanket-stated that he considers most of the people
> : in the mudding community to be morons. Yet he himself gets very upset
> : when HE is called similar names.
>
> : in mud technology". But all of us are idiots, so he probably isn't here to
> : listen to us. Rather, he is most likely here to bless us with his devine
> : knowledge and superior coding skills.
>
> but the misguided idea that he has major technical contributions to make
> persists. All he really does is slam stuff he doesn't like. And make
> shit up. A while ago I was debating the relative merits of PerlMUD and
> Java based designs and I mentioned p2c as giving PerlMUD an even more
> gigantic speed advantage than it had anyway. I'll admit now I was
> confused, but it was an honest mistake. p2c is the pascal translator.
> George's response?
>
> "Check out a JIT. You get better performance with it than with p2c."
>
> Implying that he had used p2c a lot, was fammiliar with its performance,
> etc. Nice try there.
You base your assumption on what? My statement still stands, though it
probably should read 'you can get better performance'.
You and David are a seriously deranged. If my goal was to sit and slam
things I do not like, I could just hang around the Microsoft
newsgroups. Even a "moron" should realize that I am honestly interested
in mud technology... I have been involved with mud technology for 6
years. In the last year, however, I have lost all desire to help others
with it.
And PerlMud remains a seriously deranged concept.
Chris Lawrence (Contra)
Jon A. Lambert (jlsy...@ix.netcom.com) wrote:
: I would bet that Chris's implementation will outperform the
: above software by a large factor for different reasons.
Oh dear. What have I done to this poor chap?
<<It bloody well better outperform it by several orders of
magnitude or something is very fishy in mine code>>
Jon A. Lambert
David Rudy <dar...@Eng.Sun.COM> wrote in article <5jj09i$b...@handler.Eng.Sun.COM>...
> Last time I checked, "moron" and "idiot" were terms with almost equal
> definitions. George has blanket-stated that he considers most of the people
> in the mudding community to be morons. Yet he himself gets very upset
> when HE is called similar names.
The U.S armed services used to keep statistics on this sort of thing
in the 1940's and perhaps they still do.
An idiot was defined as one with an IQ between 80 and 90.
A moron has a somewhat lower IQ rating between 60 and 70.
Just a useless bit of trivia for y'all. Have fun. :-)
JL
"If I'd known it was harmless, I would have killed it myself"
Abigail
On Wed, 23 Apr 1997 21:38:14 -0500, George Reese wrote in
rec.games.mud.admin <URL: news:335EC796...@imaginary.com>:
++
++ And PerlMud remains a seriously deranged concept.
++
Why?
Perl gives something muds desparately need: regex support.
I would prefer programming in Perl over LPC anytime.
Abigail
Kris Van Hees
George Reese <bo...@imaginary.com> wrote:
: Britton wrote:
: > A while ago I was debating the relative merits of PerlMUD and
: > Java based designs and I mentioned p2c as giving PerlMUD an even more
: > gigantic speed advantage than it had anyway. I'll admit now I was
: > confused, but it was an honest mistake. p2c is the pascal translator.
: > George's response?
: >
: > "Check out a JIT. You get better performance with it than with p2c."
: >
: > Implying that he had used p2c a lot, was fammiliar with its performance,
: > etc. Nice try there.
: You base your assumption on what? My statement still stands, though it
: probably should read 'you can get better performance'.
Can you please back that statement up with hard evidence? Although there
are several versions of p2c implementations, the ones I have seen (and in
fact worked on porting to VM/CMS, thus investigated the sources) do a very
decent job using the fact that for most operations C is more flexible than
Pascal. It will nver be as fast as a true rewrite in C of course due to
the nature of Pascal which has to be retained by p2c, but considering a
JIT for Pascal compared to p2c I'm almost positive that at least the p2c's
I've looked into will have the better performance.
After all, I cannot really see how a JIT could outperform a binary obtained
from true compilation to machine code.
Aedil
Britton
David Rudy (dar...@Eng.Sun.COM) wrote:
: >There are two things here. First, yes, they are complaining about the
: >way I present myself. Big fucking deal. Like I said, I am not here to
: >make friends with mudders. I am here because I am interested in mud
: >technology. My attitude derives from my complete lack of respect for a
: >large portion of my peers in this community.
: >> Your comments on this group do lead me to the conclusion that you think
: >> everyone on it, bar yourself, is a complete moron.
: >
: >Not everyone... but most.
: Last time I checked, "moron" and "idiot" were terms with almost equal
: definitions. George has blanket-stated that he considers most of the people
: in the mudding community to be morons. Yet he himself gets very upset
: when HE is called similar names.
: Just give up fighting him. Remember, he's here because he is "interested
: in mud technology". But all of us are idiots, so he probably isn't here to
: listen to us. Rather, he is most likely here to bless us with his devine
: knowledge and superior coding skills.
Most everyone has figured out by now that he is intolerable personnaly,
but the misguided idea that he has major technical contributions to make
persists. All he really does is slam stuff he doesn't like. And make
shit up. A while ago I was debating the relative merits of PerlMUD and
Java based designs and I mentioned p2c as giving PerlMUD an even more
gigantic speed advantage than it had anyway. I'll admit now I was
confused, but it was an honest mistake. p2c is the pascal translator.
George's response?
"Check out a JIT. You get better performance with it than with p2c."
Implying that he had used p2c a lot, was fammiliar with its performance,
etc. Nice try there.
: I of course have my own personal opinions - that his true interest is to
: keep the mudding community fragmented by advocating a "with me or against me"
: type of mentality. Or using the more common words: "Either you see that I am
: correct and I am not an idiot, or you are a complete moron."
: Anyone who assumes that a large portion of computer-literate people are
: morons with such a general statement must be an idiot.
Well said. George marks himself an arrogant fool with this type of statement.
: David Rudy.
Marcus Meißner
In article <E94Jv...@nonexistent.com>, Abigail <abi...@fnx.com> wrote:
>On Wed, 23 Apr 1997 21:38:14 -0500, George Reese wrote in
>rec.games.mud.admin <URL: news:335EC796...@imaginary.com>:
>++
>++ And PerlMud remains a seriously deranged concept.
>++
>
>Why?
>
>Perl gives something muds desparately need: regex support.
The regexp functionality in Amylaar's is rather complete
(regexp, regexplode, regreplace). Except perhaps regexps as
a basic type.
I would go farther and prefer a good parser generator. One where you can
add and subtract rules on the fly (to be able to get rid of that stupid
'verb [optional arguments]' syntax).
>I would prefer programming in Perl over LPC anytime.
Perl is definitely not suited for the beginning wizard with no former
programming experience (or experience only in *Basic* or *Pascal*).
It is well suited for easy, everyday tasks and small hacked up programs.
But I don't think it's better than LPC for programming multiuser domains.
Marcus
--
<URL:http://wwwcip.informatik.uni-erlangen.de/~msmeissn/>
"Sneak in? And waste a perfectly good battering ram?" - chu...@art.ohiou.edu
Tim Hollebeek
In article <ndfg1wm...@arioch.tky.hut.fi>, Petri Virkkula <pvir...@iki.fi> writes:
>
> I would make the gd internally multi threaded: multiple
> compiler threads, a thread for hname/addr_server, threads for
> player input/output handling, but only one thread for
> evaluation of LPC code. That would be simplest way (easiest
> way to make bugfree code) to support multiple threads.
Hmm, deja vu; there was just a thread about this on lpc-language. I
agree this is the only real solution (and that Abigail's opinion that
adding mt support is "easy; just use semaphores" is rubbish); the
problem is that this solution doesn't help much, since a well-tuned gd
spends the vast majority (~99%) of its time evaluating LPC code
(because the overhead due to the rest of the work that needs to be
done approaches zero). Handling input/output async doesn't gain you
much since (for example) doing something with player input forces you
to wait to be able to call LPC code anyway, so one cannot really get
too far ahead. One ends up with a more complex gd which only offers
very marginal benefits over a single-threaded one.
---------------------------------------------------------------------------
Tim Hollebeek | Disclaimer :=> Everything above is a true statement,
Electron Psychologist | for sufficiently false values of true.
Princeton University | email: t...@wfn-shop.princeton.edu
----------------------| http://wfn-shop.princeton.edu/~tim (NEW! IMPROVED!)
Tim Hollebeek
In article <5jfuqb$h...@corn.cso.niu.edu>, mor...@niuhep.physics.niu.edu writes:
> bo...@visi.com (George Reese) writes:
> >mor...@niuhep.physics.niu.edu wrote:
> >: co...@null.net ("J C Lawrence") writes:
> >: >George Reese (bo...@visi.com) wrote:
> >:
> >: >: It depends on what you are trying to build. Clearly a lot of muds do
> >: >: very well without threading.
> >:
> >: agreed
>
> >: >: Well, as has been stated many times before, this is a genuinely hard
> >: >: issue. The typical example might be:
>
> >: >: I issue the close door command in room A.
> >: >: You issue the exit room command in room B.
>
> >: This particular example doesn't seem to be that much of a problem.
> >: You have a database that stores the state of the door. When you
> >: try to exit through the door it checks the state of the door.
>
> >Yes, that is the way it traditionally happens. the problem is that
> >you can perform the check, find the door open, have another thread
> >become the current running thread, that thread changes the door's
> >state, the initial thread becomes current and proceeds through the
> >door.
>
> put a lock on the data bit that is not released until the action is
> done. (he say rather blythely... well how hard is that to do?)
That works, but that's where deadlocks come in.
Tim Hollebeek
In article <5jg4kp$s...@corn.cso.niu.edu>, mor...@niuhep.physics.niu.edu writes:
>
> rlo...@franck.Princeton.EDU.composers () writes:
>
> >In article <5j8jvg$8tm$1...@darla.visi.com>, bo...@visi.com writes:
> >> mor...@niuhep.physics.niu.edu wrote:
>
> >> : This particular example doesn't seem to be that much of a problem.
> >> : You have a database that stores the state of the door. When you
> >> : try to exit through the door it checks the state of the door.
>
> >> Yes, that is the way it traditionally happens. the problem is that
> >> you can perform the check, find the door open, have another thread
> >> become the current running thread, that thread changes the door's
> >> state, the initial thread becomes current and proceeds through the
> >> door.
>
> >Wait a minute. I'm just passing through this thread, but morphis's
> >statement that "[this] doesn't seem to be much of a problem" implies
> >he doesn't even know what a race condition *is*. Isn't debating the
> >merits of single vs. multi threadedness with such a person a waste of
> >time?
>
[...]
>
> Unlike some people I do not claim overwhelming
> expertise (and would probably look like a fool if I did) but coming
> from a VMS background I have some general knowledge of similar problems
> that are solved using locks. However my knowledge isn't deep enough
> to see how well that would apply here. I am guessing that the
> semaphores mentioned by Abigail are somewhat related, but that is,
> as noted, guessing.
Passing through again :-) You're more or less right btw.
Yeah, I just find it odd that there are people in this discussion who
don't know what race conditions, deadlocks, semaphores, etc *are*, who
don't seem to have any problem with declaring that all the associated
problems are trivial and here is how you solve them ...
Of course, the other half of the discussion is at fault for never
taking a paragraph to say what a semaphore is ;-) [there have been
pretty good elementary examples of race conditions, though I don't
remember if they were labeled as such]
Tim Hollebeek
In article <yospe-20049...@usrns48.dialup.hawaii.edu>, yo...@hawaii.remove.this.edu writes:
>
> is use of multiple threads, but not support. The perspective, not
> surprisingly, of an LPC mud designer is molded by the way LPs drivers
> are constructed.
Your ability to slam LPs unnecessarily evidentally knows no bounds.
If you actually read Petri's article, you would note that he discussed
adding threads at the LPC level, and concluded it wasn't worth it and
*then* went on to offer his proposal.
I know this has been pointed out to you before, but I'll just mention
yet again that MOO's *are* threaded in the sense you mean, and that
LPMoo *is* threaded, and runs under a single threaded traditional
style LP driver.
One *could* write a threaded LP mudlib from scratch, and I suspect
Petri knows this, and I suspect he even knows how you would go about
doing this, which I suspect you do not.
Abigail
On Thu, 24 Apr 1997 22:34:20 +0200, Marcus Meißner wrote in
rec.games.mud.admin <URL: news:5jog4c$j...@rznews.rrze.uni-erlangen.de>:
++
++ In article <E94Jv...@nonexistent.com>, Abigail <abi...@fnx.com> wrote:
++
++ The regexp functionality in Amylaar's is rather complete
++ (regexp, regexplode, regreplace). Except perhaps regexps as
++ a basic type.
Hmm, time to look more into Amylaar then. Perhaps that will be the
driver of my choice for my perfect mudlib. (yeah, right `perfect').
++ I would go farther and prefer a good parser generator. One where you can
++ add and subtract rules on the fly (to be able to get rid of that stupid
++ 'verb [optional arguments]' syntax).
++
++ >I would prefer programming in Perl over LPC anytime.
++
++ Perl is definitely not suited for the beginning wizard with no former
++ programming experience (or experience only in *Basic* or *Pascal*).
++ It is well suited for easy, everyday tasks and small hacked up programs.
++ But I don't think it's better than LPC for programming multiuser domains.
True, but not every mud needs to be for beginning wizards with no
former programming experience. Heck, not every mud needs to have
auto-wizzing after collecting large enough values in some variables. :)
Abigail
Nathan F. Yospe
t...@wfn-shop.princeton.edu wrote:
yo...@hawaii.remove.this.edu writes:
:>
:> is use of multiple threads, but not support. The perspective, not
:> surprisingly, of an LPC mud designer is molded by the way LPs drivers
:> are constructed.
:Your ability to slam LPs unnecessarily evidentally knows no bounds.
:If you actually read Petri's article, you would note that he discussed
:adding threads at the LPC level, and concluded it wasn't worth it and
:*then* went on to offer his proposal.
The issue was whether LPs could be threaded without redesigning the
entire driver concept. Most LP libs, incidentally, use a pulse (shudder)
system. Part of the question here is the rather clueless attitude of
many LP proponents that LP contains everything anyone could ever
possibly want in a mud. This is ridiculous... therefore I ridicule.
:I know this has been pointed out to you before, but I'll just mention
:yet again that MOO's *are* threaded in the sense you mean, and that
:LPMoo *is* threaded, and runs under a single threaded traditional
:style LP driver.
There is a difference between process switching to emulate threads
(LPMoo - and yes, I checked to make sure that's what it does) and
having an integrated thread system underlying the entire process
model.
:One *could* write a threaded LP mudlib from scratch, and I suspect
:Petri knows this, and I suspect he even knows how you would go about
:doing this, which I suspect you do not.
One could not. One could write a threaded driver if one was willing to
go to that much trouble. There is a difference, as I said before, between
emulation of threads and OS level threads. I have written a threadded
mud server, and while it has made some sacrifice in thread capabilities
(see the earlier notes on that) it is still something that cannot, and
could not without a completely new and unrelated driver, be done in LPC.
And if a driver were created that could do what Physmud++ does, it would
no longer be an LP. I have learned LPC, and studied the available drivers.
They are not all that impressive.
George Reese
Nathan F. Yospe wrote:
>
> t...@wfn-shop.princeton.edu wrote:
>
> yo...@hawaii.remove.this.edu writes:
> :>
> :> is use of multiple threads, but not support. The perspective, not
> :> surprisingly, of an LPC mud designer is molded by the way LPs drivers
> :> are constructed.
>
> :Your ability to slam LPs unnecessarily evidentally knows no bounds.
> :If you actually read Petri's article, you would note that he discussed
> :adding threads at the LPC level, and concluded it wasn't worth it and
> :*then* went on to offer his proposal.
>
> The issue was whether LPs could be threaded without redesigning the
> entire driver concept. Most LP libs, incidentally, use a pulse (shudder)
> system. Part of the question here is the rather clueless attitude of
> many LP proponents that LP contains everything anyone could ever
> possibly want in a mud. This is ridiculous... therefore I ridicule.
No one argues that except you... perhaps to create something to argue
about. Most LP proponents consider multi-threading a dubious want at
best.
Petri Virkkula
>>>>> "Tim" == Tim Hollebeek <t...@franck.Princeton.EDU.composers> writes:
Tim> (because the overhead due to the rest of the work that needs to be
Tim> done approaches zero). Handling input/output async doesn't gain you
Tim> much since (for example) doing something with player input forces you
Tim> to wait to be able to call LPC code anyway, so one cannot really get
Tim> too far ahead. One ends up with a more complex gd which only offers
Tim> very marginal benefits over a single-threaded one.
I agree that it wouldn't help much. But I can also see
situation where it is cheaper to buy second CPU than buy a new
CPU and to throw away the old one.
If there are two CPUs, one can be dedicated into evaluation
thread (consumer) which does just following:
while (1) {
wait_queue (apply_queue, &ob, &func, &args,
&cond, &resptr);
apply(&retval, ob, func, args);
if (resptr) {
assign (resptr, &retval);
cond_signal (cond);
}
}
Then there can be multiple producer threads, one for
heart_beat, one for call_outs, one for player input, etc. I
think that the gd would be cleaner, not more complex.
With single cpu above would not help much, that's
true. However, we have noticed that evaluation thread is
blocked during disk I/O. That was prevented with caching in
log_file. IMHO multiple threads would have been cleaner
solution, but impossible to do without remaking whole gd.
Petri
Nathan F. Yospe
bo...@imaginary.com wrote:
:Nathan F. Yospe wrote:
:> The issue was whether LPs could be threaded without redesigning the
:> entire driver concept. Most LP libs, incidentally, use a pulse (shudder)
:> system. Part of the question here is the rather clueless attitude of
:> many LP proponents that LP contains everything anyone could ever
:> possibly want in a mud. This is ridiculous... therefore I ridicule.
:
:No one argues that except you... perhaps to create something to argue
:about. Most LP proponents consider multi-threading a dubious want at
:best.
For LPs, it is. That was my point. Read what I wrote again: LPs don't do
everything _I_ think a mud should do. Obviously, that means that I will
not try to multithread LPC. I have, however, written a multithreaded mud
with an internal language that is capable of use of that threading
without conflict. This is not to say that LP is not a usable paradigm,
but that I think most of its proponents are a little too close to the
trees to see the forest. I stand by that statement, and the opinions of
most of the people I know who started with LPs and decided to go scratch
support my view. Now go away. You're a twit.
George Reese
Nathan F. Yospe wrote:
>
> bo...@imaginary.com wrote:
>
> :Nathan F. Yospe wrote:
>
> :> The issue was whether LPs could be threaded without redesigning the
> :> entire driver concept. Most LP libs, incidentally, use a pulse (shudder)
> :> system. Part of the question here is the rather clueless attitude of
> :> many LP proponents that LP contains everything anyone could ever
> :> possibly want in a mud. This is ridiculous... therefore I ridicule.
> :
> :No one argues that except you... perhaps to create something to argue
> :about. Most LP proponents consider multi-threading a dubious want at
> :best.
>
> For LPs, it is. That was my point. Read what I wrote again: LPs don't do
> everything _I_ think a mud should do.
You read what you wrote again.
"...many LP proponents that LP contains everything anyone could ever
possibly want in a mud"
> Obviously, that means that I will
> not try to multithread LPC.
The issue is not whether multi-threaded LPC is a good thing or not... it
is whether multi-threading is all that useful in an environment like an
LPMud.
> I have, however, written a multithreaded mud
> with an internal language that is capable of use of that threading
> without conflict. This is not to say that LP is not a usable paradigm,
> but that I think most of its proponents are a little too close to the
> trees to see the forest. I stand by that statement, and the opinions of
> most of the people I know who started with LPs and decided to go scratch
> support my view.
My view certainly does not support yours.
> Now go away. You're a twit.
Who is it that has a problem with opposing points of view?
George Reese
Nathan F. Yospe wrote:
> :My view certainly does not support yours.
>
> I said most. One arrogant jackass does not outweigh over a dozen highly
> intelligent mud designers.
I am not the only one who feels this way clearly... I am just not going
to sit by and speak for others.
Which brings up...
> :> Now go away. You're a twit.
>
> :Who is it that has a problem with opposing points of view?
>
> I have a problem with your caustic personality, not your POV.
Whether or not my personality is problematic, you cannot use it as an
argument against my POV. You have, and this suggests a problem with
opposing points of view.
Nathan F. Yospe
:Nathan F. Yospe wrote:
:> bo...@imaginary.com wrote:
:> For LPs, it is. That was my point. Read what I wrote again: LPs don't do
:> everything _I_ think a mud should do.
:You read what you wrote again.
:"...many LP proponents that LP contains everything anyone could ever
:possibly want in a mud"
Eep. Typo. Add a "have claimed" between "proponents" and "that". And I
stand by that statement.
:> Obviously, that means that I will
:> not try to multithread LPC.
:The issue is not whether multi-threaded LPC is a good thing or not... it
:is whether multi-threading is all that useful in an environment like an
:LPMud.
Actually, the issue was whether or not multi-threading is all that useful
in an environment lika a Mud. Period. And my answer was yes. And the
reply was you can't thread an LP. I replied that that was a problem in
LPs, but not all muds are LPs... and it escalated from there.
:> I have, however, written a multithreaded mud
:> with an internal language that is capable of use of that threading
:> without conflict. This is not to say that LP is not a usable paradigm,
:> but that I think most of its proponents are a little too close to the
:> trees to see the forest. I stand by that statement, and the opinions of
:> most of the people I know who started with LPs and decided to go scratch
:> support my view.
:My view certainly does not support yours.
I said most. One arrogant jackass does not outweigh over a dozen highly
intelligent mud designers.
:> Now go away. You're a twit.
:Who is it that has a problem with opposing points of view?
I have a problem with your caustic personality, not your POV.
Abigail
On 26 Apr 1997 11:11:28 +0300, Petri Virkkula wrote in
rec.games.mud.misc,rec.games.mud.admin <URL: news:ndfyba6...@arioch.tky.hut.fi>:
++ >>>>> "Tim" == Tim Hollebeek <t...@franck.Princeton.EDU.composers> writes:
++
++ Tim> (because the overhead due to the rest of the work that needs to be
++ Tim> done approaches zero). Handling input/output async doesn't gain you
++ Tim> much since (for example) doing something with player input forces you
++ Tim> to wait to be able to call LPC code anyway, so one cannot really get
++ Tim> too far ahead. One ends up with a more complex gd which only offers
++ Tim> very marginal benefits over a single-threaded one.
++
++ I agree that it wouldn't help much. But I can also see
++ situation where it is cheaper to buy second CPU than buy a new
++ CPU and to throw away the old one.
++
++ If there are two CPUs, one can be dedicated into evaluation
++ thread (consumer) which does just following:
++
++ while (1) {
++ wait_queue (apply_queue, &ob, &func, &args,
++ &cond, &resptr);
++ apply(&retval, ob, func, args);
++ if (resptr) {
++ assign (resptr, &retval);
++ cond_signal (cond);
++ }
++ }
++
++ Then there can be multiple producer threads, one for
++ heart_beat, one for call_outs, one for player input, etc. I
++ think that the gd would be cleaner, not more complex.
If you have concurrent threads for heart_beat/call_outs and player
input, you have the same problems as running two concurrent threads
for player input. To get back to the example of a player entering
a door which is being closed by another thread, it really doesn't
matter whether the door is closed by a different player, an NPC driven
by its heart_beat, or a call_out.
++ With single cpu above would not help much, that's
++ true. However, we have noticed that evaluation thread is
++ blocked during disk I/O. That was prevented with caching in
++ log_file. IMHO multiple threads would have been cleaner
++ solution, but impossible to do without remaking whole gd.
You might be able to gain something with a different thread for disk I/O,
but not always. Even if you have something like:
write_file (file, "string");
call_other (foo, "xxx");
the call_other might need to wait till the write_file is finished,
after all, foo might not be loaded and (part of) its code is in file.
Abigail
Petri Virkkula
>>>>> "Abigail" == Abigail <abi...@fnx.com> writes:
Abigail> If you have concurrent threads for heart_beat/call_outs and player
Abigail> input, you have the same problems as running two concurrent threads
Abigail> for player input. To get back to the example of a player entering
Abigail> a door which is being closed by another thread, it really doesn't
Abigail> matter whether the door is closed by a different player, an NPC driven
Abigail> by its heart_beat, or a call_out.
Perhaps I wasn't clear enough. I tried to say that there is
only ONE thread doing evaluation. The thread takes
object/function pairs from a queue (ie. it is a consumer). Then
there would be MULTIPLE threads producing those
object/function pairs into the queue. There would not be
problems you describe in above paragraph as there is NOT
multiple threads doing evaluation.
Abigail> You might be able to gain something with a different thread
Abigail> for disk I/O, but not always. Even if you have something like:
I was not suggesting different thread for disk I/O. I was
suggesting that if there is multiple threads, when a thread
(probably the evaluation thread or compiler thread) is
blocked, others can do their job: player handling thread can
divide input into lines and find function to be called (if
add_actions are used), etc.
Petri
Jukka V Heinonen
In article <E90uF...@nonexistent.com>, Kris Van Hees wrote:
<< lots of snipping - hate it when people quote whole articles :) >>
>In more low level sense this can be accomplished using an exception
>mechanism, which would interrupt the movement thread if the state of the
>door changes (and then the appropriate exception handling should take
>care of any user interaction). As such, moving through the door doesn't
>mean that the door is not allowed to close (locking the door state), but
>rather that movement can only succeed if the door remains open for the
>entire time of the movement.
>
>Most problems of this kind can be refined towards an exception model
>rather than the less correct locking strategy.
>Whether one can hide concurrency from the end developer is still to be
>seen, and seems to be the major issue in this thread (except for the mud
>slinging and name calling). I happen to be one of the people who believe
>that *up to a reasonable point* concurrency issues can be hidden from the
>end developer, and furthermore that most if not all can be handled in a
>fairly simplified way.
I have been toying with the following architecture for a mud.
It should both be a (kind of) example of the exception model and it should
be able to hide the concurrency issues (to some extend).
Every object belongs to a single node. A single node might
for example have a few rooms and all their contents etc.
Every node then has a single thread to process all the events that
happen inside it and all external events that it receives from other nodes.
Then we just define that if two objects belong to the same node they
can call the methods in each other in a standard way. If they don't belong
to the same node they can only send asynchronous events to each other.
(That is, sending an event doesn't freeze the sending thread. This also means
the reply will be like any other external events and not like a method
return value.)
This way we would never need to do any synchronization in the object code
and the threads would never have to wait for each other.
(Actually the global event passing system needs to do some synchronization.)
The door example might however cause some trouble but it could be solved
with rather unelegant solution:
Player A is in node X and closes a door.
Player B is in node Y and moves through the door to node X.
The door object is in room X and Y has only a proxy object that
routes the events to the real object.
Node Y executes the move event.
Door proxy removes B from Y and sends asynchronous event to the real door.
Node X executes the close event.
A closes the door. Since the door is not proxy object it is closed immediately.
(Asynchronous event is sent to the door proxy.)
Node X executes the external event (the move event).
Since the door is closed a reply event is sent to the door proxy.
Node Y executes the external event (the reply event).
Player B is returned to the node Y and will be notified that the
door was closed just as he was trying to move through it.
If the system has any flaws in it I would be happy to know :)
Nice thing about the above system is that it would be quite easy
to make it into a distributed system - you just divide the nodes between
different servers... (I do believe that getting a cluster of fast PCs with
Linux is much cheaper than getting a single fast server with
commercial OS).
- Jukka (\V/) Heinonen
Nathan F. Yospe
jvhe...@rock.helsinki.fi (Jukka V Heinonen) wrote:
:I have been toying with the following architecture for a mud.
:It should both be a (kind of) example of the exception model and it should
:be able to hide the concurrency issues (to some extend).
<Description of system snipped - it was well thought out, so if you
missed it, track it down in deja news.>
I suspect the end result of this is similar to my system, save that my
entire system is based on asynchronous message passing (but threads are
centered in a location, as in your system) with any message passed
within a locality being resolved instantly. (optimized out, actually, in
compilation and later process compression) The reasoning of this was
originally a dislike for the placement of an object in a player's
inventory by another player, but the fact that I had used this as my
original precept led to me being confused by part of the dragon's
dinner concept, as I was almost certain that the thread that checked
to move the player through the door from the next room (from the same
room is utterly impossible) could not split execution with the second
part of the check, the movement itself. In other words, if the door
is closed as a player passes through, the player will bounce off the
outside of the door, or beat the closing inside the next room. The
only catch here is that for a moment, the player does not exist as an
active processable object, as it is in the message handler instead of
in either room. That didn't sound very clear. If I am confusing, let
me know, and I will try to sxplain more clearly.
Kris Van Hees
On 24 Apr at 19:09:49, Tim Hollebeek wrote <5job62$gmc$5...@cnn.princeton.edu> which contained:
>
> In article <ndfg1wm...@arioch.tky.hut.fi>, Petri Virkkula <pvir...@iki.fi> writes:
>>
>> I would make the gd internally multi threaded: multiple
>> compiler threads, a thread for hname/addr_server, threads for
>> player input/output handling, but only one thread for
>> evaluation of LPC code. That would be simplest way (easiest
>> way to make bugfree code) to support multiple threads.
>
> Hmm, deja vu; there was just a thread about this on lpc-language. I
> agree this is the only real solution (and that Abigail's opinion that
> adding mt support is "easy; just use semaphores" is rubbish); the
It may be the only solution in your opinion, but not everyone will share
that opinion, believe me. So it's not the only real solution, merely a
matter of avoiding the problem altogether. Then agsin, of course you are
aware of that (with your experience), and you even write:
> problem is that this solution doesn't help much, since a well-tuned gd
> spends the vast majority (~99%) of its time evaluating LPC code
> (because the overhead due to the rest of the work that needs to be
> done approaches zero).
Which indeed might lead to the conclusion that concurrency is not a viable
thing for MUD drivers. I choose to disagree though. It may not be an
option for existing drivers, because of the enormous complexity to rework
the driver into one which supports concurrency (often needing LPC language
changes). But what's against writing a whole new driver which in fact does
support concurrency? Again this would have to be at the LPC execution level,
and not separation of IO and LPC execution etc, since it still remains a
valid argument that most of the time is spent evaluating LPC code.
Aedil
Chris Lawrence (Contra)
Jukka V Heinonen (jvhe...@rock.helsinki.fi) wrote:
: Every object belongs to a single node. A single node might
: for example have a few rooms and all their contents etc.
: Every node then has a single thread to process all the events that
: happen inside it and all external events that it receives from other nodes.
Ouch. There are few OS designs about which will be happy with processes
containing multi-hundreds if not thousands of threads.
George Reese
I don't disagree with anything you said. In fact, I agree 100%. The
thread was started as a discussion of the future of muds and evolved
into (Nathan, I believe?) suggesting that muds lack the ability to do
true event processing because of a lack of multi-threading.
I guess what I am specifically getting at in my posts is that I simply
see no benefit to multi-threaded event handling.
Jon A. Lambert wrote:
>
> George Reese <bo...@imaginary.com> wrote in article <5k31jm$eer$1...@darla.visi.com>...
> >
> > Let's say, however, that you have a system worked out for doing good
> > threading and you implement it. You only really stand to gain
> > something if you are on a multi-CPU machine. As Beek pointed out,
> > very little of a mud is spent in an I/O blocked state. With CPU
> > intensive tasks, most of which mud event processing is, threading a
> > bunch of the events does not accomplish much of anything except make
> > non-deterministic or difficult to determine the order in which those
> > events occur. They all still take the same amount of time to complete.
> >
> One benefit is in implementing truly persistent objects. Muds currently spend
> little time in I/O because disk access has largely been avoided in favor of
> memory because of its speed. One fallout of this is that many servers don't save
> enough game information or save it at irregular intervals that at reboot
> things don't usually begin quite where they left off. The saving of the entire
> game state at once could block all activity until it completes. Some servers
> are also scaleable only to the point where memory limits are reached.
> Imagine for instance more complex object states involving macro-events like
> economies, politics and war. If a server crashes or reboots then all of this
> stuff tends to roll back to the last saved state as if none of it ever happened.
> The extreme cases being a stock DIKU where no game state is saved except
> for that of the player and their inventory and the closest other extreme that I
> know of being the Cold driver where the entire state of system is saved at
> shutdown or when a backup is performed.
> Having a thread(s) running at a low priority in the background maintaining
> a persistent storage system may be a good alternative to those who believe
> the current game state is real important.
>
> Another potential benefit is the ability to process very long running transactions
> without blocking the rest of the mud activity. Sure this can be accomplished
> using a software time-splicing system for running tasks like some MOOs, but
> it might be also accomplished through multi-threading.
> I can see some forms of complex Mob AI running as background tasks, like an implementation of Ractor or perhaps a thread that runs
> that attempts to analyze
> the entire economic system, analyze the availability of goods and update all
> of the prices throughout the mud. Its a low priority task that shouldn't interrupt
> normal mud play.
>
> While the CPU time necessary to accomplish a trivial action like 'move north'
> is longer, the user response time would be less than if you had single-threaded
> the long running tasks I describe above in addition to more frequent disk I/O.
>
> As far as event processing is concerned, I don't think multi-threading is
> a prerequisite for event driven systems. These have been around
> for many, many years before multi-threading was an option. I think the
> reverse is probably more true. Once you are multi-threaded, an event
> driven simulation becomes a much more attractive implementation.
>
> JL