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

Original Article ↗ Hacker News Discussion ↗

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.