[DGD] Immortal Cheating

[Dan Bentley]

Hrm, what about instead of having the OOG stuff check what it's dealing
with, having the IG stuff check?

Since IG stuff all has to go through QC, you could give QCers access to a
special location where only IG objects go, and when something tries to
interact with the IG object, it just checks to make sure the object is in
that protected location... if it's not, then no interaction takes place...

> -----Original Message-----
> From: dgd-bounces at dworkin.nl [mailto:dgd-bounces at dworkin.nl] On Behalf
> Of Steve Wooster
> Sent: Saturday, September 30, 2006 9:02 PM
> To: dgd at dworkin.nl; s.f.m.wooster+dgd at gmail.com
> Subject: [DGD] Immortal Cheating
> 
> Hi... I figured I'd test my new e-mail address and filters by posting
> an
> idea I had for preventing immortals from cheating.
> 
> I used to volunteer at a mud where non-intervention was an important
> aspect of immortal conduct - it was strictly against the rules for
> immorts to help/hinder players in any sort of potentially
> gameplay-related sense (with the exception of helping lost newbies with
> information) and areas had to undergo a rigorous QC process before
> being
> added to the game. Unfortunately, sometimes people would disregard
> those
> rules, creating items to level up their friends, or giving them
> uber-weapons, or modifying previously QCed code to unbalance it. As far
> as I could tell, there wasn't an easy way to detect or prevent
> untrusted
> code from interacting with the game.
> 
> So my idea is to have the concept of "in-game" (as opposed to immortal
> toys or code that's in production) be an inherent part of objects. An
> object would be considered in-game (IG) only after being QCed, and
> out-of-game (OOG) objects could only have restricted interaction with
> in-game objects. So a wiz-tool might be able to ask a player object
> what
> their stats are, but it wouldn't be able to modify them. Coders could
> change IG code in case of emergencies or to fix reported bugs, but all
> such changes would be logged for admins to review. OOG code would not
> be
> kept track of at all.
> 
> So what I've been trying to think about is a good way of preventing OOG
> functions from calling restricted functions of IG code. One possibility
> would be to provide an afun like validateCall() which would runtime if
> the function was IG but its caller was OOG. But that could be clunky
> and
> inconvenient, so I'd like to make something a little more seamless. So
> I
> thought about something along these lines:
> 
> private int __outOfGame;
> static mixed call_other( mixed obj, string function, mixed args... ) {
>     if ( __outOfGame ) {
>         if ( !::call_other( obj, "__queryOutOfGame" ) &&
> isCapitalized(function) ) /* capitalized functions are considered
> restricted */
>             runtime("OOG objects cannot call restricted funcions in IG
> objects");
>     }
>     return ::call_other( obj, function, args... );
> }
> 
> Do other people thing overriding call_other() like this would take too
> much overhead for IG objects?
> 
> Another possibility I was thinking of, was to switch out versions of
> auto-objects... when the object-daemon would load an OOG object, it
> would recompile the auto object to include an overridden call_other(),
> but when loading IG objects, it would recompile the auto-object to omit
> that code. Although it would lead to longer load-times and more
> object-daemon complexity, I was thinking that maybe that could allow IG
> code to be unhindered by security checks.
> 
> One thing I haven't really put much thought into, is if you discover
> that somebody has used IG code to cheat, how do you detect who they
> helped?
> 
> -Steve Wooster
> 
> 
> __________________________________________
> http://mail.dworkin.nl/mailman/listinfo/dgd