G: Ah, yes. Now I see the distinction you're making.

You're not asking why wall impacts didn't kill people.

You're asking why there weren't more engines where the floor itself became a death trigger once your absolute velocity exceeded some threshold, regardless of direction.

Essentially:

"Why didn't bunny hopping eventually reach a speed where the instant your foot touched the ground the engine declared you dead?"

And the answer is: there actually were engines and mods that got surprisingly close to that, but most mainstream FPS engines accidentally avoided it because of how they were structured.

The key is that most movement engines separated velocity into components.

When you landed, they didn't ask:

"How fast is the player moving?"

They asked something closer to:

"How fast is the player moving toward the ground?"

In physics terms, they were often implicitly looking at the velocity component along the surface normal.

For a flat floor:

• 1000 units/sec horizontal
• 0 units/sec vertical

looks harmless.

Whereas:

• 0 units/sec horizontal
• 1000 units/sec vertical

looks fatal.

They weren't necessarily computing a proper dot product every frame, but the logic ended up resembling that.

What's funny is that the shortcut you're imagining would actually have been cheaper computationally:

if speed > threshold:
    kill player

That's dirt simple.

But it would have felt awful.

Imagine Quake:

• running normally
• grabbing a speed boost
• hitting a launch pad
• landing perfectly

and instantly exploding because your speedometer happened to say 1201.

Players would perceive that as a bug immediately.

Even on 1990s hardware, the extra logic needed to distinguish "moving fast" from "impacting hard" wasn't particularly expensive.

The other reason you don't see many famous examples is that game developers were usually solving a very specific problem:

"How do I make falling hurt?"

not

"How do I simulate kinetic trauma?"

Those are completely different design goals.

As a result, the code path for damage often wasn't even reached during normal ground contact.

Landing might look like:

if touching_ground:
    vertical_velocity = 0

and then separately:

if previous_vertical_velocity > threshold:
    apply_damage

The horizontal component never enters the conversation.

There are places where something close to your Back to the Future scenario happened, but usually as bugs.

One classic category was velocity overflow.

A player acquires ridiculous speed through:

• ramps
• explosions
• physics glitches
• stacked boosts

Then some subsystem says:

"Velocity is absurdly high. Something has gone wrong."

The result isn't always death.

Sometimes it's:

• instant death
• teleportation
• falling through the map
• getting launched into space
• numerical overflow that turns velocity negative

Those are the closest examples to the "88 mph and vanish" phenomenon.

What's especially interesting is that your imagined engine is actually more likely to appear in an early prototype than in a finished game.

A programmer building a test environment might absolutely write:

if player_speed > 2000:
    kill_player()

simply as a sanity check.

The reason you don't hear stories about commercial games doing it is that such a rule would be discovered almost immediately and would make high-speed movement mechanics feel terrible.

So the historical trend was almost the opposite of what you'd expect:

• Early games often had crude damage systems.
• Crude damage systems usually looked only at downward speed.
• Therefore they accidentally became more tolerant of ridiculous horizontal velocity than a realistic physics simulation would have been.

In other words, bunny hopping survived not because old engines were sophisticated enough to understand glancing impacts, but because they were primitive enough that they mostly ignored horizontal kinetic energy altogether. That's a surprisingly lucky accident for the entire movement-tech community.

G: That's much closer to what actually happened.

By the time games got into true 3D environments, they couldn't just ask "am I touching the ground?" because now you had:

• ramps
• stairs
• hills
• sloped roofs
• curved terrain

The engine had to decide whether a surface was:

• floor
• wall
• ceiling

And the usual answer was surprisingly elegant:

Look at the surface normal.

The surface normal is the vector pointing straight out of the surface.

For example:

• Flat floor → normal points straight up.
• Vertical wall → normal points sideways.
• Ceiling → normal points down.

A modern engine would literally classify surfaces based on the angle between the normal and the gravity direction.

For a flat floor:

normal = (0,0,1)

For a wall:

normal = (1,0,0)

Then the engine checks something equivalent to:

"How upward-facing is this surface?"

The mathematical version is essentially a dot product against the gravity-up direction.

If the result is high enough:

• it's a floor

If it's low enough:

• it's a wall

If it's negative:

• it's a ceiling

This is where things get interesting for movement exploits.

Most engines have a maximum walkable slope.

For example:

• 30°
• 45°
• 60°

depending on the game.

So the logic becomes:

if slope_angle < 45°
    floor
else
    wall

conceptually.

This is also where a lot of famous exploits came from.

Suppose a ramp is 44.9°.

The engine says:

Floor.

Suppose another is 45.1°.

The engine says:

Wall.

Those two surfaces look nearly identical to a human.

To the engine they belong to completely different categories.

Players eventually learned to abuse these boundary conditions.

In Quake-derived engines especially, movement code often branched based on whether you were:

• grounded
• airborne
• sliding against a wall

Each state used different acceleration and friction rules.

The famous movement tricks frequently happened right at those classification boundaries.

A surface that the engine barely considered a floor might preserve momentum differently than one it barely considered a wall.

So in a sense, your intuition about "normalization" was correct.

The engine wasn't usually checking:

How fast am I moving into this surface?

for ordinary movement.

But it absolutely was checking:

What kind of surface is this?

using the surface normal.

Once it classified the surface as floor vs wall, completely different physics rules would activate.

The funny historical consequence is that movement communities eventually became experts in the engine's geometry classification.

A casual player sees:

"That's a ramp."

A speedrunner sees:

"That's a 44.7° surface with floor friction, but this one is 45.3° and therefore uses wall-slide behavior."

They're effectively reverse-engineering the same normal-vector tests the programmers wrote years earlier.

So the answer is: no, they generally didn't say "anything not horizontal is a wall." By the mid-1990s and certainly by the Quake era, they were usually classifying surfaces by their angle relative to gravity, which is a much more robust solution and one of the reasons ramps, stairs, and uneven terrain felt surprisingly natural even on hardware that was primitive by modern standards.

G: That's a genuinely good engine-design question, because the answer changes depending on the era.

For Quake-era engines and most of their descendants, the answer is usually:

The normal was already available as part of collision detection, so there wasn't much reason to pre-classify surfaces as floor/wall/ceiling.

In other words, the expensive part wasn't computing the normal. The expensive part was figuring out what you hit.

Once the collision system says:

"You just hit polygon #572"

it almost always already knows the polygon's plane equation, and therefore its normal.

At that point, checking whether it's a floor is extremely cheap.

Conceptually:

collision found
↓
retrieve surface normal
↓
dot(normal, up_vector)
↓
floor or wall?

The last step is tiny compared to the collision search itself.

The thing that may surprise you is that many BSP-based engines (Doom's descendants, Quake, Half-Life, etc.) were already storing plane information because they needed it for rendering and collision.

A wall wasn't just:

wall = true

It was something more like:

plane:
  normal = (...)
  distance = (...)

So the normal often existed in memory already.

The engine wasn't calculating it from scratch every time you landed.

There's a subtle middle ground here.

The normal itself was often precomputed.

The classification wasn't.

So instead of storing:

surface 572 = floor

they stored:

surface 572:
  normal=(0,0,1)

and then asked:

is this floor enough?

whenever needed.

Why?

Because different systems might use different thresholds.

For example:

• Walking might allow 45°.
• AI pathfinding might allow 35°.
• A rolling object might allow 60°.
• A player with special boots might allow 55°.

If you hardcoded "floor" into the map, you lose flexibility.

If you store the normal, everyone can make their own decision.

Ironically, the memory argument actually pushes things toward storing the normal rather than storing the classification.

Suppose you have 50,000 polygons.

Each polygon already needs plane information.

Adding a separate floor/wall flag saves almost no computation while consuming additional storage and reducing flexibility.

Programmers generally dislike that trade.

Where preclassification did happen was at higher levels.

For example:

• BSP trees
• visibility sets
• portals
• navigation meshes

Those were often heavily precomputed because they were genuinely expensive.

The normal test wasn't.

A dot product is just a few multiplications and additions.

Even on a late-1990s CPU, that's basically free compared to collision detection.

So if I had to guess what led you to wonder about this, I suspect you're thinking along the lines of:

"Wouldn't repeatedly calculating surface orientation be expensive on a Pentium-era machine?"

And that's a very reasonable intuition.

The trick is that by the time you've already figured out which surface was hit, you've already done 99% of the work. Looking at that surface's normal and deciding "floor or wall?" is almost an afterthought.

In fact, many engine programmers would probably tell you the opposite of what people expect:

The normal wasn't computed because the player landed on the surface. The player could determine whether it was a floor because the normal was already sitting there as part of the surface definition.

Now I'm curious what your guess was, because this is exactly the sort of question where the wrong intuition can sound completely plausible.

G: That's actually a very interesting historical question, and the answer is that many early 3D engines treated ceilings asymmetrically with floors, not because they couldn't identify them, but because there wasn't much gameplay reason to care.

Once you have the normal, identifying a ceiling is trivial:

• Normal mostly up → floor
• Normal mostly down → ceiling
• Normal mostly sideways → wall

The question becomes: what do you do with that information?

And for a surprising number of games, the answer was:

"Almost nothing."

Think about the typical FPS player in 1996.

They can:

• walk
• run
• jump

They cannot:

• rocket-jump reliably (at least not intentionally by most players)
• fly
• get launched by physics objects
• experience ragdoll forces

As a result, ceiling impacts are rare.

Floor impacts happen constantly.

So developers spent effort on:

• fall damage
• landing behavior
• stair stepping
• slope handling

while ceilings often got:

bonk
vertical velocity = 0

and that's the end of the story.

In fact, a lot of old FPS engines effectively treated ceilings as "anti-floors."

Floor contact often triggered special logic:

• become grounded
• regain friction
• allow jumping
• apply fall damage

Ceiling contact frequently just canceled upward motion.

Something conceptually like:

if hit_ceiling:
    vertical_velocity = min(vertical_velocity, 0)

The engine wasn't asking whether the impact should hurt.

It was asking how to prevent the player from entering solid geometry.

This creates exactly the asymmetry you're wondering about.

Imagine:

• Falling downward at 1000 units/sec.
• Launching upward at 1000 units/sec.

Many engines would:

Downward

• Apply fall-damage calculation.
• Land.

Upward

• Stop upward velocity.
• Begin falling.

No damage at all.

Same speed. Different result.

Part of this comes from game design rather than technical limitations.

Players generally accept:

"Huge fall = damage."

Players are less accepting of:

"You jumped into a doorway and lost 20 health."

So even if the engine could calculate ceiling impact damage, many designers wouldn't want it.

Where things started changing was in engines that allowed extreme vertical movement.

Examples include:

• rocket jumping in entity["video_game","Quake","1996 first-person shooter"]
• skiing and launching in entity["video_game","Starsiege: Tribes","1998 multiplayer shooter"]
• vehicle-heavy games
• physics sandbox games

Once players could routinely reach ceilings at absurd speeds, developers had to decide whether upward impacts should matter.

But even then, many games retained the old asymmetry simply because that's what players expected.

The really funny consequence is that some engines ended up with what amounts to an "upward invulnerability loophole."

If you somehow acquired enough upward velocity:

• Floor: potentially lethal.
• Ceiling: merely embarrassing.

The engine wasn't secretly computing impact energy and deciding you survived.

The engine often wasn't computing impact energy at all.

It was running two completely different pieces of code:

if landed:
    maybe damage

versus

if hit ceiling:
    stop moving upward

Which means that, historically speaking, there absolutely were engines where being launched into a ceiling at a speed that would have turned the equivalent downward impact into paste resulted in nothing more than a loud thunk and an immediate change of direction. That wasn't usually because the programmers believed ceilings were soft; it was because floor impacts had a dedicated damage system and ceiling impacts often never got one.

G: Exactly.

And once you notice it, you start seeing it everywhere.

A lot of games historically treated vertical motion less like "a body moving through space" and more like "a jump state machine."

The engine isn't really asking:

"What happened to the kinetic energy?"

It's asking:

"Are you going up, down, or standing on something?"

Which leads to the odd situations you're describing.

You get launched by:

• a jump pad,
• a catapult,
• a rocket jump,
• an explosion,
• a scripted launcher,

and the game is perfectly happy to let you:

1. Accelerate to absurd speed.
2. Smash into the underside of a platform.
3. Stop instantly.
4. Fall back down.

The dangerous part isn't the skull-crushing impact at step 2.

The dangerous part is often step 4.

From a physics perspective that's backwards, but from a gameplay perspective it makes perfect sense because the designers only built a damage model for falling.

One way to think about it is that many older games had a concept of:

"Dangerous velocity"

rather than

"Dangerous impact."

And dangerous velocity usually meant:

Downward velocity when becoming grounded.

Not:

Relative velocity between player and surface.

So the engine might never care that you hit a ledge at 200 mph.

It only cares that you landed while moving downward at 60 mph.

There's a related phenomenon that speedrunners and exploit hunters love.

Sometimes you can convert one kind of velocity into another in ways the engine doesn't fully understand.

For example:

• gain enormous horizontal speed,
• hit a ramp,
• get converted into vertical speed,
• bypass some damage check,
• land safely.

Or the reverse:

• gain vertical speed,
• convert it into horizontal speed,
• avoid what would normally be a fatal fall.

The engine's damage model and movement model are often not measuring the same thing.

What's especially amusing is that real humans have almost the opposite problem.

In reality, your body doesn't care much whether the impact came from:

• falling,
• being launched,
• being hit by a truck,
• running into a wall.

Your tissues mostly care about acceleration and force.

The distinction between "floor impact" and "ceiling impact" is largely irrelevant to your skeleton.

A game engine, however, may literally contain logic equivalent to:

floor = maybe death
ceiling = boink

because those cases were written by different programmers, at different times, for different gameplay purposes.

So the weird feeling you're remembering isn't a misunderstanding of how those games worked. It's often a genuine inconsistency. The player is subconsciously interpreting the world as a physical place, while the engine is treating it as a collection of special-case rules:

• Floors are where fall damage happens.
• Walls stop movement.
• Ceilings stop upward movement.
• The fact that all three are made of concrete is somebody else's problem.

That's one of the reasons movement exploits became such fertile ground for speedrunners. They were probing the seams between systems that each made sense individually but didn't always agree with each other when pushed to extremes.