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
On Thu, 17 Dec 1998 11:57:36 +0100
Emil Eifrem<emil@prophecy.lu> wrote:
> At 04:31 AM 12/17/98 , J C Lawrence wrote:
>> Should there actually be *ANY* distinguishing features between
>> NPC's and players other than the source of their actions? There
>> are good reasons for both approaches and reasonable design
>> methods to salve most of each other's problems.
> What good reasons are there for separating NPCs and PCs?
The usual argument is simplicity and performance. By making them
the same you remove the possibility of using short-circuit logic in
your NPC's or their AI's, thus imposing extra logic which is really
only needed for players and their typoes, command goofs,
guess-the-verb-games etc. By devolving NPC's to a simpler form you
can bypass that and present a much simpler and in many ways more
elegant API to the NPC AI's.
George Reese IIRC has written articulately on this in
rec.games.mud.*, but I'm unable to find the reference right now.
>> A well defined inheritance model can do wonders as can a good
>> grammar, which brings up the questions:
>>
>> Central grammar and vocabulary?
>>
>> Standardised grammar at all?
>>
>> Per-object dynamic vocabulary?
> Per-object dynamic vocabulary was quite extensively discussed in
> an earlier thread that I read up on in the archives. Did you guys
> reach a conclusion on a reasonable design?
No. It has the advantage of simplicity on the server side, and the
disadvantages of fostering bad-reuse, guess-the-verb games, and
logical vocabulary inconsistancies.
Both *can* be done equally well. The problem is the everlastingly
fallable maintenance, area, and user programmers.
> It may be too game specific a problem for a generic solution, I
> guess.
Quite.
> I'm pretty ambivalent on this issue. It's a 'flexibility vs
> consistency' matter for me: I want the flexibility of letting a
> builder add the verb "smell" to a mob's (or character or any
> Living) vocabulary when the mob picks up a flower. But I strongly
> dislike the fact that if I drop the flower and walk into another
> room, "smell" would give a "Huh!?".
Ditto. My current approach is a global vocabulary and grammar, and
local overloaded definitions.
> The other consistency problem (which that thread opened my eyes
> to) is the case when you have a zillion buttons in the world which
> all add the verb "push" to your vocabulary and respond
> accordingly, except one tiny little one built by NewbieJoeBuilder,
> which responds to "press." No fun.
Bingo.
> The last problem can be solved administratively. One approach is
> to maintain a list (a physical document, not a data structures
> list) of different types of objects and the verbs they shall use
> for different actions. (Such as "buttons: if a character push it,
> add the 'push' word to its vocab".)
Allowing vocabulary to be part of the inheritance tree (cf Cold)
such that objects inherit their verbs from the parents can go a long
way. There are ugly problems with multiple inheritance and verbs of
course, as well as multiple base objects, but that's another
crusade.
> That approach would soon get unreasonable -- both for the
> NewbieJoeBuilder who needs to look through a monstrous file for
> every lil object he builds and for
> ExperiencedJackMaintainerOfTheList who has to maintain the dang
> thing and update it as new object types come along in the game.
<nod>
Making a useful set of base verbs on your base classes and then
inheriting them into the instanced children *can* do a lot to handle
this. It can't do it all, but it helps.
> One could also have a head builder that walks through all areas to
> check the dynamic vocabulary but that does tend to hamper
> productivity.
And such administration scales wonderfully.
> What solutions are there for #1? I had some thoughts along the
> line of instead of removing the verb from vocabulary, just cancel
> the action and replace it with a can't-find-it message. So typing
> smell in the other room (w/o a flower in it) would give you a "But
> you've dropped your flower!" or whatever message.
It took me a lot of brain beating, but I finally game up on
per-object vocabularies (I was a big proponent for its simplicity
effects). Using a global vocabulary with default (crude)
definitions and well defined and dynamic contextual overloading of
those base definitions current seems the way to go for me. I
haven't cut code there *yet*, but the design seems basically sound
once I get a decent context analyser mapped out.
> Or maybe just for every character (/mobile/etc) object keep track
> of the item last associated with a dynamically added verb. So
> "smell" with an absent flower would give a "You don't see a flower
> here." message.
Uhh huh,
> l
There is a flower and shot cow pies here.
> smell
The cow manure smells something horrid.
> get flower
You pick up the flower, kneeling in the manure in the process.
> drop flower
> n
> smell
You don't have the flower any more.
>> Rules for genating precedence and grammar rules with dynamic
>> vocabularies?
>>
>> Is grammar a dynamically inherited structure across objects?
> So Sword would inherit the grammar of Weapon? Hmmm...
Bingo. See Cold/ColdX for a working example.
> I'm not even sure how, and why, having dynamic grammar attached to
> objects would work. Pros and cons, anyone? And how?
I'll bow out here to the various Cold people on the list.
> [timing in combat:]
>> In #1 each player action (eg "bash buffa") takes a preset length
>> of time, and prevents the player character's motions/actions
>> during that time.
>>
>> #2 is a little different. Players submit the actions that their
>> characters are going to perform in the next "round", where a
>> round is a known and predefined length of time. At the end of
>> the round all the various actions by the various players are
>> resolved against each other (the action and round resolution
>> logic can be quite complex -- see the combat package threads in
>> the list archives) and the final results computed and reported
>> before the next round starts and the players again submit their
>> intended actions. It is common with round systems for player
>> characters to operate under a quota system, where each of their
>> proposed actions has a quota value and their total must not
>> exceed some maximum. See Jon Lambert's posts on his (IIRC) round
>> based combat system for some interesting design notes on this
>> area.
>>
>> #3 is where I've been heading, while mixing in generous dollops
>> of #1 and #2. Loosely, each character does whatever he can as
>> fast as he can with the limiting factor being the execution time
>> of his various actions and the speed with which he can submit
>> them. Arguments about fairness are of course rife with this
>> approach.
> Ack. Haven't your players heard of tintin?
Yes. Its not necessarily a problem with untimed combat. One of my
pet criteria is that any game which can be usefully automated has
demonstrated the failure of its design.
> Surely you must have some way to delay a player's queing commands
> while they're busy doing something else. For example, say you have
> a spell that causes damage. According to the above, a fight
> between two people with this spell would basically be a fight
> between their clients and connections -- whomever gets through
> most "cast my damagespell" messages would win.
Not quite. Wiggins has already given simple cases where this is not
the case.
> This doesn't sound feasible, so I assume that you do have
> individual delays after commands. I think that's what you mean
> with the limiting factor being the execution time of various
> actions. So the execution time for cast damagespell would be
> pretty high and thus not unbalance the game. I don't see how
> that's different from 1?
Aside: One of the reasons I'm not concerned about
inter-client/lag_balance wars is that I actively encourage and
support free user programming. As such, players are free to program
their own combat code/scripts/packages to automate whatever they may
wish. The result? Yes, many combats will derive to who has the
better/faster/luckier combat automation. I don't see this as a
problem.
As for timing of individual acts, no I don't control this, and I do
assume that similar actions performed by two characters are likely
(this is not true BTW, but I assume it anyway as the exceptions are
either generally realisitic or prone to amusing and interesting
abuse by players) to execute in similar lengths of time. Further,
while a player's commands normally execure serially, they can
execute in parallel (player character doing multiple things at the
same time). I do very little to restrict this other than factoring
it into the luck and sloppiness fields (a parallelly executed
command suffers runtime penalties).
The result? Yes, from one viewpoint the question is who can enter
the most commands most rapidly. However that's a false viewpoint as
the combat structure is heavily predisposed to tactical reactions
(ie very interactive and supportive of prior preparation) as versus
a simple pile-on-the-hp's. A player character coming in swinging a
broadsword as fast as he can might get a couple whacks in -- until
his opponent freezes him and then disects him at leisure while the
attacker's command buffer empties. Even if the attacker notices the
freeze, by the time he cancels his command buffer and usefully
reacts it is likely to be too late as his opponent now has the
timeing advantage.
> [independent time ratio:]
>> > stats You are 10 days old.
>> > stats bubba Bubba is 10 days old.
>> > stats boffo Boffo is 10 days old.
>> ...play the game for a while...
>> > stats You are 50 days old.
>> > stats bubba Bubba is 30 days old.
>> > stats boffo Boffo is 168 days old.
>>
>> I don't however see this as a problem
> This is the approach used by most DIKU-derivatives.
There are two main differences:
1) Nobody logged off in the above example.
2) I don't remove characters from the game when their players logout.
> In my experience, players will acccept unrealistic things as long
> as they are consistent and at least somewhat logical. Most of our
> wacky magical systems being a good example.
Quite. For me time is one of the things a player can causitively
affect in his game environment, both for himself and for other
characters. Temporal inconsistencies are the expected norm.
--
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... - 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
- 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