Doom's Artificial intelligence

[Csonicgo]

I was reading the thread on the proposed doom rewrite when I came across this:

Scet said:

You look to be around where I was when I stopped working on Doom.Net because I couldn't figure out the AI.

I thought, "why not do a study on the Doom AI?" It would be very easy to do, easy to manipulate, and maybe enough observation would help programmers like Scet figure out the seemingly complex AI.

http://doom.wikia.com/wiki/Monsters
As the link above isn't really enough information, I guess some more observation would suffice.

So, I guess I can start.


From my observations, The doom AI is a simple magnet style (monsters attract to you) with enough variations thrown in to mask it and to keep the baddie from being "stuck" in pursuit. Monsters seem to never give up pursuit unless attacked by an other. If given a choice of targets, The monsters usually concentrate on one target at a time, seemingly at random, or perhaps the target that inflicted the most pain, I don't really know.

Some monsters seem to have an erratic motion to them. while a human walks mostly straight at you, bull demons take a chaotic zig-zag pattern. if "stuck", the demon erratically moves in many directions, possibly to "unstick" itself.

If a monster that doesn't have a melee attack, like zombies, reaches your position as closely as possible, they walk away for a period, turn and fire, unlike what you would expect(a shot at point blank, unless you have -fast on) This is quite odd and I never understood it.

of course there are a lot of exceptions to this due to other conditions, like floating monsters, lost souls sliding helplessly backwards, and a baron killing himself.

Sometimes a monster in a distant room becomes active, even though it should not see or hear you. I noticed this on very large and complex maps. I don't know what causes that either.



Have any of you noticed any "weird" things from the AI in doom?

[Pure Hellspawn]

I noticed that other monsters will not attack the Archvile, even if it attacks them.

I also noticed that Lost Souls will usually only attack a monster once if the monster hurts them. Then, it goes back to you.

Archviles sometimes might attack right next to their target, despite the fact that it would hurt them.


The monsters activating when they shouldn't could be caused by a texture alignment problem.

[Khojan]

This is a good idea for a thread. Although I'm not nearly ready to start working on the AI in my game yet I've been going over in my head how I'm going to do it. Even Doom's simple AI is going to be complicated.

I'm going to keep an eye on this thread to and keep track of all the weird player-monster and monster-monster interactions listed here so I can try to mimic it as best as I can in the AI I write.

[Graf Zahl]

Doom's AI contains a lot of randomness, especially in the decision whether to attack or not. This randomness alone is probably responsible for more than 50% of the quirks and oddities monsters exhibit.

But why take wild guesses about its inner workings? All the source is available and can be studied.

[Quasar]

Csonicgo said:

Monsters seem to never give up pursuit unless attacked by an other. If given a choice of targets, The monsters usually concentrate on one target at a time, seemingly at random, or perhaps the target that inflicted the most pain, I don't really know.

Not entirely true, although this only normally comes into play in coop or in ports that support friendly monsters. Monsters have a countdown timer called "threshold". The longer a monster walks around with the same target, the lower the threshold gets. If the threshold reaches zero, the monster MAY look for a new target to chase. In coop, this means a Cyberdemon stomping around looking for a player he cannot find may eventually turn and fight another, for example.

Conversely, if the threshold value is too high, the monster will not change targets even though something else has hurt it. The reason Archviles change targets instantly is because they ignore the threshold value entirely (they treat it like it's zero all the time).

Csonicgo said:

Some monsters seem to have an erratic motion to them. while a human walks mostly straight at you, bull demons take a chaotic zig-zag pattern. if "stuck", the demon erratically moves in many directions, possibly to "unstick" itself.

Yes, monsters choose a randomized direction to move in, but tend to move toward their target. This randomization is to allow them to ignorantly "path find" much in the same way that real-life insects move (ants use this exact strategy to find food). The idea is if a monster can't get to the player because he's walked into a small indentation in the wall, he just MIGHT walk back out of it and then be able to get to the player again. Without this, monsters would get trapped a lot easier. ALL monsters in DOOM use identical walking logic. Any difference is imagined.

Csonicgo said:

If a monster that doesn't have a melee attack, like zombies, reaches your position as closely as possible, they walk away for a period, turn and fire, unlike what you would expect(a shot at point blank, unless you have -fast on) This is quite odd and I never understood it.

This is simply a consequence of them having nowhere else to go. Bumping into the player causes them to turn, and often completely around. You might consider it poorly designed in that respect.

Csonicgo said:

Sometimes a monster in a distant room becomes active, even though it should not see or hear you. I noticed this on very large and complex maps. I don't know what causes that either.

This was a bug in some versions of zdoom; AFAIK it hasn't happened in DOOM itself since v1.2, when a buggy tracer-based line-of-sight algorithm was used that could sometimes fall into a logic hole and go through walls.

[Scet]

Great timing as I actually started working on Doom.Net again a few weeks ago. I'm redoing the graphics portion now because the previous one was slow and a complete mess, so I have no screenshots yet :(

Anyway figuring out how the monsters act isn't that hard. Anyone that has played the game as long as us had noticed the patterns of the AI. Implementing them is a whole other story. BTW everything said about the Arch-Vile is actually on the Doom Wiki.

One thing I don't understand though is why sometimes flying monsters will climb walls, but other times just float through mid-air? Maybe they run into the wall and see the player is in the walls sector, but higher up so they climb?

Graf Zahl said:
But why take wild guesses about its inner workings? All the source is available and can be studied.

I love Doom, but the source code looks like someone puked into a C editor. I know the whole C family, but it's painful to read and try to sort though what each (horribly named) function/variable does. Plus if I use anything from the doom code I have to go GPL, which sucks( not against open source, just the GPL ).

[Anders]

Pure Hellspawn said:

The monsters activating when they shouldn't could be caused by a texture alignment problem.

Say what?

[Pure Hellspawn]

Anders said:

Say what?

Sometimes a monster in a distant room becomes active, even though it should not see or hear you. I noticed this on very large and complex maps. I don't know what causes that either.

I believe that might be due to misalignment of textures or linedefs.

[Linguica]

Pure Hellspawn said:

I believe that might be due to misalignment of textures or linedefs.

The alignment of textures is a purely cosmetic issue and cannot possibly have anything to do with monsters being activated.

[Use]

Pure Hellspawn said:

Sometimes a monster in a distant room becomes active, even though it should not see or hear you. I noticed this on very large and complex maps. I don't know what causes that either.

It's called reject table. Some node builders do sloppy rejects, the purpose of this table is to help Doom quickly decide weather or not a monster can or can't see the player. You and Craigs should hang out.

[Quasar]

Nope. A reject will never allow monsters to be able to see you when they shouldn't be able to. The only thing a reject can do wrong, or as a special effect, is to make them NOT be able to see you when they SHOULD be able to. It's called REJECT for the precise reason that it's used to quickly *reject* line of sight checks. If the reject doesn't say the monster cannot see, then the monster has to do a full, normal visibility check, which steps through the BSP tree and is really complicated (even I barely understand and avoid messing with this code as much as is possible).

[Csonicgo]

Graf Zahl said:

But why take wild guesses about its inner workings? All the source is available and can be studied.

If you're, say, doing a complete doom rewrite (as one person is suggesting/attempting), you can't do that!

[Quasar]

Then you can at least ask somebody who knows. Like me.

[Use]

Quasar said:

Nope. A reject will never allow monsters to be able to see you when they shouldn't be able to.

Well, what I was getting at (badly), is without a reject specified during node build (or an improperly generated one?) then monsters would wake up in odd parts of the map.

[Graf Zahl]

Use3D said:

Well, what I was getting at (badly), is without a reject specified during node build (or an improperly generated one?) then monsters would wake up in odd parts of the map.

No, they won't. At least not with proper sight checking code. And that exists in all post-1.2 versions of Doom and all source ports. Unless, of course the sectors are connected somehow and the monster can hear the player.

[Dr. Zin]

Graf Zahl said:

No, they won't. At least not with proper sight checking code. And that exists in all post-1.2 versions of Doom and all source ports. Unless, of course the sectors are connected somehow and the monster can hear the player.

I think it has more to do with map problems, esp. teleporting monsters. If you use the method of split sectors to wake them up, but have the monster holding areas connected, the sound can travel into the holding area and through another split sector to wake up the monsters in that destination.

[Use]

Graf Zahl said:

No, they won't. At least not with proper sight checking code. And that exists in all post-1.2 versions of Doom and all source ports.

Hmm, well I'm not sure what to make of this then. I know that with a few of my larger, older maps built with the old (and I mean OLD) tBSP, monsters would wake up in places that they should not be able to wake up in. Then, after rebuilding the nodes and reject with say, Zennode, the problem is solved. I also have a theory that monsters can wake up if they are seen through a 'slime trail'.

Edit: Well I went through my old editing book that covers the reject quite extensively, and it does confirm what Graf and Quasar explained that without Reject Doom will simply make its own line-of-sight checks, which I figured, but wouldn't an improperly generated reject trump the line-of-sight check? If not I don't know what to make of the problems I was having many moons ago. It was in one of my biggest maps at the time, and these imps kept waking up. I was pulling my hair out trying to make them stay asleep like the other monster just a few feet from them...

[EarthQuake]

Use3D said:

I also have a theory that monsters can wake up if they are seen through a 'slime trail'.

I can verify this. It only happens with particularly odd slimetrails, where you can see parts of the other side of the map in the automap.

Dunno how much this is related to a bad reject table though...

[Hobbs]

Slime trails are cause by imprecision in the nodebuilding process. idBSP generates slime trails by the truckloads, which is why you see them so much in the IWADs. This has nothing to do with the REJECT table.

[Use]

EarthQuake said:

Dunno how much this is related to a bad reject table though...

Yeah I didn't claim had relation to reject, but that's good that you've also seen evidence of slime trails and monster behavior.

[Lüt]

Use3D said:

If not I don't know what to make of the problems I was having many moons ago. It was in one of my biggest maps at the time, and these imps kept waking up. I was pulling my hair out trying to make them stay asleep like the other monster just a few feet from them...

That's happened to me a few times, though for some reason it was mostly in Heretic maps. I tried making dummy rooms inbetween the gaps where these deaf enemies facing away from me would keep "seeing" me, etc but nothing could stop them from waking up. That was years ago and I never did solve it but I haven't had problems like that for years so somehow I think a reconstruction from scratch would probably eliminate it. Would be nice to salvage the existing map though.

A weirder bug I had was when I'd pass a certain amount of raw data in certain maps, all the texture info would become jumbled. Somehow it was a problem that got encoded into the WAD file, as it would happen no matter which editor I used to go past those limits, despite other maps having gone past those limits previously. Not that this has anything to do with the original topic, but it seems the best place to complain at the moment :P

[Graf Zahl]

Lüt said:

That's happened to me a few times, though for some reason it was mostly in Heretic maps. I tried making dummy rooms inbetween the gaps where these deaf enemies facing away from me would keep "seeing" me, etc but nothing could stop them from waking up. That was years ago and I never did solve it but I haven't had problems like that for years so somehow I think a reconstruction from scratch would probably eliminate it. Would be nice to salvage the existing map though.

That's the bug Quasar was talking about. Heretic and Hexen have a buggy sight checking algorithm that in some circumstances makes a monster think it can see the player - even if it shouldn't.

[Kristian Ronge]

I remember experiencing the "monsters waking up when they shouldn't" bug in ZDoom 1.22, but not with any other engines. If the underlying bug came from Heretic and/or Hexen it was likely introduced to ZDoom via imported code. I can't remember seeing it in any remotely recent version of ZDoom, though. I wonder when it was fixed.

[Graf Zahl]

Kristian Ronge said:

I wonder when it was fixed.

It was fixed in v2.0.53.