The 1987 game “The Last Ninja” was 40 kilobytes
Developers reminisce about 1980s games like The Last Ninja and Super Mario Bros. fitting rich worlds, music and mechanics into tens of kilobytes and a few kilobytes of RAM, contrasting that with today’s multi‑gigabyte titles and even bloated tooling. Many argue that strict memory and storage limits once forced elegant, process‑intensive designs and clever data representations, while modern abundance, safety features, high‑res media, and frameworks like Electron trade efficiency for developer speed and richer audiovisual experiences, sometimes at the cost of responsiveness and simplicity.
Game size and hardware constraints
- The C64 version of The Last Ninja reportedly fit in
40KB of RAM, with total disk/tape content on the order of a single 1541 floppy side (170KB–a few hundred KB at most). - Some clarify that C64 could access nearly 64KB by bank-switching out ROMs; tape games often just loaded one contiguous memory image and never streamed more.
- Comparisons are made to similarly tiny classics: Super Mario Bros. at ~40KB ROM, Elite fitting in 32KB on BBC Micro, Pac‑Man at 24KB.
Efficiency vs modern software “bloat”
- Many contrast these sizes with modern games and tools in the tens to hundreds of GB (e.g., COD, Claude Code CLI at 200+MB).
- Several recount modern systems where actual data is a few MB while processes consume GBs, attributing this to layers, frameworks, and lack of pressure to optimize.
- Others argue the increased footprint often buys safety (GC, bounds checks), networking, crypto, and richer media.
Graphics, audio, and data representation
- Old games used low resolution, tiny color palettes, and procedural or tracker-like audio; today’s games use high‑res textures, 32‑bit color, and PCM/streamed audio, which inherently scales storage and RAM by orders of magnitude.
- Framebuffer and texture sizes alone now exceed entire 8‑bit games.
Demoscene and extreme compression
- Multiple posts highlight modern 4KB–64KB PC demos and a sub‑100KB 3D FPS as proof that high‑res real‑time graphics and music can still fit in tiny binaries via procedural generation and streaming.
- There is debate whether this approach just trades memory for CPU/VRAM and engineering effort; consensus: impressive, but not generally economical for mainstream software.
Tradeoffs, economics, and tooling
- Some defend “waste” as rational cost: developer time and maintainability are expensive, memory is relatively cheap; optimization is only pursued when constraints bite.
- Electron and similar stacks are repeatedly criticized as emblematic of avoidable bloat and custom UI churn; others note they win on portability and developer availability.
Nostalgia and design
- Many share fond memories of The Last Ninja: distinctive isometric graphics, tape‑loading music, finicky movement/search mechanics, and iconic SID soundtracks.
- A recurring theme: constraints once forced ingenuity; today, abundant resources plus business pressures favor “good enough” over tightly engineered minimalism.