How Rockstar fit an entire city into PlayStation 2 memory

Lobsters Hottest News

Summary

The article provides a detailed analysis of how Rockstar achieved a seamless open world in GTA III on the PlayStation 2 with only 32MB of RAM through streaming loading, LOD, memory fragmentation management, and disc layout optimization, setting a benchmark for the industry.

<p><a href="https://lobste.rs/s/i6pafc/how_rockstar_fit_entire_city_into">Comments</a></p>
Original Article Export to Word Export to PDF
View Cached Full Text

Cached at: 05/12/26, 03:21 PM

# TL;DR *Grand Theft Auto III* used innovative streaming technology to fit an entire city into the PlayStation 2’s 32 MB of RAM. By loading and unloading assets in real-time, controlling Level of Detail (LOD), managing memory fragmentation, and optimizing disc layout, it delivered a seamless open-world experience. ## Background: 32 MB vs. a City The PlayStation 2 (PS2) had a 4.7 GB DVD disc, enough to store the entire game — all models, textures, sounds, and radio stations. But the DVD read speed was slow (~5–6 MB/s), making real-time asset loading impossible; system RAM was fast (3.2 GB/s) but only 32 MB — less than 1% of the disc capacity. The traditional approach was to load all data for the current area into memory, clear it upon leaving, and load the next area with a loading screen. But *GTA III*’s world was open and seamless. Players could freely explore Liberty City, built from thousands of unique models (~77 MB) and textures (~45 MB), totaling ~130 MB — far exceeding the memory budget. ## Solution: Streaming The game’s technical lead, Adam Fowler, proposed a more radical method: divide Liberty City into thousands of small zones. Set an invisible square around the player and load only the models and textures for zones within that square. As the player moved, continuously load new zones while unloading those left behind. Since newly loaded models were always far from the player, any slight delay from DVD reads wouldn’t cause noticeable stutter. This technique was called **streaming**. By modifying *GTA III*’s source code and recompiling, you can see the mechanism visually: the city constantly loads and unloads chunks of assets as the player moves — the world secretly builds ahead and silently vanishes behind. > **Core idea**: Don’t cram the whole city into memory. Build a “moving window” around the player, showing only what’s needed to maintain the illusion. ## Level of Detail (LOD) and Pop-in Control A simple rectangular load zone would cause horrible “pop-in” — buildings appearing out of thin air. The solution: - For distant zones, load only large structures (buildings, bridges, ships, etc.) using **simplified, low-poly, low-resolution texture** stand-ins. - As the player approaches, stream in the real models and textures, smoothly fading them over the low-poly copies. - This system is called **LOD** (Level of Detail). Even other islands (Portland, Staunton, Shoreside Vale) each had low-poly versions that floated on the horizon as stand-ins for the rest of Liberty City. For example, Staunton Island had two different distant models — one when seen from Portland and another from Shoreside Vale — to avoid rendering unnecessary backfaces and save triangles. ## Memory Management: Squeezing Every Byte The 32 MB of RAM also had to hold animations, pedestrian AI, physics calculations, player vehicle positions, and more. In reality, only a small portion was available for streaming. For example, in the same-engine *San Andreas*, the `stream.ini` file shows only about **13.5 MB** dedicated to city streaming. ### Vehicle Pool Limits The game had ~60 unique vehicle types, with total models + textures ~10 MB. But only 8 vehicle types’ models could be kept in memory at once. When spawning a new car, either reuse one of the existing 8, or kick out an old one to free up space. This pool had to include the car you’re driving, cars you drove earlier, nearby parked cars, plus common taxis, police cars, helicopters, military trucks, etc. This is why players often see the same vehicles repeatedly, and why after finding a rare car, it seems to appear everywhere — because it occupies one of the eight slots, increasing its spawn probability. ### Memory Fragmentation Continuously loading and unloading small resources created memory fragmentation that was hard to coalesce, potentially crashing the game. Adam Fowler wrote a custom memory manager that could: - Merge and move memory blocks to avoid fragmentation. - Actively free memory — delete objects behind the camera or large buildings on the distant horizon. - Ensure **hundreds of resource files were exactly the same size**: over 500 files were exactly 2 KB, and 416 exactly 4 KB. This allowed resources to seamlessly replace each other when loaded/unloaded, filling gaps and preventing fragmentation. Testing method: Bind the character to a train speeding around Portland, and let the game run on five PS2 dev kits overnight. All crashed within the first five minutes. After days of debugging, gradually survived half an hour, one hour, and eventually ran all night — meaning it cycled through loading and unloading models all night long. ## Disc Seek Optimization DVDs were designed for sequential reads (like movies), with data stored in a continuous spiral track. Jumping to another part of the disc (seeking) required moving the laser, costing time. *GTA III* constantly asked the DVD reader to seek different locations. To speed this up, Rockstar had to physically optimize resource placement on the disc: - Group assets from the same city area together to minimize long laser movements. - The DVD reader code maintained a queue of pending loads, prioritizing assets closest to the current read position, not in queue order. - Try duplicating assets on the disc — for example, placing multiple copies of the same model (trees, lampposts) at different locations on the disc, which was more efficient than constantly seeking back to a single location. This technique is still used today, e.g., Insomniac’s *Spider-Man* placed hundreds of identical mailboxes on the Blu-ray disc. ## Risks and Validation Was constant seeking safe for the DVD drive? Producer Leslie Benzies said in a documentary: “Streaming was risky. Could the drive in the machine keep moving for 24 hours without melting?” In fact, the PS2 drive did not melt — Vermeij believes Sony approved the design before release. The game was ultimately successful and set a technical benchmark for the entire open-world genre. --- Source: How Rockstar fit an entire city into PlayStation 2 memory (https://www.youtube.com/watch?v=cIbCxbrBCys)

Similar Articles

25+ years of pathfinding problems with C++

Lobsters Hottest

The Engineering Director of Age of Empires provides an in-depth analysis of the technical debt in the series' pathfinding system over the past 25 years, pointing out that legacy code, dynamic map mechanics, and floating-point errors caused by SIMD instruction sets replacing x87 extended precision are the root causes of classic bugs such as units clipping through walls.

@AYi_AInotes: 卧槽,有大神直接用Claude Code,复刻出一整套完整游戏开发工作室。 GitHub 1.8万stars,免费开源,项目名叫Claude Code Game Studios, 48个AI智能体1:1还原线下工作室全岗位,从创意总监到关…

X AI KOLs Timeline

卧槽,有大神直接用Claude Code,复刻出一整套完整游戏开发工作室。 GitHub 1.8万stars,免费开源,项目名叫Claude Code Game Studios, 48个AI智能体1:1还原线下工作室全岗位,从创意总监到关卡设计师全覆盖。 36条斜杠指令一键启动全流程,适配Godot Unity Unreal三大游戏引擎。 自带自动化校验钩子、分路径编码规则、28套行业标准文档模板,架构拉满。 所有AI只做梳理方案不擅自操作,决策权全程握在自己手里。 克隆仓库一键启动,MIT开源可商用,凭空拥有一支专业游戏开发团队。 老规矩GitHub地址评论区自取!

@PandaTalk8: These test results are stunning. The original poster tested the DS4 inference engine written in C by @antirez, and local deployment seems incredibly fast. The good news is that only 128GB of RAM is needed to run a local model equivalent to GPT-4o. The bad news is that you need a MacBook Pro with 128GB of RAM.

X AI KOLs Timeline

This article reports on tests of the DS4 inference engine written in C by @antirez, noting its impressive speed when running a GPT-4o-equivalent model on a MacBook Pro with 128GB of RAM.