Need interesting threads (shade-free)
Brad
> I'm sick of looking at the threads here and trying to work out which ones
> I can safely click on without seeing a post by Shade. Add to that the
I agree...
> Heres some things that interest me:
> - Pure (almost) 3D based coordinate systems for text based muds.
> (there are many things that come under this I would like to discuss)
I've seen a lot of discussions on 3d systems in mud-dev, but I've never
really seen a way to have an interface that wasn't awkward. I think
something along the lines of the Skotos proximity system is better (as it
appeared in Imagined Realities). Unless you mean 3d ansi graphics, which
has been done in door games before and wouldn't really translate over to
muds very well (a lot of the ansi escape sequences used wouldn't be handled
correctly by most clients).
> - Division of game into user and body objects and how this affects
> things like social elements on the different levels.
I'm not sure what you mean by this. My mud does seperate the user,
encompassing the networking aspects and other non-game related elements,
from the game representation. You log on, and you become bound to an
object. Theoretically any object, so you could conceivably play anything
that is represented by an object. Since everything is represented by
objects, you could be a zone, actor, prop, scene, population list, etc (or
in other words, area, player/npc, item, room, resets sort of). It is kind
of pointless to play something like that, but it is also an important part
of the command parser/scripting system.
> - What makes the perfect area creator.
I don't know, but I do think that builders need to be given more
compensation for their work. I don't think imps should expect builders to
put their effort and creativity into something for nothing, and some do.
The reward doesn't have to be money, it could also be fame, promotions, ic
rewards, or partial ownership of the mud. The latter really appeals to me,
because the mud does partly belong to those who have contributed. You don't
give anything away really, but you do formalize things and offer a pledge
that the mud and the builder's hard work will not simply vanish one day.
> - Community project to create a medieval resource for muds who
> believe a theme is important and needs to be believable.
A list of facts would be nice... for instance, in medieval times, chairs
were uncommon and used mostly by royalty. Just a small thing, but I've
never seen chairs put in the proper places in muds. Another thing I was
toying around with, was a filter that would convert American words and
common phrases into their Old English counterparts.
- Brad
Myles L Skinner
Brad <br...@invalid.nospam.com> wrote:
>
> Another thing I was toying around with, was a filter that would convert
> American words and common phrases into their Old English counterparts.
And then you just have to teach all of your players to read Old English, a
language which looks almost nothing like its modern counterpart...
sg
--
Covenant MUD: "Our Silent Supporters Can Beat Up Your Silent Supporters!"
telnet://quandary.mudservices.com:1685
http://www.quandary.mudservices.com
Azi
>"Brad" <br...@invalid.nospam.com> wrote in message
>news:<4Pv85.461$06....@news-west.usenetserver.com>...
>> "Richard" <rm...@hotmail.com> wrote:
<snipped>
>> > - What makes the perfect area creator.
>>
>> I don't know, but I do think that builders need to be given
more
>> compensation for their work. I don't think imps should
expect builders to
>> put their effort and creativity into something for nothing,
and some do.
>> The reward doesn't have to be money, it could also be fame,
promotions, ic
>> rewards, or partial ownership of the mud. The latter really
appeals to
>me,
>> because the mud does partly belong to those who have
contributed. You
>don't
>> give anything away really, but you do formalize things and
offer a pledge
>> that the mud and the builder's hard work will not simply
vanish one day.
>
>This is all very nice from a builders point of view, but from a
mud
>administrators point of view, I can only say f*ck off :)
>
>If someone contributed quality areas to the mud, and stuck
around and put
>as much effort into it as I have. Then I would be more than
willing to
>offer
>partial ownership - and I have in the past given partial
ownership.
>Although
>my co-owners have as much as retired. In fact, thats kind of
how I acquired
>my mud, when I started I was only an area creator but due to
the fact I was
>the only real active mudlib coder, I eventually acquired the
mud through
>circumstances.
>
>I think if it had been the case that the partial ownership was
dangled
>as a carrot from ground zero, amidst all the squabbling (that
would have
>been
>in addition to the petty squabbling that goes on normally in
muds) about
>who deserves pieces of the mud, I would have lost interest in
doing what I
>did. Inheriting without it being a carrot, gave it more value
to me.
>
>What my point is, is that I think to make a decent mud, the
foremost reward
>for a creator should be that they are happy with the work they
are doing
>and are content to continue doing it. If the administrator is
a good person
>to work for, and conversely, if the work being done is
considered valuable
>to the administrator then, by all means, the administrator is
going to want
>to reward the player. But in my experience, 99% of area
creators are
>chaff who should regularily be weeded. The good ones are few
and far
>between.
>
You fogot as can be the good admins...the creation of a good mud
is a co-operative effort between coders, builders and admins. No
one or the other is most important. Neither one or the other are
generally better or worse. They all have the same chance of
being useless, regardless of their title/position on the mud.
As for ownership, that is a bit extreme. Perhaps the one mistake
new Admins make is not setting out definate parameters for
builders to work and grow within. Nothing makes a disgruntled
builder faster then "Well, you're 500 room area is nice,
MrDeath, but we are strictly a medievil mud and the Pokemon
theme just doesn't fit". (Silly example but point is made, I
think).
Motivations vary from builder to builder and asking what makes a
good one is kind of like asking what makes a flower
pretty...there isn't one answer that everyone will form a
consensus on, too many variables.
What I think makes a good builder is someone who has the ability
to build a bit of humor into their areas. Someone who will put
in extra descriptions for everything, no matter how small.
Someone who does it just to hear players talk about how cool
their area is. Those, of course, are hard to find in your
everyday, run of the mill builder, I would take 2 out of 3
though.
Okay, rambled enough...
Azi
<more snipped>
>Anyway, that will do for now.
>Donky@Nameless Sorrows
-----------------------------------------------------------
Got questions? Get answers over the phone at Keen.com.
Up to 100 minutes free!
http://www.keen.com
H. McDaniel
> >to reward the player. But in my experience, 99% of area
> creators are
> >chaff who should regularily be weeded. The good ones are few
I've found that 90% of volunteers are going to do little to
nothing.
> You fogot as can be the good admins...the creation of a good mud
> is a co-operative effort between coders, builders and admins. No
> one or the other is most important. Neither one or the other are
> generally better or worse. They all have the same chance of
> being useless, regardless of their title/position on the mud.
The difference is that when a mud is intially being built one individual
(or a very small number of people) control who can work on the game.
These administrative gate keepers are more responsible for the
outcome on that basis alone. Also as you noted elsewhere in your post
it's important for an admin to lay down paramaters for the builders to
work in and to set goals or rewards. It's also important (IMO) for the
admin to be an expert in one or many areas of the game... not to mention
overall game design and other mystical stuff. These things make an
admin hundreds of times more important than your average builder.
Also... I don't know about others but I pick people for administrative
positions much more selectively than for general building positions.
In fact... only once have I ever promoted someone to admin without
taking a *long* time to get to know their working style and whether
we would make a good team. That turned out to be a disaster as the
guy attempted to take over the mud (by coding some special powers
for himself.) So... in my experience admin working on my projects are
not just as likely to be useless compared to other builders.
-McDaniel
Richard
I can safely click on without seeing a post by Shade. Add to that the
Has anyone got any thing that interests them that they want to discuss?
Do not bother replying unless you are prepared to ignore all posts by
Shade in the thread (or posts referring to Shade).
Heres some things that interest me:
- Pure (almost) 3D based coordinate systems for text based muds.
(there are many things that come under this I would like to discuss)
- Division of game into user and body objects and how this affects
things like social elements on the different levels.
- What makes the perfect area creator.
- Community project to create a medieval resource for muds who
believe a theme is important and needs to be believable.
Donky@Nameless Sorrows
Richard
news:<4Pv85.461$06....@news-west.usenetserver.com>...
> "Richard" <rm...@hotmail.com> wrote:
> > - Pure (almost) 3D based coordinate systems for text based muds.
> > (there are many things that come under this I would like to discuss)
>
> really seen a way to have an interface that wasn't awkward. I think
> something along the lines of the Skotos proximity system is better (as it
> appeared in Imagined Realities). Unless you mean 3d ansi graphics, which
> has been done in door games before and wouldn't really translate over to
> muds very well (a lot of the ansi escape sequences used wouldn't be
handled
> correctly by most clients).
Have you read my article in the latest issue of Imaginary Realities?
The Skotos proximity system is nice, but it adds value to the game in
other areas than our 3D coordinate system. I read Mud-Dev, but most of
the discussion seems to be more philisophical ramblings than the type
of things I like to read about.
> > - Division of game into user and body objects and how this affects
> > things like social elements on the different levels.
>
> I'm not sure what you mean by this. My mud does seperate the user,
> encompassing the networking aspects and other non-game related elements,
> from the game representation. You log on, and you become bound to an
> object. Theoretically any object, so you could conceivably play anything
> that is represented by an object. Since everything is represented by
> objects, you could be a zone, actor, prop, scene, population list, etc (or
> in other words, area, player/npc, item, room, resets sort of). It is kind
> of pointless to play something like that, but it is also an important part
> of the command parser/scripting system.
I kind of based how my mudlib works on the Lima mudlib in this regard.
The user object handles the connection and represents the user being
logged into the mud. They see other users in the game in a who command.
They can tell things to other users.
The body object handles the players representation in the actual game.
It has a location in the game world, etc. It cannot see on the user level.
The user object controls the body object.
So, if you have social commands (smile, laugh, etc) on a body level that
work in theme and in game, then how do you do the same social commands on
the user level. Its kind of an ugly situation that arises out of what
seems to be an elegant division of functionality.
Maybe its not an issue to anyone else, but it looks like I am going to
have two sets of social commands. I guess it solves the problems I have
with having out of theme social commands in the body set, because they
can all with no qualms be put in the user set. However, two sets are
kind of confusing.
> > - What makes the perfect area creator.
>
to reward the player. But in my experience, 99% of area creators are
chaff who should regularily be weeded. The good ones are few and far
between.
> > - Community project to create a medieval resource for muds who
> > believe a theme is important and needs to be believable.
>
> A list of facts would be nice... for instance, in medieval times, chairs
> were uncommon and used mostly by royalty. Just a small thing, but I've
> never seen chairs put in the proper places in muds. Another thing I was
> toying around with, was a filter that would convert American words and
> common phrases into their Old English counterparts.
Thats something I certainly didn't know.
In any case, the resource would have to be based around a certain date to
keep it all consistent - or at the least allow restricting of the knowledge
base to time periods relevant to the browsers interest.
The kind of things that would interest me in it, would be how things were
made and what they were made out of and what they looked like. Also how
things were done. This is what I need to know for my player professions.
tel...@xenon.triode.net.au
> I'm sick of looking at the threads here and trying to work out which ones
> I can safely click on without seeing a post by Shade. Add to that the
> fact that theres nothing of interest to me being discussed here anyway.
Possibly the lack of interesting discussion was the original problem,
creating a ``discussion vacuum'' that sweeps in a lot of irrelevant postings.
Anyone who hangs around on IRC would understand the ``discussion vacuum''
problem -- people will say any stupid thing just to be saying something.
This is part and parcel with being a social animal.
> Has anyone got any thing that interests them that they want to discuss?
Yeah, lots but most of them have come up various times before and
actual progress in these areas is a lot slower than the rate of ideas
and suggestions for things that would be cool if only we could do them.
> - Pure (almost) 3D based coordinate systems for text based muds.
> (there are many things that come under this I would like to discuss)
This has been a long term interest of mine. You can check out my
2D coordinate based maps by downloading the code at:
http://www.triode.net.au/~telford/mud/msm.html
There are some demo maps presented as PNG files too, all of them
generated by the software provided, some of them are hideously complex
to walk around inside, even when using the ASCII map generator to help
you figure out where you are.
A different but still interesting 2D mapping engine is contained in
my 16k MUD competition entry, follow the link off:
http://www.triode.net.au/~telford/mud/codebase.html
Both of these techniques could be extended to 3D without a great deal
of pain but my own reflections on the matter have concluded that using
a bunch of 2D layers is better than true 3D both from the coding point
of view and to simplify the area building and to make it easier for
players to understand. I would say that the ideal would be something like:
[+3] -- sky level: flying carpet territory
[+2] -- top level: roof of house, top of tall tree
[+1] -- upper level: top story of house, climbing tree, castle battlement
[0] -- ground level: walking, riding, streets, roads, market, etc
[-1] -- dungeon 1: basement, small tunnels, sewer, hobit holes
[-2] -- dungeon 2: deeper tunnels, natural caves, most lairs
[-3] -- dungeon 3: really deep tunnels, lairs of nasty things, dwarf mines
[-4] -- dungeon 4: seriously deep, close to centre of earth, even dwarfs
wouldn't go this far, have we made it to hell yet?
Then just use 2D mapping for each layer and don't worry too much that
it is only pseudo-3D. Possibly support inclines within each layer so
that [0] can slope up and down as required by terrain (then [1] and [2]
will naturally incline along with [0]).
If anyone is out there playing with real 3D, I have a spatial database
engine that can find objects inside or intersecting and arbitrary 3D
block (i.e. every object is bounded by a lowest point and a highest
point making a 3D block that contains the object). It _should_ be faster
than a linear search and neater than splay trees and octrees because
it uses a hashtable combined with a virtual tree search. You can delete
and insert objects without needing to rebuild the structure of the database
and all queries only search that region of the database which is local
to the query region. Storage is sparse from a logarithmic point of view
(i.e. same storage requirements as any subdividing tree).
So if you want the code for that, you should get in touch with me.
It still has a lot of rough edges but handles most queries. The hastable
speed is still poor because it needs tuning and a better hashing algorithm
(something I know how to do but just haven't got a round tuit).
I've also been meaning to write up the algorithm properly because I
believe it is fairly unique.
All my code is GPL by the way...
- Tel
Richard
news:8ju8rs$l09$1...@hyperion.triode.net.au...
> Richard <rm...@hotmail.com> wrote:
> This has been a long term interest of mine. You can check out my
> 2D coordinate based maps by downloading the code at:
I have to go home so this is going to be short for now.
The problem that I have with your code is that it is too theoretical for me.
I like the end results and to have to get my fingers dirty with polygons is
distasteful. Thats kind of what I like about LPC. Its an abstract language
compared to C (IMO, and I am not an expert) and allows for me to
easily implement complicated concepts in an abstract way.
I would rather discuss the abstract concepts, problems or whatever to
do with 3D coordinate systems than dig through someones C code.
In any case, I will followup your post properly tomorrow.
Donky@Nameless Sorrows.
Richard
news:07474e15...@usw-ex0105-040.remarq.com...
> "Richard" <rm...@hotmail.com> wrote:
> >"Brad" <br...@invalid.nospam.com> wrote in message
> >news:<4Pv85.461$06....@news-west.usenetserver.com>...
> >> "Richard" <rm...@hotmail.com> wrote:
> >to reward the player. But in my experience, 99% of area
> creators are
> >chaff who should regularily be weeded. The good ones are few
> and far
> >between.
> >
>
> is a co-operative effort between coders, builders and admins. No
> one or the other is most important. Neither one or the other are
> generally better or worse. They all have the same chance of
> being useless, regardless of their title/position on the mud.
Good point. As with everything else, its all relative. Whether your
administrator is good depends on what your idea of a theme and
mud is. Whether you consider a builder on your mud to code to the
standard of the mud depends on whether they share your goals
and standards. Etc.
And as an administrator I have to say its very hard to define your
vision so that area creators may clearly grasp it. I guess a good
area creator by my definition is one who can pick up my vision and
create areas that are believable within it. A strictly bad creator is
one that just can't grasp that an area has to be believable.
Along those lines, perhaps the perfect creator is one who can
create those believable areas but has a good grasp of the detail
that fits within that theme and good descriptive abilities and
also good writing and gramatical skills. Really, its not much to
ask :) Needless to say, we only ever had one creator who
matched those criteria...
But I disagree, the administrator is more important by definition.
Not because he is above the creators, but because its his vision
which has to be followed and his standards which have to be met.
If he doesn't work on sharing his vision with the creators so that
they can see it or enforce that their work is up to that standard,
then the chance that it is a good mud is significantly lower. Also,
whether the builders are interested or capable of sharing his
vision or meeting his standards is a factor. If the administrator
does not provide an environment a creator wishes to be in, then
the creator should not be there in the first place. Before they
invest their time and effort, they should make sure its worth it.
Oh, and I would say 99% of administrators are chaff as well.
What with muds not taking that much nounce to start, it goes
without saying that theres a lot of lamers out there who start
it because of the ego boost administrating gives rather than
because of the goal of creating a good mud itself.
I wonder if there are any guidelines out there that set out
what makes a good mud for a builder (not the abstract
description of mine), steps that a builder can use to determine
if a mud and its administrator is in their best interests to
get involved with. Although if there was, whether they
would find it before creating there is another matter.
And on the other side of the coin, a set of steps defining
how to work out whether a new builder has what it takes
to meet an administrators muster.
Heh :) I guess thats enough for now.
Donky@Nameless Sorrows
Brad
> "Brad" <br...@invalid.nospam.com> wrote:
> > "Richard" <rm...@hotmail.com> wrote:
<snip>
> > I've seen a lot of discussions on 3d systems in mud-dev, but I've never
> > really seen a way to have an interface that wasn't awkward. I think
> > something along the lines of the Skotos proximity system is better (as
it
> > appeared in Imagined Realities). Unless you mean 3d ansi graphics,
which
> > has been done in door games before and wouldn't really translate over to
> > muds very well (a lot of the ansi escape sequences used wouldn't be
> handled
> > correctly by most clients).
>
> Have you read my article in the latest issue of Imaginary Realities?
Room for Improvement? If that is the one, I have only glanced over it.
I'll try to read it over more in depth when I get the chance.
My own take on the whole area design is to use fuzzy coordinates--my own
spur-of-the-moment term for it. My theory goes that since 3d games can
fudge a bit with the dimensions since they must ultimately be displayed as
2d, then you can get away with a lot more with text and still give the
illusion of a realistic environment. I'm throwing realism out the window
for a clever way of faking it :-).
<snip>
> So, if you have social commands (smile, laugh, etc) on a body level that
> work in theme and in game, then how do you do the same social commands on
> the user level. Its kind of an ugly situation that arises out of what
> seems to be an elegant division of functionality.
Just an idea, but why not force the user to either be ic or ooc. If the
user is controlling a character, he can only do things on a body level, and
if he is not he may only do things on a user level.
> > > - What makes the perfect area creator.
> >
> > The reward doesn't have to be money, it could also be fame, promotions,
ic
> > rewards, or partial ownership of the mud. The latter really appeals to
> me,
> > because the mud does partly belong to those who have contributed. You
> don't
> > give anything away really, but you do formalize things and offer a
pledge
> > that the mud and the builder's hard work will not simply vanish one day.
>
> This is all very nice from a builders point of view, but from a mud
> administrators point of view, I can only say f*ck off :)
I'm more a coder than an admin, and an admin more than a builder. I'm more
of a drugged-out gonzo journalist than a builder, come to think of it, which
doesn't make me much of a builder. Well, the point is, just to say that
those weren't the words of a builder really. Just my own $.02.
<snip>
> I think if it had been the case that the partial ownership was dangled
> as a carrot from ground zero, amidst all the squabbling (that would have
> been
> in addition to the petty squabbling that goes on normally in muds) about
> who deserves pieces of the mud, I would have lost interest in doing what I
> did. Inheriting without it being a carrot, gave it more value to me.
I didn't mean it to be a carrot-and-stick routine, or even that equal
ownership should be offered. My idea of actually implementing something
like this would be to have a heirarchy of people who would inherit the mud
if it were to be abandoned by the current owners. The incentive wasn't
really so much that you would own the mud, or even hope to own it some day,
although I can see how that could happen, but rather that you would know
that your hard work would not be easy to lose.
> > A list of facts would be nice... for instance, in medieval times, chairs
> > were uncommon and used mostly by royalty. Just a small thing, but I've
> > never seen chairs put in the proper places in muds. Another thing I was
> > toying around with, was a filter that would convert American words and
> > common phrases into their Old English counterparts.
<snip>
> In any case, the resource would have to be based around a certain date to
> keep it all consistent - or at the least allow restricting of the
knowledge
> base to time periods relevant to the browsers interest.
So if MSIE 4.0 was interested in the 12th century, and Netscape was
interested in... okay, bad joke, nevermind.
- Brad
Azi
>Azi wrote:
>
>> >to reward the player. But in my experience, 99% of area
>> creators are
>> >chaff who should regularily be weeded. The good ones are few
>
>nothing.
>
mud
>> is a co-operative effort between coders, builders and admins.
No
>> one or the other is most important. Neither one or the other
are
>> generally better or worse. They all have the same chance of
>> being useless, regardless of their title/position on the mud.
>
individual
>(or a very small number of people) control who can work on the
game.
>These administrative gate keepers are more responsible for the
>outcome on that basis alone.
I think you misunderstood, what I was pointing out was that it
is silly to assume that, on a mud, the builders are the ones
that are going to be lazy and useless. From personal experience
with a few muds not yet opened, it was the Admin/Wiz/Imp that
were lazy. The ones who flip-flopped on ideas and couldn't
decide from one day to the next who was going to code, build or
even be allowed to log on. Unfortunately, now, the flakey admins
are just as common as flakey builders and coders.
Than your average build 10 rooms a year builder, you're right.
However, this was how to get good builders (and keep 'em).
Honestly, if you really want to know the answer to that it is
simple, respect. Respect for the amount of research we put into
areas, respect for the amount of time and effort we give freely
and respect for being damn good at what we do. Not everyone is
cut out for building and not everyone is expecting to be up
until 2am researching arches which is why I think the "useless"
attitude is perpetuated. Funny, though, that attitude turns away
the exact people Admins are screaming for. Why would I, as a
builder, want to work for an admin that doesn't think I'm really
all that important to the success of his mud? Why would I bother
spending hours at the library doing research or agonize over
wording and room placement if the admin thinks I'm useless? It's
simple, unless I was a complete idiot, I wouldn't and I don't.
I don't mean this as a flame but I suppose it came out that way
regardless. Perhaps it is as it should be, though. It seems from
reading here and tmc that there is now and always will be a
great big rift between builders and the admin staff. Makes you
wonder why any of us "average builders" do it at all.
Azi
tel...@xenon.triode.net.au
> My own take on the whole area design is to use fuzzy coordinates--my own
> spur-of-the-moment term for it. My theory goes that since 3d games can
> fudge a bit with the dimensions since they must ultimately be displayed as
> 2d, then you can get away with a lot more with text and still give the
> illusion of a realistic environment. I'm throwing realism out the window
> for a clever way of faking it :-).
Not at all a bad idea. Got any sample code or any details of the algorithm?
I have some experience with fuzzy logic so I can see that a person might
be walking from room 1 to room 2 and instead of jumping between them instantly,
they might go through some transitional phase where they are p% in room 1 and
( 100 - p )% in room 2 (as x slowly counts down from 100 to 0). If room 1
has the coordinates [ x1 y1 z1] and room 2 has the coordinates [ x2 y2 z2 ]
then a person between the two rooms will have coordinates of
( p / 100 )[ x1 y1 z1 ] + (( 100 - p ) / 100 )[ x2 y2 z2 ]
which puts them on the line from room 1 to room 2.
Hmmm, might give this a bit of a stab when I get time.
Unfortunately, it does require construction and storage of the mesh of links
between rooms... fortunately that can be done automatically given that the
coordinates of each room is known... unfortunately the construction process
will be slow... fortunately it only has to be done when rooms are modified
which is not often... hmmm still looks reasonable.
> <snip>
>> So, if you have social commands (smile, laugh, etc) on a body level that
>> work in theme and in game, then how do you do the same social commands on
>> the user level. Its kind of an ugly situation that arises out of what
>> seems to be an elegant division of functionality.
> Just an idea, but why not force the user to either be ic or ooc. If the
> user is controlling a character, he can only do things on a body level, and
> if he is not he may only do things on a user level.
Yeah, I was thinking the same but then you can only do emotes which are
pre-programmed which is going to piss off anyone creative. I guess you can
have a method for getting personalised emotes approved but that is going
to kill the spontaneous action.
- Tel
tel...@xenon.triode.net.au
If you want some sort of packaging then sketch out an API that would
suit you and I'll try to knock it together into a library that you can
treat as a black-box and plug onto what you are already using
Actually it sort of already is supposed to work like a bolt-on library
but I guess that I have written so much C and reverse engineered so many
C libraries that I tend to take the presumption that anyone who uses it
is going to bend it around to suit their tastes so my packaging is sort of
``open ended''. I can put together something more encapsulated if that
makes you more comfortable.
I agree with you that the abstract concepts need high level documentation.
The API needs documentation too, read the header files and look at the
way the walk.c program works (that program was deliberately very simple).
I wrote one article for Imaginary Realities
http://imaginaryrealities.imaginary.com/volume2/issue1/map_article.html
but that only briefly covers the concepts, a lot of undocumented water
has gone under the bridge since then. I have a half-written LaTeX document
that covers some of it and will soon cover the rest. Hopefully I can
include enough applications that it makes a useful contribution to
my PhD thesis (which happens to be about magnets but the logic is something
like magnetic fields -> finite element method -> discretisation of
spacial geometry -> spacial database -> map systems. All good mathematical
fun to boot!
By the way, did you get the ASCII maps working as you walk around?
That was the bit I enjoyed doing the most.
- Tel
H. McDaniel
> even be allowed to log on. Unfortunately, now, the flakey admins
> are just as common as flakey builders and coders.
Ah. I can't disagree with that (not that I've done a survey.)
[How to keep good builders...]
> Honestly, if you really want to know the answer to that it is
> simple, respect. Respect for the amount of research we put into
> areas, respect for the amount of time and effort we give freely
> and respect for being damn good at what we do. Not everyone is
> cut out for building and not everyone is expecting to be up
> until 2am researching arches which is why I think the "useless"
Hmm. I think this boils down to control? In other words, how much
freedom does the admin give the builder (within whatever overall
thematic framework the mud has of course.) If by respect you also
mean Admin shouldn't say things like, "hey dufus, you couldn't
code your way out of a wet paper bag with a zipper" I agree.
> attitude is perpetuated. Funny, though, that attitude turns away
> the exact people Admins are screaming for. Why would I, as a
> builder, want to work for an admin that doesn't think I'm really
> all that important to the success of his mud? Why would I bother
> spending hours at the library doing research or agonize over
> wording and room placement if the admin thinks I'm useless? It's
> simple, unless I was a complete idiot, I wouldn't and I don't.
As an admin I don't really want all of the volunteers or potential
builders out there. Just a select few. 2 or 3 dedicated builders
are worth 100s of the sort that just log on to chat and watch the
virtual grass grow. And when I know that you are dedicated you'll
know that I really, really value your contribution. Plus I'll
promote you. Not because I hand out titles like candy at the
Dentist's office but because you earned it.
> I don't mean this as a flame but I suppose it came out that way
> regardless.
No problem.
> Perhaps it is as it should be, though. It seems from
> reading here and tmc that there is now and always will be a
> great big rift between builders and the admin staff. Makes you
> wonder why any of us "average builders" do it at all.
I wouldn't lose sleep over it at night. In the end all we have
(hopefully) is a personal relationship between an admin and a builder.
What happens on other games you aren't directly involved in shouldn't
really matter as far as this issue goes.
-McDaniel
rr...@lanminds.com
wrote:
>I wonder if there are any guidelines out there that set out
>what makes a good mud for a builder (not the abstract
>description of mine), steps that a builder can use to determine
>if a mud and its administrator is in their best interests to
>get involved with. Although if there was, whether they
>would find it before creating there is another matter.
>
I would think that these would be the same guidelines that the players
use to pick a mud to play on. Which, of course, vary widely among
players. After all, why build for a mud if you hate playing there?
>And on the other side of the coin, a set of steps defining
>how to work out whether a new builder has what it takes
>to meet an administrators muster.
>
Well, I would think that most of your builders come from your players.
So it shouldn't be that hard to get to know them and figure out what
they are like.
>Heh :) I guess thats enough for now.
>
>Donky@Nameless Sorrows
>
Kira Skydancer
Peter Register
>However, this was how to get good builders (and keep 'em).
>Honestly, if you really want to know the answer to that it is
>simple, respect. Respect for the amount of research we put into
>areas, respect for the amount of time and effort we give freely
>and respect for being damn good at what we do. Not everyone is
>cut out for building and not everyone is expecting to be up
>until 2am researching arches which is why I think the "useless"
>attitude is perpetuated. Funny, though, that attitude turns away
>the exact people Admins are screaming for. Why would I, as a
>builder, want to work for an admin that doesn't think I'm really
>all that important to the success of his mud? Why would I bother
>spending hours at the library doing research or agonize over
>wording and room placement if the admin thinks I'm useless? It's
>simple, unless I was a complete idiot, I wouldn't and I don't.
>
>I don't mean this as a flame but I suppose it came out that way
>regardless. Perhaps it is as it should be, though. It seems from
>reading here and tmc that there is now and always will be a
>great big rift between builders and the admin staff. Makes you
>wonder why any of us "average builders" do it at all.
>
You are the exception, though. I've worked with a _lot_ of area builders over
the years, and very _very_ few put the time and effort into it as you've
described.
Quality areas are the lifeblood of any mud. Creators who can produce quality
areas deserve all the respect an admin can muster. 95% can't produce it,
though.
A decent chunk of creators can produce an adequate area as long as they are
provided a lot of handholding from the administrative/quality control/balance
staff.
I had a point originally, but its gone now...
-murmur
tel...@xenon.triode.net.au
>> Brad <br...@invalid.nospam.com> wrote:
>> > My own take on the whole area design is to use fuzzy coordinates--my own
>> > spur-of-the-moment term for it. My theory goes that since 3d games can
>> > fudge a bit with the dimensions since they must ultimately be displayed
> as
>> > 2d, then you can get away with a lot more with text and still give the
>> > illusion of a realistic environment. I'm throwing realism out the
> window
>> > for a clever way of faking it :-).
>>
>> Not at all a bad idea. Got any sample code or any details of the
> algorithm?
>>
>> I have some experience with fuzzy logic so I can see that a person might
>> be walking from room 1 to room 2 and instead of jumping between them
> instantly,
>> they might go through some transitional phase where they are p% in room 1
> and
>> ( 100 - p )% in room 2 (as x slowly counts down from 100 to 0). If room 1
>> has the coordinates [ x1 y1 z1] and room 2 has the coordinates [ x2 y2
> z2 ]
>> then a person between the two rooms will have coordinates of
>> ( p / 100 )[ x1 y1 z1 ] + (( 100 - p ) / 100 )[ x2 y2 z2 ]
>> which puts them on the line from room 1 to room 2.
> This is a bit out of my league, but does it take into account rooms which
> have
> differing sizes? Like for instance, in my system, we divide rooms up into
> 1 metre square movement spaces, so the number of movement spaces in the
> room differs depending on the size of the room..
It doesn't really account for room size but you could have a pretty
good guess by looking at the distance between neighboring rooms.
It depends on what you intend to use the movement spaces for...
>> Yeah, I was thinking the same but then you can only do emotes which are
>> pre-programmed which is going to piss off anyone creative. I guess you can
>> have a method for getting personalised emotes approved but that is going
>> to kill the spontaneous action.
> On a user level I am all for allowing the use of emoteto/echoto/emote/echo
> commands for spontaneous action, but on a body level, I will probably be
> giving social comands a rating using a limited system like the skotos
> proximity
> to restrict how they are used.
> I guess we will probably end up with two sets of social commands.
OK, maybe you should make all emotes strictly user level and everything
else body level. Then there is division of function in that emotes contain
arbitrary text and only provide atmosphere while body actions are real
game events.
For example:
emote waves his hand through the laser beam
has no in-game effect other than the reactions of other players
wave hand in front of laser beam
might trigger some in-game response.
- Tel
tel...@xenon.triode.net.au
> discuss how to make it usable by the players sort of person, rather than
> a discuss how it should be implemented.
Oh. I would say the easy answer to that one is you want a text mode
interface to be as natural as possible and support the widest range
of possibilities. For example:
"walk past the big, black stone while keeping it to the left"
As the computer theorest once said, "all the rest is implementation"
However, what you probably really want is an interface that doesn't
do quite everything that it SHOULD do but still does enough to make a
decent game and is simple enough that you are able to implement it.
In which case I think that the basic compass directions are not too
bad even though they are not completely realistic. Also being able
to site landmarks from a distance and get a rough idea of how far they
are away from you and which direction is useful. Finally you should
be able to walk towards a landmark. This would be the minimum features
that I would like.
I also find the system of abstract regions of personal space kind
of strange (e.g. people are at ``near'', ``close'', ``intimate''
proximities) since I prefer using a proper distance in metres.
This is not that I'm trashing the Skotos ideas but I see the first
step as establishing a realistic geometry and then you can overlay
adjectives onto that (rather than try and reconstruct the geometry
from a bunch of adjectives).
>> By the way, did you get the ASCII maps working as you walk around?
> I didn't try it.
> I did save the archive meaning to though :) Maybe I have it on CD
> somewhere,
> will have to see if I have a copy of it at home.
grumble, grumble, grumble.
- Tel
Richard
news:396352a9...@nntp.lanminds.com...
> On Wed, 5 Jul 2000 17:45:34 +1200, "Richard" <rm...@hotmail.com>
> wrote:
>
>
> >I wonder if there are any guidelines out there that set out
> >what makes a good mud for a builder (not the abstract
> >description of mine), steps that a builder can use to determine
> >if a mud and its administrator is in their best interests to
> >get involved with. Although if there was, whether they
> >would find it before creating there is another matter.
> >
> I would think that these would be the same guidelines that the players
> use to pick a mud to play on. Which, of course, vary widely among
> players. After all, why build for a mud if you hate playing there?
Because you don't know better? You haven't been to better places?
> >And on the other side of the coin, a set of steps defining
> >how to work out whether a new builder has what it takes
> >to meet an administrators muster.
> >
> Well, I would think that most of your builders come from your players.
> So it shouldn't be that hard to get to know them and figure out what
> they are like.
You're looking at it from the perspective of an open mud. I spend alot
of time around unopened muds still in development.
Donky.
Richard
> "H. McDaniel" <ha...@DEATH-TO-SPAMMERS.wolfenet.com> wrote:
> >The difference is that when a mud is intially being built one
> individual
> >(or a very small number of people) control who can work on the
> game.
> >These administrative gate keepers are more responsible for the
> >outcome on that basis alone.
>
> I think you misunderstood, what I was pointing out was that it
> is silly to assume that, on a mud, the builders are the ones
> that are going to be lazy and useless. From personal experience
Biased as I am, as a mud administrator, I have to say:
Well, thats really the fault of the builder for choosing the wrong mud.
> with a few muds not yet opened, it was the Admin/Wiz/Imp that
> were lazy. The ones who flip-flopped on ideas and couldn't
> decide from one day to the next who was going to code, build or
> even be allowed to log on. Unfortunately, now, the flakey admins
> are just as common as flakey builders and coders.
Thats neither here nor there. 99% of the muds out there are shite
or more of the same 'nothing special'. Before you invest in something
you should make sure its worth it.
And I don't know how it works in the non-LP mud circle that you work
in, but no admin I ever encountered matchs that description. I think the
worst that I ever saw just had lack of vision and lack of standards
(compared to what I consider a vision and standards).
> >for himself.) So... in my experience admin working on my
> projects are
> >not just as likely to be useless compared to other builders.
> >
> >-McDaniel
> >
> Than your average build 10 rooms a year builder, you're right.
Quality is better than quantity, if I had a creator who coded a
ten room area that met my standards and vision, then I would
pick them anyday over the 2000 room city creator.
I know your point is that of the average creator who does little,
but still.
> However, this was how to get good builders (and keep 'em).
Actually, if you are referring to the thread. I thought it was how
a mud administrator worth his salt gets good builders who can
grasp his vision and meet his standards .. i.e. the perfect area
creator.
> Honestly, if you really want to know the answer to that it is
> simple, respect. Respect for the amount of research we put into
> areas, respect for the amount of time and effort we give freely
> and respect for being damn good at what we do. Not everyone is
Well, the mud administrator worth his salt would give that naturally.
Its to be expected. The real problem is how to find the perfect
creator, if they are out there and they haven't been disillusioned by
working in a bad environment..
> cut out for building and not everyone is expecting to be up
> until 2am researching arches which is why I think the "useless"
Huh?
> attitude is perpetuated. Funny, though, that attitude turns away
> the exact people Admins are screaming for. Why would I, as a
> builder, want to work for an admin that doesn't think I'm really
> all that important to the success of his mud? Why would I bother
> spending hours at the library doing research or agonize over
> wording and room placement if the admin thinks I'm useless? It's
> simple, unless I was a complete idiot, I wouldn't and I don't.
Again, it would be your fault for choosing the wrong mud.
I see this as sort of like me walking into KFC and asking why
they gave me chicken when I wanted a cheeseburger, after I order
a chicken meal.
Donky.
Richard
> > Have you read my article in the latest issue of Imaginary Realities?
>
> I'll try to read it over more in depth when I get the chance.
Any comment good or bad would be great. I have abandoned the idea of a 3D
VRML/web based area creating tool for now though. That was going to be
part two. However, I need to rewrite the coordinate spaces a bit to get
them to
match up to how I thought they worked in the article first (which is about
70%
done) :) And then I probably will do an area designer with a text
interface - I'm
sort of inspired by Jack L Chalkers Soul Rider Sci Fi books for that.
> My own take on the whole area design is to use fuzzy coordinates--my own
> spur-of-the-moment term for it. My theory goes that since 3d games can
> fudge a bit with the dimensions since they must ultimately be displayed as
> 2d, then you can get away with a lot more with text and still give the
> illusion of a realistic environment. I'm throwing realism out the window
> for a clever way of faking it :-).
Fudge a bit with the dimensions in what way? I'm not sure what you mean as
ultimately being displayed as 2D, mapped to fixed size movement spaces
maybe.
> <snip>
> > So, if you have social commands (smile, laugh, etc) on a body level that
> > work in theme and in game, then how do you do the same social commands
on
> > the user level. Its kind of an ugly situation that arises out of what
> > seems to be an elegant division of functionality.
>
> Just an idea, but why not force the user to either be ic or ooc. If the
> user is controlling a character, he can only do things on a body level,
and
> if he is not he may only do things on a user level.
Ick. In the LP world I am used to, being able to be in both at the same
time
is the norm :) And making it otherwise would not seem usable.
> > I think if it had been the case that the partial ownership was dangled
> > as a carrot from ground zero, amidst all the squabbling (that would have
> > been
> > in addition to the petty squabbling that goes on normally in muds) about
> > who deserves pieces of the mud, I would have lost interest in doing what
I
> > did. Inheriting without it being a carrot, gave it more value to me.
>
> I didn't mean it to be a carrot-and-stick routine, or even that equal
> ownership should be offered. My idea of actually implementing something
Neither did I. I guess what I was thinking but perhaps not saying was that
rewards should be earned, not worked towards. If the reward is granted
in response to the quality and value of the work that happens, then that
work
is more likely to be worth the reward than work that is done in the aim of
getting a reward - oh, bugger it, something liek that :)
Donky.
Richard
news:8jv0aq$63e$1...@hyperion.triode.net.au...
> Brad <br...@invalid.nospam.com> wrote:
> > spur-of-the-moment term for it. My theory goes that since 3d games can
> > fudge a bit with the dimensions since they must ultimately be displayed
as
> > 2d, then you can get away with a lot more with text and still give the
> > illusion of a realistic environment. I'm throwing realism out the
window
> > for a clever way of faking it :-).
>
algorithm?
>
> I have some experience with fuzzy logic so I can see that a person might
> be walking from room 1 to room 2 and instead of jumping between them
instantly,
> they might go through some transitional phase where they are p% in room 1
and
> ( 100 - p )% in room 2 (as x slowly counts down from 100 to 0). If room 1
> has the coordinates [ x1 y1 z1] and room 2 has the coordinates [ x2 y2
z2 ]
> then a person between the two rooms will have coordinates of
> ( p / 100 )[ x1 y1 z1 ] + (( 100 - p ) / 100 )[ x2 y2 z2 ]
> which puts them on the line from room 1 to room 2.
This is a bit out of my league, but does it take into account rooms which
have
differing sizes? Like for instance, in my system, we divide rooms up into
1 metre square movement spaces, so the number of movement spaces in the
room differs depending on the size of the room..
> > <snip>
> >> So, if you have social commands (smile, laugh, etc) on a body level
that
> >> work in theme and in game, then how do you do the same social commands
on
> >> the user level. Its kind of an ugly situation that arises out of what
> >> seems to be an elegant division of functionality.
>
> > Just an idea, but why not force the user to either be ic or ooc. If the
> > user is controlling a character, he can only do things on a body level,
and
> > if he is not he may only do things on a user level.
>
> Yeah, I was thinking the same but then you can only do emotes which are
> pre-programmed which is going to piss off anyone creative. I guess you can
> have a method for getting personalised emotes approved but that is going
> to kill the spontaneous action.
On a user level I am all for allowing the use of emoteto/echoto/emote/echo
commands for spontaneous action, but on a body level, I will probably be
giving social comands a rating using a limited system like the skotos
proximity
to restrict how they are used.
I guess we will probably end up with two sets of social commands.
Donky.
Richard
news:8ju8rs$l09$1...@hyperion.triode.net.au...
> Richard <rm...@hotmail.com> wrote:
> > - Pure (almost) 3D based coordinate systems for text based muds.
> > (there are many things that come under this I would like to discuss)
>
> 2D coordinate based maps by downloading the code at:
>
I like this a lot. The maps look very promising.
> There are some demo maps presented as PNG files too, all of them
> generated by the software provided, some of them are hideously complex
> to walk around inside, even when using the ASCII map generator to help
> you figure out where you are.
>
> A different but still interesting 2D mapping engine is contained in
> my 16k MUD competition entry, follow the link off:
>
> http://www.triode.net.au/~telford/mud/codebase.html
Broken link.
> Both of these techniques could be extended to 3D without a great deal
> of pain but my own reflections on the matter have concluded that using
> a bunch of 2D layers is better than true 3D both from the coding point
> of view and to simplify the area building and to make it easier for
> players to understand. I would say that the ideal would be something like:
>
> [+3] -- sky level: flying carpet territory
> [+2] -- top level: roof of house, top of tall tree
> [+1] -- upper level: top story of house, climbing tree, castle battlement
> [0] -- ground level: walking, riding, streets, roads, market, etc
> [-1] -- dungeon 1: basement, small tunnels, sewer, hobit holes
> [-2] -- dungeon 2: deeper tunnels, natural caves, most lairs
> [-3] -- dungeon 3: really deep tunnels, lairs of nasty things, dwarf mines
> [-4] -- dungeon 4: seriously deep, close to centre of earth, even dwarfs
> wouldn't go this far, have we made it to hell yet?
>
> Then just use 2D mapping for each layer and don't worry too much that
> it is only pseudo-3D. Possibly support inclines within each layer so
> that [0] can slope up and down as required by terrain (then [1] and [2]
> will naturally incline along with [0]).
This might be really nice with a populous style editor :)
But it is too limited for the things I want to accomplish.
> If anyone is out there playing with real 3D, I have a spatial database
> engine that can find objects inside or intersecting and arbitrary 3D
> block (i.e. every object is bounded by a lowest point and a highest
> point making a 3D block that contains the object). It _should_ be faster
> than a linear search and neater than splay trees and octrees because
> it uses a hashtable combined with a virtual tree search. You can delete
> and insert objects without needing to rebuild the structure of the
database
> and all queries only search that region of the database which is local
> to the query region. Storage is sparse from a logarithmic point of view
> (i.e. same storage requirements as any subdividing tree).
Well, I helped thrash out our system and then the most intelligent one
of us went away and coded it and I found out to my surprise that we
had a polygon based system. Now hes lost interest in mudding and
I have found interest in continuing it.
So, this is all a bit over my head.
I'm more on the level of knowing what we need to get out of our
system and working back from there.
Which I guess is basically:
- inside a room, work out where everything is placed compared to
someone and dynamically describe in a readable way how it is
positioned to them in the room description.
- outside, work out where people, things and structures are
placed compared to someone and dynamically describe their
surroundings in a way that is easy to read and gives them
perspective.
- and most likely more.
What I need to do is work out how I can do what I need to
do and right about then, I guess I will know if your code would
help me. Although I would be more likely to recode it in LPC.
But if speed rather than experimentation ever becomes a concern,
I would probably use your code then as a driver package.
Donky.
Richard
news:8jv1as$6f8$1...@hyperion.triode.net.au...
> Richard <rm...@hotmail.com> wrote:
> > <tel...@xenon.triode.net.au> wrote in message
> > news:8ju8rs$l09$1...@hyperion.triode.net.au...
> >> Richard <rm...@hotmail.com> wrote:
> >> This has been a long term interest of mine. You can check out my
> >> 2D coordinate based maps by downloading the code at:
>
>
> > The problem that I have with your code is that it is too theoretical for
me.
> > I like the end results and to have to get my fingers dirty with polygons
is
> > distasteful. Thats kind of what I like about LPC. Its an abstract
language
> > compared to C (IMO, and I am not an expert) and allows for me to
> > easily implement complicated concepts in an abstract way.
>
> > I would rather discuss the abstract concepts, problems or whatever to
> > do with 3D coordinate systems than dig through someones C code.
>
> > In any case, I will followup your post properly tomorrow.
>
> If you want some sort of packaging then sketch out an API that would
> suit you and I'll try to knock it together into a library that you can
> treat as a black-box and plug onto what you are already using
> Actually it sort of already is supposed to work like a bolt-on library
> but I guess that I have written so much C and reverse engineered so many
> C libraries that I tend to take the presumption that anyone who uses it
> is going to bend it around to suit their tastes so my packaging is sort of
> ``open ended''. I can put together something more encapsulated if that
> makes you more comfortable.
Well, as I have mentioned, I don't know at this stage how this would
apply to our system.
> I agree with you that the abstract concepts need high level documentation.
I guess I am more of a discuss how I would like the game to work and
discuss how to make it usable by the players sort of person, rather than
a discuss how it should be implemented.
> The API needs documentation too, read the header files and look at the
> way the walk.c program works (that program was deliberately very simple).
>
> I wrote one article for Imaginary Realities
>
> http://imaginaryrealities.imaginary.com/volume2/issue1/map_article.html
>
> but that only briefly covers the concepts, a lot of undocumented water
> has gone under the bridge since then. I have a half-written LaTeX document
> that covers some of it and will soon cover the rest. Hopefully I can
> include enough applications that it makes a useful contribution to
> my PhD thesis (which happens to be about magnets but the logic is
something
> like magnetic fields -> finite element method -> discretisation of
> spacial geometry -> spacial database -> map systems. All good mathematical
> fun to boot!
>
> By the way, did you get the ASCII maps working as you walk around?
I didn't try it.
I did save the archive meaning to though :) Maybe I have it on CD
somewhere,
will have to see if I have a copy of it at home.
Donky.
Scatter
wrote:
>Its to be expected. The real problem is how to find the perfect
>creator, if they are out there and they haven't been disillusioned by
>working in a bad environment..
You are unlikely to find the perfect area creator for a simple reason
- there are very few of them out there.
After all, the perfect area creator for your mud must have the
following qualities:
1) have the same understanding of the world, its theme, rules and
restrictions as you do
2) have imaginative ideas that fit within the world
3) have good creative and descriptive writing skills
4) in the LP world, have a fair grasp of programming
5) have adequate free time available to spend on creating
6) have heard of your mud
It's difficult enough to get (3). To get (3) and (4) together is rarer
and often essential for a good LPmud area. (2) is easier to find alone
but finding it in combination with (3) and (4) will be rare, and (1)
will be very rare. Now of this tiny fraction of creators left, you
need (5) as well, so they actually have the time to do things for you.
Thus, by the time you need (1), (2), (3), (4) and (5) you have very
few people to choose from and then there's (6) - chances are none of
them will have ever heard of you, let alone be applying for a
position.
--
Scatter ///\oo/\\\
Lars Duening
wrote:
>On Thu, 6 Jul 2000 08:39:45 +1200, "Richard" <rm...@hotmail.com>
>wrote:
>
>After all, the perfect area creator for your mud must have the
>following qualities:
>
>1) have the same understanding of the world, its theme, rules and
> restrictions as you do
>2) have imaginative ideas that fit within the world
>3) have good creative and descriptive writing skills
>4) in the LP world, have a fair grasp of programming
>5) have adequate free time available to spend on creating
>6) have heard of your mud
>
>It's difficult enough to get (3). To get (3) and (4) together is rarer
>and often essential for a good LPmud area. (2) is easier to find alone
>but finding it in combination with (3) and (4) will be rare
Alternatively one could look for people who
7) are able to teamwork
Especially for LPs I think it's useful to have one person handling the
programming of an area, and leave the design and writing to others.
--
Lars Duening; la...@bearnip.com
http://www.bearnip.com/
Derrick Rushlo
I write the descriptions and come up with the theme, while a friend of mine
who loves just pure code implements it all. It works out great and both of
us are happy and we end up producing a lot.
While I do wish to learn more about coding, it's a subject that has been a
little hard for me.
Lars Duening <lars...@bearnip.com> wrote in message
news:3964b397.66166842@news...
H. McDaniel
> > I also find the system of abstract regions of personal space kind
> > of strange (e.g. people are at ``near'', ``close'', ``intimate''
> > proximities) since I prefer using a proper distance in metres.
> > This is not that I'm trashing the Skotos ideas but I see the first
> > step as establishing a realistic geometry and then you can overlay
> > adjectives onto that (rather than try and reconstruct the geometry
> > from a bunch of adjectives).
> A man after my own heart :) My take on it is move around in one
Hmm. I don't see much difference between knowing that a box is 3.5
meters away from another box or that it is "near" the other box,
provided that the internal representation of the relationship is
sufficent to allow one to build a context or multi-dimensional
map of where one box is in relation to other objects. Using numbers
is one route, using some kind of tree to specify what is closer to
what in a particular dimension is another. I suppose it depends on
whether one wishes to make a distinction between being in direct
"physical" contact with an object and simply being infinitely close
to but not touching an object.
-McDaniel
Richard
news:396440f3.847728@localhost...
> >creator, if they are out there and they haven't been disillusioned by
> >working in a bad environment..
>
> following qualities:
>
If they have all the other qualities, they don't need to know how
to program at all. I'm perfectly willing to teach them and by the
time I find someone who meets all the other criteria, I will have
finished expermental mudlib project 8,342:
- Automated tools to teach a newbie creator.
Still, a creator who has the other qualities I can guarantee will
have no problems learning this one.
> 5) have adequate free time available to spend on creating
I don't think this is suck a big concern. Its kind of a given thing,
So, I say we have 4/6 more chance of finding the perfect creator
than you think. Lets ignore the fact it will be christmas 2020 before
all my mudlib projects are working just right and that we have no
plans to open at all.
Donky.
Richard
news:8k0g8a$m2b$1...@hyperion.triode.net.au...
> > I guess I am more of a discuss how I would like the game to work and
> > discuss how to make it usable by the players sort of person, rather than
> > a discuss how it should be implemented.
>
> interface to be as natural as possible and support the widest range
> of possibilities. For example:
>
> "walk past the big, black stone while keeping it to the left"
I can only work on stuff that interests me and the interest I have in
playing a game that requires me to type something like that is roughly
equivalent to the interest I have in licking the toenail cheese from under
my toenails :)
> As the computer theorest once said, "all the rest is implementation"
> However, what you probably really want is an interface that doesn't
> do quite everything that it SHOULD do but still does enough to make a
> decent game and is simple enough that you are able to implement it.
Which is what I am aiming for.
> In which case I think that the basic compass directions are not too
> bad even though they are not completely realistic. Also being able
> to site landmarks from a distance and get a rough idea of how far they
> are away from you and which direction is useful. Finally you should
> be able to walk towards a landmark. This would be the minimum features
> that I would like.
Yeah, compass directions, the bane of my creativity as a mudlib
coder. The alternative is of course the 'forward', 'turn left,right,around'
which I doubt players would favour. I guess I am kind of resigned
to the compass directions and have dubious plans to have a
disorientation factor which will rotate the players natural compass.
> I also find the system of abstract regions of personal space kind
> of strange (e.g. people are at ``near'', ``close'', ``intimate''
> proximities) since I prefer using a proper distance in metres.
> This is not that I'm trashing the Skotos ideas but I see the first
> step as establishing a realistic geometry and then you can overlay
> adjectives onto that (rather than try and reconstruct the geometry
> from a bunch of adjectives).
A man after my own heart :) My take on it is move around in one
metre steps and have souls work on a distance basis and perhaps some
restricted version of the skotos system where you can only use souls
on someone where the souls intimacy rating is less than the rating they
allow you to use on them. Or something like that.
> >> By the way, did you get the ASCII maps working as you walk around?
>
> > I didn't try it.
>
> > I did save the archive meaning to though :) Maybe I have it on CD
> > somewhere,
> > will have to see if I have a copy of it at home.
>
> grumble, grumble, grumble.
Compile a version for Win32 and email it to me and I guarantee I will
run it immediately ;P
Donky.
Lars Duening
wrote:
><tel...@xenon.triode.net.au> wrote in message
>news:8k0g8a$m2b$1...@hyperion.triode.net.au...
>> In which case I think that the basic compass directions are not too
>> bad even though they are not completely realistic. Also being able
>> to site landmarks from a distance and get a rough idea of how far they
>> are away from you and which direction is useful. Finally you should
>> be able to walk towards a landmark. This would be the minimum features
>> that I would like.
>
>Yeah, compass directions, the bane of my creativity as a mudlib
>coder. The alternative is of course the 'forward', 'turn left,right,around'
>which I doubt players would favour.
Back in my mudlib days, I gave the idea of getting rid of this
'natural compass' some thought, but eventually decided against it.
As I see it, this compass is a concession to the fact that a mud
presents only a very sketchy and incomplete description of the
player's surroundings. In the real world, one doesn't have a builtin
compass, but there are things like features on the horizon, twisted
trees, a hovering stormcloud, the sound of a distant creek, etc which
help one to get one's bearings.
Therefore, just taking away the compass in a mud without giving the
player some other means of quick orientation wouldn't even be
realistic, it would just make the game harder for no purpose.
...hmm, and now I got the idea of assigning locations an 'orientation
difficulty' so that unexperienced players have a chance at getting
lost (mistaking north for west and the like)...
-- Lars throws some zorkmids into the crowd.
Scatter
wrote:
>On Thu, 06 Jul 2000 08:26:51 GMT, sca...@thevortex.com (Scatter)
>wrote:
>>After all, the perfect area creator for your mud must have the
>>following qualities:
>>
>>1) have the same understanding of the world, its theme, rules and
>> restrictions as you do
>>2) have imaginative ideas that fit within the world
>>3) have good creative and descriptive writing skills
>>4) in the LP world, have a fair grasp of programming
>>5) have adequate free time available to spend on creating
>>6) have heard of your mud
>
>Alternatively one could look for people who
>
>7) are able to teamwork
That's a good point - if you can get (1) and (2) together, then each
of (3) and (4) could be handled by someone else working with them.
Of course, you then need to find people who are good at working
together.
>Especially for LPs I think it's useful to have one person handling the
>programming of an area, and leave the design and writing to others.
Personally, I've yet to see this work well in practice. There seems to
be an attitude of "it's mine! I want to do it myself!" a lot of the
time - and I know I'm guilty of this myself on occassions. =)
--
Scatter ///\oo/\\\
Scatter
wrote:
>"Scatter" <sca...@thevortex.com> wrote:
>> 4) in the LP world, have a fair grasp of programming
>If they have all the other qualities, they don't need to know how
>to program at all. I'm perfectly willing to teach them
Ok, I'll rephrase it to:
4) have a fair amount of actual or potential programming ability
=)
I have encountered people who just can't be taught to program,
especially to specific quality and style guidelines.
>and by the time I find someone who meets all the other criteria, I
>will have finished expermental mudlib project 8,342:
>- Automated tools to teach a newbie creator.
Out of interest, what are the 8341 higher priority tasks? =)
>Still, a creator who has the other qualities I can guarantee will
>have no problems learning this one.
I disagree - I have had inventive, imaginative and creative people
leave basically because they couldn't get their heads around
programming and as a result got very frustrated. Unfortunately our
staff numbers were (and still are) too low for there to be anyone
around to help them out most of the time.
>> 5) have adequate free time available to spend on creating
>I don't think this is suck a big concern. Its kind of a given thing,
I put this one in because of the continuing problem I seem to have
with recruiting people who then rapidly become "too busy in real life"
to actually produce anything.
--
Scatter ///\oo/\\\
Brad
news:8jv0aq$63e$1...@hyperion.triode.net.au...
> Brad <br...@invalid.nospam.com> wrote:
> > My own take on the whole area design is to use fuzzy coordinates--my own
> > spur-of-the-moment term for it. My theory goes that since 3d games can
> > fudge a bit with the dimensions since they must ultimately be displayed
as
> > 2d, then you can get away with a lot more with text and still give the
> > illusion of a realistic environment. I'm throwing realism out the
window
> > for a clever way of faking it :-).
>
> Not at all a bad idea. Got any sample code or any details of the
algorithm?
Umm... somewhere :-). I have the bad habit of writing my notes on whatever
writeable surface I have handy at the moment. If I find them, I'll post it.
> I have some experience with fuzzy logic so I can see that a person might
> be walking from room 1 to room 2 and instead of jumping between them
instantly,
> they might go through some transitional phase where they are p% in room 1
and
> ( 100 - p )% in room 2 (as x slowly counts down from 100 to 0). If room 1
> has the coordinates [ x1 y1 z1] and room 2 has the coordinates [ x2 y2
z2 ]
> then a person between the two rooms will have coordinates of
> ( p / 100 )[ x1 y1 z1 ] + (( 100 - p ) / 100 )[ x2 y2 z2 ]
> which puts them on the line from room 1 to room 2.
I didn't actually mean to imply a relationship between my own fuzzy
coordinate system and fuzzy logic, although now that you mention it, that is
an interesting approach. Since I can't find my notes right now, I won't go
too in depth, but the basic idea is that you can do a lot with a little
information. One idea I had for the implementation basically amounted to a
toned down Skotos system, which established three cases for distances. An
object could be equally distant from another object, near another object, or
intimately associated with an object (touching/inside). Room sizes would be
assumed to be perfectly square and that would affect the speed with which
travel could occur between rooms and between groups of equally distant
objects. Near objects are considered close enough that only negligible
movement would be required. The intimate object case was only to
distinguish the difference between things lying next to each other and
actually being in contact. Obviously the system fails when you're dealing
with a large room, which would put everything pretty far away from
everything else, so that isn't the implementation I went with. Although I
believe that with a world comprised of small to mid-sized rooms (not stadium
size), that it would provide a realistic enough representation of the world
without making the player have to worry much about the coordinate system.
The system in development, is more complex, but still plays loose and fast
with coordinates.
- Brad
Lars Duening
wrote:
>On Thu, 06 Jul 2000 16:22:07 GMT, lars...@bearnip.com (Lars Duening)
>wrote:
>
>>Especially for LPs I think it's useful to have one person handling the
>>programming of an area, and leave the design and writing to others.
Let me add: most of the LP coders I encountered so far (including
myself) suck at designing and writing good areas, and vice versa I
don't think that forcing gifted writers into programming is a good
idea either.
But which hopeful applicant would like to hear that? :-(
>Personally, I've yet to see this work well in practice. There seems to
>be an attitude of "it's mine! I want to do it myself!" a lot of the
>time - and I know I'm guilty of this myself on occassions. =)
*grin* who isn't?
Scatter
wrote:
>sca...@thevortex.com (Scatter) wrote:
>>lars...@bearnip.com (Lars Duening) wrote:
>>>Especially for LPs I think it's useful to have one person handling the
>>>programming of an area, and leave the design and writing to others.
>
>Let me add: most of the LP coders I encountered so far (including
>myself) suck at designing and writing good areas, and vice versa I
>don't think that forcing gifted writers into programming is a good
>idea either.
I like to think I can design and write good areas as well as produce
good code, but my heart certainly lies with the coding rather than the
writing - as far as muds go anyway. I tend to burn out very quickly
when I'm building areas rather than mudlib stuff.
Actually, one method of combining talents that I've had some success
with, is to let a fairly good programmer build his/her area and then
have a good descriptive writer go through the finished product and
spruce it all up. This seems to work better than trying to get two
people to cooperate on it (especially if they are in different
timezones!).
>But which hopeful applicant would like to hear that? :-(
One of the goals of my (custom) mudlib is to make it ever easier to
add fairly complex effects without needing complex code. Thus with any
luck, those who find the programming aspects more difficult should
find their life easier.
--
Scatter ///\oo/\\\
Richard
> I have encountered people who just can't be taught to program,
> especially to specific quality and style guidelines.
Oh god yes, after having demoted and repromoted one of these at least
four times due to an admin who believed you couldn't give enough
second chances, I am of the opinion you shouldn't waste your time
with these. They typically come across as gormless so its easy to
pick them out.
> >and by the time I find someone who meets all the other criteria, I
> >will have finished expermental mudlib project 8,342:
> >- Automated tools to teach a newbie creator.
>
> Out of interest, what are the 8341 higher priority tasks? =)
This is a brief abstract list, I describe some of these in detail with
a guy I exchange emails with.. he's a bit limited, but you gotta make
do with what you can get ;P Keywords: experimental, proof of concept
still to be done in some cases.
1. Pure 3D coordinate system (polishing off core code).
2-4300. Tasks involving fleshing out the 3D coordinate system in
various ways.
4301-8300. Tasks related to medieval research.
8301. Object decomposition system, finish fleshing out and
integrate with all the medieval research.
8302. Player professions, write templates for processes based
on the medieval research compositite object templates so
that constructed objects can be deconstructed.
8303. Poach creators from Scatter's mud, Dawn Whispers.
8304. Write simple but autonomous NPCs and see how they react
to each other.
8305. Give NPCs ability to use the profession system and have
them search for other NPCs in professions that supply
resources to them (or PCs).
8306. Write NPC controller that handles NPCs owning properties
whether for home use or business. Also handles grouping
of NPC families and how NPCs recognise each other.
8307. Write city layout controller that can generate cities,
towns, whatever containing initial NPCs, buildings,
businesses and resources according to certain rules.
8308-8340. Lots of other stuff.
8341. Write automated guidance code that looks over someones
shoulder, will help teach players to play the game at
various levels and give lessons to creators on how to
code (down to analysing the code they do).
8342. Poach players from Discworld.
(I would have made this list a lot longer but I feel guilty when I do
stuff like this when I should be working)
> >> 5) have adequate free time available to spend on creating
> >I don't think this is suck a big concern. Its kind of a given thing,
>
> I put this one in because of the continuing problem I seem to have
> with recruiting people who then rapidly become "too busy in real life"
> to actually produce anything.
I am kind of dubious that these creators really suddenly become "too busy
in real life", I think 99% of the time its more a lack of interest (or no
_real_ interest to begin with).
Donky
David Bennett
> I don't know, but I do think that builders need to be given more
> compensation for their work. I don't think imps should expect builders to
> put their effort and creativity into something for nothing, and some do.
> The reward doesn't have to be money, it could also be fame, promotions, ic
> rewards, or partial ownership of the mud. The latter really appeals to me,
> because the mud does partly belong to those who have contributed. You don't
> give anything away really, but you do formalize things and offer a pledge
> that the mud and the builder's hard work will not simply vanish one day.
Well... Most of things do happen on muds, unless Discworld is a glaring
exception :) I am the only original admin left on the mud and there are 6
admins currently. So I have given partial ownership away to other people.
One of the big problems with how the original 2.4.5 systems worked was that they
gave too much control and recognition to the one creator. It made it the
ownership for fixing errors very hard to determine when the person in question
went away. If you move everything into a more group based system it means the
mud can deal a lot better with the influx/outflux of creators.
Flowing out into the street,
David.
David Bennett
> I like to think I can design and write good areas as well as produce
> good code, but my heart certainly lies with the coding rather than the
> writing - as far as muds go anyway. I tend to burn out very quickly
> when I'm building areas rather than mudlib stuff.
Yes, I burn out really quickly writing rooms too. I am not sure I write
good ones, just weird ones. Not sure if that counts though...
> One of the goals of my (custom) mudlib is to make it ever easier to
> add fairly complex effects without needing complex code. Thus with any
> luck, those who find the programming aspects more difficult should
> find their life easier.
This was a goal with Discworld too, when I started. It is a lot easier
than the muds I had to base my ideas on... :)
Eeeking because some of the previous notes might have been html,
David.
David Bennett
> 8303. Poach creators from Scatter's mud, Dawn Whispers.
Our creators are not good enough for you?
Bristling like a broom,
David.
Scatter
<d...@discworld.imaginary.com> wrote:
>Richard wrote:
>> 8303. Poach creators from Scatter's mud, Dawn Whispers.
>> 8342. Poach players from Discworld.
>
>Our creators are not good enough for you?
We're just more advanced. =)
--
Scatter ///\oo/\\\
Richard
Well, the idea was that I wouldn't have any trouble poaching Scatters
creators in any case, but
by keeping the operation to poach Discworld's covert, it would make my job
easier :P
Richard.
Derek Snider
"Richard" <rm...@hotmail.com> wrote in message
news:96294274...@newsch.es.co.nz...
> <tel...@xenon.triode.net.au> wrote in message
> news:8k0g8a$m2b$1...@hyperion.triode.net.au...
> > > I guess I am more of a discuss how I would like the game to work and
> > > discuss how to make it usable by the players sort of person, rather
than
> > > a discuss how it should be implemented.
> >
> > Oh. I would say the easy answer to that one is you want a text mode
> > interface to be as natural as possible and support the widest range
> > of possibilities. For example:
> >
> > "walk past the big, black stone while keeping it to the left"
>
> I can only work on stuff that interests me and the interest I have in
> playing a game that requires me to type something like that is roughly
> equivalent to the interest I have in licking the toenail cheese from under
> my toenails :)
The best system for having a text interface to a 3D coordinate world would
be
to have keyworded "path" objects between points of interest.
This "path" would be very much like a footpath, trail or road.
You could still use the cardinal directions, and have it auto-follow any
path
it found going in that general direction.
Richard
"Derek Snider" <de...@idirect.com> wrote in message
news:zc_j5.17210$N47.1...@quark.idirect.com...
> The best system for having a text interface to a 3D coordinate world would
> be
> to have keyworded "path" objects between points of interest.
>
> This "path" would be very much like a footpath, trail or road.
>
> You could still use the cardinal directions, and have it auto-follow any
> path
> it found going in that general direction.
If you're going to have a realistic 3D coordinate system, with realistic
distances, you have probably already decided to implement
something like this.
Richar.d
Derek Snider
Exactly... but reading this thread, no one seemed to have a clue about
using such an obvious system, and were worried about having to type
exhaustively descriptive sentences like:
"walk north-east past the tall-maple-tree and turn left before the
oak-bridge"
or terribly technical commands like:
"turn left 48 degrees then walk 55 feet"
Brad
> Exactly... but reading this thread, no one seemed to have a clue about
> using such an obvious system, and were worried about having to type
> exhaustively descriptive sentences like:
> "walk north-east past the tall-maple-tree and turn left before the
> oak-bridge"
One man's trash is another man's treasure.
> or terribly technical commands like:
> "turn left 48 degrees then walk 55 feet"
I don't think that is a bad system in certain contexts. It would work well
with muds revolving around vehicular movements.
- Brad
Derek Snider
"Brad" <br...@invalid.nospam.com> wrote in message
news:ZsDl5.7395$iI5....@news-west.usenetserver.com...
The best system would have all three available.
Brad
> Now, my quandry is how do I adequately describe the room to the player
> depending on what
> and who is also in it, how big it is and the players position in the room?
> If you are standing
> in one corner of the room, how do you in an easy to read and understand
way,
> describe
> where the exits, objects and characters are in relation to where you are
> while keeping a
> perspective of where they are in the room?
>
> Anyone got any ideas?
Put the size of the room next to the name of the room. Unless the room is
unusually sized, or has some special meaning attached there is no need to
describe it. You don't need to describe the size of a closet, as most
people have the idea of how big an average one is, but you might as well
show the stats next to the name as it is something they would be able to
estimate easily. However, if it is the king closet of all closets with
vaulted ceilings and stained glass windows, you might want to describe it.
As far as the perspective goes, I would split everything into what is near
the player and what is not. Leave it at that unless the player actually
looks at a specific item or if he types a command such as "tatical."
>
> My current thoughts on the description in general is that:
> a) if its a generic description, it should not be repeated. (e.g. desert -
> they might see the full description for the first couple of rooms
I don't think once the players are in a generic area there shouldn't be any
messages other than the area name. Let the depth be supplied by a system
that creates environmental events (like tumble weeds blowing across the
ground, a strong breeze from the north, a speck of sand that flies into your
eye, the sweat dripping off your back, the fear of an agorophobic character
being in a desert, etc..). You could just use dinky little text messages,
or you could actually have it affect the world and add bucket loads of
depth.
- The Quintessential Brad
Richard
Stuff" when the complex "Not So Fun Stuff"
is complete.
At the moment, top of my "Not So Fun Stuff" list is the problem of
describing perspective and
distance with text. I am not sure if I have described how I do rooms
before, but rooms are
subdivided into movement spaces approximately 1m square. Objects (like
tables and other
furniture are positioned within the room at appropriate spaces, and when
characters come
through doors, they are positioned in front of the door in the room.
Now, my quandry is how do I adequately describe the room to the player
depending on what
and who is also in it, how big it is and the players position in the room?
If you are standing
in one corner of the room, how do you in an easy to read and understand way,
describe
where the exits, objects and characters are in relation to where you are
while keeping a
perspective of where they are in the room?
Anyone got any ideas?
My current thoughts on the description in general is that:
a) if its a generic description, it should not be repeated. (e.g. desert -
they might see the full
description for the first couple of desert rooms, after that, they would
get a one liner.)
b) if somethings obvious enough to put in the description, theres no need to
bury it in text
or try and make it hard to identify, it should be displayed in a simple
and easy to read
way.
"Derek Snider" <de...@idirect.com> wrote in message
news:25go5.27183$N47.3...@quark.idirect.com...