Why did the monsters have "infinite invisible pillars" of hitboxes vertically in all versions of the DOOM engine?

Question

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)?

Answer 1

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)

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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.

Answer 6

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.