November 1998
- ADMIN: Unsubscriptions J C Lawrence
- ScryMUD [CUSTOM] Code release. Ben Greear
- Designgoals for CoolComponentCore(Was MUD-Dev's...) Ola Fosheim Grøstad
- Designgoals for CoolComponentCore (Was MUD-Dev's...) Niklas Elmqvist
- Designgoals for CoolComponentCore (Was MUD-Dev's...) Ola Fosheim Grøstad
- DevMUD: CVS Tree is ready. Are your sources? J C Lawrence
- DevMUD considerations and the Halloween article J C Lawrence
- DevMUD considerations and the Halloween article Jon Leonard
- DevMUD considerations and the Halloween article Adam J. Thornton
- DevMUD considerations and the Halloween article J C Lawrence
- DevMUD considerations and the Halloween article Chris Gray
- DevMUD considerations and the Halloween article Jon Leonard
- DevMUD considerations and the Halloween article David Bennett
- DevMUD considerations and the Halloween article Alex Oren
- DevMUD considerations and the Halloween article Chris Gray
- DevMUD considerations and the Halloween article Marc Hernandez
- DevMUD considerations and the Halloween article Chris Gray
- DevMUD considerations and the Halloween article Vadim Tkachenko
- DevMUD considerations and the Halloween article Jon Leonard
- DevMUD considerations and the Halloween article Alex Oren
- DevMUD considerations and the Halloween article Alex Oren
- DevMUD considerations and the Halloween article Ola Fosheim Grøstad
- DevMUD considerations and the Halloween article Chris Gray
- Designgoals for CoolComponentCore (Was MUD-Dev's...) Chris Gray
- Fallacy Watch and DevMUD Vision (was ... CoolComponentCore) Hal Black
- Fallacy Watch and DevMUD Vision (was ... CoolComponentCore) Ola Fosheim Grøstad
- Fallacy Watch and DevMUD Vision (was ... CoolComponentCore) Jon Leonard
- Fallacy Watch and DevMUD Vision (was ... CoolComponentCore) Ola Fosheim Grøstad
- Flamebite of the day Vadim Tkachenko
- META: DevMUD, MUD-Dev, and (list) futures J C Lawrence
- META: DevMUD, MUD-Dev, and (list) futures Jon Leonard
- META: DevMUD, MUD-Dev, and (list) futures James Wilson
- META: DevMUD, MUD-Dev, and (list) futures J C Lawrence
- META: DevMUD, MUD-Dev, and (list) futures J C Lawrence
- DevMud RFC #1 - Was DevMUD considerations and the Halloween article James Wilson
- My vision for DevMUD Jon Leonard
- My vision for DevMUD Niklas Elmqvist
- My vision for DevMUD Jon Leonard
- My vision for DevMUD Thandor
- My vision for DevMUD Robert Woods
- My vision for DevMUD ApplePiMan@aol.com
- My vision for DevMUD Thandor
- My vision for DevMUD Jon Leonard
- My vision for DevMUD Adam J. Thornton
- My vision for DevMUD Jon Leonard
- My vision for DevMUD Adam J. Thornton
- My vision for DevMUD Caliban Tiresias Darklock
- My vision for DevMUD ApplePiMan@aol.com
- My vision for DevMUD James Wilson
- My vision for DevMUD ApplePiMan@aol.com
- My vision for DevMUD James Wilson
- My vision for DevMUD Jon A. Lambert
- My vision for DevMUD Darrin Hyrup
- My vision for DevMUD Jon Leonard
- My vision for DevMUD J C Lawrence
- My vision for DevMUD ApplePiMan@aol.com
- My vision for DevMUD ApplePiMan@aol.com
- My vision for DevMUD ApplePiMan@aol.com
- My vision for DevMUD Jon A. Lambert
- My vision for DevMUD Hal Black
- My vision for DevMUD ApplePiMan@aol.com
- My vision for DevMUD Jon A. Lambert
- My vision for DevMUD Chris Gray
- My vision for DevMUD Chris Gray
- My vision for DevMUD Ben Greear
- My vision for DevMUD Jo Dillon
- My vision for DevMUD Ben Greear
- DevMUD Prototyping (was META: DevMUD, MUD-Dev, and (list) futures) Jon Leonard
- DevCore Project Management Ola Fosheim Grøstad
- DevCore Project Management Adam Wiggins
- DevCore Project Management Ola Fosheim Grøstad
- DevCore Project Management Simon Duggan
- DevCore Project Management Jon Leonard
- DevCore Project Management Chris Gray
- DevCore Project Management Darrin Hyrup
- Fallacy Watch and DevMUD Vision (was ... CoolComponentCore) Chris Gray
- Drama Theory Ling
- Moral license (My vision for DevMUD) Ola Fosheim Grøstad
- Moral license (My vision for DevMUD) ApplePiMan@aol.com
- Moral license (My vision for DevMUD) Ola Fosheim Grøstad
- Fwd: My vision for DevMUD Jon Leonard
- DevMUD Prototyping Niklas Elmqvist
- Altima... Thandor
- Fwd: My vision for DevMUD Darrin Hyrup
- Tim O'Reilly's "Open Letter to Microsoft" ApplePiMan@aol.com
- Tim O'Reilly's "Open Letter to Microsoft" Adam Wiggins
- [DevMud] quick question... Franklyn Colebrooke, Jr.
- signal to noise... Andrew Wilson
- "knights and merchants" - NYTimes review James Wilson
- ADMIN: DevMUD posting authority promotions J C Lawrence
- A Small Conceptual Object System For MUDs Ola Fosheim Grøstad
- A Small Conceptual Object System For MUDs Emil Eifrem
- A Small Conceptual Object System For MUDs Mark Gritter
- A Small Conceptual Object System For MUDs Ola Fosheim Grøstad
- A Small Conceptual Object System For MUDs Jon A. Lambert
- Random Quest Generation chris@realm.zfn.uni-bremen.de
- Random Quest Generation Chris Gray
- Random Quest Generation Michael.Willey@abnamro.com
- Random Quest Generation J C Lawrence
- Random Quest Generation J C Lawrence
- Quick socket question Dr. Cat
- Quick socket question Jon Leonard
- Quick socket question Ben Greear
- Quick socket question Chris Gray
- Quick socket question J C Lawrence
- Quick socket question J C Lawrence
- Quick socket question Adam Wiggins
- Quick socket question Petri Virkkula
- ScryMUD [CUSTOM] Released under GNU General Public License Ben Greear
- Quick socket answer Dr. Cat
- Rebol Ling
- Spell components, chemistry, and the like... quzah [sotfhome]
- Spell components, chemistry, and the like... Chris Gray
- Spell components, chemistry, and the like... quzah [sotfhome]
- Spell components, chemistry, and the like... JavaAl@aol.com
- Spell components, chemistry, and the like... Adam Wiggins
- Spell components, chemistry, and the like... quzah [sotfhome]
- Spell components, chemistry, and the like... Nathan F Yospe
- Spell components, chemistry, and the like... quzah [sotfhome]
- Spell components, chemistry, and the like... Hal Black
- Spell components, chemistry, and the like... Ling
- Spell components, chemistry, and the like... Caliban Tiresias Darklock
- Spell components, chemistry, and the like... Ben Greear
- Spell components, chemistry, and the like... Caliban Tiresias Darklock
- Spell components, chemistry, and the like... quzah [sotfhome]
- Spell components, chemistry, and the like... Caliban Tiresias Darklock
- Spell components, chemistry, and the like... quzah [sotfhome]
- Spell components, chemistry, and the like... Hal Black
- Spell components, chemistry, and the like... Peck, Matthew x96724c1
- Spell components, chemistry, and the like... Nathan F Yospe
- Spell components, chemistry, and the like... Ben Greear
- Spell components, chemistry, and the like... JavaAl@aol.com
- Spell components, chemistry, and the like... Chris Gray
- Spell components, chemistry, and the like... Nathan F Yospe
- Spell components, chemistry, and the like... Adam J. Thornton
- Spell components, chemistry, and the like... Franklyn Colebrooke, Jr.
- Spell components, chemistry, and the like... Emil Eifrem
- Spell components, chemistry, and the like... Nathan F Yospe
- ADMIN: Attributions J C Lawrence
- AMIN: Unsubscriptions J C Lawrence
- OO Design Question Brad Leach
- OO Design Question J C Lawrence
- Chemistry [Warning, scientific content] Peck, Matthew x96724c1
- MUD clients, testing Chris Gray
- MUD clients, testing Scatter
- MUD clients, testing J C Lawrence
- JOB: Project manager and scaling/networking guru needed for game project J C Lawrence
- More module ideas Mark Gritter
- The Innerworld Project Niklas Elmqvist
- META: FAQ's bios. Ling
- Mage 2 Mage 0.89 J C Lawrence
- Game library notes J C Lawrence
- World Building Page Ling
- ScryMUD [CUSTOM] Code release 1.8.1 Ben Greear
- DIS: Client-Server vs Peer-to-Peer Niklas Elmqvist
- DIS: Client-Server vs Peer-to-Peer J C Lawrence
- DIS: Client-Server vs Peer-to-Peer Niklas Elmqvist
- DIS: Client-Server vs Peer-to-Peer J C Lawrence
- DIS: Client-Server vs Peer-to-Peer Ling
- DIS: Client-Server vs Peer-to-Peer Niklas Elmqvist
- DIS: Client-Server vs Peer-to-Peer Ling
- DIS: Client-Server vs Peer-to-Peer Nathan F Yospe
- DIS: Client-Server vs Peer-to-Peer J C Lawrence
- DIS: Client-Server vs Peer-to-Peer Niklas Elmqvist
- DIS: Client-Server vs Peer-to-Peer Ola Fosheim Grøstad
- DIS: Client-Server vs Peer-to-Peer Marc Hernandez
- DIS: Client-Server vs Peer-to-Peer Caliban Tiresias Darklock
- DIS: Client-Server vs Peer-to-Peer Marc Hernandez
- DIS: Client-Server vs Peer-to-Peer Caliban Tiresias Darklock
- DIS: Client-Server vs Peer-to-Peer Mik Clarke
- DIS: Client-Server vs Peer-to-Peer Adam Wiggins
- DIS: Client-Server vs Peer-to-Peer Jon Leonard
- DIS: Client-Server vs Peer-to-Peer Niklas Elmqvist
- DIS: Client-Server vs Peer-to-Peer Greg Underwood
- DIS: Client-Server vs Peer-to-Peer Greg Underwood
- DIS: Client-Server vs Peer-to-Peer Marc Hernandez
On Sun, 29 Nov 1998, Greg Underwood wrote:
> At 10:06 PM 11/24/98 +0100, Niklas Elmqvist wrote:
> > For example, in the DIS standard, the shooting client is
> >responsible for reporting the shot and the ballistics to the targeted
> >client, but it us up to the targeted client to decide whether the shot is
> >a hit or not, and the extents of the damages.
>
> Well, techinically, that is what the standard IMPLIES, not what it states.
> All it states is that the Detonation PDU has to be issued from the
> simulation that detects the detonation (note that this does not have to be
> the simulation controlling the entity that detonated). It is a common
> (and, in a trusted network, safe and easy to implement) assumption that the
> simulation controlling the targeted entity resolves the damage. However,
> if you wanted to have a Client-Server architecture, you could have the
> simulation controller resolve all damage and send out sim-control PDUs to
> enact the proper results.
>
> >In a trusted network
> >environment (such as the "safe" LANs the US DoD no doubt is using DIS on),
> >this is no problem. To me, however, this instinctively feels like a big
> >stumbling block in an untrusted network such as the Internet -- horrible
> >visions of Interstate '76 and Diablo multiplayer rise up to haunt me. In a
> >naive DIS implementation running on the devious Internet, clients could
> >easily be hacked (especially if the client is Open Source) and modified to
> >always tell the shooter that the shot missed (or that the damages are
> >minimal). Clearly, this simply won't do. (Yes, one in Raph's collection of
> >laws, the one about clients being in the hands of the enemy, does spring
> >to mind.)
> Aye, "this simply won't do." I would recommend something like so:
>
> The clients are stripped down to simply provide the interface to the
> environment, managing their own entities, and dead-reckoning the foreign
> entities, between state updates. If the client detects a
> collision/detonation, it fires off the appropriate PDU. The Server catches
'If the client detects'. So lets say I put a proxy between me and
the server and intercept all the coll/det PDU's. Does this mean I never
collide nor detonate? In small games (ie <32 or so) it would probably be
fine because it is easy to detect, but larger games (hundreds to thousands
of simul. clients) it would be a nightmare.
> any detonation/collision PDUs, and immediately sends out an
> entity-Stop/Pause PDU. Once it resolves the collision/detonation, it sends
> out a PDU (can't recall the name, I think it's an Entity State PDU, but it
> might be a special PDU) to update the targeted entity, and then a
> Start/Resume PDU. If it decides the entity is dead, it sends out an Entity
> Destroy PDU, telling everyone that the entity is dead. The clients would
> have to be set up to ignore all PDUs from any entity they didn't receive a
> Start PDU for (to prevent hacking of the client). The problem with this is
> increased latency between action and resolution.
> >While I am at it and provided the answer is "yes, client-server is the way
> >to go" I might as well ask some additional questions:
> >
> > - How would you keep the "distributed" in DIS with a client-server
> > architecture?
>
> Distrubuted does not mean "evenly distributed". The clients can do action
> detection, just not resolution. As long as all clients AND the server are
> doing detection, and the server's resolution algorithms take into account
> the possibility of false/innacurate detections, you should be safe. You'll
> have to assume that any detections made by the server are accurate.
This answers the above I think, however I fail to see why to have
the client send a message at all (it could detect it so that it could
start the death/collide animations).
> You can probably allow the client to handle modeling of motion for the
> entity(s) it controls. Just put some simple reality checks on the server
> side, so that it doesn't trust the results completely. The down side to
> this is that it requires that both client and server have the same database
> to describe the environment. You could accomplish this through use of the
> Info PDUs, to send info about the DB to the clients, if it is too large for
> the client to have a complete copy of, or there are parts of it that you
> don't want the client to know everything about (secret doors, etc).
>
> You'll also have to be able to handle a client that refuses to listen to
> the sim control PDUs from the server. I'd reccomend an Entity Destroy PDU
> for all the entities that client controls, effectively removing it from the
> loop.
>
> The only situation I can envision that would get around that would be all
> clients ignoring the server. If that happens, I'd say the person that
> pulled that off deserves to enjoy it. The client should be a sufficiently
> stripped down DIS sim that the amount of work required to allow all the
> clients to ignore the server would be collosal. That and the resulting sim
> would be peer-to-peer with all the inherant problems therin.
>
> > - What things can be trusted to the client? (Yes, I know there has been a
> > rather extensive thread on that.) Does anyone know, for example,
> > what the client-server relationships/responsibilities are for
> > games such as Quake?
>
> Dunno what Quake does, but I don't think the client does a lot. I've seen
> my position change as a result of lag (IE: I walk down a hall, then I'm
> back at the start of the hall, and walk down it again, repeat 4-5 times
> while the lag clears). Quake clients appear to be simple interfaces. You
> may be able to go a little further than that, using DIS, but you'll have to
> play with it and see how false info can be used to thwart the system.
> Come to think of it, I bet Quake clients have a full copy of the map, too. ;)
Quake simply does client prediction and display. Sadly Quake
clients have a complete copy of the map (they must for the bsp stuff to
work), as well as copies of the models. This lead to cheats concerning
changing the models to be more visible and 'cutting' parts out of the
maps. In team fortress this game the cheating teams HUGE advanteges.
So they put in CRC checks for models and maps. As simple as this
fix is it seems to be working.
They cant get rid of autoaim bots, but it is fairly easy to spot
(the person switches very quickly from person to person, fires in
directions it isnt moving etc).
Ive had an idea of just doing spot checks on the client. Assuming
most players are not wanting to cheat, and assuming the game is designed
such that cheats on the client end are detectable (ie with the collision
stuff), would it be a good design decision to let the clients do some work
but do automated spot checks occasionally? Then if the server detects
something it can flag it, send messages to admin personnel, kick the
player off etc.
> -Greg
> --
> MUD-Dev: Advancing an unrealised future. - DIS: Client-Server vs Peer-to-Peer Greg Underwood
- DIS: Client-Server vs Peer-to-Peer Niklas Elmqvist
- DIS: Client-Server vs Peer-to-Peer Greg Underwood
- DIS: Client-Server vs Peer-to-Peer Marc Hernandez
- Ruminations on CVS and developing in the Bazaar Ben Greear
- Ruminations on CVS and developing in the Bazaar Chris Gray
- Ruminations on CVS and developing in the Bazaar greear@cyberhighway.net
- Ruminations on CVS and developing in the Bazaar J C Lawrence
- Ruminations on CVS and developing in the Bazaar greear@cyberhighway.net
- Ruminations on CVS and developing in the Bazaar J C Lawrence
- Ruminations on CVS and developing in the Bazaar Petri Virkkula
- DevMUD: List data, subscription, and the rest J C Lawrence
- DevMUD: List data, subscription, and the rest J C Lawrence
- Atention SSH/Java-developers (MindTerm update) J C Lawrence
- ScryMUD/Hegemon code Release Ben Greear