The project starts from a simple desire: build an FPS to play with friends. Author /u/zRevengee did not use a cloud-based engine or a pay-per-token API assistant. They ran Qwen 3.8 Flash Next locally, with Q4_K_XL quantization and a 256k-token context window, using opencode as the harness to generate and modify code. The result is a multiplayer game with a surprisingly broad feature list: a toggleable retro PSX-style shader, fully destructible environments, tac sprint, leaning with Q and E to peek from corners, free-for-all, SnD, swords-only, RPG-only and team deathmatch modes, killfeed, a map with red dots when a player shoots, bunny hop, day-night cycle with rain or snow, FOV and shader intensity sliders, and a hide-and-seek mode.
The most interesting technical detail is not any single feature, but the pace of work. The playable demo arrived in about two hours; the refinement took three days, often with the machine working while the author was at work or asleep, checked remotely from a phone via KVM. This shifts the center of gravity: the bottleneck is not per-token cost or API latency, but available machine time. On a setup with an AMD Ryzen 9 5900X, 128 GB of DDR4 at 3200 MHz and two NVIDIA GPUs — an RTX 5090 and an RTX 4000 PRO, with 32 + 24 GB of VRAM — the model averaged 20 tokens per second with MTP. That is slow compared with hosted services, but sufficient for an asynchronous workflow: set the task, let the model iterate, and check back later.
The structural point is that this experience is not an isolated outlier. Open models, when run on local hardware with aggressive quantization, allow individual developers to tackle complex creative projects without sending code or assets outside their own network. For those evaluating on-premise deployment, the trade-offs are clear: on one side, no per-token costs and data stays on the machine; on the other, you need GPUs with adequate VRAM and cooling capable of sustaining long sessions. Here the declared total VRAM is 56 GB, a non-trivial requirement for a hobbyist but not out of reach for small teams that want to add local capacity alongside cloud.
But the point is not to advise everyone to buy two GPUs. It is that the boundary between consumer and creator is shifting. A model quantized in Q4_K_XL, with a 256k-token window, can hold an entire game project in context and produce coherent modifications. There is degradation compared with full precision, but in an iterative coding context the benefit of an always-available assistant, with no usage limits and no monthly bill, outweighs the slightly lower quality of some suggestions.
An open question remains about who loses in this scenario. Cloud coding assistants offer larger models and faster responses, but require sharing code and depending on a connection. Local hardware demands upfront investment and management skills. The story of this FPS shows that the market is segmenting: there is no single right deployment, but different paths depending on sensitivity to cost, privacy and patience. The fact that a single user got a playable demo in two hours, with a local model and a self-hosted harness, signals that the on-premise tooling ecosystem is reaching enough maturity for real projects, not just experiments.
💬 Comments (0)
🔒 Log in or register to comment on articles.
No comments yet. Be the first to comment!