Making video games (without an engine) in 2025

Original Article ↗ Hacker News Discussion ↗

Engines vs. Custom Code

  • Many argue big engines (Unity, Unreal, Godot) are popular because they solve hard, generic problems: animation blending/IK, physics, audio, rendering, asset streaming, cross‑platform builds, etc.
  • Others counter that for small, 2D, or tightly scoped projects, “no engine” can be simpler, faster, and more enjoyable, especially if 90% of engine features are unused.
  • Several note that using an engine lets you work on the game itself instead of “yak‑shaving” infrastructure; others say building the tech is the fun part and can be central to their motivation.

How Hard Are the “Hard” Parts?

  • Some commenters claim pieces like simple IK, blending, and 2D physics are not that bad, especially with narrow scope.
  • Others emphasize that robust, production‑grade physics, rendering, spatial audio, and advanced animation pipelines are extremely deep domains where homegrown solutions often fall short or consume huge time.

Tooling, Editors, and Asset Pipelines

  • A recurring theme: the runtime “engine” is the easy part; the real workload is tooling—importers, editors, asset baking, visualization, debugging, profiling, and content pipelines.
  • Multiple experienced devs report spending far more time on tools than on the core engine, and say this is where many custom‑engine projects stall.
  • Suggested compromise: use existing DCC tools (Blender, Tiled, Maya, Excel, etc.) plus hot‑reloading, or even build tooling on top of existing engines.

Productivity, Learning, and Procrastination

  • Several see “reinventing the wheel” as procrastination from the hard creative work of designing fun, polishing content, and shipping.
  • Others say writing subsystems yourself gives deep understanding, full ownership, and reusable code across a long career, which can justify weeks or months of work.
  • Common advice: if your goal is to ship quickly, use an engine; if your goal is learning or engine programming itself, rolling your own is valuable.

When Custom Engines Shine (or Hurt)

  • Custom approaches are seen as most justified for:
    • Highly non‑standard mechanics (non‑Euclidean, 4D, unusual physics, rewind systems, huge open worlds with dynamic lighting, etc.).
    • Very focused 2D or retro‑style games where scope is tightly controlled.
  • Others warn that even in these cases, engines can often be bent to fit, and that many acclaimed indie games with custom engines required years of prior experience.

C#, .NET, and GC

  • The thread is broadly positive on modern C#/.NET: cross‑platform, NativeAOT, hot‑reload, low‑level control, source generators.
  • GC pauses are acknowledged but seen as manageable via pooling, initialization‑time allocation, or new GC work (like Satori), especially for games that load most assets up front.