IdeaWell

Project ideas from Hacker News discussions.

How to engineer an AI harness for game development

Original Article

Hacker News Discussion

📝 Discussion Summary (Click to expand)

Theme 1: Coding is not the bottleneck – design, art, and polish remain the hard parts

"LLMs have completely solved the coding side of game development. But this was never the hard part." – bob1029
"Indeed, not even wrong. And it will whiff on the most basic gameplay issues. But it is still genuinely impressive how fast it can build a pretty but unplayable unfun thing out of nothing." – LogicFailsMe
"Coding is not the hardest part for a large portion of indie games. You can in theory build an AI‑coded game that sells well if you have the right art and gameplay." – glimshe

Theme 2: Determinism and reproducibility across platforms is a tricky trade‑off

"The fixed randomness and determinism thing sounds great on paper … but in reality this is an extremely confining way to build a video game. Ensuring you maintain determinism across many platforms is where things get super nasty." – rrradical
"Ensuring you maintain determinism across many platforms is where things get super nasty." – simonw
"Assuming the agent didn't put in a native nondeterministic trig function deep in the code … it's an easy mistake to make and hard to debug in a big game." – avaer
"I’ve worked on games with intentional determinism, and it’s a very valuable tool. A playtester can hand a dev a recording of the game inputs … and the dev can fast forward to the exact point and repro it 100%." – mypalmike

Theme 3: AI‑assisted development works for small/in‑indie prototypes but breaks down for larger, complex games

"For a not so extreme example, you won't vibe code Cyberpunk 2077 while just taking care of art and gameplay ideas. Gosh, humans could barely pull that one off!" – glimshe
"For example, the Thing approach is reasonable for a small game, but it's a dead end for a performance budget or layered subsystems. In a reasonably sized 3D game, iterating and copying 30 subsystems of 1000's of Things is impossible to do in frame time …" – avaer
"It's definitely not my intention to try and describe ways for making game development be more turnkey. I'm more trying to directly address ways to make non‑one‑shot (read: actual) game development be more tenable when an agent is involved." – KKukshtel

🚀 Project Ideas

Generating project ideas…

Deterministic Fixed‑Point Math Library for Cross‑Platform Game Engines

Summary

  • A lightweight, header‑only library (C++/Rust/WASM) providing deterministic replacements for floating‑point trigonometry, sqrt, and random functions using fixed‑point arithmetic.
  • Core value: guarantees bit‑identical simulation results on any CPU, GPU, or Web target, eliminating platform‑specific nondeterminism that breaks replays and netcode.

Details

Key Value
Target Audience Indie and professional game developers building deterministic simulations (replay, rollback netcode, physics) who currently rely on platform‑specific math calls.
Core Feature Deterministic sin, cos, tan, sqrt, pow, and PRNG functions based on a configurable fixed‑point format (e.g., Q16.16) with optional SIMD fallbacks; includes unit‑tested reference implementations and WASM bindings.
Tech Stack C++17 (header‑only), Rust crate, Emscripten/WASM build, CI with GitHub Actions testing on x86, ARM, WebAssembly, and various compiler versions.
Difficulty Medium
Monetization Hobby (open‑source MIT license; optional paid support/tiered consulting for engine integration).

Notes

  • HN commenters highlighted the pain: “Ensuring you maintain determinism across many platforms is where things get super nasty” (simonw, rrradical) and the need for a fixed‑point math library to avoid “nasty” nondeterministic trig calls (avaer).
  • Provides a drop‑in replacement that can be swapped into existing engines (Unity, Godot, custom C++), enabling reliable replays, rollback netcode, and easier debugging without rewriting math‑heavy code.
  • Potential for discussion: benchmarking deterministic vs. floating‑point performance, integrating with ECS frameworks, and extending to shader‑side deterministic approximations via WebGPU/WGSL.

Game Observability & Deterministic Replay Toolkit

Summary

  • An instrumentation SDK that automatically logs player inputs, game state delta, and custom metrics (DPS, health, resource usage) as time‑series data, paired with a deterministic replay system that can reconstruct any session from the log.
  • Core value: gives developers and AI agents deep insight into gameplay balance, performance bottlenecks, and bugs, while enabling 100% reproducible replays for QA and agent‑driven testing.

Details

Key Value
Target Audience Developers using LLMs or agents to iterate on game mechanics, who need visibility into progression curves and deterministic debugging (e.g., indie devs, AI‑assisted studios).
Core Feature Zero‑overhead input logger + deterministic state snapshotter; metric export (JSON/Protobuf) to Grafana/Prometheus; replay viewer that re‑simulates using the logged inputs; optional WebSocket UI for real‑time metric dashboards.
Tech Stack C++ library with thin bindings for Rust, C#, and JavaScript; uses flatbuffers for efficient logging; optional Grafana plugin; deterministic replay uses the same fixed‑point math library from Idea 1.
Difficulty Medium
Monetization Revenue‑ready: “Freemium – free core SDK, paid cloud dashboard & team collaboration features ($15/mo per seat).”

Notes

  • The discussion calls for observability: “One thing I think game dev has not (AFAIK) invested as much in is observability… measuring DPS, health, etc as an exported metric time series” (theptip).
  • Deterministic replays were praised as a huge time‑saver: “A playtester can hand a dev a recording of the game inputs… the dev can fast forward to the exact point and repro it 100%” (mypalmike).
  • By pairing deterministic math with input logging, the toolkit solves the “nasty” cross‑platform replay issues mentioned by simonw and avaer, giving AI agents a reliable way to test balance changes and performance tweaks.

AI‑Generated Side‑Agent Dev‑Tool Builder

Summary

  • A web‑based service where developers describe a small QoL tool they wish existed (e.g., level‑editor widget, asset conversion pipeline, interactive design doc with videos) and an LLM generates the source code as a plug‑in or standalone utility for their chosen engine/framework.
  • Core value: eliminates the “missing tooling” friction that slows iteration, letting developers spawn orthogonal agents to build utilities in the background without diverting from core gameplay code.

Details

Key Value
Target Audience Indie developers and small teams using LLMs for coding who repeatedly need bespoke editor extensions, asset processors, or documentation aids.
Core Feature Prompt‑to‑code pipeline: user inputs natural‑language description → LLM (fine‑tuned on game‑dev tooling) → output code skeleton with build instructions, engine‑specific hooks (Unity Editor, Godot Plugin, custom CMake), and optional test harness.
Tech Stack Frontend: React/Vite; Backend: Python FastAPI; LLM inference via open‑source model (e.g., Mistral) hosted on GPU; generated code templated with Jinja; Docker for sandboxed builds.
Difficulty High
Monetization Revenue‑ready: “Subscription – $10/mo for unlimited tool generations; enterprise tier with private model fine‑tuning and SSO.”

Notes

  • Commenters expressed the desire to off‑load tooling: “You can just spawn a side agent to build; if they are orthogonal to your main thread you can just progress them in the background” (theptip) and “build an interactive design doc with videos of each game mechanic” (theptip).
  • The idea directly addresses the pain of missing or tedious tooling (level editing, asset conversion) that pulls focus away from core game development, enabling rapid iteration via AI‑generated helpers.
  • Potential for discussion: safety of generated code, integration with version control, and community sharing of generated tools via a marketplace.

Read Later