July 2001
- [TECH] Open Source oodb/object persistence toolkit library alpha release Brian Price
- In-game email (was On socialization and convenience) Gavin Doughtie
- In-game email (was On socialization and conveni ence) Freeman, Jeff
- In-game email (was On socialization and convenience) Caliban Tiresias Darklock
- TECH DGN: Single user MOB arena Trevyn
- TECH: CRPGs vs. RPGs, Way Back When... Michael Tresca
- TECH: CRPGs vs. RPGs, Way Back When... Matt Owen
- TECH: CRPGs vs. RPGs, Way Back When... J C Lawrence
- TECH: CRPGs vs. RPGs, Way Back When... Michael Tresca
- (no subject) Alan Unsworth
- (no subject) Edward Falconer
- (no subject) J C Lawrence
- (no subject) Bruce Mitchener
- (no subject) Travis Casey
- (no subject) J C Lawrence
- (no subject) Travis Casey
- Libs for 3D Client/Servers Brian Hook
- Libs for 3D Client/Servers Freeman, Jeff
- Libs for 3D Client/Servers Trump
- Libs for 3D Client/Servers Jeremy Noetzelman
- Libs for 3D Client/Servers J C Lawrence
- Libs for 3D Client/Servers Matt Mihaly
- Libs for 3D Client/Servers Matt Owen
- Libs for 3D Client/Servers Jeremy Noetzelman
- Libs for 3D Client/Servers Bryce Harrington
- Libs for 3D Client/Servers J C Lawrence
- Libs for 3D Client/Servers Brian Hook
- Libs for 3D Client/Servers J C Lawrence
- Libs for 3D Client/Servers Brian Hook
- Libs for 3D Client/Servers J C Lawrence
- Libs for 3D Client/Servers Vincent Archer
- Libs for 3D Client/Servers Madman Across the Water
- Libs for 3D Client/Servers Richard Aihoshi aka Jonric
- Libs for 3D Client/Servers Brian Hook
- Libs for 3D Client/Servers J Todd Coleman
- Libs for 3D Client/Servers Brian Hook
- Libs for 3D Client/Servers Sean Kelly
- Libs for 3D Client/Servers Jon Lambert
- Libs for 3D Client/Servers Sean Kelly
- Libs for 3D Client/Servers Bruce Mitchener
- Libs for 3D Client/Servers Sean Kelly
- Libs for 3D Client/Servers Dave Rickey
- Libs for 3D Client/Servers Travis Casey
- Libs for 3D Client/Servers Bryce Harrington
- Libs for 3D Client/Servers Alistair Milne
- Libs for 3D Client/Servers Travis Casey
- Libs for 3D Client/Servers J C Lawrence
- Libs for 3D Client/Servers Travis Casey
- Libs for 3D Client/Servers Jon Lambert
- Libs for 3D Client/Servers Adam Martin
- Libs for 3D Client/Servers Vincent Archer
- Libs for 3D Client/Servers Travis Nixon
- Libs for 3D Client/Servers Adam Martin
- Libs for 3D Client/Servers Vincent Archer
- Libs for 3D Client/Servers Adam Martin
- Libs for 3D Client/Servers Vincent Archer
- Libs for 3D Client/Servers Adam Martin
- Libs for 3D Client/Servers Dave Rickey
- Libs for 3D Client/Servers Travis Casey
- Libs for 3D Client/Servers Dave Rickey
- Libs for 3D Client/Servers Timothy Dang
- Libs for 3D Client/Servers Alistair Milne
- Libs for 3D Client/Servers J C Lawrence
- Libs for 3D Client/Servers Brian Hook
- Libs for 3D Client/Servers Sean Kelly
- Libs for 3D Client/Servers Gavin Doughtie
- Libs for 3D Client/Servers J C Lawrence
- Libs for 3D Client/Servers Brian Hook
- Libs for 3D Client/Servers Daniel.Harman@barclayscapital.com
- Libs for 3D Client/Servers Joel Chestnutt
- Libs for 3D Client/Servers Richard Aihoshi aka Jonric
- Libs for 3D Client/Servers Aaron Mulder
- Libs for 3D Client/Servers Max Gilead
- Libs for 3D Client/Servers Jon Lambert
- Libs for 3D Client/Servers Caliban Tiresias Darklock
- Libs for 3D Client/Servers Luke Carruthers
- Libs for 3D Client/Servers Jeremy Noetzelman
- Libs for 3D Client/Servers J C Lawrence
- Libs for 3D Client/Servers Jeremy Noetzelman
- Libs for 3D Client/Servers Adam Martin
- New polls claw@kanga.nu
- virtual mind project Phillip Lenhardt
- [TECH] Data-transfer protocols for MUDs Adam Martin
- Chatbot Michael Tresca
- GPL (was:Libs for 3D Client/Servers) Joackim Birgersson
- GPL (was:Libs for 3D Client/Servers) Travis Casey
- GPL (was:Libs for 3D Client/Servers) ghovs
- GPL (was:Libs for 3D Client/Servers) Vincent Archer
- GPL (was:Libs for 3D Client/Servers) Max Gilead
- GPL (was:Libs for 3D Client/Servers) Bobby Martin
- GPL (was:Libs for 3D Client/Servers) Joackim Birgersson
- GPL (was:Libs for 3D Client/Servers) Patrick Dughi
- GPL (was:Libs for 3D Client/Servers) Matt Mihaly
- GPL (was:Libs for 3D Client/Servers) Koster, Raph
- GPL (was:Libs for 3D Client/Servers) Joackim Birgersson
- Graphical Mud-in-a-box musings Brian Hook
- Graphical Mud-in-a-box musings Justin Rogers
- Graphical Mud-in-a-box musings Rob Bartel
- Graphical Mud-in-a-box musings Adam Martin
- Chatbot, NLP and explaining away NPC limitations Erin Mulder
- Server hosting Brian Hook
- Server hosting Corey Crawford
- Server hosting Daniel.Harman@barclayscapital.com
- Server hosting Valerio Santinelli
- Server hosting Madman Across the Water
- Server hosting Frank Crowell
- Server hosting Alistair Milne
- Server hosting Brian Hook
- Server hosting Freeman, Jeff
- Server hosting Matt Mihaly
- Server hosting fred@clift.org
- Chatbot, NLP and explaining away NPC limitations Robert Zubek
- Edged weapon damage John W Pierce
- Player characters as a prey species Jon Leonard
- Player characters as a prey species Justin Rogers
- Player characters as a prey species Ling Lo
- Player characters as a prey species J C Lawrence
- Player characters as a prey species lhulbert@hotmail.com
- Player characters as a prey species Dan Shiovitz
- Player characters as a prey species Justin Rogers
- Player characters as a prey species Matt Mihaly
- Request to mailing list MUD-Dev rejected J C Lawrence
- Chatting in MMPORPGs Peter Tyson
- Chatting in MMPORPGs Derek Licciardi
- Chatting in MMPORPGs Matt Mihaly
- Chatting in MMPORPGs Peter Tyson
- Chatting in MMPORPGs Eric Lee {RAT}
- Chatting in MMPORPGs John Buehler
- Chatting in MMPORPGs lhulbert@hotmail.com
- Chatting in MMPORPGs Adam Martin
- Chatting in MMPORPGs Eli Stevens
- Chatting in MMPORPGs Dave Rickey
- Chatting in MMPORPGs Vincent Archer
- Chatting in MMPORPGs Adam Martin
- Chatting in MMPORPGs Kevin Littlejohn
- Chatting in MMPORPGs Hans-Henrik Staerfeldt
- Chatting in MMPORPGs Lee Sheldon
- Chatting in MMPORPGs Madman Across the Water
- Chatting in MMPORPGs Peter Tyson
- Chatting in MMPORPGs J C Lawrence
- TECH: Mail (was On socialization and convenience) Chris Jones
- [TECH] String Classes, Memory Management, and Fragmentation Derek Licciardi
- [TECH] String Classes, Memory Management, and Fragmentation Sean Kelly
- [TECH] String Classes, Memory Management, and Fragmentation Justin Rogers
- [TECH] String Classes, Memory Management, and Fragmentation Chris Dern
- [TECH] String Classes, Memory Management, and Fragmentation David Bennett
- [TECH] String Classes, Memory Management, and Fragm entation Daniel.Harman@barclayscapital.com
- [TECH] String Classes, Memory Management, and Fragmentation Kwon Ekstrom
- [TECH] String Classes, Memory Management, and Fragmentation Bruce Mitchener
- [TECH] String Classes, Memory Management, and Fragmentation Adam Martin
- [TECH] String Classes, Memory Management, and Fragm entation Daniel.Harman@barclayscapital.com
- [TECH] String Classes, Memory Management, and Fragmentation Hans-Henrik Staerfeldt
- [TECH] String Classes, Memory Management, and Fragm entation Daniel.Harman@barclayscapital.com
- [TECH] String Classes, Memory Management, and Fragmentation Derek Licciardi
- [TECH] String Classes, Memory Management, and Fragm entation Bruce Mitchener
- Mudpie Matt Mihaly
- strong encryption for authentication Fred Clift
- strong encryption for authentication David Bennett
- strong encryption for authentication Caliban Tiresias Darklock
- strong encryption for authentication Edward Glowacki
- strong encryption for authentication Caliban Tiresias Darklock
- strong encryption for authentication Derek Licciardi
- strong encryption for authentication Caliban Tiresias Darklock
- strong encryption for authentication shren
- strong encryption for authentication Caliban Tiresias Darklock
- strong encryption for authentication Ben Tolputt
- strong encryption for authentication Caliban Tiresias Darklock
- strong encryption for authentication Edward Glowacki
- strong encryption for authentication Caliban Tiresias Darklock
On Fri, 13 Jul 2001 10:12:07 -0400, Edward Glowacki
<glowack2@msu.edu> wrote:
> Quoted from Caliban Tiresias Darklock on Wed, Jul 11, 2001 at
> 08:29:12PM -0700:
>> On Wed, 11 Jul 2001 09:35:39 -0400, Edward Glowacki
>> <glowack2@msu.edu> wrote:
>>> 1. Cheating 2. Spying
>> So... you don't consider these perfectly legitimate applications
>> of player ingenuity?
> Cheating is not a legitimate application of player ingenuity,
> IMHO.
But if it's legitimate, it's not cheating. It's all in your
perception. If you say "this is not OK", it's cheating; if you say
"this is OK", it's not. Cheating and fair play are arbitrary
distinctions.
> Think about the Quake style games that people have built
> auto-aimers for. You walk into a room and before it's humanly
> possible for anyone to target you, the cheating player has a
> bullet flying towards your head. Yes, it's player ingenuity, but
> it devalues the game as a whole when people use it.
I've been accused of using them, and I don't. That devalues the game
more than any auto-aimer. When excellent play is suspicious,
something is wrong with your game.
> As for spying, if you want to support it in a game, build it into
> the game itself.
I did. :)
> See the above Quake example for people using cheating to ruin the
> game for others.
Quake assumes people will play fair. I don't. I know that people
cheat. I expect them to cheat. I account for that in the design. It
is then no longer cheating.
>> I don't think either of those has particularly far-reaching
>> consequences.
> As long as you don't count "destroying the balance of the game"
> far-reaching.
Then your game is improperly balanced. You are attempting to prevent
an action from working at all because it could unbalance the
game. Why not just prevent it from unbalancing the game? In both
cases, the player has simply accomplished something more easily than
the game allows -- but the game still allows him to accomplish the
same thing. If he feels the need to accomplish it more easily, maybe
the game is not properly designed.
>> I couldn't think of any good reason why it should be disallowed,
>> either. Players *should* hack the game, reverse-engineer the
>> protocol, and know every byte their client sends and
>> receives. If they intercept someone else's information, I think
>> they have every right to inspect it.
> Once again this allows someone to use real-world skills to give
> them an advantage in-game.
It also encourages people who want an advantage in-game to *develop*
real world skills. When real world skills become useless, your game
will appeal primarily to those who don't have them. My military and
martial arts training were exceptionally helpful when playing
Quake. That was a real world skill giving me an advantage. Frame
rate and bandwidth were also important; a fast graphics card and a
fat pipe gave me an advantage, too. Writing good aliases was an
advantage, and as a programmer I could do that pretty well. So that
was my own real-world skills making me a better Quake player. Why is
that wrong? Real-world skills DO make you a better player. Which
real world skills those are is dependent on the game.
> The point of a virtual world is that everyone starts the same and
> can build from that base to be whatever they want to according to
> the rules of the universe.
This is a delusion. Nobody ever starts the same. Your game may
*treat* them all the same, as it should, but that does not make them
the same.
> As long as the game is fairly well balanced (which is very
> difficult to do), every player will always have a relative
> advantage in *something* over other players, and other players
> will always have a relative advantage in *something* over them.
This is a naive statement. All players exist on a continuum. Some
players are at the top, and others are at the bottom. Those on the
top are reasonably safe. Those at the bottom are in trouble.
> If any single skill is one-way and there is no defense against it,
> it will be abused and unbalance the game.
Any skill that can be abused, will be abused. Assume players will
abuse it, and design accordingly.
>> That aside, let's stop and think: has this ever actually
>> HAPPENED?
> I've never been thrown through the windshield of a car, but I
> still always wear my seatbelt...
But *other* people have been so thrown. That's why seatbelts are no
longer an OPTION, as they used to be.
> All it would take is one or two big MUDS to say, "Hey, we're going
> to start supporting SSL/SSH connections," and soon there'd be MUD
> clients out there that support SSL/SSH. In fact, a quick search
> at SourceForge.net reveals one Unix MUD client that already
> supports SSL.
The vast majority of players are not using UNIX and do not have SSL
readily available, so a MUD server that supported SSL wouldn't help
them at all.
> You appear to dislike current applications/implementations of
> encryption, not the encryption itself.
What's the difference? Either could be improved to address my
complaints, but until one or both are, the complaints will still
apply. Encryption as a concept, no, I don't have any problem with
that. The *idea* of encryption doesn't bother me at all.
> Security isn't about making your system invincible, it's about
> making your system more difficult to break in than it's worth.
Or making your system worth less to break. Removing a space from the
previous sentence would make it even better. ;)
> a game, and in games, people talk about more than their favorite
> band, they talk about things like when they are going to raid the
> enemy stronghold, who they have grudges against, who owes them
> money, etc. Players will take advantage of this information if
> they can get ahold of it.
And they SHOULD. Allow me to write a short essay (well, it's short
for *me*, anyway).
Most MUDs are *too* secure. People can smile and nod and be nice and
friendly to you while they PRIVATELY plan to assassinate you via the
MUD's person-to-person channels. You have no ability to
eavesdrop. You have no indication that they are even talking. And
they take advantage of that, don't they? Doesn't that damage game
balance, when a player can lie to me without the slightest
indication that he's lying or even doing something suspicious?
Doesn't that destroy the game's immersion?
What about when I'm in the town square and two guys come in and
start going "How are your hit points?" "Is your armor class better
than 2?" "What level are you now?" -- doesn't that ruin my
enjoyment of the game? Isn't it destructive to my game experience
when I go to some area to solve a puzzle and someone tells me the
answer over a chat channel? You can't stop those things. You can't
fix those things. You just have to DEAL WITH IT.
The average MUD is built on the assumption that most players want to
play fair. In my experience, people do NOT want to play fair. People
just want to play. Playing "fair" is a luxury which they will
indulge if -- and only if -- it allows them to succeed.
MUDs are designed to be played by people who use computers. Those
people will want to use their advantages, just like in any game. I'm
not very good at observing static objects. If it doesn't move, I
don't often register that it even *exists*. But I'm a phenomenally
fast reader (in the vicinity of 700 lines a minute) -- so while I
don't have any problem with reading reams of text looking for
interesting things, I'm going to need some sort of help when I have
to scan graphical scenes for clickable hot-spots.
A client which highlights those will be a big help, but those who
don't need this kind of help are always going to claim that this is
cheating... and if I write the appropriate "helper" functions into
my client, people will complain that I've hacked the system
unfairly. If I write a client that translates protocol information
into text for me, I'll get a LOT better at responding to that
information. And other players will cry "foul" and say I should play
the game the way it was designed. But that design places me at a
disadvantage, so I turned that disadvantage (scanning text better
than images) into an advantage. Isn't that what the game's about?
There is a neuropsychological theory called the "rare trait marker"
syndrome which can come into play here. Let us assume that we have a
game consisting of 90% honest and 10% dishonest people, and that 10%
of the people playing the game will switch their tactics (honest to
dishonest or vice-versa) as a response to the specific allowances of
the game. Honest people are honest because it works; dishonest
people are dishonest because it works. Let's look at the results of
this situation.
HONEST
- 81% of players are naturally honest and remain so. (90% of
90%)
- 1% of players are naturally dishonest but act honestly. (10%
of 10%)
DISHONEST
- 9% of players are naturally honest but act dishonestly. (10%
of 90%)
- 9% of players are naturally dishonest and remain so. (90% of
10%)
The end result is 82% honesty and 18% dishonesty. But fully *half*
of your dishonest players WOULD play honestly IF IT WORKED. (It's
also worth noting that the perception of an observer might well be
that MUDs actively *encourage* dishonesty -- because half of the
dishonest people are normally honest, but virtually none of the
honest people are normally dishonest.) And because honest play is
easier than dishonest play, making honest play work as well as
dishonest play will inevitably skew this result toward honesty,
because the DISHONEST players will recognise this as well... and if
they can achieve the same result *with less work* through honest
play, they will!
In short, people will be dishonest if and only if it is advantageous
to do so. You should take away the ADVANTAGE, not the ability. What
encryption solves with respect to cheating is a symptom of a larger
problem: the problem that packet sniffing is advantageous! The key
factor here is to IDENTIFY the advantage, and then REMOVE it. With
respect to player locations, we have a few factors that make the
sniffer advantageous:
- Any player you kill gives you a benefit.
- Any player you can locate is an acceptable kill.
- The location of a player without using a sniffer is difficult.
- All locations are similarly accessible.
I've addressed these. (Arguably, everyone should.) The average
player you kill gives you NO benefit. The killing of a player always
involves a significant cost. Any player can be located through
in-game facilities. (Tracking is a player skill, not a character
skill. As you move through the game world, you leave tracks. Those
tracks can be followed.) And players can "secure" their locations
with varying degrees of success. The only reason you might want to
kill a player is to temporarily remove him from the game. You do not
(usually) get his belongings. Instead, you pay -- sometimes dearly
-- for the privilege of removing him.
One failure of most MUDs, IMHO, is to make cheating attractive by
default. If you cheat, you will have a definite advantage. Remove
the advantage, and you remove the attraction. Remove the attraction,
you remove the cheaters. Those who do cheat, in any case, will not
gain a significant advantage.
>> No there aren't. ;)
> Yes there are! ;) (Hehehe, despite the heated discussion, all I
> can think about with this little bit is a couple of little kids
> out in the sandbox saying to each other, "No I'm not!" "Yes you
> are!" "No I'm not!" "Yes you are!" and it just makes me smile. A
> nice little reminder to myself that we're not out here to kill
> each other, we're just pushing ideas around in the sandbox. =) )
Yeah, which I think can't be said enough. My system is a little more
cutthroat than most people would want to build. It's also rather
different from the systems to which people are accustomed.
> Me too. We're kind of arguing the opposite extremes, but the real
> answer I think is somewhere in the middle. It's good discussion
> though, I think, because at least it's making me think this stuff
> through and contemplate the issues at hand.
That's all I'm really after. If you think about it and go "for MY
game, this is a Good Idea", that's great. I just think it's
important to recognise that for *many* games, it's going to be a
waste of time.
I find it exciting to think "anything I come up with is fair". It's
*frustrating* to think "anything the OTHER guy comes up with is
fair"... but that's also part of the excitement.
"Without evil there could be no good, so it must be good to be
evil sometimes." -- Satan
>> I'm not violently opposed to the idea of encryption in MUDs, but
>> I *am* violently opposed to the idea of adding features to
>> software that serve no good purpose.
> Agreed! =) Say NO to bloatware! =)
The basic flaw I see in this discussion's premises is that people
are assuming "if I didn't tell the client to tell that user, that
user does not know"... and then they're realising this is not
guaranteed, and they're trying to figure out some way to guarantee
it. They want to do this by extending their protocol, apparently
forgetting that (I believe the late Jon Postel said this) "a
protocol is not perfect when nothing can be ADDED, but when nothing
can be TAKEN AWAY".
There is most definitely something to be taken away from this
protocol concept -- things you don't want users to know! Why are you
sending that to the client in the first place? Agreed, it makes
debugging a little easier, but shouldn't it be removed once your
protocol debugging is done?
> Well that's the kind of problem you get a lot these days, where
> people know how to write code but they don't know how to really
> *write code*. Anybody can learn the syntax of a language and
> start writing stuff (say a MUD client... ;) ), but unless they
> really understand some programming theory and the underlying
> technologies their software is going to use (in this case, the
> telnet protocol), the end result is going to be less than
> desireable for others to use.
That's why my protocol is exceptionally simple. I treat the client
as a dumb terminal. Ideally, it is telnet-compliant and DEC VT-241
compatible, but it doesn't have to be. - strong encryption for authentication Edward Glowacki
- strong encryption for authentication Caliban Tiresias Darklock
- strong encryption for authentication Caliban Tiresias Darklock
- strong encryption for authentication Ben Tolputt
- strong encryption for authentication J C Lawrence
- strong encryption for authentication Caliban Tiresias Darklock
- strong encryption for authentication Vincent Archer
- strong encryption for authentication Fred Clift
- strong encryption for authentication J C Lawrence
- strong encryption for authentication Sean Kelly
- strong encryption for authentication Tamzen Cannoy
- strong encryption for authentication Sean Kelly
- strong encryption for authentication Caliban Tiresias Darklock
- strong encryption for authentication Tamzen Cannoy
- strong encryption for authentication Travis Casey
- strong encryption for authentication Caliban Tiresias Darklock
- strong encryption for authentication Travis Casey
- strong encryption for authentication Caliban Tiresias Darklock
- strong encryption for authentication Travis Casey
- strong encryption for authentication Caliban Tiresias Darklock
- strong encryption for authentication Travis Casey
- strong encryption for authentication Ola Fosheim Grøstad
- strong encryption for authentication Edward Glowacki
- strong encryption for authentication Matt Mihaly
- strong encryption for authentication Caliban Tiresias Darklock
- strong encryption for authentication Freeman, Jeff
- strong encryption for authentication Caliban Tiresias Darklock
- strong encryption for authentication Bruce Mitchener
- strong encryption for authentication Brian Price
- strong encryption for authentication Kevin Littlejohn
- strong encryption for authentication Brian Price
- strong encryption for authentication Kevin Littlejohn
- strong encryption for authentication Fred Clift
- strong encryption for authentication J C Lawrence
- strong encryption for authentication Robert Fleck
- strong encryption for authentication Sean Kelly
- strong encryption for authentication Edward Glowacki
- strong encryption for authentication Fred Clift
- strong encryption for authentication Fred Clift
- strong encryption for authentication J C Lawrence
- strong encryption for authentication Fred Clift
- strong encryption for authentication Caliban Tiresias Darklock
- strong encryption for authentication Daniel.Harman@barclayscapital.com
- strong encryption for authentication J C Lawrence
- strong encryption for authentication Oliver Jowett
- strong encryption for authentication Kwon Ekstrom
- strong encryption for authentication F. Randall Farmer
- strong encryption for authentication Kwon Ekstrom
- strong encryption for authentication J C Lawrence
- strong encryption for authentication Kwon Ekstrom
- strong encryption for authentication J C Lawrence
- strong encryption for authentication Dave Rickey
- strong encryption for authentication Jon Lambert
- strong encryption for authentication Dave Rickey
- strong encryption for authentication J C Lawrence
- Toward a Craftier Dragon Paul Schwanz
- Toward a Craftier Dragon Maximus
- Toward a Craftier Dragon rayzam
- Toward a Craftier Dragon Matt Owen
- Toward a Craftier Dragon Michael Tresca
- Toward a Craftier Dragon Travis Nixon
- Toward a Craftier Dragon Paul Schwanz - Enterprise Services
- Toward a Craftier Dragon Andrew Reisse
- Toward a Craftier Dragon J C Lawrence
- Toward a Craftier Dragon rayzam
- Toward a Craftier Dragon J C Lawrence
- Toward a Craftier Dragon rayzam
- Toward a Craftier Dragon Richard Aihoshi aka Jonric
- Toward a Craftier Dragon Michael Tresca
- Toward a Craftier Dragon John Hopson
- Toward a Craftier Dragon yospe@kanga.nu
- Grief players with ip/dns spoofers Tand'a-ur
- Grief players with ip/dns spoofers Sean Kelly
- Grief players with ip/dns spoofers J C Lawrence
- Grief players with ip/dns spoofers Greg Underwood
- Grief players with ip/dns spoofers Robert Fleck
- Grief players with ip/dns spoofers J C Lawrence
- Grief players with ip/dns spoofers Tand'a-ur
- Grief players with ip/dns spoofers Adam Martin
- Grief players with ip/dns spoofers J C Lawrence
- character transfer in EQ Matt Mihaly
- character transfer in EQ Derek Licciardi
- character transfer in EQ Dave Rickey
- character transfer in EQ Derek Licciardi
- character transfer in EQ S. Patrick Gallaty
- character transfer in EQ Michael Tresca
- DGN: Craftier dragon and players as GMs Mathieu Castelli
- DGN: Craftier dragon and players as GMs Matt Mihaly
- DGN: Craftier dragon and players as GMs Mathieu Castelli
- DGN: Craftier dragon and players as GMs Travis Nixon
- DGN: Craftier dragon and players as GMs Marian Griffith
- Biz/Media Peter Tyson
- To good to be TRUE, in an MMPORPG? David Loeser
- To good to be TRUE, in an MMPORPG? Kwon Ekstrom
- To good to be TRUE, in an MMPORPG? Xuri
- To good to be TRUE, in an MMPORPG? Adam Martin
- To good to be TRUE, in an MMPORPG? Justin Rogers
- To good to be TRUE, in an MMPORPG? David Loeser
- To good to be TRUE, in an MMPORPG? Matt Mihaly
- To good to be TRUE, in an MMPORPG? Matt Mihaly
- To good to be TRUE, in an MMPORPG? Caliban Tiresias Darklock
- To good to be TRUE, in an MMPORPG? luke@rocketship.com
- To good to be TRUE, in an MMPORPG? J C Lawrence
- To good to be TRUE, in an MMPORPG? Freeman, Jeff
- To good to be TRUE, in an MMPORPG? Koster, Raph
- To good to be TRUE, in an MMPORPG? Freeman, Jeff
- To good to be TRUE, in an MMPORPG? Koster, Raph
- To good to be TRUE, in an MMPORPG? Joe Andrieu
- To good to be TRUE, in an MMPORPG? Koster, Raph
- To good to be TRUE, in an MMPORPG? John Hopson
- To good to be TRUE, in an MMPORPG? Steve {Bloo} Daniels
- To good to be TRUE, in an MMPORPG? J C Lawrence
- To good to be TRUE, in an MMPORPG? Travis Casey
- To good to be TRUE, in an MMPORPG? Joe Andrieu
- To good to be TRUE, in an MMPORPG? Dave Rickey
- To good to be TRUE, in an MMPORPG? Marc Bowden
- To good to be TRUE, in an MMPORPG? Sean K
- To good to be TRUE, in an MMPORPG? Freeman, Jeff
- To good to be TRUE, in an MMPORPG? Matt Mihaly
- To good to be TRUE, in an MMPORPG? Koster, Raph
- To good to be TRUE, in an MMPORPG? Dave Rickey
- To good to be TRUE, in an MMPORPG? J C Lawrence
- To good to be TRUE, in an MMPORPG? Michael Tresca
- To good to be TRUE, in an MMPORPG? Trump
- To good to be TRUE, in an MMPORPG? Kristen L. Koster
- To good to be TRUE, in an MMPORPG? Sean Kelly
- To good to be TRUE, in an MMPORPG? Caliban Tiresias Darklock
- [NEWS] New MUD Magazine Derek Snider
- Real-world skills Was: strong encryption for authentication Travis Nixon
- Real-world skills Was: strong encryption for authentication Hans-Henrik Staerfeldt
- Something in the water Koster, Raph
- Something in the water Dave Rickey
- Something in the water Koster, Raph
- Something in the water John Hopson
- Something in the water Caliban Tiresias Darklock
- Something in the water J C Lawrence
- Something in the water Sean Kelly
- Something in the water rayzam
- Something in the water J C Lawrence
- Something in the water Caliban Tiresias Darklock
- Something in the water J C Lawrence
- Something in the water Caliban Tiresias Darklock
- Something in the water J C Lawrence
- Something in the water Travis Casey
- Something in the water J C Lawrence
- Something in the water Caliban Tiresias Darklock
- Something in the water J C Lawrence
- Something in the water Joe Andrieu
- Something in the water Sean Kelly
- Something in the water Caliban Tiresias Darklock
- Something in the water Hulbert, Leland
- Something in the water Caliban Tiresias Darklock
- Something in the water Hulbert, Leland
- Something in the water Matt Mihaly
- Something in the water Jon Morrow
- Something in the water Trump
- Something in the water Matt Mihaly
- Something in the water Matt Chatterley
- Something in the water Sparrowhawk
- Something in the water Matt Mihaly
- Something in the water Ola Fosheim Grøstad
- Something in the water Tamzen Cannoy
- Something in the water Matt Mihaly
- Something in the water Tomas Clark
- Something in the water Matt Mihaly
- Something in the water Marc Bowden
- Something in the water Koster, Raph
- Something in the water Jessica Mulligan
- Something in the water SavantKnowsAll@cs.com
- Something in the water Miroslav Silovic
- Something in the water Travis Casey
- Something in the water rayzam
- Something in the water Travis Casey
- Something in the water Ian Hess
- Something in the water Marc Bowden
- Something in the water J C Lawrence
- Something in the water Marc Bowden
- Something in the water J C Lawrence
- Something in the water Dave Rickey
- Something in the water Marc Bowden
- Something in the water Travis Casey
- Something in the water Marian Griffith
- Something in the water J C Lawrence
- Something in the water Eli Stevens
- Something in the water J C Lawrence
- Something in the water Adam Martin
- Something in the water Dave Rickey
- Something in the water Dan MacDonald
- Something in the water Adam Martin
- Something in the water John Hopson
- Something in the water rayzam
- Something in the water Caliban Tiresias Darklock
- Gearing up against GEAR Ted Milker
- Gearing up against GEAR Dan MacDonald
- Gearing up against GEAR Sean Kelly
- Gearing up against GEAR Vincent Archer
- Gearing up against GEAR Travis Nixon
- Gearing up against GEAR Kevin Littlejohn
- Gearing up against GEAR Sean Kelly
- Gearing up against GEAR Justin Rogers
- Gearing up against GEAR Sean K
- Gearing up against GEAR Alistair Milne
- Gearing up against GEAR Travis Nixon
- Gearing up against GEAR Vincent Archer
- Gearing up against GEAR J C Lawrence
- Gearing up against GEAR Vincent Archer
- Gearing up against GEAR Daniel.Harman@barclayscapital.com
- Gearing up against GEAR Sean K
- Gearing up against GEAR Vincent Archer
- Gearing up against GEAR Sean K
- Gearing up against GEAR Dave Rickey
- Gearing up against GEAR Derek Licciardi
- Gearing up against GEAR Caliban Tiresias Darklock
- Gearing up against GEAR Marc Bowden
- Gearing up against GEAR J C Lawrence
- Gearing up against GEAR Travis Nixon
- Gearing up against GEAR F. Randall Farmer
- OT: Writer needs help from people in the gaming industry Alex Oren
- What is cheating? [Was: Strong encryption for authentication] Caliban Tiresias Darklock
- TECH DGN: a few mud server design questions (long) Robert Zubek
- TECH DGN: a few mud server design questions (long) Caliban Tiresias Darklock
- TECH DGN: a few mud server design questions (long) Joe Andrieu
- TECH DGN: a few mud server design questions (long) Robert Zubek
- TECH DGN: a few mud server design questions (long) J C Lawrence
- TECH DGN: a few mud server design questions (long) Caliban Tiresias Darklock
- TECH DGN: a few mud server design questions (long) Robert Zubek
- TECH DGN: a few mud server design questions (long) Sean Kelly
- TECH DGN: a few mud server design questions (long) Joe Andrieu
- TECH DGN: a few mud server design questions (long) Sean K
- TECH DGN: a few mud server design questions (long) SeronisROTv3@aol.com
- TECH DGN: a few mud server design questions (long) Joe Andrieu
- TECH DGN: a few mud server design questions (long) J C Lawrence
- TECH DGN: a few mud server design questions (long) Robert Zubek
- TECH DGN: a few mud server design questions (long) Sean Kelly
- TECH DGN: a few mud server design questions (long) Adam Martin
- TECH DGN: a few mud server design questions (long) Caliban Tiresias Darklock
- TECH DGN: a few mud server design questions (long) Jon Lambert
- TECH DGN: a few mud server design questions (long) Robert Zubek
- TECH DGN: a few mud server design questions (long) Kevin Littlejohn
- TECH DGN: a few mud server design questions (long) Robert Zubek
- TECH DGN: a few mud server design questions (long) Robert Zubek
- TECH DGN: a few mud server design questions (long) Caliban Tiresias Darklock
- TECH DGN: a few mud server design questions (long) Robert Zubek
- TECH DGN: a few mud server design questions (long) Robert Zubek
- TECH DGN: a few mud server design questions (long) Caliban Tiresias Darklock
- Real-world skills luke@rocketship.com
- Real-world skills Mathieu Castelli
- Real-world skills J C Lawrence
- Real-world skills Kwon Ekstrom
- Real-world skills rayzam
- Design patterns for game database implementations Caliban Tiresias Darklock
- Design patterns for game database implementations Sean Kelly
- Design patterns for game database implementations J C Lawrence
- Design patterns for game database implementations J C Lawrence
- Real-world skills Caliban Tiresias Darklock
- Real-world skills Chris Lloyd
- Real-world skills Justin Rogers
- Real-world skills Koster, Raph
- Real-world skills Travis Casey
- Real-world skills J C Lawrence
- Real-world skills Luke Parrish
- Real-world skills Dave Talk21
- Real-world skills R.Fry
- Real-world skills Dave Talk21
- Real-world skills Luke Parrish
- Real-world skills Dave Talk21
- Real-world skills Bruce Mitchener
- Real-world skills Ola Fosheim Grøstad
- Mud Clients (was Real-world skills) Kwon Ekstrom
- Mud Clients (was Real-world skills) David Bennett
- Real-world skills Dave Talk21
- Real-world skills Justin Rogers
- Real-world skills Caliban Tiresias Darklock
- Real-world skills J C Lawrence
- Real-world skills Caliban Tiresias Darklock
- Real-world skills J C Lawrence
- Real-world skills Dave Talk21
- Real-world skills Luke Parrish
- Real-world skills Dave Talk21
- Real-world skills Adam Martin
- Players playing NPCs Vladimir Prelovac
- Players playing NPCs Christopher Allen
- Real-world skills Koster, Raph
- Real-world skills Bruce Mitchener
- Real-world skills Andrew Wilson
- Game Survey Michael Tresca
- Game Survey Richard Aihoshi aka Jonric
- Game Survey Hans-Henrik Staerfeldt
- Game Survey J C Lawrence
- MMORPG Construction Kit Koster, Raph
- MMORPG Construction Kit Lee Sheldon
- MMORPG Construction Kit Lee Sheldon
- MMORPG Construction Kit Lee Sheldon
- MMORPG Construction Kit Ola Fosheim Grøstad
- MMORPG Construction Kit J C Lawrence
- MMORPG Construction Kit Brian 'Psychochild' Green
- MMORPG Construction Kit Ola Fosheim Grøstad
- DNA Game Patent [was Randy's Resume] Christopher Allen
- DNA Game Patent [was Randy's Resume] Caliban Tiresias Darklock
- DNA Game Patent [was Randy's Resume] Adam Martin
- DNA Game Patent [was Randy's Resume] Hulbert, Leland
- DNA Game Patent [was Randy's Resume] Chris Gray
- DNA Game Patent [was Randy's Resume] David Loeser
- DNA Game Patent [was Randy's Resume] Dave Rickey
- DNA Game Patent [was Randy's Resume] Jon Lambert
- DNA Game Patent [was Randy's Resume] F. Randall Farmer
- DNA Game Patent [was Randy's Resume] Travis Nixon
- DNA Game Patent [was Randy's Resume] F. Randall Farmer
- DNA Game Patent [was Randy's Resume] Kevin Littlejohn
- DNA Game Patent [was Randy's Resume] Jessica Mulligan
- DNA Game Patent [was Randy's Resume] Caliban Tiresias Darklock
- DNA Game Patent [was Randy's Resume] F. Randall Farmer
- DNA Game Patent [was Randy's Resume] Frank Crowell
- DNA Game Patent [was Randy's Resume] Adam Martin
- DNA Game Patent [was Randy's Resume] F Farmer
- Re[4]: Something in the water Travis Casey
- Population divisions (wasTo good to be TRUE, in an MMPORPG?) Matt Mihaly
- Community feeling (was: To good to be TRUE, in an MMPORPG?) Alex Kay
- Community feeling (was: To good to be TRUE, in an M MPORPG?) Koster, Raph
- Community feeling (was: To good to be TRUE, in an M MPORPG?) J C Lawrence
- Community feeling (was: To good to be TRUE, in an M MPORPG?) Vincent Archer
- Community feeling (was: To good to be TRUE, in an M MPORPG?) Koster, Raph
- Community feeling (was: To good to be TRUE, in an M MPORPG?) Daniel.Harman@barclayscapital.com
- Community feeling (was: To good to be TRUE, in an MMPORPG?) Ola Fosheim Grøstad
- Re:DNA Game Patent [was Randy's Resume] Jessica Mulligan
- Multi-threading ( was: TECH DGN: a few mud server design questions (long)) Jon Lambert
- Wilderness Freeman, Jeff
- Wilderness Trump
- Wilderness Caliban Tiresias Darklock
- Wilderness Edward Glowacki
- Wilderness Dave Rickey
- Wilderness Sean Kelly
- Wilderness John Buehler
- Wilderness Brian Hook
- Wilderness John Buehler
- Wilderness Koster, Raph
- Wilderness Ling Lo
- Wilderness Freeman, Jeff
- Wilderness Nathan F. Yospe
- Wilderness Ling Lo
- Wilderness Nathan F. Yospe
- Wilderness John Buehler
- Wilderness Ola Fosheim Grøstad
- Wilderness Hulbert, Leland
- Wilderness John Buehler
- Wilderness Kwon Ekstrom
- Wilderness Ola Fosheim Grøstad
- Wilderness Matt Mihaly
- Wilderness Freeman, Jeff
- Wilderness John Buehler
- Wilderness Nathan F. Yospe
- Wilderness Travis Casey
- Wilderness Hans-Henrik Staerfeldt
- Wilderness Ola Fosheim Grøstad
- Wilderness Koster, Raph
- Wilderness Dave Rickey
- Wilderness Ola Fosheim Grøstad
- Wilderness Brian Hook
- Wilderness Ola Fosheim Grøstad
- Wilderness Brian Hook
- Wilderness Freeman, Jeff
- Wilderness Daniel.Harman@barclayscapital.com
- Wilderness Freeman, Jeff
- Wilderness John Buehler
- Wilderness lhulbert@hotmail.com
- Wilderness Matt Mihaly
- Wilderness John Buehler
- Wilderness Matt Mihaly
- Wilderness John Buehler
- Wilderness Matt Mihaly
- Wilderness Freeman, Jeff
- Wilderness Madrona Tree
- Wilderness Nathan F. Yospe
- Wilderness Daniel.Harman@barclayscapital.com
- Wilderness Daniel.Harman@barclayscapital.com
- Wilderness John Buehler
- Wilderness Adam Martin
- Wilderness Koster, Raph
- Wilderness John Buehler
- Wilderness Daniel.Harman@barclayscapital.com
- Wilderness Adam Martin
- Wilderness Daniel.Harman@barclayscapital.com
- Wilderness David Loeser
- Wilderness Matt Owen
- Wilderness Peter Tyson
- Wilderness Adam Martin
- Death among Friends Jon Morrow
- Death among Friends Tommy Wang
- Death among Friends Jon Morrow
- Death among Friends Matt Mihaly
- Death among Friends Jon Morrow
- Death among Friends Matt Mihaly
- Death among Friends shren
- Death among Friends Michael Tresca
- Death among Friends John Buehler
- Death among Friends Jon Morrow
- Death among Friends Matt Mihaly
- Death among Friends Michael Tresca
- BSD licenses Ross Dmochowski
- Hoping for more... (interfaces) Tommy Wang
- Hoping for more... (interfaces) Matt Mihaly
- Hoping for more... (interfaces) Ling Lo
- Hoping for more... (interfaces) Matt Mihaly
- Hoping for more... (interfaces) Jon Morrow
- Hoping for more... (interfaces) Kwon Ekstrom
- d20 shannon hall
- Group sizes and MUDs as sport? Ola Fosheim Grøstad
- free release of graphical MUD Chris Gray