August 1998
- Affordances and social method (Was: Wired Jon A. Lambert
- (Fwd) **NOTICE REGARDING YOUR SEARCHLIGHT SOFTWARE** Jon A. Lambert
- (Fwd) **NOTICE REGARDING YOUR SEARCHLIGHT SOFTWARE** John Bertoglio
- (Fwd) **NOTICE REGARDING YOUR SEARCHLIGHT SOFTWARE** Caliban Tiresias Darklock
- OT: BBSs, s001gmu@nova.wright.edu
- Ansii color, needing some specs and or pointer Jon A. Lambert
- Ansii color, needing some specs and or pointer Caliban Tiresias Darklock
- (fwd) "Smart" monsters Nathan Fenenga Yospe
- Interesting poll Koster, Raph
- Interesting poll John Bertoglio
- Milgram experiment (was WIRED: Kilers have more fun) Mike Sellers
- Implementing god. quzah
- Implementing god. Adam J. Thornton
- Implementing god. J C Lawrence
- Implementing god. Adam J. Thornton
- Implementing god. Koster, Raph
- Implementing god. Adam J. Thornton
- Implementing god. Koster, Raph
- Implementing god. J C Lawrence
- Implementing god. Marian Griffith
- Implementing god. Adam J. Thornton
- Implementing god. Andy Cink
- Blender: free version J C Lawrence
- Blender: free version J C Lawrence
- Blender: free version Adam Wiggins
- UOL/Linux client URLs J C Lawrence
- Socket-Script: Socket-capabable script language and matching library J C Lawrence
- Socket-Script: Socket-capabable script language and matching library Adam J. Thornton
- Socket-Script: Socket-capabable script language and matching library Chris Gray
- Socket-Script: Socket-capabable script language and matching library Chris Gray
- Socket-Script: Socket-capabable script language and matching library Adam J. Thornton
- Socket-Script: Socket-capabable script language and matching library Nathan F Yospe
- Socket-Script: Socket-capabable script language and matching library Adam J. Thornton
- Socket-Script: Socket-capabable script language and matching library ##Make Nylander
- Socket-Script: Socket-capabable script language and matching library Adam J. Thornton
- Socket-Script: Socket-capabable script language and matching library Ola Fosheim Grøstad
- Why threading? (Was: Output Classification Notes) Ola Fosheim Grøstad
- Why threading? (Was: Output Classification Notes) J C Lawrence
- Secrets of the Game Designers s001gmu@nova.wright.edu
- 3D World Models Leach, Brad BA
- 3D World Models S. Patrick Gallaty
- Toba Java->C Adam J. Thornton
- [IDEAS] Starting from scratch Franklyn Colebrooke, Jr.
- [IDEAS] Starting from scratch Adam J. Thornton
- [IDEAS] Starting from scratch Hans-Henrik Staerfeldt
- [IDEAS] Starting from scratch Adam Wiggins
- [IDEAS] Starting from scratch Leach, Brad BA
- [IDEAS] Starting from scratch T. Alexander Popiel
- [IDEAS] Starting from scratch Adam Wiggins
- [IDEAS] Starting from scratch J C Lawrence
- [IDEAS] Starting from scratch Ross Nicoll
- [IDEAS] Starting from scratch T. Alexander Popiel
- [IDEAS] Starting from scratch Holly Sommer
- [IDEAS] Starting from scratch T. Alexander Popiel
- [IDEAS] Starting from scratch Nathan F Yospe
- [IDEAS] Starting from scratch Holly Sommer
- [IDEAS] Starting from scratch T. Alexander Popiel
- [IDEAS] Starting from scratch s001gmu@nova.wright.edu
- [IDEAS] Starting from scratch Matt Chatterley
- [IDEAS] Starting from scratch Ross Nicoll
- [IDEAS] Starting from scratch Ross Nicoll
- [IDEAS] Starting from scratch Ross Nicoll
- [IDEAS] Starting from scratch J C Lawrence
- [IDEAS] Starting from scratch J C Lawrence
- [IDEAS] Starting from scratch Adam Wiggins
- Question regarding Java threads Jon A. Lambert
- Question regarding Java threads Chris Gray
- Question regarding Java threads Vadim Tkachenko
- Question regarding Java threads Ben Greear
- Question regarding Java threads J C Lawrence
- Question regarding Java threads Ben Greear
- Question regarding Java threads Jon A. Lambert
- Question regarding Java threads Chris Gray
- Question regarding Java threads Matt Chatterley
- Question regarding Java threads Ben Greear
- Protocols Vadim Tkachenko
- Events s001gmu@nova.wright.edu
- after the plague: mud report S. Patrick Gallaty
- after the plague: mud report quzah
- after the plague: mud report Adam Wiggins
- after the plague: mud report Ling
- Object Storage Fact Book, Release 4.0 (fwd) Nathan F Yospe
- Affordances and social method (Was: Wire d Magazine...) J C Lawrence
- META: List combat character and racial memory (was Re: J C Lawrence
- META: List combat character and racial memory (was Re: kamikaze@kuoi.asui.uidaho.edu
- Black Isle's Baldur's Gate J C Lawrence
- Black Isle's Baldur's Gate Koster, Raph
- Black Isle's Baldur's Gate Chris Gray
- Black Isle's Baldur's Gate Koster, Raph
- 208.240.161.41 Adam J. Thornton
- 208.240.161.41 Vadim Tkachenko
- ADMIN: Advertising on MUD-Dev J C Lawrence
- ADMIN: Advertising on MUD-Dev Chris Gray
- ADMIN: Advertising on MUD-Dev Caliban Tiresias Darklock
- ADMIN: Advertising on MUD-Dev Ola Fosheim Grøstad
- ADMIN: Advertising on MUD-Dev J C Lawrence
- ADMIN: Advertising on MUD-Dev Vadim Tkachenko
- ADMIN: Advertising on MUD-Dev Adam Wiggins
- ADMIN: Advertising on MUD-Dev Robert Woods
- ADMIN: Advertising on MUD-Dev Richard Woolcock
- ADMIN: Advertising on MUD-Dev Jeroen Ruigrok/Asmodai
- ADMIN: Advertising on MUD-Dev quzah
- ADMIN: Advertising on MUD-Dev Richard Woolcock
- ADMIN: Advertising on MUD-Dev Jeroen Ruigrok/Asmodai
- ADMIN: Advertising on MUD-Dev T. Alexander Popiel
- ADMIN: Advertising on MUD-Dev Mike Sellers
- ADMIN: Advertising on MUD-Dev J C Lawrence
- ADMIN: Advertising on MUD-Dev Michael Hohensee
- ADMIN: Advertising on MUD-Dev s001gmu@nova.wright.edu
- ADMIN: Advertising on MUD-Dev J C Lawrence
- ADMIN: Advertising on MUD-Dev quzah
- ADMIN: Advertising on MUD-Dev John Bertoglio
- ADMIN: Advertising on MUD-Dev Caliban Tiresias Darklock
- ADMIN: Advertising on MUD-Dev quzah
- ADMIN: Advertising on MUD-Dev Caliban Tiresias Darklock
- ADMIN: Advertising on MUD-Dev s001gmu@nova.wright.edu
- ADMIN: Advertising on MUD-Dev Chris Gray
- ADMIN: Advertising on MUD-Dev Scatter
- ADMIN: Advertising on MUD-Dev J C Lawrence
- Adverts in email on the list. Ben Greear
- Adverts in email on the list. quzah
- Adverts in email on the list. Jon A. Lambert
- Adverts in email on the list. Holly Sommer
- Adverts in email on the list. Vadim Tkachenko
- Ethernet NICS, maximum connections..mud testing. Ben Greear
- Ethernet NICS, maximum connections..mud testing. Vadim Tkachenko
- Ethernet NICS, maximum connections..mud testing. Ben Greear
- Ethernet NICS, maximum connections..mud testing. Chris Gray
- lurker emerges James Wilson
- lurker emerges Chris Gray
- lurker emerges Adam J. Thornton
- lurker emerges Chris Gray
- lurker emerges Petri Virkkula
- lurker emerges T. Alexander Popiel
- lurker emerges James Wilson
- lurker emerges T. Alexander Popiel
- lurker emerges Vadim Tkachenko
- lurker emerges Ben Greear
- lurker emerges J C Lawrence
- lurker emerges T. Alexander Popiel
- lurker emerges Vadim Tkachenko
- lurker emerges T. Alexander Popiel
- lurker emerges Vadim Tkachenko
- lurker emerges T. Alexander Popiel
- lurker emerges Vadim Tkachenko
- lurker emerges T. Alexander Popiel
- lurker emerges Vadim Tkachenko
- lurker emerges Vadim Tkachenko
- lurker emerges Chris Gray
- lurker emerges Vadim Tkachenko
- lurker emerges J C Lawrence
- lurker emerges Petri Virkkula
- lurker emerges J C Lawrence
- lurker emerges Petri Virkkula
- lurker emerges Chris Gray
- lurker emerges J C Lawrence
- Adverts in email on the list. Chris Gray
- Fw: lurker emerges James Wilson
- Fw: lurker emerges T. Alexander Popiel
- Ethernet NICS, maximum connections..mud testing. Chris Gray
- Ethernet NICS, maximum connections..mud testing. Chris Gray
- Neat surrealistic graphical mudclients in Java? Ola Fosheim Grøstad
- Ethernet NICS, maximum connections..mud testing. Chris Gray
- Ethernet NICS, maximum connections..mud testing. J C Lawrence
- Ethernet NICS, maximum connections..mud testing. Adam J. Thornton
- Ethernet NICS, maximum connections..mud testing. Ben Greear
- META/ADMIN: ADMIN: Advertising on MUD-Dev Mike Sellers
- META/ADMIN: ADMIN: Advertising on MUD-Dev Ola Fosheim Grøstad
- Rule #3 S. Patrick Gallaty
- OT: Ethernet NICS, maximum connections..mud testing. Shawn Halpenny
- OT: Ethernet NICS, maximum connections..mud testing. Vadim Tkachenko
- META: List combat character and racial memory (was Re: Chris Gray
- List of rules suggestionbox Hans-Henrik Staerfeldt
- List of rules suggestionbox Caliban Tiresias Darklock
- async i/o and threads (was: lurker emerges) James Wilson
- async i/o and threads (was: lurker emerges Jon A. Lambert
- async i/o and threads (was: lurker emerges James Wilson
- async i/o and threads (was: lurker emerges Jon A. Lambert
- Amoeba: Distributed OS release J C Lawrence
- clients anyone?... Andrew Wilson
- clients anyone?... Adam J. Thornton
- clients anyone?... Andrew Wilson
- clients anyone?... Hans-Henrik Staerfeldt
- clients anyone?... Adam J. Thornton
- clients anyone?... Bruce Mitchener, Jr.
- clients anyone?... James Wilson
- clients anyone?... Adam J. Thornton
- clients anyone?... Andrew Wilson
- clients anyone?... Adam J. Thornton
- clients anyone?... Andrew Wilson
- clients anyone?... Adam J. Thornton
- clients anyone?... Adam Wiggins
- clients anyone?... Andrew Wilson
- clients anyone?... J C Lawrence
- clients anyone?... Andrew Wilson
- Re:Methods to Reduce Ecological Wipeout Michael.Willey@abnamro.com
- ADMIN: Over quoting (again) J C Lawrence
- JASSS: The Journal of Artificial Societies and Social Simulation J C Lawrence
- Methods to Reduce Ecological Wipeout Leach, Brad BA
- Methods to Reduce Ecological Wipeout s001gmu@nova.wright.edu
- Methods to Reduce Ecological Wipeout quzah
- Methods to Reduce Ecological Wipeout Michael.Willey@abnamro.com
- Methods to Reduce Ecological Wipeout Koster, Raph
- Methods to Reduce Ecological Wipeout Michael.Willey@abnamro.com
- Methods to Reduce Ecological Wipeout Koster, Raph
- Methods to Reduce Ecological Wipeout Brandon J. Rickman
- Methods to Reduce Ecological Wipeout quzah
- Methods to Reduce Ecological Wipeout Marian Griffith
- Methods to Reduce Ecological Wipeout Damion Schubert
- Methods to Reduce Ecological Wipeout J C Lawrence
- Methods to Reduce Ecological Wipeout J C Lawrence
- LinuxThreads and SIGUSR1 (Ref: [MUD-Dev]) Adam J. Thornton
- Eye movement. quzah
- Eye movement. James Wilson
- Eye movement. quzah
- Eye movement. S. Patrick Gallaty
- Eye movement. T. Alexander Popiel
- Eye movement. Hans-Henrik Staerfeldt
- OGR: Ion Storm's Witchboy talks about the functionality of enemy AI. J C Lawrence
http://www.ogr.com/specials/guest_column1_1.shtml
--<cut>--
Exclusive on Online Gaming Review
Harvey Smith: Guest Column
Ion Storm's Witchboy talks about
the functionality of enemy AI.
DISTINCT FUNCTION IN GAME UNITS Part 1
By Witchboy
As with weapon differentiation, if each enemy has a particular
function in the game world (and it is obvious and/or something the
player can learn over time) then the player can make informed
decisions about how to deal with each enemy (which becomes a game
dynamic). The alternative (in which all enemies do basic variations of
the same thing - race forward and inflict damage) is boring.
Enemy Differentiation and Available Responses
Enemies. Monsters. Sprites. AI's. NPC's. Creatures. Villains. What
are they? More specifically, in computer games what are they? Hurdles
that must be overcome in order to reach the exit to the level?
Simulated opponents that try to kill the player or stop his progress?
Cool renders with interesting attack, fidget and death animations?
Collections of stats?
All of the above, I suppose, but one of my pet peeves is that many
game designers seem to have forgotten (or have never learned) how to
make interesting and distinctly different enemies. Or even what that
really means.
If a game has a line-up of creatures that look awesome but simply
represent an ever-ascending set of numbers in several fields, then
chances are that game will get boring quickly. Or at least it will not
be as exciting as it could have been, had the designer planned out the
creature's role in the game at an abstract level.
Think about Defender (and Stargate), the classic arcade games by
Williams Electronics. Let's choose three of their units, the Lander,
the Mutant and the Bomber.
The Lander flew slowly and occasionally fired a shot at the player. If
given the chance the Lander would descend to the surface below to pick
up one of the humanoids that the player was supposed to be
protecting. When a Lander grabbed a humanoid, it would rise toward the
upper levels of the atmosphere, suddenly firing like mad; when it
reached the top of the screen, the humanoid was destroyed and the
Lander would become a Mutant.
The Mutant was faster than the Lander and *much* more aggressive -
always making a headlong attack when it spotted the player. The Mutant
also had an erratic flight pattern, making it less predictable harder
to evade.
The Bomber was slow and peaceful for the most part, but it left a
trail of bombs that hung in space; if the player contacted one of the
bombs, his ship was destroyed.
Discounting their appearances and fictional identities completely,
think about how different these three units are... Think about the
ways in which they are different within the game's framework of
actions and mechanics. In these three units you have essentially
Movement Rate, Flight Type, Aggression Level and Special Ability. The
special abilities (an arbitrary term) for these units were
respectively: L) consume humanoids then change unit types, M) pursue
the player aggressively and B) leave a trail of explosives. (Note:
The Lander's ability to consume resources - the humanoids - is doubly
brilliant. The game-play is made dynamic because the Lander changes
from a relatively weak enemy to really critical enemy as soon as it
picks up a humanoid. The player must immediately switch gears and deal
with the threat of the Lander becoming a Mutant, or suffer the
consequences.)
In many games (old and new), the enemy design was nowhere near as
interesting and distinct. To use two hypothetical examples: Creature
One can move at a game speed of 50, does 37 points of damage in an
attack and has 100 hit points. Creature Two can move at a game speed
of 75, does 12 points of damage in an attack and has 30 hit
points. And so on. In some games, this is all you get. The problem is
that this sort of design does not cause the player to dynamically
adjust his play. It does not force the player to make any critical
decisions about how to react to a game enemy; the reaction is
generally always the same, since the enemies are fundamentally the
same.
Game designers should want to 1) present players with a series of
distinct and challenging situations, 2) give them enough information
so that they can decide how to react and 3) provide they with a set of
in-game actions that will allow them to execute on their decisions,
with consequences.
To illustrate my points, I'll create an example game enemy. And let's
make an enemy relevant to more modern games than Defender, lest
someone cry, "Games have changed; the old rules do not apply!" For
our example, I will use a crocodile, set in a 3d world-an environment
in which we'll state that the player can run and swim. Fairly standard
stuff, and an area in which designers routinely short-change players
by not making things interesting enough.
Now, for the crocodile we're discussing, you could just make it a big
green lizard with lots of hit points, an appropriate movement speed
and a large set of jaws that do damage to the player. To do so would
not be horrible--after all, this creature would be somewhat different
from the game's other enemies simply because it is capable of chasing
the player through water. (See Tomb Raider for such examples in its
crocodiles, bears, raptors and wolves.) But if this is the extent to
which our example crocodile is unique, it is then essentially the same
as a bear with a few different stats and the ability to swim. We can
do better if we add just a few interesting and unique attributes.
DISTINCT FUNCTION IN GAME UNITS Part 2
By Witchboy
So our crocodile will have three more features.
First, let's assume our player's in-game character can hold his breath
for a specific period. We'll then say that when our crocodile succeeds
in biting the character in the water, the player loses some of his
precious "breath" (and of course when the player reaches zero, he
drowns). Suddenly the player must rethink his strategies related to
how long he can swim underwater, what distances he can reach, whether
he needs to dispatch or distract enemies on land before entering the
water, etc. If the player did much swimming in the game before meeting
his first crocodile (on previous 'levels' or whatever, encountering
other types of water features such as current flows and small fish),
he will now have to adjust the way he plays because the game has
changed. Imparting our crocodile with this one attribute has made the
game a dynamic experience. (Now imagine if we applied this thinking to
every enemy or friendly AI unit in our make-believe game...)
Second, our crocodile, due to its tough leathery skin, is immune to
the tranquilizer dart gun in our game. If we do this, the player
cannot just shoot his way out of the encounter. He must instead, react
to the situation and make a decision (if only to switch weapons when
fighting crocodiles).
And lastly, let's make our crocodile move fast in the water *and* on
dry land (like a real crocodile), but let's give him a really, really
slow turning rate when on the land. This way, he will only be able to
move fast *in a straight line* when chasing after the player on dry
land. So if the player zigzags as he runs, he can easily elude the
crocodile.
So now the crocodile is different from the other enemies in the game
in a number of recognizable ways. It is not just faster, tougher and
more lethal--it also has some special attributes which will make it
more interesting to encounter. The really good game designers have
employed this philosophy for years, completely at odds with the "boss
monster" style enemy progression used in many games. This approach to
design asks the question, "What does each unit represent on an
abstract level?" It makes the game more active. It makes the player
decide and react. It grants the game interesting dynamics, instead of
creating tedious game-play.
It is also important to note that if the player never *knows* about
any of the distinct enemy functions you generate, he will never get
any enjoyment from them. So, as feedback mechanisms for to our example
croc, we could do something like this:
Related to the crocodile's tranquilizer dart immunity, we could play a
different "got hit" sound effect when the dart hits the crocodile;
instead of a nice sticking sound (made when the dart 'works' on a
given creature), we could make the dart "pa-ting!" and ricochet.
Also - to inform the player of the croc's interesting land movement
features before the player actually encounters any crocodiles--we
could drop one or two down on the beach, chasing some small innocuous
game creatures. The creatures that run from the crocodiles in straight
lines always get eaten; the creatures that run in a zigzag pattern
always escape. By studying the crocodiles before encountering them,
the player could learn something about consistent crocodile behavior
as it is within the framework of our game. (Clearly, this sort of
thing does not work if the game is nothing but a series of monster
filled rooms. Showing the next obstacle before the player actually has
to deal with it can produce a number of more interesting game
dynamics; the player has more information with which to act.)
The 'loss of breath' attack that the crocodile has against the player
when fighting in the water is less complicated to communicate: it
could be made obvious by subtracting a breath increment each time the
croc bites and triggering a player gurgling sound.
An equally valid approach to designing game enemies-perhaps more
valid-is to decide what function an enemy will provide within the game
before you decide what the creature actually is. For instance, rather
than saying, "How can we make our crocodile unique and interesting in
terms of game mechanics?" you instead ask, "What do we want Enemy X to
do or represent in the game?" In the latter practice, you would come
up with an idea that you think would be interesting in your game, then
retrofit the type of enemy to that idea. As an example, think about
Quake 2's "medic" enemy; its primary purpose was to heal wounded
monsters. This was not executed particularly well since most players
never had a chance to realize what was going on and the guys at id,
seemingly, did not have the discipline to focus this unit down to its
essence. (Sadly, it comes across in Quake 2 mostly as another big
beast with lots of hit points?) However, as a concept, it is quite
cool. It really works as an example of how you might first decide what
role a unit plays in the game, like "autonomously heal other enemy
units so that they might live to antagonize the player anew," then
come up with an identity and a look for that unit. (Note: I have no
idea which design phase came first in this case, abstract function or
fictional/artistic identity.) When you take this approach, it becomes
obvious as to why so many games are set in "dark-magic land" or
"alien-dimension x." If you are completely free to create the unit's
function first, you end up with some wild behaviors and actions,
usually inappropriate for real-world mundane animals or those that are
recognizable to the player. (Think Q*bert.)
Either way, the end result is that when players encounter the
crocodiles in our example, the function of the enemy unit is obvious,
the game's situation changes somewhat and the player is required to
react to a new form of obstacle that behaves in unique and interesting
ways. And if we account for these enemy design features by
incorporating several potential methods of reacting, the player can,
within the scope of the actions available to him within the game, make
informed and useful decisions in response to the crocodile enemy. And
those decisions will be completely different from the decisions made
when facing a bear...
-- Witchboy
http://www.io.com/~salem
During his hellish early years on the Texas Gulf Coast (surrounded by
evil shrimpers and gloomy chemical plants), Witchboy's sanity was
narrowly preserved through years of non-stop gaming and subcultural
pursuits. Only through this massive assimilation of SF/Fantasy books,
computer/vid games, paper RPG's and mope rock did he manage to evolve
into the fey being he is today. He makes his home in Austin, Texas
because he has a lick of sense. He eats nothing but Tex-Mex and fried
seafood, and he is a 6th generation native Texan.
Projects to date: Deus Ex (Design Team Leader), FireTeam (Lead
Designer), Technosaur (Project Director/Designer), CyberMage
(Associate Producer), Ultima VIII, CD Re-release (Lead
Tester/Designer), System Shock (Lead Tester) and Super Wing Commander
3DO (Tester).
--<cut>--
--
J C Lawrence Internet: claw@null.net
(Contractor) Internet: coder@ibm.net
---------(*) Internet: claw@under.engr.sgi.com
...Honourary Member of Clan McFud -- Teamer's Avenging Monolith... - OGR: Ion Storm's Witchboy talks about the functionality of enemy AI. s001gmu@nova.wright.edu
- Methods to Reduce Ecological Wipeout (fwd) Marc Hernandez
- avoiding ecological wipeout Laurel Fan
- Passing file descriptors to other processes Adam J. Thornton
- Yet another update on threads and signals Adam J. Thornton
- Yet another update on threads and signals s001gmu@nova.wright.edu
- Yet another update on threads and signals Chris Gray
- Yet another update on threads and signals Adam J. Thornton
- Yet another update on threads and signals Chris Gray
- Yet another update on threads and signals Adam J. Thornton
- Yet another update on threads and signals Chris Gray
- Yet another update on threads and signals Adam J. Thornton
- OT: access s001gmu@nova.wright.edu
- Affordances and social method cat
- Affordances and social method cat
- Affordances and social method Caliban Tiresias Darklock
- Affordances and social method Ola Fosheim Grøstad
- Missing MUD-Dev post (fwd) Dr. Cat
- FW: UBE/high: W IRED: Kilers have more fun Koster, Raph
- Affordances and social method Koster, Raph
- Marian's Tailor Problem Koster, Raph
- Marian's Tailor Problem Brandon Cline
- Marian's Tailor Problem Hans-Henrik Staerfeldt
- Marian's Tailor Problem Brandon Cline
- Marian's Tailor Problem Ola Fosheim Grøstad
- Marian's Tailor Problem Damion Schubert
- Marian's Tailor Problem Chris Gray
- UBE/high: W IRED: Kilers have more fun Koster, Raph
- UBE/high: W IRED: Kilers have more fun Mike Sellers
- UBE/high: W IRED: Kilers have more fun s001gmu@nova.wright.edu
- UBE/high: W IRED: Kilers have more fun Marian Griffith
- Question for the list (Semi-OT) Nathan F Yospe
- Question for the list (Semi-OT) Oliver Jowett
- Question for the list (Semi-OT) Jon Leonard
- Question for the list (Semi-OT) Ben Greear
- FW: UBE/high: W IRED: Kilers have more fun Jon A. Lambert
- Private Affordances and social method Mike Sellers
- Private Affordances and social method Marian Griffith
- Private Affordances and social method Mike Sellers
- FW: UBE/high: W IRED: Kilers have more fun Marian Griffith
- UBE/high: FW: UBE/high: W IRED: Kilers have more fun Dr. Cat
- UBE/high: FW: UBE/high: W IRED: Kilers have more fun S. Patrick Gallaty
- free XML Parser (was clients anyone?...) James Wilson
- UBE/high: FW: UBE/high: W IRED: Kilers Jon A. Lambert
- UBE/high: FW: UBE/high: W IRED: Kilers Koster, Raph
- UBE/high: FW: UBE/high: W IRED: Kilers S. Patrick Gallaty
- UBE/high: FW: UBE/high: W IRED: Kilers quzah
- UBE/high: FW: UBE/high: W IRED: Kilers James Wilson
- UBE/high: FW: UBE/high: W IRED: Kilers Damion Schubert
- UBE/high: FW: UBE/high: W IRED: Kilers J C Lawrence
- UBE/high: UBE/high: FW: UBE/high: W IRED: Kilers Dr. Cat
- Marion's Tailor Problem s001gmu@nova.wright.edu
- Marion's Tailor Problem Caliban Tiresias Darklock
- Marion's Tailor Problem jwilson@rochester.rr.com
- Marion's Tailor Problem Travis Casey
- Marion's Tailor Problem Caliban Tiresias Darklock
- Marion's Tailor Problem Adam J. Thornton
- Marion's Tailor Problem Travis S. Casey
- Marion's Tailor Problem Jynx {Wyrm / Tygr / Myth} Ryn
- Marion's Tailor Problem s001gmu@nova.wright.edu
- Marion's Tailor Problem Damion Schubert
- Marion's Tailor Problem Damion Schubert
- Marion's Tailor Problem Ola Fosheim Grøstad
- Marion's Tailor Problem Adam Wiggins
- Marion's Tailor Problem quzah
- Marion's Tailor Problem Marian Griffith
- Marion's Tailor Problem J C Lawrence
- Marion's Tailor Problem Marian Griffith
- Marion's Tailor Problem Koster, Raph
- Marion's Tailor Problem Matthew R. Sheahan
- Marion's Tailor Problem quzah
- Marion's Tailor Problem Matthew R. Sheahan
- Marion's Tailor Problem Koster, Raph
- Marion's Tailor Problem Marian Griffith
- Marion's Tailor Problem Ola Fosheim Grøstad
- Marion's Tailor Problem J C Lawrence
- Marion's Tailor Problem Ola Fosheim Grøstad
- Marion's Tailor Problem Marian Griffith
- Slightly-OT: RPG Mapping Tool Holly Sommer
- UBE/high: UBE/high: FW: UBE/high: W IRED: Kilers Dr. Cat
- UBE/high: FW: UBE/high: W IRED: Kilers Scatter
- UBE/high: FW: UBE/high: W IRED: Kilers Marian Griffith
- UBE/high: FW: UBE/high: W IRED: Kilers Scatter
- UBE/high: FW: UBE/high: W IRED: Kilers Brandon J. Rickman
- UBE/high: FW: UBE/high: W IRED: Kilers Damion Schubert
- UBE/high: FW: UBE/high: W IRED: Kilers quzah
- UBE/high: FW: UBE/high: W IRED: Kilers Marian Griffith
- UBE/high: FW: UBE/high: W IRED: Kilers Adam Wiggins
- UBE/high: FW: UBE/high: W IRED: Kilers Travis Casey
- UBE/high: FW: UBE/high: W IRED: Kilers Brandon J. Rickman
- UBE/high: FW: UBE/high: W IRED: Kilers Koster, Raph
- Thoughts on Marian's Tailor Problem s001gmu@nova.wright.edu
- Standard Mud Room Format? plateau
- Standard Mud Room Format? T. Alexander Popiel
- Standard Mud Room Format? Michael.Willey@abnamro.com
- Standard Mud Room Format? J C Lawrence
- Standard Mud Room Format? Adam J. Thornton
- Standard Mud Room Format? Holly Sommer
- Standard Mud Room Format? Matthew R. Sheahan
- Standard Mud Room Format? Hans-Henrik Staerfeldt
- Standard Mud Room Format? Scatter
- Tangent to the Tailor Marc Bowden
- PerLDAP, usefull for your perl-mud? quzah
- UBE/high: Affordances and social method Dr. Cat
- UBE/high: FW: UBE/high: W IRED: Kilers have more fun Dr. Cat
- Article: A Summary of Principles for User-Interface Design. J C Lawrence
- Article: A Summary of Principles for User-Interface Design. Adam J. Thornton
- Article: A Summary of Principles for User-Interface Design. Ola Fosheim Grøstad
- Sockets permanently in CLOSE_WAIT state. (fwd) Oliver Jowett
- Fw: BlackSquad Releases File Formats Damion Schubert
- Revenants (Marion's Tailor Problem) Damion Schubert
- Finer points of Telnet programming ... Jynx {Wyrm / Tygr / Myth} Ryn
- Finer points of Telnet programming ... quzah
- Finer points of Telnet programming ... J C Lawrence
- Finer points of Telnet programming ... quzah
- Finer points of Telnet programming ... J C Lawrence
- Finer points of Telnet programming ... Marc Hernandez
- Finer points of Telnet programming ... Ben Greear
- Finer points of Telnet programming ... Greg Munt
- Finer points of Telnet programming ... Ben Greear
- Finer points of Telnet programming ... Jynx {Wyrm / Tygr / Myth} Ryn
- Finer points of Telnet programming ... Caliban Tiresias Darklock
- Finer points of Telnet programming ... Adam Wiggins
- Finer points of Telnet programming ... Caliban Tiresias Darklock
- Finer points of Telnet programming ... quzah
- Finer points of Telnet programming ... Greg Munt
- [off-topic] Email Jeroen Ruigrok/Asmodai
- Minimal MUD-kernel (was Finer points of Telnet programming ...) Niklas Elmqvist
- Modular MUD [Was:Finer points of Telnet programming ...] Jynx {Wyrm / Tygr / Myth} Ryn
- Modular MUD [Was:Finer points of Telnet programming ...] Caliban Tiresias Darklock
- Modular MUD [Was:Finer points of Telnet programming ...] Adam J. Thornton
- Modular MUD [Was:Finer points of Telnet programming ...] Caliban Tiresias Darklock
- Modular MUD [Was:Finer points of Telnet programming ...] Adam J. Thornton
- Modular MUD [Was:Finer points of Telnet programming ...] Caliban Tiresias Darklock
- Modular MUD [Was:Finer points of Telnet programming ...] pomales
- Modular MUD [Was:Finer points of Telnet programming ...] Caliban Tiresias Darklock
- Modular MUD [Was:Finer points of Telnet programming ...] Caliban Tiresias Darklock
- Modular MUD [Was:Finer points of Telnet programming ...] Jeroen Ruigrok/Asmodai
- Modular MUD [Was:Finer points of Telnet programming ...] Jynx {Wyrm / Tygr / Myth} Ryn
- Modular MUD [Was:Finer points of Telnet programming ...] Caliban Tiresias Darklock
- Modular MUD Caliban Tiresias Darklock
- Modular MUD Ola Fosheim Grøstad
- Modular MUD Caliban Tiresias Darklock
- Modular MUD Jeroen Ruigrok/Asmodai
- Modular MUD D. B. Brown
- Modular MUD quzah
- Modular MUD Caliban Tiresias Darklock
- Modular MUD Adam J. Thornton
- Modular MUD Caliban Tiresias Darklock
- Modular MUD Adam J. Thornton
- Modular MUD quzah
- Modular MUD J C Lawrence
- Modular MUD Adam J. Thornton
- Modular MUD Bruce Mitchener, Jr.
- Modular MUD Holly Sommer
- Modular MUD Adam J. Thornton
- Modular MUD Caliban Tiresias Darklock
- Modular MUD Vadim Tkachenko
- Modular MUD John Bertoglio
- Modular MUD [Was:Finer points of Telnet progra Jon A. Lambert
- OS Wars [Was: Modular MUD] Jynx {Wyrm / Tygr / Myth} Ryn
- Modular MUD [Was:Finer points of Telnet progra Jon A. Lambert
- Modular MUD [Was:Finer points of Telnet programming ...] Chris Gray
- The 'consider' command Richard Woolcock
- The 'consider' command Damion Schubert
- The 'consider' command Jon Leonard
- The 'consider' command Hans-Henrik Staerfeldt
- Scripting:was Modular Mud Jon A. Lambert
- Quake 3: How to do OpenGL J C Lawrence
- lockless system - foolproof? James Wilson
- lockless system - foolproof? Chris Gray
- lockless system - foolproof? J C Lawrence
- lockless system - foolproof? James Wilson
- lockless system - foolproof? J C Lawrence
- lockless system - foolproof? James Wilson
- lockless system - foolproof? J C Lawrence
- lockless system - foolproof? T. Alexander Popiel
- lockless system - foolproof? J C Lawrence
- lockless system - foolproof? T. Alexander Popiel
- lockless system - foolproof? J C Lawrence
- lockless system - foolproof? James Wilson
- lockless system - foolproof? J C Lawrence
- Admin: OS wars and avocacy are off-topic J C Lawrence