Even in the last version of the DOOM engine, v1.9, used for Final DOOM, there is this strange limitation in which all the monsters have an invisible, infinitely tall "pillar" above and underneath them which blocks the player from, for example, running underneath a Cacodemon, or jumping down from a height above the heads of a bunch of Demons.

This was less of a problem in the original DOOM from 1993, but DOOM II and Final DOOM both have far more complex and open levels, where this frequently becomes a problem.

John Carmack fine-tuned his excellent DOOM engine for years until it stopped with v1.9. Many bugs of all kinds were fixed, and even new features were added, such as the "Nightmare" difficulty level. But this "infinite pillars" glitch/limitation was never addressed. How come? Was it actually too "expensive" CPU-wise to keep track of?

It should be noted that many later, third-party modifications of the DOOM engine have this feature (the ability to run underneath and over monsters), but then again, those engines ran on more advanced/modern computers, so maybe it only became possible to do this later?

Considering how much this changes the gameplay, and how it seems like an easy fix code-wise, was this simply a technical limitation of the kind of computers that were targeted even in 1996 (when the last DOOM game was released)?

  • 24
    Well, Doom isn't fully 3-D rendered, rather it's 2½-D (projection is really only done on a 2-D plane with sprites used to represent non-static objects). The "infinite-height hitbox" is likely an artifact of this. Commented Oct 14, 2021 at 16:00
  • 1
    I don’t remember this being a problem in Heretic or Hexen: those are also based on the Doom engine, and they feature many more flying enemies. Commented Oct 14, 2021 at 17:17
  • 1
    @user3840170 Yeah, but Heretic and Hexen was pretty heavily modified, I think.
    – Farrad
    Commented Oct 14, 2021 at 17:26
  • 8
    @user3840170 It's not a bug, it's just how the 2.5D works. For the same reason, the fact you can't have two passages crossing in X/Y at different Z heights or use bridges isn't a bug either. (Yes, for nitpicky people, I know about faking things with a floor that moves when you're not around to see it. :)
    – Graham
    Commented Oct 15, 2021 at 8:12
  • 9
    "how it seems like an easy fix code-wise" - Citation Needed. I may not be a video game programmer by trade, but I can think of a dozen ways this could become extremely complicated and, overall, not worth the technical effort.
    – Zibbobz
    Commented Oct 15, 2021 at 13:33

6 Answers 6


Doom maps and locations on the maps were essentially 2D. This makes a lot of stuff much cheaper to calculate that a general 3D solution but has some limitations: objects can't stack, you can't jump over them, you can shoot them by aiming over/under them and paths can't pass over/under other paths. But 99% of the time you don't notice any of this :o)

  • 20
    Having a 3rd axis is actually non-trivial and adds substantially to the math required.
    – Nelson
    Commented Oct 15, 2021 at 9:10
  • 1
    The naive solution to the infinite pillars would be to check if the hit monster's hitbox was hit within the monster's vertical box. But that creates another very subtle bug wherein you can't hit a monster across a pit if another monster stands at just the right place inside the pit. If you keep casting from the first intersection that should do it, however. Commented Oct 16, 2021 at 9:17
  • 1
    Floor heights and floor-height based mechanics like stairs, platforms etc are the only gameplay mechanic in Doom that are not essentially 2D. Everything else in the game would play the same if it was a top-down 2D shooter. Compare this with ID's earlier game, Wolfenstein 3D, which plays exactly like a 2D top-down shooter except for the graphics.
    – Robyn
    Commented Oct 17, 2021 at 23:42
  • Doom does a ton of 3D math where height is considered, for example when tracing hitscan projectiles, and quite obviously for rockets and missile projectiles. It's quite naive in some cases; for example rockets will travel at the same speed along the horizontal plane regardless of the vertical angle they're heading. But a missile can pass over or under a player or enemy, so the choice of making enemies and players infinitely tall for the purpose of enemy-player collision probably wasn't made because of technical concerns.
    – boomlinde
    Commented Sep 8, 2023 at 0:51

Allowing two objects to occupy the same position in XY space but different elevations would create the possibility that one object might collide with another from above or below. While this might not be a problem when dealing with projectile weapons that would naturally be destroyed in the collision, it would pose some complications if e.g. a player could jump down from a balcony and land on another player who might then walk up a step. There are various ways such complications could have been accommodated, but all would have added complexity versus forbidding objects from being vertically stacked in the first place.

  • 7
    Perhaps not so much 'forbidding' as not having a mechanism for it in the first place?
    – Jon Custer
    Commented Oct 14, 2021 at 22:21
  • 4
    @JonCuster: The prohibition on stacked vertical objects would result from the general prohibition against two objects occupying the same 2d region, combined with the lack of any exemption for objects that don't overlap vertically. Adding an exception for objects that don't overlap vertically would have been pretty easy, but the decision not to do so may have been motivated by a desire to prevent vertical stacking.
    – supercat
    Commented Oct 14, 2021 at 22:25
  • Projectile weapons? Wasn't Doom using hitscan?
    – Kevin
    Commented Oct 16, 2021 at 23:06
  • 2
    @Kevin the rocket launcher, plasma rifle and BFG all fire actual projectiles.
    – Carcer
    Commented Oct 17, 2021 at 7:57
  • This seems the most likely answer since the engine already contains all the code necessary for performing full 3D collision checking (as it's done for the projectiles). But collision resolution (which isn't necessary for projectiles) is much more involved than just checking.
    – tylisirn
    Commented Oct 17, 2021 at 10:59

DOOM comes from an era when stability of the game's rules/mechanics actually mattered. Folks were generally unhappy when an upgrade to the game broke their existing demo recordings, and for the most part, the updates to the game engine avoided doing that. Note that this also matters for things like trying to score achievements, where changes to the rules, even ones that "make sense", radically alter the dynamics in some parts of the game. (Note that lots of modern DOOM "ports" actually break this by letting the player look up/down to aim without requiring a target to auto-aim vertically.)

Sadly, nowadays the appreciation for this kind of thing has been completely lost. Most games shipped in the past few decades will never again be playable as they originally shipped, even if you saved the original files, because of dependence on network resources, behaviors specific to operating system version and drivers, etc.

  • 2
    Having precisely equivalent mechanics was especially important for Doom given the way it handled deathmatch play: rather than having a central server maintain game state, it required that every client receive a list of moves performed by every other client on every frame, and compute game state based upon the moves that were performed. If two clients were to process the same sequence of moves differently, that would completely break the game.
    – supercat
    Commented Oct 19, 2021 at 17:54

In the original Doom, you can't look up and down.

The display renderer draws the walls as strips of textured vertical lines and doesn't have the capability to tilt wall textures backward and forward. This keeps it fast.

Some later Doom-engine based games did allow a small amount of looking up and down (Heretic IIRC) and then you can see why - since the engine doesn't render walls as real 3d, things get very distorted and unrealistic and the 3D illusion fails.

You can use a modern source port like GZDoom, enable software rendering along with freelook, and see what would happen if there were no limits on it.

So I think a design decision was made to allow infinite vertical hitboxes instead of trying to support looking up and down and the graphical distortion that would have ensued. I'm sure programming being easier was a bonus.


Think in the other direction: Monsters chase players, if they are allowed to be above a player, they are in a spot where they cannot be seen and cannot be shot at.

  • 2
    Something close to this does happen in Doom, see this engine bug — a monster far above you can hit you even though you can’t see it! Commented Oct 15, 2021 at 13:22

This seems to be just neglectful programming.

The other answers mention Doom (and Doom II) being based on a ‘2½-dimensional’ engine (later retroactively named id Tech 1), meaning the engine internally keeps floor and ceiling heights bolted on to what would otherwise be a two-dimensional map. While this is true, and it does limit the game environment in certain ways (most infamously: by making it impossible to place one room atop another), by itself this does not necessarily preclude placing sprites one over another. After all, the engine is aware of the height of each sprite, and incorporates that into the physics of the game, e.g. in implementing mechanics like crushing monsters by a descending ceiling. The engine is even capable of checking the vertical position of projectile sprites versus monster sprites to determine whether the projectile should fly over or hit the monster. All the necessary information is already there.

So why wasn’t the vertical axis taken into account in monster–player collisions as well? Hard to say. The Doom Wiki page on the subject leaves only the faintest of clues: it certainly wasn’t a matter of computational resources, since the issue was actually addressed in Heretic, based on the same id Tech 1 engine and released in December 1994, only a year after Doom (December 1993), so we can treat them as roughly contemporaneous and meant to be played on the same class of hardware. (The wiki notes their solution is hardly perfect, but it probably wasn’t very noticeable in playthroughs.) It seems like simply nobody got around to fixing this in Doom itself.

Whatever the reason, this issue is fixed in many modern source ports, especially those derived from ZDoom. More conservative ports, like Chocolate Doom, may omit the fix.

  • 5
    Do we know that this is "neglectful" programming? Perhaps the people at ID thought long about the z-clipping issue and decided on the limitations seen in Doom for good reasons. Perhaps they were afraid of performance problems in the released game after all (the fact that Ravensoft managed to improve z-clipping for Heretic would then only be evidence that the concerns may not have been justified).
    – Schmuddi
    Commented Oct 17, 2021 at 7:11
  • 2
    The engine contains a number of even simpler blunders than this, and Carmack himself found some aspects of the design ‘downright silly in retrospect’. Sure, without an official statement we can only speculate, but I wouldn’t put it past them. Commented Oct 18, 2021 at 9:51

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .