Let's write a video game from scratch like it's 1987

Original Article ↗ Hacker News Discussion ↗

Recreating a minimalist Minesweeper-style game “like it’s 1987” prompts a broader look at how much lower-level control and frugality older platforms demanded compared to today’s bloated, ad-laden equivalents. Commenters contrast raw X11, SDL, and Wayland, and debate allocator design and systems languages, while reminiscing about writing games and tools on early PCs, calculators, and 8‑bit machines with kilobytes of RAM. Many argue that despite the pain of manual memory management and primitive tooling, those constraints fostered highly efficient, inventive software that modern engines and hardware often obscure.

Retro hardware & nostalgia

  • Several comments reminisce about programming on TI graphing calculators (TI‑85/86/89), including algebra solvers and even a primitive ray tracer exploiting slow LCD response for anti‑aliasing.
  • Others recall TI’s dominance in education and link it to broader histories of TI and calculators.
  • Home computers like TI‑99/4A, ZX Spectrum, Amstrad CPC, Atari, and Amiga are discussed as fertile ground for early game dev, often with assembly, sprite chips, and tiny memory footprints.

Allocators, systems languages, and game engines

  • Odin’s implicit allocator passing is compared with Zig’s explicit “no hidden allocations” philosophy.
  • Debate over whether implicit/default allocators are acceptable:
    • One side argues systems programming is about tight, explicit control of memory, threading, and latency; otherwise a managed language may be better.
    • Others counter that implicit allocator threading doesn’t reduce control and that high-level abstractions and safety (e.g., Rust, C++) can coexist with low-level control.
  • Game engines are framed as systems programming: heavy dynamic allocation, custom allocators, and the importance of predictability.

X11, SDL, Wayland, and network transparency

  • Some argue SDL adds little overhead and big portability; others note that for X11 you can keep pixmaps server‑side for very efficient networked blitting, which SDL often doesn’t exploit.
  • Strong debate over whether X11’s network transparency is a “flaw” or a powerful feature now largely lost with Wayland.
  • Wayland is criticized for lack of native remote display and for requiring more pixel pushing; defenders say remote protocols (VNC‑like) are sufficient.
  • Clarification that Wayland can still send shared‑memory pixel buffers; claim that static linking is “impossible by design” is challenged.

Code readability: Doom vs modern engines

  • Some find Doom’s C code archaic and hard to maintain by today’s standards: terse names, few comments, and large functions raise bus‑factor concerns.
  • Others say it’s quite readable for its era and that minor indentation quirks are nitpicks.
  • Modern AAA practices favor small, self‑documenting functions, heavy commenting, and maintainability metrics; the Doom style is viewed as historical but not ideal today.

Constraints, binaries, and dev workflow then vs now

  • The article’s ~300 KB static binary and ~1 MB assets are praised, but multiple comments note this would still be “huge” for 1980s hardware (often 64–640 KB RAM, tiny disks).
  • Comparisons to tiny classic games (Minesweeper, Chip’s Challenge, SNES titles) emphasize how far resource use has grown.
  • Recollections of DOS/Turbo Pascal workflows highlight how integrated IDEs and fast compilers once gave very tight edit–compile–run loops, sometimes faster than modern C++ toolchains.
  • There is widespread sentiment that early dev combined strong constraints, custom tools, and intense focus (no internet/notifications), enabling impressive creativity.