November 2003
- Fwd: Web vs. Java client Eric Merritt
- Fwd: Web vs. Java client Mike Shaver
- MUD-Dev Digest, Vol 6, Issue 3 Alex Chacha
- MUD-Dev Digest, Vol 6, Issue 3 Zach Collins {Siege}
- java clients (was: MUD-Dev Digest, Vol 6, Issue 3) ceo
- MUD-Dev conference 2003/2004 Brian 'Psychochild' Green
- Biz: Game support Peter Tyson
- Biz: Game support Damion Schubert
- Biz: Game support Daniel.Harman@barclayscapital.com
- Biz: Game support Michael Sellers
- Biz: Game support John Erskine
- Advantage for outside skills T. Alexander Popiel
- Advantage for outside skills Jeff Fuller
- Advantage for outside skills Paul Schwanz
- Removing access to entertainment John Buehler
- Removing access to entertainment szii@sziisoft.com
- Removing access to entertainment Patrick Dughi
- Removing access to entertainment John Buehler
- Removing access to entertainment Sheela Caur'Lir
- Removing access to entertainment Marian Griffith
- Removing access to entertainment John Buehler
- Removing access to entertainment Paul Schwanz
- Removing access to entertainment Hans-Henrik Staerfeldt
- Removing access to entertainment apollyon .
- Removing access to entertainment Amanda Walker
- Removing access to entertainment Peter Keeler
- Removing access to entertainment Matt Mihaly
- Removing access to entertainment Amanda Walker
- Removing access to entertainment John Buehler
- Removing access to entertainment Daniel.Harman@barclayscapital.com
- Removing access to entertainment John Buehler
- Removing access to entertainment Michael "Flury" Chui
- Removing access to entertainment Paul Schwanz
- Removing access to entertainment John Buehler
- Removing access to entertainment Sheela Caur'Lir
- Removing access to entertainment John Buehler
- Removing access to entertainment Sheela Caur'Lir
- Removing access to entertainment John Buehler
- Removing access to entertainment Sheela Caur'Lir
- Removing access to entertainment John Buehler
- Removing access to entertainment Daniel.Harman@barclayscapital.com
- Removing access to entertainment John Buehler
- Removing access to entertainment Sheela Caur'Lir
- Removing access to entertainment Jeff Crane
- Removing access to entertainment John Buehler
- Removing access to entertainment Paul Schwanz
- Removing access to entertainment John Buehler
- Removing access to entertainment Chanur Silvarian
- Removing access to entertainment Sheela Caur'Lir
- Removing access to entertainment Michael Sellers
- Removing access to entertainment Amanda Walker
- Removing access to entertainment Matt Mihaly
- Removing access to entertainment Kwon J. Ekstrom
- Removing access to entertainment Brian Lindahl
- Removing access to entertainment John Buehler
- Removing access to entertainment Damion Schubert
- Removing access to entertainment John Buehler
- Removing access to entertainment Marian Griffith
- Removing access to entertainment John Buehler
- Removing access to entertainment Marian Griffith
- Removing access to entertainment John Buehler
- Removing access to entertainment Corpheous Andrakin
- Removing access to entertainment Darren Hall
- Removing access to entertainment John Buehler
- Removing access to entertainment Sheela Caur'Lir
- Removing access to entertainment John Buehler
- Removing access to entertainment Chanur Silvarian
- Removing access to entertainment Amanda Walker
- Removing access to entertainment Jeremy Neal Kelly
- Removing access to entertainment Corpheous Andrakin
- Removing access to entertainment John Buehler
- Second Life's customers own the IP of their creations Mike Shaver
- Second Life's customers own the IP of their creatio ns Christer Enfors XW {TN/PAC}
- Second Life's customers own the IP of their creatio ns Lee Sheldon
- Second Life's customers own the IP of their creatio ns Christer Enfors XW {TN/PAC}
- Second Life's customers own the IP of their creatio ns Jeff Thompson
- Second Life's customers own the IP of their creations Corey Crawford
- Second Life's customers own the IP of their creatio ns Corpheous Andrakin
- Second Life's customers own the IP of their creatio ns Ren Reynolds
- Second Life's customers own the IP of their creatio ns Daniel.Harman@barclayscapital.com
- Second Life's customers own the IP of their creatio ns Crosbie Fitch
- Second Life's customers own the IP of their creatio ns Amanda Walker
- Second Life's customers own the IP of their creatio ns Ren Reynolds
- Second Life's customers own the IP of their creatio ns Ola Fosheim Grøstad
- Effects of skill-imbalances? Joshua Judson Rosen
- download-barriers Joshua Judson Rosen
- download-barriers Matt Mihaly
- Language and platform for Text MUD server =?koi8-r?Q?=22?=Andrew Batyuck=?koi8-r?Q?=22=20?=< javaman@mail.ru>
- Language and platform for Text MUD server Miroslav Silovic
- Language and platform for Text MUD server Kwon J. Ekstrom
- Language and platform for Text MUD server Patrick Dughi
- Language and platform for Text MUD server Alex Chacha
- Ragnarok Wisdom Michael Tresca
- Java on Linux gbtmud
- Java on Linux Artur Biesiadowski
- AS TECHNOLOGY SCATTERS VIEWERS, NETWORKS GO LOOKING FOR THEM Michael Tresca
- Breakdown of Java users Christopher Kohnert
- Second Life's customers get [copyright?] of their creations Joshua Judson Rosen
- Rubies of Eventide shutting down Mantees de Tara
- Rubies of Eventide shutting down Zach Collins {Siege}
- Rubies of Eventide shutting down Sheela Caur'Lir
- Rubies of Eventide shutting down Michael Sellers
- Rubies of Eventide shutting down Koster, Raph
- Dopamine and addiction Ola Fosheim Grøstad
- Dopamine and addiction David Love
- Dopamine and addiction a t y mcguire
- Dopamine and addiction Lars Duening
- Dopamine and addiction Ola Fosheim Grøstad
- Dopamine and addiction Rayzam
- Dopamine and addiction Ola Fosheim Grøstad
- Dopamine and addiction Rayzam
- Dopamine and addiction Marian Griffith
- Trusting the client, encrypting data Ola Fosheim Grøstad
- Trusting the client, encrypting data Eli Stevens
- Trusting the client, encrypting data Ola Fosheim Grøstad
- Trusting the client, encrypting data Jessica Mulligan
- Trusting the client, encrypting data ceo
- Trusting the client, encrypting data Amanda Walker
- Trusting the client, encrypting data Mike Shaver
- Trusting the client, encrypting data Ola Fosheim Grøstad
- Trusting the client, encrypting data Ola Fosheim Grøstad
- Trusting the client, encrypting data Sean Middleditch
- Trusting the client, encrypting data Peter Harkins
- Trusting the client, encrypting data Amanda Walker
- Trusting the client, encrypting data Crosbie Fitch
- Trusting the client, encrypting data Richard A. Bartle
- Trusting the client, encrypting data Mike Shaver
- Trusting the client, encrypting data ceo
- Trusting the client, encrypting data J C Lawrence
- Trusting the client, encrypting data Ola Fosheim Grøstad
- Trusting the client, encrypting data Sean Middleditch
- Trusting the client, encrypting data Mike Shaver
- Trusting the client, encrypting data Paul Schwanz
- Trusting the client, encrypting data Vincent Archer
- Trusting the client, encrypting data Felix A. Croes
- Trusting the client, encrypting data Sean Middleditch
- Trusting the client, encrypting data Alain Hamel
- Trusting the client, encrypting data Richard A. Bartle
- Trusting the client, encrypting data Alex Chacha
- Trusting the client, encrypting data Amanda Walker
- Trusting the client, encrypting data Crosbie Fitch
From: Amanda Walker
> The problem is not the cryptosystem. You can use any cryptosystem
> you want, implemented on a FIPS 140 approved hardware
> cryptographic module, whatever. It won't matter.
Indeed.
You have to escape the centric mindset of the game provider.
Take a step back.
Imagine there is no game provider.
You have a hundred players.
99 of them are interested in playing a fair game.
None of them know each other's human identity. There is only a
machine identity that each player maintains only so long as it
suits them.
They all exchange open information about the game they're playing,
but willingly choose not to look at or modify any information not
in accordance with the rules of the game. They play by the rules.
The only hope for them is that they are interested in maintaining
play by the rules.
Of course, they can always change the rules, democratically
perhaps, but there must be an interest or realisation that the
game is only fun if they agree to follow the same set of rules.
At this point it should be clear that to hide any information makes
little sense. Everyone trusts everyone else already. To hide
something indicates a lack of trust. In any case, hiding something
just adds a minor one time cost to the effort involved in undoing
the hiding. It's like sending someone a parcel with "Do not open
until Xmas" written on it. If you're into the rules of the game you
won't open it until the right time, but the wrapping paper is a
minor barrier, given you have to be able to open it up eventually
anyway.
What 99 of the players really want to do is know in fairly good time
when 1 player has decided not to play by the rules.
If there are 99 computers with 'cheat detection' analysis programs
running, then it doesn't matter if the 1 cheat disables
theirs. There will be enough CPUs whirring away in the background
analysising all the players' behaviour, and as soon as a player
consistently behaves in a way that reveals they have unfair
advantage (not just that they're a good player), then the cheat can
be ditched. Only to return as player 101 or 125 - who knows?
Perhaps in the same way that Open Source programs may be considered
to have fewer back-doors in them than proprietary programs, the
integrity of game rules may be better achieved by processes that can
operate in the open rather than those that rely on encryption.
A cheat faces a similar kind of problem to the police with an
undercover agent working within a drugs cartel, if one wishes to
remain playing, even with inside information, one still has to take
pains to engineer situations where one can take remedial action such
that the cartel doesn't suspect they've been infiltrated.
With games I expect the trick is to make it take a large amount of
effort for the cheat to operate without triggering the 'automatic
cheat detectors'.
Conversely to cheat detectors, there's also the trustworthiness
detectors. Players who've built up a good reputation with other
players, have a long history, no evidence of cheating, and can be
relied upon to be interested in fair play. One can then be more
suspicious of the players with poor reputations, and more forgiving
of players with good reputations.
I like to believe that players are the friend (well, most of
them). If you like to believe that players are the enemy, then
perhaps I can only suggest you look at organised crime or
terrorism. Each criminal is a priori suspect, nevertheless, the
organisation can only arise based on some degree of trust,
reputation, and integrity checking. Reward according to reputation,
not according to how well you cheat.
Ok, I admit it. I waved my hands.
Or did I?
- Trusting the client, encrypting data Crosbie Fitch
- Payment Transaction Processing altug
- Payment Transaction Processing Sean Middleditch
- Payment Transaction Processing Jason Smith
- Payment Transaction Processing stanza
- Payment Transaction Processing Matt Mihaly
- Payment Transaction Processing Gary Cooper
- Payment Transaction Processing J C Lawrence
- Payment Transaction Processing Gary Whitten