Fallout Foot Sliding: A Case Study in R&D

The "Figure It Out" Era

Tim Cain sets the stage by describing game development in the 1980s and 1990s as the era of "figure it out folks." There were no game engines to buy off the shelf, no tutorials, no online resources, and very few books. The books that did exist — like the Graphics Gems series — dealt in first principles: vector math and matrix operations with no hand-holding on how to apply them to your specific game on your specific hardware.

Every developer — programmer, artist, designer — had to be a "figure it out" person. If you couldn't work that way, you simply wouldn't be in the industry. This is the essential backdrop for understanding why a walk cycle bug could consume months of effort.

How Fallout Made Sprites

Fallout used 3D software called Alias, running on SGI workstations with the IRIX operating system. This was groundbreaking: previous Interplay games used 2D artists hand-drawing and hand-animating sprites in every direction. Fallout's approach was different.

The team would create one 3D model and one walk cycle animation, then rotate the virtual camera to six hex-based orientations, generating all six directional sprite sets from a single source. The rendered 2D frames were stored as sprites with per-frame offset data controlling how far the character moves each frame. On screen, the sprite itself just animated in place — the offset handled the movement.

This approach gave enormous leverage to a small team. Swapping armor, weapons, or equipment meant modifying the 3D model and re-rendering, rather than redrawing hundreds of hand-animated frames.

The Bug: Hiccups and Sliding Feet

In early 1995, the team hit a maddening problem. Every time a character completed one walk cycle (left foot forward → right foot forward → back to even), there was a visible hiccup — a jarring stutter. The feet also appeared to slide on the ground, never quite matching the expected movement offset.

The team initially diagnosed this as imperfect looping: if any body part — hands, head, arms — wasn't in exactly the same position at the end of a cycle as at the start, there'd be a visible jerk at the loop point. They spent extensive time perfecting the loop, eventually confirming in the 3D view that every element was pixel-perfect between start and end frames.

The hiccup persisted. Blame flew: "The programmers are doing this wrong. There's something wrong with your math. Something wrong with the 2D conversion tool." It was branded a programmer problem.

The Real Culprit: Projection Mismatch

The actual root cause was a camera projection mismatch. Alias in the early '90s only supported perspective projection — objects get smaller as they recede, parallel lines converge. But Fallout's game world used orthographic projection — tiles at the top and bottom of the screen have identical proportions, parallel lines stay parallel.

You cannot take a perspective-rendered sprite and drop it into an orthographic game without visual artifacts. The subtle distortion from perspective projection caused the offsets to be slightly wrong, producing the sliding and hiccup effects.

Jason Anderson's Clever Fix

The software didn't support orthographic projection, and there was no sign Autodesk would add it anytime soon. Jason Anderson found an ingenious workaround: he moved the virtual camera to a near-infinite distance from the subject, then cranked the magnification/zoom to near-infinite as well.

With a physical camera this would produce a blurry mess, but in a virtual camera, distance and zoom are just numbers. At near-infinite distance, perspective distortion effectively vanishes — parallel lines appear parallel, just like orthographic projection. The result: perfect walk animations, no more hiccups, no more foot sliding.

Was It Worth It?

The fix consumed serious resources. Tim estimates that individually, each person involved lost weeks; collectively, they lost months of development time — at least two programmers and two artists. This on a game that was still over a year from shipping.

Then in 1996, Diablo released with obvious foot sliding — characters skating across the ground — and nobody cared. Tim challenges anyone to find a single 1996 review or forum post that mentions Diablo's foot sliding. No one nitpicked it. No one noticed.

Tim's honest assessment: the priority on fixing foot sliding was probably set too high. The months spent on it meant other things didn't get done or were rushed. He can't prove a direct trade-off, but after three and a half years on the project, his feeling is clear — they spent way too much time on it.

Lessons for Modern Development

Tim connects this story to modern game development in two ways.

First, the proliferation of engines like Unity and Unreal means most developers no longer face these kinds of raw, unsupported technical problems. That's genuinely good — it lets solo developers and small teams ship games without reinventing rendering pipelines.

Second, the "figure it out" mentality remains essential during the prototype stage of any ambitious project. During prototyping, you need people who can work without documentation, who can diagnose novel problems, who don't need to be told exactly what to do. People who only thrive with established tools and clear instructions are valuable later — during vertical slices and polish — but they struggle in the chaotic early phases where everything is being invented.

If you build your own engine, this is doubly true. Your hires need to be "figure it out" people because there's no community, no Stack Overflow thread, no tutorial for your proprietary tech.

References

• Tim Cain. YouTube video. https://www.youtube.com/watch?v=gKEIE47vN9Y