December 1998
- Hex-grid mapping Matthew R. Sheahan
- Hex-grid mapping Jon Leonard
- Hex-grid mapping James Wilson
- Hex-grid mapping Jon Leonard
- Hex-grid mapping James Wilson
- Hex-grid mapping Par Winzell
- Hex-grid mapping quzah [sotfhome]
- Hex-grid mapping Nathan F Yospe
- Hex-grid mapping Ling
- Hex-grid mapping Jon A. Lambert
- Hex-grid mapping Nathan F Yospe
- Hex-grid mapping Alberto Barsella
- Hex-grid mapping (example from PSL empire) Pericolo DiMorte
- Hex-grid mapping (example from PSL empire) Nathan F Yospe
- Hex-grid mapping (example from PSL empire) quzah [sotfhome]
- Hex-grid mapping (example from PSL empire) Pericolo DiMorte
- Hex-grid mapping (example from PSL empire) James Wilson
- ADMIN: Personalities... J C Lawrence
- Hex-grid mapping (fwd) Nathan F Yospe
- Hex-grid mapping (fwd) J C Lawrence
- Electric Communities' E Ola Fosheim Grøstad
- Electric Communities' E Ola Fosheim Grøstad
- mud client development systems Sunny Gulati
- mud client development systems Caliban Tiresias Darklock
- mud client development systems Chris Gray
- mud client development systems greear@cyberhighway.net
- mud client development systems Sunny Gulati
- mud client development systems Benjamin D. Wiechel
- mud client development systems Sunny Gulati
- mud client development systems J C Lawrence
- mud client development systems Per Vognsen
- mud client development systems Sunny Gulati
- mud client development systems Scatter
- mud client development systems Per Vognsen
- mud client development systems Chris Gray
- mud client development systems Jon Leonard
- mud client development systems Bruce Mitchener, Jr.
- mud client development systems Sunny Gulati
- mud client development systems Chris Gray
- Stack-Based NPC AI Eli Stevens {KiZurich}
- Stack-Based NPC AI Mark Gritter
- Stack-Based NPC AI Marc Hernandez
- Stack-Based NPC AI Richard Woolcock
- Stack-Based NPC AI Par Winzell
- Stack-Based NPC AI David Bennett
- Stack-Based NPC AI Mik Clarke
- Stack-Based NPC AI Felix A. Croes
- Introduction Mik Clarke
- Introduction Adam J. Thornton
- Introduction Mik Clarke
- Introduction ApplePiMan@aol.com
- Introduction Mik Clarke
- Thought Treasure Adam Wiggins
- Netscape's "Gecko" Browsing Engine (fwd) Nathan F Yospe
- Netscape's "Gecko" Browsing Engine (fwd) Adam Wiggins
- Netscape's "Gecko" Browsing Engine (fwd) Bruce Mitchener, Jr.
- Netscape's "Gecko" Browsing Engine (fwd) greear@cyberhighway.net
- Error tolerant UDP data streams J C Lawrence
- Error tolerant UDP data streams James Wilson
- Error tolerant UDP data streams J C Lawrence
- Error tolerant UDP data streams Ola Fosheim Grøstad
- ADMIN: (IMPORTNANT) Server down time and possible service interruption J C Lawrence
- [DevMUD] Error tolerant UDP data streams Darren Henderson
- MUD Design doc (long) Thinus Barnard
- MUD Design doc (long) Benjamin D. Wiechel
- MUD Design doc (long) Thinus Barnard
- MUD Design doc (long) J C Lawrence
- MUD Design doc (long) Koster, Raph
- MUD Design doc (long) Emil Eifrem
- MUD Design doc (long) Adam Wiggins
- MUD Design doc (long) Michael Willey
- MUD Design doc (long) Adam Wiggins
- MUD Design doc (long) J C Lawrence
- MUD Design doc (long) Mik Clarke
- MUD Design doc (long) Caliban Tiresias Darklock
- MUD Design doc (long) Thinus Barnard
- MUD Design doc (long) Mik Clarke
- MUD Design doc (long) Mik Clarke
- MUD Design doc (long) Travis Casey
- MUD Design doc (long) Nathan F Yospe
- MUD Design doc (long) Mik Clarke
- MUD Design doc (long) Nathan F Yospe
- MUD Design doc (long) Mik Clarke
- MUD Design doc (long) Nathan F Yospe
- MUD Design doc (long) Mik Clarke
- MUD Design doc (long) Adam Wiggins
- MUD Design doc (long) J C Lawrence
- MUD Design doc (long) Ling
- MUD Design doc (long) J C Lawrence
- MUD Design doc (long) Koster, Raph
- MUD Design doc (long) J C Lawrence
- MUD Design doc (long) Mik Clarke
- MUD Design doc (long) J C Lawrence
- MUD Design doc (long) J C Lawrence
- MUD Design doc (long) Emil Eifrem
- MUD Design doc (long) Travis Casey
- MUD Design doc (long) Emil Eifrem
- MUD Design doc (long) Travis Casey
- MUD Design doc (long) Emil Eifrem
- MUD Design doc (long) Travis S. Casey
- MUD Design doc (long) Caliban Tiresias Darklock
- MUD Design doc (long) Marian Griffith
- MUD Design doc (long) Koster, Raph
- MUD Design doc (long) Chris Gray
- MUD Design doc (long) Sunny Gulati
- MUD Design doc (long) J C Lawrence
- MUD Design doc (long) Chris Gray
- MUD Design doc (long) Benjamin D. Wiechel
- MUD Design doc (long) J C Lawrence
- MUD Design doc (long) Nathan F Yospe
- MUD Design doc (long) Chris Gray
- MUD Design doc (long) Emil Eifrem
- MUD Design doc (long) Chris Gray
- MUD Design doc (long) Mik Clarke
- MUD Design doc (long) Chris Gray
- MUD Design doc (long) Caliban Tiresias Darklock
- Hex grids. quzah [softhome]
- small dev-mud invite Chris Gray
- small dev-mud invite J C Lawrence
- mud client development systems Sunny Gulati
- mud client development systems Jay Carlson
- mud client development systems J C Lawrence
- AFAP: As fast as possible, non linear... quzah [softhome]
- AFAP: As fast as possible, non linear... Jon Leonard
- AFAP: As fast as possible, non linear... quzah [softhome]
- AFAP: As fast as possible, non linear... Mik Clarke
- AFAP: As fast as possible, non linear... Alex Oren
- AFAP: As fast as possible, non linear... Dan Shiovitz
- AFAP: As fast as possible, non linear... Mik Clarke
- AFAP: As fast as possible, non linear... quzah [softhome]
- AFAP: As fast as possible, non linear... quzah [softhome]
- AFAP: As fast as possible, non linear... Greg Connor
- AFAP: As fast as possible, non linear... quzah [softhome]
- Graphic design, client questions Thinus Barnard
- Graphic design, client questions Caliban Tiresias Darklock
- Graphic design, client questions Jo Dillon
- Graphic design, client questions Caliban Tiresias Darklock
- Graphic design, client questions Jo Dillon
- Graphic design, client questions Thinus Barnard
- Graphic design, client questions Sunny Gulati
- Graphic design, client questions J C Lawrence
- Graphic design, client questions Caliban Tiresias Darklock
- Graphic design, client questions J C Lawrence
- Graphic design, client questions J C Lawrence
- Graphic design, client questions Jay Carlson
- Graphic design, client questions Ben Greear
- More Laws, was DIS: Client-Server vs Peer-to-Peer Koster, Raph
- More Laws, was DIS: Client-Server vs Peer-to-Peer Ola Fosheim Grøstad
- More Laws, was DIS: Client-Server vs Peer-t o-Peer Koster, Raph
- More Laws, was DIS: Client-Server vs Peer-t o-Peer J C Lawrence
- More Laws Niklas Elmqvist
- More Laws J C Lawrence
- Re[2]:MUD Design doc (long) Michael Willey
- Re[2]:MUD Design doc (long) Adam Wiggins
- Re[2]:MUD Design doc (long) Caliban Tiresias Darklock
- Re[2]:MUD Design doc (long) J C Lawrence
- Re[2]:MUD Design doc (long) Sunny Gulati
- Re[2]:MUD Design doc (long) quzah [softhome]
- Re[2]:MUD Design doc (long) David Bennett
- Re[2]:MUD Design doc (long) quzah [softhome]
- Some useful links Niklas Elmqvist
- Response (Was MUD Design doc (long)) Ola Fosheim Grøstad
- Response (Was MUD Design doc (long)) Chris Gray
- Response (Was MUD Design doc (long)) J C Lawrence
- example custom protocol and its uses Chris Gray
- client stuff... Andrew Wilson
- Developing a MUD for the first time? Alex Oren
- Re[2]:MUD Design doc (long) J C Lawrence
- [DevMUD] Database module J C Lawrence
- [DevMUD] Database module cynbe@muq.org
- [DevMUD] Database module J C Lawrence
- [DevMUD] Database module cynbe@muq.org
- [DevMUD] Database module T. Alexander Popiel
- [DevMUD] Database module Jay Carlson
- [DevMUD] Database module cynbe@muq.org
- [DevMUD] Database module Felix A. Croes
- Re[2]:MUD Design doc (long) Caliban Tiresias Darklock
- [RRE]AAAI 1999 Fall Symposium: Narrative Intelligence Bruce Mitchener, Jr.
- (fwd) DESIGN: Proposed topic of Discussion (Injecting Pure Signal) J C Lawrence
- Terragen Vadim Tkachenko
- [RELEASE] Insanity To Infinity (I:I_OS) v.01a Bobby Bailey
- [RELEASE] Insanity To Infinity (I:I_OS) v.01a Robin Carey
- [RELEASE] Insanity To Infinity (I:I_OS) v.01a Bobby Bailey
- META: 1998 Topic Summary Jon A. Lambert
- [RELEASE] Insanity To Infinity (I:I_OS) v.02a Bobby Bailey
- ADMIN: New text formatting rule for MUD-Dev J C Lawrence
- More Laws Jon A. Lambert
- More Laws Travis Casey
- MUD Design doc - Combat Jon A. Lambert
- MUD Design doc - Combat J C Lawrence
- MUD Design doc - Combat cynbe@muq.org
- MUD Design doc - Combat Koster, Raph
- MUD Design doc - Combat Caliban Tiresias Darklock
- MUD Design doc - Combat quzah [softhome]
- MUD Design doc - Combat Caliban Tiresias Darklock
- MUD Design doc - Combat T. Alexander Popiel
- MUD Design doc - Combat J C Lawrence
- MUD Design doc - Combat Koster, Raph
- MUD Design doc - Combat Adam Wiggins
- MUD Design doc - Combat J C Lawrence
- MUD Design doc - Combat quzah [softhome]
- MUD Design doc - Combat Dr. Cat
- MUD Design doc - Combat T. Alexander Popiel
- MUD Design doc - Combat Caliban Tiresias Darklock
- MUD Design doc - Combat J C Lawrence
- MUD Design doc - Combat James Wilson
- MUD Design doc - Combat Nathan F Yospe
- MUD Design doc - Combat James Wilson
- MUD Design doc - Combat Nathan F Yospe
- MUD Design doc - Combat diablo@best.com
- MUD Design doc - Combat Kristen Koster
- MUD Design doc - Combat Chris Gray
- MUD Design doc - Combat Scatter
- MUD Design doc - Combat Koster, Raph
- MUD Design doc - Combat Kristen Koster
- MUD Design doc - Combat Caliban Tiresias Darklock
- MUD Design doc - Combat T. Alexander Popiel
- Levels versus Skills, who uses them and when. Till Eulenspiegel
- Levels versus Skills, who uses them and when. Travis Casey
- Levels versus Skills, who uses them and when. Koster, Raph
- Levels versus Skills, who uses them and when. Adam Wiggins
- Levels versus Skills, who uses them and when. Marian Griffith
- Levels versus Skills, who uses them and when. Andy Cink
- Levels versus Skills, who uses them and when. Ling
- Levels versus Skills, who uses them and when. Till Eulenspiegel
- Levels versus Skills, who uses them and when. Caliban Tiresias Darklock
- Levels versus Skills, who uses them and when. Justin Robinson
- Levels versus Skills, who uses them and when. Andy Cink
- Levels versus Skills, who uses them and when. Mik Clarke
- Levels versus Skills, who uses them and when. J C Lawrence
- Levels versus Skills, who uses them and when. Koster, Raph
- Levels versus Skills, who uses them and when. J C Lawrence
- Levels versus Skills, who uses them and when. Koster, Raph
- Levels versus Skills, who uses them and when. Adam Wiggins
- Levels versus Skills, who uses them and when. Marian Griffith
- Levels versus Skills, who uses them and when. J C Lawrence
- Levels versus Skills, who uses them and when. Marian Griffith
- Levels versus Skills, who uses them and when. J C Lawrence
- Levels versus Skills, who uses them and when. Alex Oren
- Levels versus Skills, who uses them and when. Mik Clarke
- Levels versus Skills, who uses them and when. Adam Wiggins
- Levels versus Skills, who uses them and when. J C Lawrence
- Levels versus Skills, who uses them and when. Koster, Raph
- Levels versus Skills, who uses them and when. Mik Clarke
- Levels versus Skills, who uses them and when. Matt Wallace
- Levels versus Skills, who uses them and when. Adam Wiggins
- Levels versus Skills, who uses them and when. Adam Wiggins
- Levels versus Skills, who uses them and when. Marian Griffith
- Levels versus Skills, who uses them and when. J C Lawrence
- Levels versus Skills, who uses them and when. Koster, Raph
- Levels versus Skills, who uses them and when. Caliban Tiresias Darklock
- Levels versus Skills, who uses them and when. Andy Cink
- Levels versus Skills, who uses them and when. Koster, Raph
- Levels versus Skills, who uses them and when. Caliban Tiresias Darklock
- Levels versus Skills, who uses them and when. J C Lawrence
- Levels versus Skills, who uses them and when. Caliban Tiresias Darklock
- Levels versus Skills, who uses them and when. Andy Cink
- Levels versus Skills, who uses them and when. Koster, Raph
- Levels versus Skills, who uses them and when. Caliban Tiresias Darklock
- Levels versus Skills, who uses them and when. Marian Griffith
- Levels versus Skills, who uses them and when. Caliban Tiresias Darklock
- Levels versus Skills, who uses them and when. Koster, Raph
- Levels versus Skills, who uses them and when. Mik Clarke
- Levels versus Skills, who uses them and when. Koster, Raph
- Levels versus Skills, who uses them and when. Adam Wiggins
- Levels versus Skills, who uses them and when. J C Lawrence
- Levels versus Skills, who uses them and when. Holly Sommer
- Levels versus Skills, who uses them and when. Adam Wiggins
- Levels versus Skills, who uses them and when. J C Lawrence
- Levels versus Skills, who uses them and when. Mik Clarke
- Levels versus Skills, who uses them and when. Matt Wallace
- Levels versus Skills, who uses them and when. J C Lawrence
On Thu, 14 Jan 1999 20:36:54 -0800 (PST)
Matt Wallace<matt@ender.com> wrote:
> Incidentally, we also use this for a great deal of permanent
> memory features, allowing our builders to (as part of builder
> defined mob/obj progs) set, clear, and check bits from another 8k
> (they get those bits matching their vnums), which is "remembered"
> between sessions, they can use for various purposes. Quest
> results, whether a player has assaulted a certain race of mobiles,
> perhaps -- whatever strikes their fancy.
I have a concept I call "probability fields". In essence these are
arbitrary collections of weights attached to objects or areas
(bounded volumes of space) which are applied to probability
computations.
Translation: An object, or an area (part of the game) can change
the balance of "luck" for anything relating to it. There are many
flavours of "luck" (eg combat strike, combat defend, injury,
lottery, etc), each of which can be affected by this "change" in a
positive or negative manner. Additionally such luck may be tied
very specifically to particular forms of actions or those involving
particular objects ("You will be lucky with XXX.").
Thus, for instance a "lucky sword" could increase the players chance
of getting good strikes, etc.
The intended use of this is to create "lucky areas" and "lucky days"
for players. On some days it would seem that nothing could go wrong
for a given character. On other days it might seem that nothing
could go right. The underlieing intention was to track player
behaviour against an "desirable play style" scale, and thus move
their luck modifiers about accordingly. Further, the underlieing
base field monitors practiced limited positive feedback -- good luck
(positive returns from probability computations) tended to feed back
into higher luck field weights, with bad luck similarly feeding on
itself (the positive feedback is needed to make sure the pendulum
swings and never really rests; other factors are used to damp the
rate of swing (mainly trigger values)).
Player does something an admin really doesn't like, but the admin
can't be seen to be intervening? No problem: Just touch the guy's
probability fields and give him a hard time in such areas in future.
It doesn't handle the problem, it just influences the default. The
other big part of the intention was to make luck, and the perception
of luck, something that players could be indirectly aware of,
influence, and attempt to (poorly) control, thus adding a silent
third handl to most interactions:
> i
You are wearing impenetrable ultimate armour and are wielding
the sword of insta-kill.
> stats
You are feeling pretty unlucky.
> l
Bubba is here.
> l at bubba
Bubba looks like an utter wimp and is carring a rutsy butter
knife.
> look at bubba's luck
Bubba looks incredibly lucky.
> say, "Oh shit!
> flee!
Anyway, to get back to the point, the problem of course is storage.
There are several dozen different probability fields. Additionally
some affects on probability fields are temporary (eg a player can
cast a luck spell on himself or another, giving the target an extra
dose of good/bad luck of a particular type for a defined period), or
are subject to or otherwise affected by external influences ("You
are lucky with women as long as they don't have red hair."). The
result is that I need dozens of values stored, each of which is
supported by a database of potentially active calculations (ie
volatile values which need to be re-computed on every query) etc etc
etc. Ugly. Expensive.
Final implementation:
Probability fields are stored in the following structures which
are attached to objects or bounded spaces:
1) A tuple which contains two lists and a timestamp as to the
last time the list in #1b was updated:
a) A list of records, each containing a list of tuples each of
which contains a probability field name, a qualifying call, and
either an absolute weight or a call that reutrns a weight.
b) A list of tuples, hashed by probability field name.
i) Each tuple stores its name, the current summated weight
for that field (last query), and a list of references to entries in
the #1a list.
Originally this was all accomplished via spoofs and having the
spoofs mutate the probability calculations on the way thru to the
base object. That proved extremely expensive at runtime as well as
exposing horrible potential leaks in spoofs which failed to clean up
after themselves when they fell out of scope/validity.
Using the above dynamic database approach is more complex and far
less generic, but also works. Further, as repeated and rapid
probability calculations can be expensive due to the many qualifying
and/or weight calls (#1a), the timestamp in #1 is used to have #1a
and its supported #1bi only recalculated periodically (I think I'm
using 50 seconds as my current cap) or upon significant state change
in the object the whole mess is hung off (currently not
implemented). The result is that most probability chekcs of course
only reference #1bi, which is pretty cheap.
--
J C Lawrence Internet: claw@kanga.nu
(Contractor) Internet: coder@kanga.nu
---------(*) Internet: claw@under.engr.sgi.com
...Honorary Member of Clan McFud -- Teamer's Avenging Monolith...
- Levels versus Skills, who uses them and when. J C Lawrence
- Levels versus Skills, who uses them and when. Mik Clarke
- Levels versus Skills, who uses them and when. D. B. Brown
- Levels versus Skills, who uses them and when. Mik Clarke
- Levels versus Skills, who uses them and when. J C Lawrence
- Levels versus Skills, who uses them and when. J C Lawrence
- Levels versus Skills, who uses them and when. Vladimir Prelovac
- Levels versus Skills, who uses them and when. J C Lawrence
- Levels versus Skills, who uses them and when. Caliban Tiresias Darklock
- Levels versus Skills, who uses them and when. Nathan F Yospe
- Levels versus Skills, who uses them and when. J C Lawrence
- Levels versus Skills, who uses them and when. J C Lawrence
- Levels versus Skills, who uses them and when. Jon A. Lambert
- Levels versus Skills, who uses them and when. Travis S. Casey
- Levels versus Skills, who uses them and when. Caliban Tiresias Darklock
- Levels versus Skills, who uses them and when. J C Lawrence
- Levels versus Skills, who uses them and when. Petri Virkkula