[MUD-Dev] Containing automation?

[Koster]

> -----Original Message-----
> From: Asmodeus [mailto:asmodeus at benshaw.com]
> Sent: Tuesday, July 20, 1999 1:30 PM
> To: 'mud-dev at kanga.nu'
> Subject: RE: [MUD-Dev] Containing automation?
> 
> 
> On Tue, 20 Jul 1999, Koster, Raph wrote:
> 
> > > -----Original Message-----
> > > From: Matthew Mihaly [mailto:diablo at best.com]
> > > Sent: Monday, July 19, 1999 6:08 PM
> > > To: 'mud-dev at kanga.nu'
> > > Subject: RE: [MUD-Dev] Containing automation?
> > > 
> > > On Mon, 19 Jul 1999, Koster, Raph wrote:
> > > 
> > > > And in commercial games it goes to the extent of custom
> > > > packet-altering software for maximum possible speed and 
> efficiency.
> > > 
> > > Good point. What an awful world we live in.
> > 
> > If you're interested, I can go into great detail about the 
> forms these
> > things take when taken to the extreme... :)
> 
>  Actually, I, for one am interested in this.  If you don't know what
> people can, and are willing to do to 'beat the game,' you 
> can't protect
> against it.

The basic initial tool is memory snooping to alter client-side memory. This
is easily done by running your client within a process that is acting as a
debugger. If you're foolish enough to trust the client, there's quite a lot
that can be done here. We didn't trust the client, so all they can do is
change the local appearance of things on their screen. So a good example
here is that someone wrote a hack that displayed all the female figures
topless; someone else wrote one that gave you a nice GUI list of monster
artwork and you could transform your image on the client into any monster.
Nobody else saw these changes of course.

A more advanced form of this mined memory in order to get data the user
wouldn't normally have, in order to generate a packet using a wedge. For
example, when you target something, you send back a packet with the id# of
the object being targeted with the mouse on your screen and the id of the
particular targeting you were doing (eg, targeting with a fireball,
targeting with an arrow, whatever). Players used this to spam the server
with fireball targeting without actually having received the prompt to
target first--without mousing over and clicking on them. Essentially a
quickie hotkey instatarget. A semaphore fixed this, but when you consider
the zillions of places where you need to set up semaphores, it's easy to see
why it was missed.

There were a few places where the code relied on the fact of physically
clicking on someone in order to prevent out of range attacks. With this, you
could target anyone on the server. :P Needless to say, we went thru and made
sure everything had ranges...

Another example was dye tubs. We sent a packet to the client that opened a
menu of colors. Selecting from the menu sent back the actual color. A
trigger on a server-side script went off when it received the packet with
the color selection, and then poof, they dyed the item. Well, the server did
not verify that the color received back was in the menu that was originally
sent, so they spoofed it and got colors that were impossible.

Combining the above two loopholes could easily allow players to dye items
that are not normally dyeable. Such as dyeing themselves translucent (eg,
permanent invisibility). Fortunately, this never happened.

A similar thing happened with the ability to pick an appearance for the
house sign. It sent back a particular icon # chosen off the menu--they
spoofed in different icon numbers. The way this was fixed in all cases was
to have the menu send an index into a server-side array instead, and verify
that the index value returned was within the array...

Worse is if the client knows about something that is not yet on screen
(which is desirable to reduce vulnerability to latency). If the client has
the id# of the object, it can then send requests for things like names.
Originally, hidden people were known by the client--players used this to
display their names and thus unhide them. Or target them with spells even
though they were not on screen yet.

The above all had nice GUI interfaces, of course.

The next, trickier, step, is to monitor and alter the packet stream. Several
players wrote wedges that lived between the client and server. UO requires a
confirmation from the server after a certain amount of moves, to prevent the
client and server from getting out of synch. Client and server both had the
same collision detection code for data that existed on both sides (such as
buildings and the map). But the server had to verify collisions against
dynamic objects that the client might not be up to speed about. One wedge
intercepted the "move denied" messages from the server and replaced them
with "move accepted." This meant that the client got out of synch, but as
long as you didn't collide with any dynamic objects, you were better than
ok--you were eating the latency involved, and therefore had a faster
connection. The program also offered a "resynch" button.

> > - you can't tie it to an advancement model then, since all 
> players would
> > advance steadily at the same rate from it. Certainly not a 
> usage-based
> > advancement model. I have come to hate usage based 
> advancement models though
> > (and will gladly explain why if anyone asks. :)
> 
>  Again, I'm asking "why?"  Anything besides the opportunity 
> for lots of
> macroing by the players to advance through that advancement model?
> Unfortunately, IMO, usage-based models make the most logical 
> sense: With a
> straight XP one (like traditional AD&D, for instance), the player
> (amazingly) gets better at doing everything by killing monsters.  It
> doesn't matter if he/she/it actually used those skills--they 
> get improved
> anyways.  What other advancement models are out there?

Usage based advancement means that you are rewarding players for performing
repetitive actions. This not only begs automation, but it means that you
have players purposely logging long hours of doing nothing socially
contributive in order to log lots of usages.

If you happen to be in the circumstance of paying for your bandwidth, this
sucks. It also eats CPU too, of course. Plus it makes for a lot of robots on
your game who are running macros rather than conversing.

Different skills are typically used at different rates during normal play.
They are also typically used at different rates when automated. And the two
tables likely won't match up. Finding advancement rates that work under both
circumstances is very very hard. A balance nightmare. (We tried a table that
dynamically adjusted, it was a moderate success).


_______________________________________________
MUD-Dev maillist  -  MUD-Dev at kanga.nu
http://www.kanga.nu/lists/listinfo/mud-dev