Spec floors

The weakest supported machine sets the design, not the strongest.

The constraint that shapes everything above it

Every game that ships on more than one platform carries a hidden architecture decision: which machine is the floor? Whatever hardware sits at the bottom of the support list determines how much simulation the game can run, how dense the geometry can get, how ambitious the AI budget is allowed to be, and how many simultaneous sound sources the mixer can open. The stronger machines in the lineup get scalability work — higher-resolution assets, better shadow cascades, longer draw distances — but they do not get fundamentally different games. The floor sets the shape; everything else is decoration applied on top of it.

This is the part that surprises people outside production. A PC game with a minimum specification is not a game built for a high-end machine and then stripped back. It is, structurally, a game built for the minimum spec and then given more expensive clothes for the machines that can afford them. The design decisions that hold the floor together — level geometry sized to fit within a certain budget, crowd densities kept inside what a weaker CPU can tick, streaming assumptions tuned to slower storage — are not negotiable by a scalability slider. They are load-bearing.

What sets the floor, and when

Studios arrive at a spec floor by several routes. A multiplatform deal made during pre-production can lock the floor before a single level is blocked out. A platform holder's minimum hardware requirement, published as part of a certification programme, sets a hard lower bound regardless of the studio's preference. Sometimes the floor is set by the weakest console in a simultaneous launch — and a console's hardware is fixed at manufacturing, meaning the floor does not move for the product's entire commercial life.

The timing matters enormously. A floor established early, before core systems are built, allows those systems to be architected against it from the start: memory allocators sized appropriately, physics tick rates chosen with the weakest CPU in mind, texture streaming designed around the slowest bus. A floor established late — because a new platform was added to the shipping plan after production began — means retrofitting. Retrofitting means cuts, and cuts made under schedule pressure are the cuts that hurt the most.

PC development complicates the picture. There is no single floor; there is a minimum specification that is partly a warranty promise and partly a practical guess about the installed base at shipping time. Studios benchmark against representative hardware, usually several generations old at minimum, and the honest ones budget optimisation time against that machine specifically. What often happens instead is that minimum spec hardware is tested late and found wanting, producing a last-minute round of quality reductions and draw-distance hacks that were entirely foreseeable in pre-production.

It is, structurally, a game built for the minimum spec and then given more expensive clothes for the machines that can afford them.

Scalability is not free

The common assumption is that scalability systems solve the floor problem: build for a strong machine, add quality presets, done. What this misses is that scalability systems have costs of their own — conditional code paths, asset variants that must be loaded and managed, QA time multiplied across every combination of setting and hardware. A game with five quality tiers across a dozen settings has dozens of configurations that each need to behave correctly, load without error, and be tested before certification. The asset pipeline carries the weight of every variant; it does not scale magically just because the runtime does.

More important, scalability cannot add simulation budget that was never there. If a city district was designed to hold three hundred AI agents because the strongest dev kit could run them, but the floor CPU can only run forty before frame time collapses, the city district is wrong. The art is wrong. The design is wrong. Scalability can reduce draw distance and drop shadow resolution, but it cannot replace geometry with emptiness without players noticing.

The studios that handle multi-platform shipping most cleanly are the ones that run the floor machine alongside development from day one — not as a validation step at the end, but as the continuous reference point. The vertical slice gets profiled on the floor. Level budgets are signed off against the floor. When the game ships and the scalability presets make the strong machines look better, that is a gift the floor made possible. The floor is not the least important machine in the lineup. It is the only one that actually matters to the design.

Every figure in this entry is an illustrative worked example, shown because concrete numbers make the trade-off legible. It is not a measurement of any particular production.