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
- strong encryption for authentication Edward Glowacki
Quoted from Caliban Tiresias Darklock on Mon, Jul 16, 2001 at
10:26:19AM -0700:
> 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.
Yes, often the boundary is arbitrary. So are boundaries in any
game. Think about football, soccer, basketball, volleyball, tennis,
etc. where the boundary is just a painted line on the playing
surface. The exact location of the line is arbitrary, and the game
would still function the same if the line was moved or changed. But
the line denotes what is "in" the game and what is "out" of the
game, it's part of the rules of the game, and the only way the game
can be fair is if everyone respects those rules and therefore those
boundaries. Now, sometimes the enforcement of those rules and
boundaries isn't so cut and dried, or evenly distributed, but that's
another issue.
>> 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.
Even if auto-aimers didn't exist and you had that level of skill,
people would be suspicious until it was proven that you weren't
cheating. Because there's the possibility that maybe *you* came up
with an autoaimer that nobody else knows about.
>> As for spying, if you want to support it in a game, build it into
>> the game itself.
> I did. :)
=) I think that's definately a "Good Thing".
>> 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.
People will always come up with new ways of cheating that you've
never thought of yet. If you allow some levels of cheating to
become part of the game, there will be new ones that fall outside
that domain, and you still have the problem.
>>> 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.
Cheating will always unbalance the game. Even if you eliminate all
out-of-game cheating (packet sniffing, etc.), there can be loopholes
inside the game to exploit, such as buying and selling items for
ridiculous profits. When you lay down the rules for a game and set
boundaries to what is in the game and what is outside the game (or
cheating), people will use those boundaries, and if some people are
allowed to exploit them, they will have an advantage.
Take basketball (or soccer, or other similar game). If you're on
defense and the offense moves the ball to one of the corners of the
playing field, you can use the boundaries of the game to block 3/4
of the possible directions they can move the ball. You can then
focus your defense on the last 1/4, knowing there's really no way
the opposing player can escape from the corner except through you.
But if the opposing player cheats and goes outside the boundaries to
get around you, suddenly what was a valid strategy for playing the
game by the rules no longer works.
The same applies to cheating and online games. One difference
though is that in a sport with lines painted and referees watching,
stepping out of bounds can be seen, whereas something like packet
sniffing is for all intents and purposes invisible. If you know it
takes on average 2 minutes to find you hiding in the zone, you can
expect on average to be able to rest and recover for 2 minutes by
hiding somewhere in that zone. There are finite limits to how fast
someone can search the area to find you. If suddenly someone can
cheat and know exactly where you are, the average time it takes for
that person to find you could suddenly drop from 2 minutes to 15
seconds. But since you don't have access to that same cheat, it
will still take you on average 2 minutes to find *them* when the
roles are reversed. Your opponent now has an 8-to-1 advantage in
finding you because they have cheated and you did not (or cannot).
>>> 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.
Quake is an extreme example of the player and the character being
exactly the same. All avatars in Quake are created equal, and all
differences in them are purely the result of the player playing
them. However, we're talking more about MUD-style games here where
characters have skill sets that can be nearly as complete as
real-life. If the game has a skill for swordfighting, then within
the game, the primary factor involved when two characters duel with
swords should be that swordfighting skill. If one of the players is
in real life an olympic fencer and the other a 14 year old kid who
has never picked up a sword before, whichever *character* has the
better skill should win. There are some secondary factors which
might make a slightly less skilled character be able to defeat a
more skilled opponent, and some of these may come from the player,
but these are *secondary* to the *character's* skill.
>> 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.
True, because everyone is different outside the game. I guess I
should have stated more clearly, I meant that the *characters* (or
avatars, or in-game personae, or whatever) all start the same.
Based on a players background, a player may have knowledge in
different areas, and that may apply to the game, but for the most
part the characters would be equal.
>> 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.
For a specific skill, yes, but not necessarily for *every* skill.
For example, you may be a crack shot in Quake, able to do headshots
from a mile away, but I may be better with the rocket launcher.
Some people will rise to the top of many categories, but very rarely
would someone be the best at *everything* about a game.
>> 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 seems to me to be a paradox. If you build it with abuse in
mind, then it won't be balanced (it will be sub-standard most
likely), and therefore people won't have a reason to abuse it.
>>> 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.
Proving my point. =) Other people have been sniffed, not
necessarily for games but for information in general. Therefore,
encryption is my seatbelt.
>> 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.
I believe the vast majority of computers run MS Windows. Most
recent versions of MS Windows come with MS IE. MS IE supports SSL
connections. Therefore MS Windows has SSL. There's also OpenSSL,
which I believe is available for Windows.
>> 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.
There is plenty of encryption available today that is sufficiently
strong and technically sound enough to work. SSH and SSL are
"secure" for almost all applications. Eventually, increased
computing power will render them vulnerable in a trivial amount of
time, but by then larger keys and new algorithms will be available.
Actually using the encryption is another matter entirely. Web
browsers seem to do a fairly good job of implementing encryption
transparently, but many other ways of using encryption aren't so
easy. PGP is one example that I think you mentioned that requires
extra effort. The *implementation* of using the encryption is at
fault, not the technology behind the encryption.
>> 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. ;)
People will still try the door to see if its unlocked, and if they
can get in, they'll come and hang out for a while. If there's
nothing there, they might leave or they might make it a base of
operations for doing other things. If the door is locked, even with
a cheap homemade lock, they'll twist the knob, find out the door
doesn't open, and move on until they find a place where they can
just waltz right in.
If every place they go has at least a simple lock, they'll try
again, this time twisting the knob and pushing on the door with
their shoulder. The weakest ones will break under the strain and
they'll be in, and if the doors don't open right away, they'll move
on for easier targets. Therefore, if you are more secure than your
neighbors, you'll have fewer people seriously attempt to get in.
>> 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?
Unfortunately, yes. =( But I still don't think packet sniffing or
other forms of cheating are a suitable answer to the dilemma.
> 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
It's kinda hard to play an online game without using computers. I
mean, I can whistle ethernet packets onto the wire using a Dixie
cup, but it's a lot easier if I just plug the ethernet cable into my
computer and use that... ;) (hehe, sorry, just had to interject a
bit of humor in there, break up the conversation a bit... =) )
I understand what you're saying, that MUDs are designed with the
serious computer types in mind. However, for online games in
general, specifically larger ones that cater to a more general
audience, I think having an established set of rules and boundaries
for the game is important.
> 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.
Hmm... interesting scenario... Not sure how to best solve this one.
> 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?
I guess personally if I didn't like the way the game presented
information, I probably wouldn't play for very long unless there was
a really good reason to (all my friends played it and I wanted to
too, beta/bug testing, etc.).
> 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
It's not always possible to take away the advantage. For example,
player killing may be part of the game. I played on Medievia, where
most of the world was LPK (the game wouldn't even let you attack
another player in these areas), there was a bunch of NPK (you could
kill players, but their bodies were teleported out to a safe LPK
area when killed and they were brought back with 1 HP and all their
equipment), and small pockets of CPK (dead players sat on the ground
and could be looted for a while until their corpse turned into a
ghost). In NPK or CPK areas, knowing an opponents location is an
advantage, and that advantage can not be taken away.
> One failure of most MUDs, IMHO, is to make cheating attractive by
> default. If you cheat, you will have a definite advantage. Remove
That sounds like a definition of cheating.
>> 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 guess that's a decision everyone has to make for themselves.
> 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
=)
--
Edward Glowacki glowack2@msu.edu
"Speak softly and carry a +6 two-handed sword." --fortune - strong encryption for authentication Caliban Tiresias Darklock
- strong encryption for authentication Edward Glowacki
- 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