March 1997
- Linear Quadtrees Carter T Shock
- Linear Quadtrees gzhang1234@yahoo.com
- q-tree stuff Chris Gray
- q-tree stuff Carter T Shock
- q-tree stuff coder@ibm.net
- Issues from the digests and Wout's list Alex Oren
- Issues from the digests and Wout's list coder@ibm.net
- Issues from the digests and Wout's list coder@ibm.net
- Issues from the digests and Wout's list coder@ibm.net
- Issues from the digests and Wout's list clawrenc@cup.hp.com
- Issues from the digests and Wout's list Nathan Yospe
- Issues from the digests and Wout's list Shawn Halpenny
- Issues from the digests and Wout's list Nathan Yospe
- Issues from the digests and Wout's list Shawn Halpenny
- Issues from the digests and Wout's list clawrenc@cup.hp.com
- Issues from the digests and Wout's list clawrenc@cup.hp.com
- Issues from the digests and Wout's list clawrenc@cup.hp.com
- Issues from the digests and Wout's list Shawn Halpenny
- Issues from the digests and Wout's list clawrenc@cup.hp.com
- Issues from the digests and Wout's list Shawn Halpenny
- Issues from the digests and Wout's list clawrenc@cup.hp.com
- Issues from the digests and Wout's list Shawn Halpenny
- Issues from the digests and Wout's list clawrenc@cup.hp.com
- Issues from the digests and Wout's list Shawn Halpenny
- Issues from the digests and Wout's list clawrenc@cup.hp.com
- Issues from the digests and Wout's list clawrenc@cup.hp.com
- Issues from the digests and Wout's list Adam Wiggins
- Issues from the digests and Wout's list coder@ibm.net
- Issues from the digests and Wout's list Chris Gray
- Issues from the digests and Wout's list clawrenc@cup.hp.com
- Issues from the digests and Wout's list Miroslav Silovic
- Issues from the digests and Wout's list clawrenc@cup.hp.com
- Issues from the digests and Wout's list Miroslav Silovic
- Issues from the digests and Wout's list Jeff Kesselman
- Issues from the digests and Wout's list Caliban Tiresias Darklock
- Issues from the digests and Wout's list clawrenc@cup.hp.com
- Issues from the digests and Wout's list Caliban Tiresias Darklock
- Issues from the digests and Wout's list Miroslav Silovic
- Issues from the digests and Wout's list clawrenc@cup.hp.com
- Issues from the digests and Wout's list Caliban Tiresias Darklock
- Issues from the digests and Wout's list clawrenc@cup.hp.com
- Issues from the digests and Wout's list Caliban Tiresias Darklock
- Issues from the digests and Wout's list coder@ibm.net
- Issues from the digests and Wout's list Miroslav Silovic
- Issues from the digests and Wout's list Jon A. Lambert
- Issues from the digests and Wout's list Ling
- Issues from the digests and Wout's list Adam Wiggins
- Issues from the digests and Wout's list clawrenc@cup.hp.com
- Issues from the digests and Wout's list Adam Wiggins
- Issues from the digests and Wout's list clawrenc@cup.hp.com
- Issues from the digests and Wout's list Adam Wiggins
- Issues from the digests and Wout's list clawrenc@cup.hp.com
- Issues from the digests and Wout's list Adam Wiggins
- Issues from the digests and Wout's list Shawn Halpenny
- Issues from the digests and Wout's list clawrenc@cup.hp.com
- Issues from the digests and Wout's list Nathan Yospe
- Issues from the digests and Wout's list clawrenc@cup.hp.com
- Issues from the digests and Wout's list Shawn Halpenny
- Issues from the digests and Wout's list Chris Gray
- Issues from the digests and Wout's list Ling
- Issues from the digests and Wout's list clawrenc@cup.hp.com
- Issues from the digests and Wout's list Jeff Kesselman
- Issues from the digests and Wout's list clawrenc@cup.hp.com
- Issues from the digests and Wout's list Chris Gray
- Issues from the digests and Wout's list Nathan Yospe
- Issues from the digests and Wout's list Shawn Halpenny
- Issues from the digests and Wout's list Jeff Kesselman
- Issues from the digests and Wout's list clawrenc@cup.hp.com
- Issues from the digests and Wout's list Jeff Kesselman
- Issues from the digests and Wout's list clawrenc@cup.hp.com
- Issues from the digests and Wout's list Jon A. Lambert
- Issues from the digests and Wout's list Jeff Kesselman
- Issues from the digests and Wout's list clawrenc@cup.hp.com
- Issues from the digests and Wout's list Jeff Kesselman
- Issues from the digests and Wout's list S001GMU@nova.wright.edu
- Issues from the digests and Wout's list Shawn Halpenny
- Issues from the digests and Wout's list Travis Casey
- Issues from the digests and Wout's list Nathan Yospe
- Issues from the digests and Wout's list Jeff Kesselman
- Issues from the digests and Wout's list Nathan Yospe
- Issues from the digests and Wout's list Jon A. Lambert
- Issues from the digests and Wout's list Adam Wiggins
- Issues from the digests and Wout's list Ling
- Issues from the digests and Wout's list clawrenc@cup.hp.com
- Issues from the digests and Wout's list Adam Wiggins
- Issues from the digests and Wout's list Adam Wiggins
- Issues from the digests and Wout's list Orion Henry
- Issues from the digests and Wout's list clawrenc@cup.hp.com
- Issues from the digests and Wout's list Ling
- Issues from the digests and Wout's list Shawn Halpenny
- Issues from the digests and Wout's list Nathan Yospe
- Issues from the digests and Wout's list Jeff Kesselman
- Issues from the digests and Wout's list clawrenc@cup.hp.com
- Issues from the digests and Wout's list Chris Gray
- Issues from the digests and Wout's list Jon A. Lambert
- Issues from the digests and Wout's list clawrenc@cup.hp.com
- Issues from the digests and Wout's list Jeff Kesselman
- Issues from the digests and Wout's list Jon A. Lambert
- Issues from the digests and Wout's list clawrenc@cup.hp.com
- Issues from the digests and Wout's list Jeff Kesselman
- Issues from the digests and Wout's list Chris Gray
- Issues from the digests and Wout's list Chris Gray
- Issues from the digests and Wout's list Adam Wiggins
- Issues from the digests and Wout's list Jeff Kesselman
- ListMail dupes coder@ibm.net
- Threads, IO handling, and Event Queues Nathan Yospe
- Threads, IO handling, and Event Queues Chris Gray
- Threads, IO handling, and Event Queues coder@ibm.net
- Threads, IO handling, and Event Queues Carter T Shock
- Threads, IO handling, and Event Queues Nathan Yospe
- Threads, IO handling, and Event Queues claw@null.net
- Threads, IO handling, and Event Queues coder@ibm.net
- mud grammar (was Just a bit of musing) Carter T Shock
- mud grammar (was Just a bit of musing) Nathan Yospe
- mud grammar (was Just a bit of musing) Chris Gray
- mud grammar (was Just a bit of musing) claw@null.net
- mud grammar (was Just a bit of musing) Chris Gray
- mud grammar (was Just a bit of musing) claw@null.net
- mud grammar (was Just a bit of musing) Chris Gray
- mud grammar Carter T Shock
- mud grammar Nathan Yospe
- mud grammar Alex Oren
- mud grammar Nathan Yospe
- mud grammar Adam Wiggins
- mud grammar Chris Gray
- Just a bit of musing (VRML) Dmitri Kondratiev
- Just a bit of musing (VRML) claw@null.net
- Room coding Nathan Yospe
- Room coding Furball
- command parsing Chris Gray
- command parsing Adam Wiggins
- command parsing claw@null.net
- Room coding S001GMU@nova.wright.edu
- Room coding Chris Gray
- Resets and repops Furball
- Resets and repops claw@null.net
- Resets and repops Jon A. Lambert
- Resets and repops claw@null.net
- Resets and repops Nathan Yospe
- Resets and repops Jon A. Lambert
- Resets and repops Nathan Yospe
- Resets and repops claw@null.net
- Resets and repops Adam Wiggins
- Resets and repops Nathan Yospe
- Resets and repops Adam Wiggins
- Resets and repops Nathan Yospe
- Resets and repops Chris Gray
- Resets and repops Chris Gray
- Resets and repops Adam Wiggins
- Resets and repops Travis Casey
- Resets and repops Chris Gray
- Resets and repops Adam Wiggins
- Resets and repops Shawn Halpenny
- Resets and repops Jeff Kesselman
- Resets and repops Chris Gray
- Resets and repops Nathan Yospe
- Resets and repops Jon A. Lambert
- Resets and repops Nathan Yospe
- Resets and repops claw@null.net
- Resets and repops claw@null.net
- Resets and repops claw@null.net
- Resets and repops claw@null.net
- Resets and repops Nathan Yospe
- Resets and repops Adam Wiggins
- Resets and repops claw@null.net
- Resets and repops Adam Wiggins
- Resets and repops claw@null.net
- Resets and repops Nathan Yospe
- Resets and repops claw@null.net
- Resets and repops Jon A. Lambert
- Resets and repops Furball
- Resets and repops Chris Gray
- Resets and repops Adam Wiggins
- Resets and repops claw@null.net
- Resets and repops Adam Wiggins
- Resets and repops claw@null.net
- Resets and repops Chris Gray
- Resets and repops claw@null.net
- Resets and repops Adam Wiggins
- Resets and repops claw@null.net
- Resets and repops Adam Wiggins
- Resets and repops claw@null.net
- Resets and repops S001GMU@nova.wright.edu
- Resets and repops coder@ibm.net
- Resets and repops S001GMU@nova.wright.edu
- Resets and repops clawrenc@cup.hp.com
- Resets and repops S001GMU@nova.wright.edu
- Resets and repops Chris Gray
- Resets and repops Nathan Yospe
- Resets and repops claw@null.net
- Resets and repops Nathan Yospe
- Resets and repops Adam Wiggins
- Resets and repops Nathan Yospe
- Resets and repops Adam Wiggins
- Resets and repops Nathan Yospe
- Resets and repops Chris Gray
- Resets and repops Nathan Yospe
- Resets and repops Chris Gray
- Resets and repops Adam Wiggins
- Resets and repops Chris Gray
- Resets and repops claw@null.net
- Resets and repops lhulbert@czn.com
- Resets and repops claw@null.net
- Resets and repops Chris Gray
- Resets and repops claw@null.net
- Resets and repops Adam Wiggins
- Resets and repops Chris Gray
- Resets and repops Chris Gray
- Resets and repops claw@null.net
- Resets and repops claw@null.net
- Resets and repops claw@null.net
- mud grammar claw@null.net
- mud grammar Nathan Yospe
- mud grammar claw@null.net
- List software claw@null.net
- List software Nathan Yospe
- List software Chris Gray
- List software claw@null.net
- List software claw@null.net
- I got your message..! MAYA DASWANI
- 3D graphics claw@null.net
- Sorry for the dups (again) coder@ibm.net
- mud grammar Jon A. Lambert
- mud grammar claw@null.net
- mud grammar Nathan Yospe
- mud grammar coder@ibm.net
- mud grammar Nathan Yospe
- mud grammar Chris Gray
- mud grammar claw@null.net
- EVOLUTION response claw@null.net
- EVOLUTION response Jon A. Lambert
- EVOLUTION response claw@null.net
- Garbage Collector Artur 'Revinor' Biesiadowski
- A perspective out of time - the mudreport document Nathan Yospe
- A perspective out of time - the mudreport document claw@null.net
- Old missing posts from old list coder@ibm.net
- Execution Chris Gray
- Mixture Furball
- Resets and repops (a really short post) claw@null.net
- Resets and repops (a really short post) Nathan Yospe
- Resets and repops (a really short post) claw@null.net
- Resets and repops (a really short post) Adam Wiggins
> >Yeah... I guess the focus makes a difference too. I tend to have more
> >passive scenarios... there is a definate plot, self renewing. Well...
> >different philosophies..
>
> I basically avoided the plot viewpoint as I have no control over what
> other builders do, I've never seen it done well (multiple
> order/solution path intersections (and that's with a background as a
> paid writer (SF&F, mostly short stories))) and I don't think its
> suited to a MUD world which is in a constant state of development and
> change (ie user's changes permanently afffect the world for all
> players).
I'm in agreement with ya here...there's a thread in one of the r.g.m
ngs right now about zones with 'stories'. That is, there is a definite
goal to the zone, that you comple through a combination of adventure-game
style puzzles and the sheer might of your character, rather than just a
collection of rooms, objects, and mobiles. I rather disagree with this
setiment, however - to me it's regressing to be more like a single-player
game instead of progessing to something which is less a 'game' and more
just a giant, believable world within a given setting.
One of the goals we set when we started getting ambitious with our mud
was to be able to do everything on our mud that happened in the Princess
Bridge. Thus we implemented many things like climbing (cliffs of insanity),
realistic swordplay (Wesley vs Inigo), being able to use any object as a
weapon or throw any object (Fezik's rock), wrestling combat (Wesley vs
Fezik), poisons and building resistances to those poisons (Wesley vs
the short dude), adrenaline (Inigo vs six-fingered man), and so on.
Obviously our ambitious expanded quite a bit further than these simple
examples, but the point is that we never script any of these things to happen.
But the capability is there, and potentially the sequence of events which
took place in the Princess Bride could occur fairly naturally on our mud.
This is our goal - to make a place where all sorts of cool things CAN happen,
not necessarily WILL. This ends up making the world infitely more interesting
(there aren't a fixed number of paths).
> The difference is that the now-dead mobile can pre-determine the
> characteristics of the to-be-created mobile. That can be rather
> useful. Kill the shopkeeper too often and his replacements become
> increasingly twitchy.
One idea I had long ago but doesn't exactly fit into our current
system is natural selection. I really like playing characters with
unusual class/race/guild membership/skills - 'unusual' in the sense that
not many other players are playing them. Of course, it usually works
out that the _reason_ no one else is playing them is because they aren't
as "good", ie they aren't balanced with the rest of the classes/etc.
Understable, though...those sorts of things can be difficult to balance.
I had the thought, then, that you could have the system 'balance' both
methods and mobiles/objects automatically via a sort of natural selection.
For starters, mobiles that got killed frequently would become worth less
and less exp, load up with less gold, etc (which fixes the problem of people
making critters that are too easy relative to the experience and gold that
they give, for whatever reason). More importantly, they'd become more
resistant to the types of attacks that are usually used against them -
if they were constatly getting killed by backstabs, they'd get more wary
of backstabs and 'notice' thieves sneaking up on them more often, thus
causing the backstab to fail.
As I said, doesn't fit into our current system, but would work pretty
well (I think) on more traditional muds.
> >:As pointed out earlier on this thread, the problem is that an object
> >:in a well travelled location (ie constant player traffic) will never
> >:reset. While this may be a Good Thing on the face of it, there
> >:should be an automated system to retrieve the object to allow the
> >:reset.
>
> >Ah. I try to discourage high trafic areas with resets. I prefer non
> >reset mothods in high pop areas, preferably organic and evolutionary.
>
> How about a key item for an area being removed and dropped in a
> heavily travelled room?
This is another interesting topic - keys. There are two schools of thought
on this one. My personal favorite is the method that Arctic uses. It's
not even slightly realistic, but it works very well for them. Basically,
keys turn to dust as soon as you use them, and have short decay times once
you leave the zone. Thus if you kill Foozle and get his arcane key of power,
it will unlock his chest, once - after that you have to kill him again.
As for the problem of people killing them, then taking the key with
them in order to hold a monopoly on whatever it unlocks - either the key
decays in a few minutes once you leave the zone, or there just can be
multiple keys, and once the zone resets, only the 'new' key will unlock
the chest, thus your old one becomes more or less useless.
The other method is to actually expand upon this idea. On one mud some
friends of mine played, they made most of their money via the 'monopoly'
thing mentioned above - as soon as the mud booted, they'd run over and
get the key to the dwarven kingdom. Now anyone that wants the (excellent)
dwarven equipment has to go through them, and they can charge whatever they
like to go in and retrieve the item the desire, plus the shop's cost of course.
I'm not *real* fond of this, but it does work. In this case I'd say that
you'd not ever want to have things reset to their locked position, because
then you get the problem where people die inside a zone, the zone resets,
now they and no one else can get to their corpse and equipment because the
only key is inside their corpse, behind the locked door. (On these sorts of
muds people get in the habbit of giving keys to mobs standing right outside
the zone in case this happens.)
As for us...most of these things don't apply, for instance perment death
makes corpse-retrieval not so important. :) Also, our zones aren't so
linear - in most cases there are many, many ways in and out. The exception
would be something like the dwarven keep that only has one entrance, but
we just have the guards yell down to you as you approach. If you're someone
in the good graces of the dwarven empire, they'll open the gates for
you. If not, you're out of luck. (I always find it funny how the
keepers of 'impregnable' fortresses put guards outside their front door that
are holding the key to the gates...)
> >:Which presents a very interestingly fluid aspect to time. Were I to
> >:do this I could see having mobiles set up to edit character's
> >:timelines for a fee, adding or deleting event histories to allow
> >:travel to different time tracks.
> >:
> >:(Always the rebel)
>
> >Heh. Time pirates and time police. This could get fun.
>
> Thought you'd like that one.
Owwwwww...sounds REALLY messy. Could defintely be fun, though, if you
could pull it off.
> >I've already given the list a taste of my
> >system... a different type of strategy, with a lot of dodges, mad
> >dashes, tossed explosives, ducks behind cover... a little more
> >intense in that sense, but with less of your clever strategy.
>
> As you may guess from my compleat Gordon R Dickson collection, and
> signed mint set of the Dorsai quadrilogy, I'm a fan of strategy. I
> really like the idea of changing combat from a spontaneous blast of
> chaotic violence, to something that is prepared for and launched as a
> series of predicted set pieces. Its no longer a penis waving question
> of who has the biggest weapon, but who has the best application of
> their available attacks and defenses in regard to that particular
> foe's similar set. Yet again, EQ is driven down in significance, and
> the importance of the point of application of the EQ is raised.
For some reason I alwasy think of those old battle-script games like
Corewars, CBots, etc when you talk about your battle-programming
thing. How technical is it going to be, exactly? Basically programming
an AI, or something more in the 'mood' of the game?
That is, the difference between:
if blow.power > 5 joules
call parry
else
call dodge
and:
> dodge all blows
Okay, you'll now dodge all blows.
> parry heavy blows
Okay, you'll now parry heavy blows and dodge all others.
It seems, though, from your example battle-log, that quick thinking is
still of some value. Currently I'd say that's the most important thing
for good combat (*especially* PK), aside from actually have a strong character.
I generally do well at PK simply because I type ~100 wpm, and read very
quickly. Would be nice to see a mud where this wasn't much of an issue,
and it was actually your tactical ability. Of course, most muds are too
simple for this right now - if you had a lot of time to think about what
you were doing, everything would be insanely easy. On the other hand, I do
like the frantic pace of combat; certainly gets your heart pumping when
things get hairy! Versus..."Oh dear, he just lobbed a plasma grenade at
me, primed for 3 seconds...think I'll go get a beer out of the fridge while
I think about what I'm gonna do about it." - Resets and repops (a really short post) claw@null.net
- Resets and repops (a really short post) Nathan Yospe
- Resets and repops (a really short post) Nathan Yospe
- Resets and repops (a really short post) Adam Wiggins
- Resets and repops (a really short post) <= hah! Chris Gray
- VT100 codes ... Khanone@aol.com
- VT102 codes Adam Wiggins
- VT102 codes Adam Wiggins
- VT102 codes Adam Wiggins
- Dupes coder@ibm.net
- Efficiency Chris Gray
- Event Handling Nathan Yospe
- Event handling Shawn Halpenny
- Event handling Vadim Tkachenko
- Event handling Maddy
- A brief introduction.. ok, you got me: an introduction Greg Munt
- A brief introduction.. ok, you got me: an introduction Adam Wiggins
- A brief introduction.. ok, you got me: an introduction coder@ibm.net
- Greetings. :) Michael Hohensee
- Greetings. :) claw@null.net
- Greetings. :) Nathan Yospe
- Greetings. :) Michael Hohensee
- Greetings. :) coder@ibm.net
- Greetings. :) Nathan Yospe
- Greetings. :) Chris Gray
- Greetings. :) coder@ibm.net
- Greetings. :) Chris Gray
- Greetings. :) Nathan Yospe
- Greetings. :) Jeff Kesselman
- Greetings. :) Chris Gray
- Greetings. :) Greg Munt
- Greetings. :) Jon A. Lambert
- Greetings. :) Nathan Yospe
- Greetings. :) clawrenc@cup.hp.com
- Greetings. :) Furball
- Greetings. :) Chris Gray
- Greetings. :) clawrenc@xsvr1.cup.hp.com
- Greetings. :) Shawn Halpenny
- Greetings. :) Jeff Kesselman
- Greetings. :) Shawn Halpenny
- Greetings. :) Jeff Kesselman
- Greetings. :) Shawn Halpenny
- Greetings. :) Jon A. Lambert
- Greetings. :) Jeff Kesselman
- Greetings. :) Shawn Halpenny
- Greetings. :) Jon A. Lambert
- Greetings. :) clawrenc@cup.hp.com
- Greetings. :) Jeff Kesselman