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
- Resets and repops (a really short post) claw@null.net
- Resets and repops (a really short post) Nathan Yospe
On Thu, 27 Mar 1997, Adam Wiggins wrote:
:> >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).
Yeah, I don't like the direction that thread is heading. That's what I get
for abandoning it, letting others direct it. I like your princess bride
thing... I wrote a bunch of development "mood" chapters for the book I am
writing out of my MUD world, and then wrote combat drivers, and the rest
of the drivers, to allow everything in the book. Then I wrote a single
player test engine with it and turned one of my space war strategy buff
friends (you know, the "Armor, Starship Troopers, and Steel, David Weber
and Timothy Zahn" crowd) loose on it, then corrected everything he
complained of, not with a hack but with a core concept rewrite. When he
told me that he found it disapointing that the grenades he had tossed into
the hole he punched next to the door didn't ping, but instead were lost to
knowledge until they blew, I rewrote sound and signal generation. When he
complained that he couldn't drill a hole in the ground outside of a
complex and pour nerve gas pelets down (I hadn't extended wall code to 20
foot thick ground, but it was a reasonable strategy) I redesigned the
locational code to allow spatial relationships with extrapolated contents
in between. (This had the pleasant side effect of the 'jungle/desert/ice
field off into infinity' system.) I'm gonna credit him as the best
playtester I've ever had. (The previous best, on our ROM version, found
our flaws by writing a complex script... he's probably going to be our
regular area tester supreme.) The idea here is, don't patch a blemish
over, figure out the underlying flaw that caused it. The point is, story
(plot) and flexibility up the wazoo are not incompatible. It doesn't
matter _who_ kills Lord Croede, or how... killing him is going to set off
the inevitable side effect of increasing Andromedan security and control
in our galaxy, making the temporary hero's position a tenuous one, and
triggering the events that allow the (aware - meaning in that timestream)
players to begin taking part in the retaliation. The ways to get into the
Andromedan galaxy are mostly military, and most enter that galaxy in a
killing rage. Some don't find the fact that they are slaughtering
civilians shocking, more than I had hoped on Sing1 gladly killed what was
obviously a peaceful family, or destroyed a museum of art or history in
the bloodlust, knowing what they were doing... but the story is there.
:> 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.
Yeah, I intend to do this with GURU. The way the powers work there makes
for interesting effects. The four natures, with their internal symetries,
encourage different types of slaughter... the physical is gained through
expendature, so the more that is spent, the more is recovered. The magical
is a complex dance of sixfold symetries, with the six magics having
natural enemities and alliances, death(void) anhiliates life(ether),
creation(water) kills destruction(fire), infinity(earth), time(air). Two
non enemies magnify, and three create a totality (death+time = age,
death+infinity = shade, death+creation = reclamation, death+destruction pain, creation+time = wonder, death+creation+time = transcendence) Killing
something with magic causes the descendent to gain a little more of each
component essence. There are also empathy/telepathy forces, and animistic
forces, with similar subsystems, and an underlying primal force.
Everything is evolutionary in the GURU system. That, however, waits for a
future time. I'm not going to add support code for evolution in Physmud++,
though builders can do it if they wish.
<snip about keys> (I don't even have them... most locks being electronic
at the least)
:> >: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.
Yeah. But I'm probably not going to bother.
:> >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.
I'm pretty sure this one was in reference to me...
Both versions actually exist, if not exactly in that form... well, not the
first, quite. More like, if(enemy.strength/strength > 2) where
enemy.strength is going to be your _perception_ of the enemy's strength...
I don't remember how its written, its been a while since I worked on that
file, but it is entirely based on your _perception_ of things... nothing
can be programmed that you cannot do by typing out commands yourself...
etc. The second version is derived from the Diku auto configs, and allows
you to configure a lot of responses... and is headed for the chopping
block. It keeps messing with the lower level version.
: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."
Yeah, well... that's why you want to program reflexes. If you hae a reflex
for something like a thrown grenade (which you would, if you kept getting
them lobbed at you), would you have to think about lobbing it back? Of
course, the problem with that is... what if they have your friend hostage?
Overriding your reflexes can get quite touchy... you have to think _not_
to do something, in cases like that.
__ _ __ _ _ , , , ,
/_ / / ) /_ /_) / ) /| /| / /\ First Light of a Nova Dawn
/ / / \ /_ /_) / \ /-|/ |/ /_/ Final Night of a World Gone
Nathan F. Yospe - University of Hawaii Dept of Physics - yospe@hawaii.edu
- Resets and repops (a really short post) Nathan Yospe
- 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