[DGD] Immortal Cheating

[Steve Wooster]

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