How Rockstar fit an entire city into PlayStation 2 memory

Grand Theft Auto III is a lot of things. It laid the foundation for one of the most profitable franchises in game history. It helped trigger a wave of open-world games. It also became a regular target for anxious news coverage.

But it is also a technical magic trick. Rockstar North, then DMA Design, managed to squeeze a four kilometer wide pastiche of New York City into the tiny 32 MB memory chip of a PlayStation 2.

The basic memory problem is simple. A PS2 DVD could hold 4.7 GB, enough for the full game: models, textures, sound effects, radio stations, and more. But the DVD was slow, transferring only about 5 to 6 MB per second. System memory was much faster, but much smaller.

A traditional game can load the assets for one area, stop at a door or hallway, flush those assets, and then load the next area behind a loading screen. Grand Theft Auto III could not rely on that structure. Liberty City was a sprawling city the player could move through freely in any direction.

The full city used thousands of unique models for buildings, vehicles, and pedestrians, plus thousands of textures for materials, signs, and skins. Altogether, that was roughly 130 MB of data. Even with Liberty City split into three islands, each island was still too large to fit comfortably into the PS2's memory.

The first idea was to make the city simpler, using basic 3D models and low-resolution textures so each island could fit into memory. That solved the budget but made the city look bland.

The more ambitious answer was streaming. Liberty City was split into thousands of small sectors. The game kept an invisible square around the player, loaded the models and textures needed inside that square, and unloaded sectors as the player moved away from them.

The important trick is distance. New assets generally appeared far enough from the player that the game had time to pull them from the DVD before they were inspected up close.

Instead of trying to fit a whole city into memory, the game built a moving window. It silently constructed the world in front of the player and deleted the world behind them.

That approach removed a huge limitation. The team could build the city it wanted as long as the area near the player fit in memory and could be fetched from the disc quickly enough.

Grand Theft Auto III was not the first game to load assets while the player moved. Earlier games had already chopped worlds into chunks and loaded the next chunk as the player approached it. That technique helps explain why so many games use narrow gaps, elevators, doors, or corridors to give the machine time to prepare the next area.

A dense city creates a different problem. The developers cannot reliably predict which way the player will go next. There is no simple linear corridor and no guarantee that a door, tunnel, or elevator can hide the load.

The player can drive in almost any direction, turn around, cut across streets, and look toward distant landmarks. The streaming system therefore had to support a 360-degree open environment rather than a chain of disguised loading zones.

That ambition created five major problems: pop-in, the rest of the memory budget, fragmentation, disc seeking, and player speed.

If the game only loaded assets in a tight rectangle around the player, buildings and props would appear out of thin air. That is the dreaded pop-in effect: the world materializing just before the player reaches it.

The solution was to check a wider set of sectors while loading different detail levels. The area near the player could be fully loaded, while farther zones only needed the biggest structures: buildings, bridges, ships, cranes, and other skyline pieces.

Those distant structures used simplified low-poly imposters with low-resolution textures. As the player approached, the real model and texture could stream in and fade over the cheaper stand-in.

This is level of detail, or LOD. It even extended to the other islands. Portland, Staunton, and Shoreside used distant low-poly versions as horizon stand-ins, with different versions depending on the viewing direction. There is no reason to render the back of a skyscraper if the player can only see it from the east.

The result is a city that maintains a readable skyline for immersion and navigation while spending far less memory on faraway scenery.

The 32 MB memory budget was not only for buildings and roads. It also had to track animations, pedestrian AI, physics, the location of the player's last car, and many other systems. The radio stations were one exception because they could play directly from the DVD.

That means only a slice of the memory budget could be dedicated to city streaming. In San Andreas, which used the same console and the same broad engine lineage, the stream.ini file shows that about 13.5 MB was dedicated to streaming the city.

Liberty City also needed cars and pedestrians. Grand Theft Auto III had roughly 60 vehicle types, but keeping the full fleet loaded would have eaten too much space. Instead, the game used a strict pool: only eight vehicle types could be loaded at once.

When a car spawned, it had to use one of those slots or push an older vehicle type out. The pool also had to include the car the player was driving, the last car they drove, parked cars nearby, and common vehicles such as taxis and police cars.

That explains a familiar open-world oddity. If the player finally finds a specific car, suddenly it can feel like everyone in the city is driving that same car. Once that model is in memory, it is much easier for the game to spawn more of it.

The lesson is that the streaming system did not exist in isolation. Every adjacent system had to be optimized and constrained so the city itself had room to breathe.

Constantly loading and unloading assets creates another problem: memory fragmentation. If small assets are removed, they leave small gaps. If a bigger asset needs to load later, the total free space might technically exist, but it may be scattered across too many little holes.

If the new asset cannot fit into one contiguous block, it may have to be placed at the end of memory, pushing beyond the budget and crashing the game.

The answer was a bespoke memory manager that could merge and move memory blocks to avoid fragmentation. It could also aggressively free assets when needed, deleting things behind the camera or distant skyline pieces to recover space.

Another trick was to keep many asset files the exact same size. Hundreds of models and textures were 2 KB, and hundreds more were 4 KB. Same-sized assets can take each other's place cleanly, filling gaps instead of creating new fragmentation problems.

The system was stress-tested by attaching the player character to the train that circles Portland and leaving several PS2 development kits running overnight. Early runs crashed after minutes. Later runs survived longer. Eventually, the game could spend the whole night loading and unloading assets without falling over.

DVDs are excellent for reading continuous data, like an album or a movie. They are less ideal for jumping constantly between unrelated files. That jump is called seeking, and it requires the laser head to move, accelerate, settle, and read again.

Grand Theft Auto III was constantly asking the PS2 drive to seek different bits of the disc. To speed that up, Rockstar optimized the physical position of assets on the DVD. Assets from the same part of the city were grouped together so the laser did not need to travel as far for nearby buildings and roads.

The DVD reader also did not simply load requests in the order they arrived. It could prioritize assets closest to the current read position, reducing seek time.

The team also experimented with duplicating common assets on the disc. It can be more efficient to store several copies of a tree or lamppost near different city data than to seek back to one master copy every time that object is needed.

That idea has lasted well beyond the PS2 era. Even later games have duplicated common props across physical media to reduce seek cost. The exact storage devices changed, but the underlying problem remained: the world can only appear smoothly if data can reach memory quickly enough.

Even after all those optimizations, the disc could not always read assets fast enough. If the player moved through Liberty City too quickly, they could outrun the streaming system and see the world appear ahead of them, or worse, fall through unloaded ground.

The practical fix was to slow the player down. Cars had strict maximum speeds. In some parts of the city, air resistance on vehicles was secretly increased by a few percentage points: not enough for players to notice, but enough to let the streaming system catch up.

Flying vehicles were ruled out, and the only plane in the game was clipped so it could barely fly. That was not just a design decision. Seeing Liberty City from the air would expose edge cases the city was not built to handle.

The city layout also changed. Portland once had a long main road that let players build up too much speed while the streaming code struggled to load buildings on both sides. A large building was placed in the middle of that route to break the straightaway.

This is a useful reminder that technical constraints can shape level design. The map is not only an artistic or navigational object. It is also a tool for keeping the streaming system inside its safe operating range.

In normal play, Grand Theft Auto III rarely exposes the trick. That is what makes it impressive. The game is constantly moving buildings, trees, cars, and textures in and out of memory, but the illusion usually holds.

The same foundation carried into the next PS2 entries. Vice City added helicopters by showing low-poly models when the player was above a certain altitude, leaving enough memory for distant skylines. San Andreas removed the hard island loading breaks partly by spacing cities apart with enough countryside that one city could leave memory before another entered it.

As hardware improved, the technique did not disappear. The worlds simply became richer. A modern machine can easily hold Liberty City from Grand Theft Auto III in memory, but it cannot necessarily hold the entire world of a much newer open-world game at full detail.

Solid-state drives make some parts easier because there is no mechanical seeking, but open worlds still stream data in and out of memory. The core idea remains the same: show just enough of the world, at just enough detail, exactly when the player needs it.

Grand Theft Auto III proved that a dense open city could work on a low-powered console by combining a moving streaming window, LOD stand-ins, strict asset pools, custom memory management, careful disc layout, and subtle limits on speed. The magic was not that the whole city fit. The magic was that the game made players believe it did.