32

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

user3840170
  • 23,072
  • 4
  • 91
  • 150
Farrad
  • 329
  • 3
  • 3
  • 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. – Alex Hajnal Oct 14 '21 at 16:00
  • @AlexHajnal But, again, this was added to the same engine later... – Farrad Oct 14 '21 at 16:55
  • 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. – user3840170 Oct 14 '21 at 17:17
  • 1
    @user3840170 Yeah, but Heretic and Hexen was pretty heavily modified, I think. – Farrad Oct 14 '21 at 17:26
  • The viewpoint is fixed vertically and you can't look up or down in the original Doom. With that limitation not having to worry about up/down aiming plays better. The latter games you listed work around this limitation often by warping the view (not true 3d). – Brian Oct 14 '21 at 17:34
  • 1
    @Brian This was the case in all of the DOOMs I listed (all the actual DOOM games). Looking up/down has nothing to do with this. – Farrad Oct 14 '21 at 17:41
  • https://doomwiki.org/wiki/Engine_bug doesn’t mention this at all, and I think it would. – user3840170 Oct 14 '21 at 18:31
  • @Farrad I think Brian's guess might be that it's for aiming — though it wouldn't explain why the collision boxes and hit boxes have to be the same. – Tommy Oct 14 '21 at 18:43
  • 1
    @user3840170 Maybe it's not considered a "bug" since it was very much known/designed? – Farrad Oct 14 '21 at 18:46
  • 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 Oct 15 '21 at 08:12
  • @Graham That page lists a number of issues with the engine more minor than that (though some tagged as ‘disputed’). I did eventually find a page about this one: https://doomwiki.org/wiki/Z-clipping. It’s categorised in ‘Errors and bugs’ for what it’s worth. The fact it’s been fixed in Heretic (and later ports) shows it’s not an inherent limitation of the design, just neglectful programming. – user3840170 Oct 15 '21 at 08:33
  • 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 Oct 15 '21 at 13:33
  • I was pretty impressed with the first game that tried to get around this (or first as far as I know) - Star Wars Dark Forces. It still didn't have true 3D, instead using maps with multiple levels, but it still was damn cool. – Vilx- Oct 15 '21 at 15:53
  • @user3840170: What's easy is exempting objects at different height from overlap checks. What's hard is ensuring that this won't ever cause the game to behave weirdly in any situations that might arise as a result. – supercat Oct 15 '21 at 17:26
  • @supercat Well… I don’t disagree? The Z-clipping page I linked mentions such a case in Heretic. – user3840170 Oct 15 '21 at 17:41
  • This is a great example of how decisions made (and probably necessary) early on in a project's development create practically insurmountable limitations later on. What seems to a client to be a simple additional feature would actually pull the carpet out from under the entire project, requiring a complete rewrite based on new assumptions. Even one of the greatest programmers ever possibly wasn't able to solve this—or at least didn't judge it to be worth the effort. – iconoclast Oct 15 '21 at 20:49
  • For many intents and purposes, Doom actually does consider objects in terms of 3D space. The places where it doesn't are notable exceptions: for example, for the purpose of enemy/player collision, splash damage and melee damage, heights are not considered. At least for enemy/player collisions I think this choice is a deliberate design choice, not a technical consideration. – boomlinde Sep 08 '23 at 00:47

6 Answers6

45

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)

Michael Borgwardt
  • 103
  • 3
Peter Ashford
  • 399
  • 2
  • 3
  • 20
    Having a 3rd axis is actually non-trivial and adds substantially to the math required. – Nelson Oct 15 '21 at 09: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. – John Dvorak Oct 16 '21 at 09: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 Oct 17 '21 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 Sep 08 '23 at 00:51
35

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.

supercat
  • 35,993
  • 3
  • 63
  • 159
  • 7
    Perhaps not so much 'forbidding' as not having a mechanism for it in the first place? – Jon Custer Oct 14 '21 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 Oct 14 '21 at 22:25
  • Projectile weapons? Wasn't Doom using hitscan? – Kevin Oct 16 '21 at 23:06
  • 2
    @Kevin the rocket launcher, plasma rifle and BFG all fire actual projectiles. – Carcer Oct 17 '21 at 07: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 Oct 17 '21 at 10:59
  • @JonCuster The fact that rockets, plasma, bfg balls and enemy missiles can pass under or over enemies and that player-item collisions are z-dependent speaks against that theory. It's only for some handful of purposes that height is ignored, which makes me agree that it's probably a matter of deliberate convenience than a technical limitation. – boomlinde Sep 08 '23 at 01:03
4

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.

R.. GitHub STOP HELPING ICE
  • 581
  • 3
  • 14
  • 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 Oct 19 '21 at 17:54
1

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.

LawrenceC
  • 1,199
  • 7
  • 18
0

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.

Franky
  • 109
  • 2
0

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.

user3840170
  • 23,072
  • 4
  • 91
  • 150
  • 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 Oct 17 '21 at 07: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. – user3840170 Oct 18 '21 at 09:51