Some vanilla Doom code found in Doom 3

We're not sure if it survived all the way through the entire id Tech engine chain or if it has come and gone a few times, but:

http://pastie.org/8122797

This function is a direct modification, comments and variable names preserved, of a portion of the DOOM source, a function originally named P_NewChaseDir, and is the core of the DOOM AI "wandering" behavior - try a direct path; if that's blocked, try a non-reversal direction; if that's blocked, maybe turn around and move the other way.

We need to trace this back and see if it's really been in there the whole time ;)

EDIT: I give you the full history of the code. Interestingly, though not surprisingly, it does drop out of the tree in Quake 3, as that game had no single player mission and thus no need for ordinary AI.
http://eternity.mancubus.net/text/p_newchasedir_history.txt

It's even in Wolfenstein 3d, in three variants even: pastebin.com/ASBNvLfm (wl_state.c)

Interesting.

Might explain why monster AI still is shitty and has barely evolved. Are the Rage monsters equally bad?

Holy crap - what a nice find! So much for "he starts with a blank code window for each game"...

This is not part of the rendering engine.

Great find Quasar! I've not played Rage so I'm not sure what the monster behavior is like but this is certainly an interesting find.

kb1 said:

Holy crap - what a nice find! So much for "he starts with a blank code window for each game"...

It's never been true, not even for Quake and its supposed total engine rewrite. It's pretty clear that what happened was that Carmack took the DOOM source code directory, made a copy of it, and then started pruning game-specific crap til he was left with a minimal framework and some utilities. This is how wad.c and zone.c (the latter in particular) are intact, and some other file names and such still remain the same even though the contents may be radically different. Other code may have been brought back in after having been cleared out, such as this scrap of the AI, when it became clear later that the same approach with some minor modifications would work in the new game.

DOOM itself, though you could hardly say it is based on Wolfenstein, did grow out of what I describe as a "cloud" of transitional engines - see Shadowcaster and RoTT in particular - which were largely still based on it, the former having colormap distance fading and DOOM-like sky drawing; the latter using an alpha form of DOOM's patches, DOOM's wad files, and DOOM's memory allocator. I have little doubt that the "code cloud" started life in the same way, as a direct copy of the Wolf source which was quickly cleared of everything but basic utilities and then rebuilt back up.

My question at this point would be if Wolf started as a copy of Catacomb 3D, and Catacomb 3D as a copy of Hovertank 3D :P

I have to bump this thread because, thanks to Blzut 3, we've discovered this code is also in the Catacomb games and in Hovertank.

Here's the Pascal version of it that appears in Catacomb:
https://github.com/FlatRockSoft/Catacomb/blob/master/CAT_PLAY.PAS#L1009

And the version that is in Hovertank 3D:
https://github.com/FlatRockSoft/Hovertank3D/blob/master/HOVACTS.C#L1341

If you check out IDASM.ASM in Hovertank, you will also find the same random number table used by the Doom engine, and the zone memory system seems to be based loosely on a cleanup for 32-bit of the MEMMGR.C file.

So, Doom 3 has code from the earliest id games :)

Hovertank needs a remake! :)

This would not be hard to believe as doom 3 its AI feels simplistic while playing, even though it is never easy to figure out an AI while programming.

I wish i had recorded this, but in my last doom 3 play session i severely confused the doom 3 AI beyond to funny to watch.

I was in a room where there is a Pipe hanging down to the floor with behind that a desk on which you can jump in a way you are blocked in movement except one angle to get of the desk. When i was standing there two zombies came out of a doorway in their 'to dead' to walk animations and when they could see me they just started twirling around standing still on one leg because the AI could not figure out how to get to me.

They where rotating like a carnival attraction around a fixed axle without moving from the spot, and they kept doing that until i left that location.

FireFish said:

...because the AI could not figure out how to get to me.

They where rotating like a carnival attraction around a fixed axle without moving from the spot, and they kept doing that until i left that location.

Yeah. The AAS stuff doesn't always degrade gracefully in the presence of completely unanticipated architectural features. If you get into an area with no AAS links at all (not just ones the monster doesn't think it can fit into) the monster will go completely dormant, which if you ask me isn't very realistic either. As soon as you re-enter an area with an AAS link to the one the monster is in, it suddenly starts running back to find you.

A late continuation :
One thing i have noticed is that burning zombies, or unarmed ones seem to be the easiest to force into funny AI based behaviours.

funny burning zombie ;
There is an area where a burning zombie walks out of small maintenance corridor into a hallway. In that hallway there is a medium sized crate.
I jumped on top of that crate (dont ask me why) and the burning zombie just started strolling the hallway... turns around... strolls again... and it repeated that until i killed it while on the box, it kept ignoring me even when hit.

And in that same play session i experienced similar things with other melee zombies.

Quasar said:

If you get into an area with no AAS links at all (not just ones the monster doesn't think it can fit into) the monster will go completely dormant, which if you ask me isn't very realistic either. As soon as you re-enter an area with an AAS link to the one the monster is in, it suddenly starts running back to find you.

I always kind of liked that: If you can't reach your opponent, retreat and lure them back to you.

But wow, that's amazing that some ancient Id code (heck, proto-Id, really) worked its way all the way up to one of the biggest technical marvels in PC gaming of the dawn of the new millennium.

Does Rage look like it has that too?

kb1 said:

Holy crap - what a nice find! So much for "he starts with a blank code window for each game"...

He may still start with a blank code window he just puts this code in the same as other games, dosen't mean he copied it.

Solid Snake said:

He may still start with a blank code window he just puts this code in the same as other games, dosen't mean he copied it.

That's true, and for his renderers he has definitely always started with a "blank window". But when it comes time to marry that new renderer with a game engine, the way it was gone about seems to have been to always keep whatever could be useful from the previous iterations, and rewrite it progressively if necessary. The MEMMGR file is a good example, as you couldn't use that code as-is in a 32-bit program, yet, it was still obviously the basis for Doom's z_zone system after a heavy rewrite.

OF COURSE does Carmack start with an empty code window. The he moves his curser to the file menu and clicks 'open' ....

Quasar said:

Yeah. The AAS stuff doesn't always degrade gracefully in the presence of completely unanticipated architectural features. If you get into an area with no AAS links at all (not just ones the monster doesn't think it can fit into) the monster will go completely dormant, which if you ask me isn't very realistic either. As soon as you re-enter an area with an AAS link to the one the monster is in, it suddenly starts running back to find you.

As someone who's been working with id Tech 4 for over 5 years, I can say that this type of situation is more a fault of the level design than the AI code. The AI doesn't work on the basis of AAS links, (what you're describing is more along the lines of the node-based system the CryEngine uses) it works by analyzing and calculating map geometry and clip brushes and subsequently finding paths and 'reachables', both during map compilation and in real-time.

If you think of a blind man feeling his way along all the brush geometry (not models or patches, the AAS ignores those), and then recording everything he touches, that's similar to what the AAS does when you BSP a map. The more polygons and vertices there are, the more the AAS has to calculate. This is where the job of the level designer comes in. He should be familiar with the capabilities of each monster, where they can fit in and what the overhead height limits are for each one. The level designer performs collision mapping, which optimizes the AAS by making sure, for instance, that it doesn't make calculations for the space under a table when the monster can't even go down there.

So in short, level designers have to keep in mind the limitations of each monster, and also all the possible ways a combat scenario could play out. That's part of their job. In the instance of a crate the player can jump onto where a zombie can't, the level designer could either create a small series of monster clip brush steps that the zombie could use to step up, or just make sure the crate isn't wide enough to where the zombie can't reach him from the ground.

So yeah, when you see something like what FireFish described, that's more than likely faulty level design, not faulty programming.

Talk about not fixing what ain't broken...