Programming origin of (bug? feature?) in old game ("Duke Nukem 3D")

Started by
5 comments, last by adam4813 10 years, 8 months ago

Hi.

(I'm posting this here because to me it seems game-programming related, but if you think it should be elsewhere, you can move it)

I saw this on Wikipedia:

http://en.wikipedia.org/wiki/Noclip_mode

No-clipping can conflict with other elements of the game. For instance, in Duke Nukem 3D, and the Commander Keen series, having no-clip and walking outside the level area causes death, and if the player has god mode activated the game will be left in an infinite loop or crash due to the way god mode was implemented. In most source ports for Duke Nukem 3D, this problem is corrected and it instead behaves more like Doom.

I'm curious about this. Now, Duke Nukem 3D's source code has apparently been released under free license (GPL), so I suppose one could dig through it and/or run experiments, though I don't feel like doing it right now. What would cause this phenomenon (namely that going out of the level in "noclip" mode kills you), from a programming point of view? As it doesn't seem at first obvious that this kind of thing would occur.

Advertisement

Probably a failsafe check, to kill you incase of collision bugs. Better than getting stuck and having to manually restart the game.

I usually check for a deep-below-the-earth Y position, incase you fall through the ground. Also catches going through walls, since there's usually no ground under them,

Maybe Duke Nukem has an infinite ground plane so you can't fall forever, but checks if you get outside the bounding box of the level model. Although the only way you could really get yourself stuck in a situation like that is by walking so far out into nothingness that you can't find your way back... in which case you arguably deserve having to restart manually tongue.png

Well, if it's a feature, I suppose then one could find it by searching the source code for calls to the player death routine, no?

I just got the code from the 3D Realms website and had a look. I believe your hypothesis is in fact correct.

I discovered the following code segment in the routine "processinput" in PLAYER.C:


    psect = p->cursectnum;
    if(psect == -1) /* hypothesis: this means "out of range" sector */
    {
        if(s->extra > 0 && ud.clipping == 0) /* "clipping == 0" = no clipping? I note this variable is modified by the noclip cheat */
        {
            quickkill(p); /* kill the player */
            spritesound(SQUISHED,pi);
        }
        psect = 0;
    }

(Comments added by me -- this code has pretty much no comments)

It looks to be exactly what you said. To check if the player is out of range, and kill them if that is the case. A failsafe, just as you thought.

There also appear to be a few other checks that look like this one.

Thanks for the suggestion!

ADDENDUM:

Apparently, I discovered something that said the kill-on-noclip was removed in version 1.4 and 1.5, the last of which is the version for which the released source code is for. So now I'm not so sure as to the meaning of the above code.

Duke3D's world isn't quite a real 3d cartesian world, because two rooms can exist independently at the same location. It's "portal based", where you're in a room, and the doorways are "portals" to other rooms. You can only see the room you're currently in, and you can see through portals into other rooms.

This lets you construct impossible spaces,

e.g. starting in the red room, you can only see the red room and out into the orange coridoor (and again out into the green room), you can't see the blue room.

If you walk into the green room, you can see back into the orange/red rooms, and into the blue room.

If you walk into the blue room, you can only see it, and back into the green room, but you can't see the red room.

The red and blue rooms exist in the same space, but aren't connected!

NfeeYoi.png

In a normal game, given a 3d position, you can ask "which room am I in". This doesn't quite work in this strange portal room -- it has to track your movements from one room to the next through portals, because there are a set of positions that are in both the red and blue rooms, but the player can only be in one of them at a time.

I'm not sure if this is the reason behind the bug/feature, but it could be... maybe... Because the game has to track your movement through portals, if you leave a room via a wall, it would have no way of ever getting you back into a room (as you have to exit/leave via portals).

Maybe that is the logic then. If you aren't in a "section" or room then you left it via a non-portal, so kill.

This topic is closed to new replies.

Advertisement