Gamedev

A working comic artist and animator enters game dev planning to draw 2D characters and study animation seriously — and immediately collides with the vibe-coding scene: “I BUILT GTA 6!! LOOK, ITS A CITY WITH CARS!!” demos with no mechanics, goals, or vision. Their frustration: Vibe-coded demos clog storefronts and starve real first games of feedback AI content ruined their reference sites after a decade; they switched to library books The response is craft: studying geometry, learning engine node systems, planning a custom engine someday The thread’s pushback is the useful part: ...

A solo dev with no coding or art background spent months building a game with heavy AI assistance — and found the reality is nothing like “a few prompts and you have a game.” Halfway to a playable demo, they’re wrestling with a harder question: whether the “AI was used” label dooms the project, especially if they charge money for it. The arc of their experience: AI removed the technical barriers — then the real work began: “Add a mechanic. Break three things. Fix them. Change your mind. Refactor. Repeat.” They couldn’t recreate the code from scratch — but they designed mechanics, chose how systems interact, rejected bad outputs, and hand-fixed pixel art in Aseprite. The authorship question resolves in practice: “Did I actually make this game? I think I did.” The remaining fear is reputational: free feels safe, €5 feels like crossing a line. The comment section converges on a consistent answer: ...

Lennart Nacke’s second-week lecture from his Basic Introduction to Game Design course walks through the Rules of Play lens on games: a game is a closed formal system that subjectively represents a subset of reality. Rather than debating what a game “is,” it lays out the eight formal elements every game is built from — and how their relationships create gameplay. The four system ingredients (Littlejohn & Foss, via Rules of Play): ...

A video game lawyer tells GamesRadar+ that “no gen AI” clauses have gone from a risk-averse-publisher nicety to standard practice in a single year — even small publishers now include them “just to cover our butts.” The drivers: gamer backlash and a copyright system that does not protect purely AI-generated work. The contract shift: Clauses now appear in marketing, porting, and QA agreements, not just core development Her advice to studios without them: “Don’t touch it. It’s not worth the legal liability that it brings to you.” Palworld’s publishing lead recently said the devs avoid AI because “gamers don’t want it, end of conversation” The copyright angle is the part most devs miss: ...

The r/gamedev moderation team (1,100+ points) lays out an official AI policy: the subreddit does not prohibit AI use, and AI involvement does not automatically make a post low effort. The core argument — “we are not policing AI use itself. We are moderating the contribution.” Why they refuse to police AI: AI is already part of game development — studios use it across programming, prototyping, production, QA, localization, and research AI literacy is becoming a professional skill: knowing where tools help, where they fail, and how to evaluate output Banning discussion would actively disadvantage developers trying to learn how the industry is changing Policing AI use is not realistic — moderators cannot reliably detect whether someone used AI to draft, edit, translate, or debug Mandatory disclosure is not realistic either — modern tools blur the line between traditional software and AI assistance The practical rules that follow: ...

A r/aigamedev post argues anti-AI-coder criticism is unwinnable by design: whatever an AI-assisted developer does, the dismissal is the same. Disclose AI use and the project is “AI slop.” Keep quiet and you’re accused of deception. Spend months building a serious, professional-level library with AI and critics say “maybe you shouldn’t have used AI.” The goalpost pattern: Hide AI use → bashed for not mentioning it, with the standard line “using AI is fine if you just say so” Disclose AI use → instantly labeled “AI slop” anyway Build something serious with AI → “maybe you shouldn’t have used AI,” quality be damned The author’s read: the complainers are mostly hobbyists, not professionals — game companies have moved on to AI-assisted programming. And the same people happy to build on Unity or Godot bash hand-coded AI-assisted libraries, which makes the objection about the tool, not the work. ...

A r/gamedev thread (455 points) pushes back on the vibecoding narrative from the developer’s chair: Claude output works, but the architecture is “complete gloop,” and steering the agent costs more time than writing the code would. The replies turn the complaint into a practical checklist. The complaint: The review tax — guiding and reviewing the AI takes longer than writing it yourself: “if im going to spend time anyway why not just do it myself with ai as a wingman.” Silent cruft — even successful generations insert unnecessary sections that “pile up” if you don’t catch them. Architecture loss — “I could of written all of it myself and have 1000 times better understanding of my architecture.” The fixes the thread converges on: ...

A solo dev building a fishing game entirely with AI documents how the workflow matured by week 3 — from “just typing what I want” to a network of dedicated AI sessions wired into Blender and Godot via MCPs. The post is really about process discipline, and it reads like a checklist born from concrete failures. The six rules: Reference first — ChatGPT generates concept art and UI mockups; the human decides the look before any geometry exists. “Without human eye AI will just make stuff not fit together.” Scripts over generated meshes — Rodin’s 3D output needed too much cleanup, so a dedicated Blender MCP session writes models instead. The script is the source, so proportions stay editable — and low-poly is all the camera distance needs. One session per job — modeling, integration, and UI each get their own session; a general chat window dispatches commands between them. Screenshots are the referee — nothing counts until it’s rendered from the actual in-game camera. Four new islands checked from overhead looked fine, but in game they were “flat sandy pancakes floating on the water. From above, a pancake looks perfect.” Blind scored reviews — criteria written before the change, twelve things scored out of ten, ship only at 8+. One critic judged screenshots without being told which version was newer — that kills “I changed loads, so it must be better.” Every decision tagged with who made it — marked USER or AI-suggested, because an upgrade nobody ever proposed once sat in the design docs and got quoted back as the author’s own idea. The summary line: “AI does the work, I’m the art director, and I’m the only human in the loop.” ...

A solo developer (qqop_) introduced Flemenco to r/roguelikedev — a spy-heist roguelike where twelve unique thieves, each with distinct skills and abilities, work to dismantle the ubiquitous Flemenco Corporation. The core loop centers on a safehouse planning phase, contract selection, and mission execution with consequences that ripple forward. The design highlights so far: 12 distinct characters — not stat-variant classes but genuinely different spy-thieves with their own mechanical identities Planning matters — acquiring blueprints, selecting equipment, and even signing up for a gym membership affect contract outcomes Sensible UI layout — map top-left, stats top-right, message log at the bottom (clean and effective) Non-gridlocked ASCII — characters move freely rather than snapping to a tile grid, giving the visuals more life The most interesting part is the planned procedural contract system. Rather than pulling from a random pool, objectives chain through cause and effect: an executive eats an access code because you disabled his backdoor, turning the objective from data retrieval into kidnapping. That kind of systemic reactivity is what makes roguelikes sing — and it’s ambitious for a v0.1.5. ...

Game Code School released a free 17-part written tutorial series that builds a complete traditional roguelike from scratch in C++ with SDL3 — turn-based, ASCII, procedurally generated, permadeath. Every part ends with something you can build, run, and play, and all source is on GitHub with one folder per part. The series covers: Dungeon generation: BSP rooms, then cellular-automata caves Recursive-shadowcasting field of view, fog of war, and a remembered map Monster AI on a Dijkstra map — one flood fill over the floor that everything pathfinds from Turn-based melee, ranged magic, equipment, and status effects Data-driven character classes, multiple floors, a plain-text save system, HUD and message log, and synthesized sound with no asset files A win condition The stated philosophy is explaining the why as much as the what: why a Dijkstra map beats a pile of A* searches here, and why the architecture gets refactored exactly when it does — not before. Part 1 makes the sharpest argument: draw the dungeon as ASCII glyphs from the very first frame, because the renderer you build now is the one you keep. Start with colored rectangles and you will delete that renderer in Part 2. ...

A first-time game dev shared his flopped demo on HN and asked for resources to learn game design. 140 comments later, the advice converges from every direction: stop trying to learn design from content and start finishing small games. The recurring lessons, from veterans who actually shipped: Ship small, ship many. DOOM was Romero’s 100th game. Your gems sit at the back of the stack — you have to pop the shit ones first. Clone before you create. Reproduce a tiny mechanic from a game you love and throw it away. Duplicate a proven mechanic like Tetris or Balatro and perfect it until you are bored — then add one tweak. Study board games. Ruthless constraints force designers to justify every element. A video game should be pitchable as succinctly as a board-game teach video. Ask early, in person. Show devs before you are ready. Start with five trusted testers, iterate until they are excited, then scale to 20, then 100. Never debut in a large public venue. Kill the signup wall. Players bounce the moment they are asked to create an account. Drop them straight into the fun; ask for the signup only after they are hooked. Design is the craft. If you are a programmer, game design is not a side skill — it is the product. Work with someone confident in design instead of expecting to invent it from books. Clean up your information diet. People with time to podcast and build personal brands mostly are not building anything. Makers are too busy to post. The thread’s real message: a failing first demo is not the problem — it is the fastest feedback you will ever get. The fix is not another book, it is a smaller game, finished, in front of five people who will tell you the truth.

A solo RPG dev nails a problem every systems-heavy game faces: changing a scaling formula that looks fine on a graph, then finding three weeks later that a mid-tier item dominates a level band you never manually checked. The curve was fine — the problem was the interaction with crit, attack speed, and enemy resist. The thread surfaces a few approaches: Spreadsheet tabulation — the default. Plot every stat and average across 100 levels, scan for visual outliers. Most people do this, and it catches single-variable drift but misses cross-system interactions. Combat simulation + statistics — one dev tried four iterations: a combat generator, statistical TTK averages, optimization (failed — no suitable objective function), and finally simulating many hero variants against bins of actors. The hard-won lesson: the fewer variables the better. Derive HP from weight. Shrink the space before you simulate. Alpha/beta + postlaunch patches — accept that no automated tool catches everything, use playtest metrics, patch after ship. The most transferable insight is from jube_dev’s four-attempt journey: reducing the number of independent variables by computing derived stats from formulas is the only systematic way to make the remaining combos testable. The same balance math that works at parameter level breaks at interaction level, and no off-the-shelf tool handles that — everyone builds their own spreadsheet.

A systems-design devlog for BAKERRRR, a pygame-first systemic crime sandbox roguelike written in Python. The author reached the point where describing it as a list of planned systems feels less accurate than describing the simulated world that already exists — everything drawn procedurally in code, nothing from a conventional sprite sheet. The core thesis is that crime should be epistemic — driven by what the world actually knows: Witnesses can know a crime happened without knowing who committed it. Descriptions degrade with distance and poor light. Justice can arrest the wrong person if clothing, build, location, and timing match closely. Disguises, framing somebody else, and plain bad luck matter — without the game inventing fictional crimes to justify an arrest. The simulation runs deeper than NPC schedules. NPCs have names, relationships, memories, jobs, and their own ideas about what they should be doing — they work, commute, shop, spread rumors, investigate trouble, and sometimes interfere with one another in ways the author never explicitly scripted. ...

A r/aigamedev post from an indie dev (thewokelama) who released the Guns & Gargoyles demo on Steam. Built with Godot, sprites from PixelLab heavily reworked in GIMP, AI use self-disclosed — and it was still dismissed as “an AI game” in announcement threads. His bet: the critics are a vocal minority, and players will play a game that looks and feels good. The thread’s sharper points: The dev’s thesis: the backlash is a vocal minority afraid of change; quality wins players The top reply’s counter: the label tracks perceived cohesion, not toolchain — store-page copy that contradicts the title reads as “no human reviewed this” Concrete art feedback: a single repeating ground texture makes the world look sparse and “very AI”; a grind-texture pass would define spaces better A default-font store page undercuts the presentation The dev accepted the art feedback and said he would try it Disclosure does not immunize a release against the AI label. The actionable lesson: the “AI game” tell is incoherence — inconsistent copy, flat textures, default fonts — and it reads as AI regardless of the actual toolchain. Fix the tells and the label loses its grip. ...

A r/aigamedev post from Jakal7 (John Kinyanjui) introduces Sprite Studio, an MIT-licensed desktop app that uses a locally installed Codex CLI to create and animate 2D game assets. The design bet: image models alone cannot keep a character consistent across animation frames, so the pipeline runs through a code agent with a harness constraint. How it works: Generates characters, creatures, props, and effects, then previews animated sprite loops Keeps character, style, proportions, and equipment consistent across frames via an internal “sprite harness” Organizes assets and AI conversations into worktrees for isolation Adjusts animation timing and inspects individual frames Includes a playground to test movement before export Exports sprite sheets; ChatGPT-backed today, with more providers (including open-weight models) planned The interesting pattern is treating frame consistency as a pipeline problem, not a prompting problem. Instead of hoping a raw image model keeps a six-legged creature coherent across frames, the app constrains generation through the code agent and a harness that checks each frame against the original. Community reception was warm — the main friction reported was local build complexity, not the workflow itself. ...

A r/aigamedev post from Ari, his quadriplegic nonspeaking brother Ben, and his wife Nancy describes how they use AI to build free, open-source games for Ben. The constraint list is the design document: every game runs on one or two switches, speaks everything aloud, and never demands reflexes. The constraints that shape every game: Input model: Spacebar/Return keyup scans and selects; long-hold scans backward or opens charge/context menus All interactions need text-to-speech; no or low reflex requirements (mostly turn-based) Games must run standalone in the browser, independent of their hub Level editors are core — no two disabled players share the same visual needs, cognitive load, or pacing, so each game bends to fit the person instead of the other way around Everything is open source: games at switchedgames.org, developer guide at narbehouse.github.io The NARBE Foundation backs active volunteers with Claude Code access and AI credits — tooling as support for the work, not payment The transferable lesson is the level-editor-as-accessibility move: when player needs vary wildly, the game must adapt to the player rather than the reverse. AI’s role is acceleration — it makes a hyper-niche audience economically buildable — and the fork-the-input-logic model turns accessibility scaffolding into reusable infrastructure for the whole community.

Jen Nichol (XBOX Game Dev Community Manager) interviews Willem Willemse, the solo developer behind Idle Not Idle Games in Johannesburg. The conversation is a rare honest look at what solo development actually demands — beyond the coding. The thesis is simple: solo devs don’t just build games. They become the entire team, often without realizing how many hats they’re wearing until scope catches up. Willem started focused on coding, but became storyteller and designer out of necessity — “to actually make a proper story, there needs to be some form of narrative experience” A structured roadmap (art update → level design → skill systems → story integration → playtesting) keeps solo projects from unraveling The hardest bottleneck isn’t code or art — it’s feedback. Over 1000 views on his playtest requests, zero people actually opened the project An entity system rewrite cut resource usage while supporting more NPCs, teaching the lesson that sometimes rebuilding is faster than retrofitting Tool affordability is a binding constraint: “If I can afford them, I’ll use them. It’s an affordability issue.” Self-doubt is constant: “I do not feel as skilled as I think I am sometimes” The lessons section is the most directly useful part — earned observations from shipping, not theory: ...

StraySpark Studio’s GDC 2026 recap is framed by one number: 52% of game developers now say generative AI is negatively impacting the industry — up from 30% in 2025 and 18% in 2024. The post filters every announcement through the lens of what’s actually useful for indie developers on a budget. The survey data tells a more interesting story than the headline numbers: 81% of AI-using developers rely on it for research and brainstorming 47% use it for code assistance and 47% for email writing Only 19% use it for asset generation and just 5% for player-facing features AI has been quietly absorbed into background work while the flashy use cases remain niche The big announcements get honest assessments: ...

A r/gamedev essay from a self-described AI skeptic argues the AI-in-gamedev question is not black and white. He concedes generative tools produce new compositions but not new ideas — then draws a sharp line between where AI is a liability and where it genuinely helps. The line he draws: Art, sound, and writing are a non-starter — derivative work is “creatively bankrupt,” and if the legal consensus lands on LLM output as derivative, it becomes a liability for any studio. The “AI is inevitable” framing is wrong — the future is set by present actions, and community pushback matters. The one genuinely exciting use case: a reactive story truly personalized to each player. Code is the gray area — copying code has always been normal (Stack Overflow, similar implementations everywhere), so AI-assisted code is less of a philosophical problem. His position evolved: older models couldn’t reliably produce working code; current ones implement well-described features in one or two passes. AI code is “average at best,” but shipping beats elegance — Undertale’s famously messy code powered a very successful game. The essay’s sharpest distinction: derivative art is a legal and creative liability, while average code that ships is a productivity win. The author offers no general answer for where the line sits — but argues dismissing AI entirely is as short-sighted as evangelizing it. The thread’s top commenters add a useful counterweight: the economic and environmental costs, and the risk of problem-solving muscles atrophying for developers who never learn the underlying craft.

A Reddit post from user sharkymcstevenson2 demonstrates what “long horizon thinking” looks like in practice for AI-assisted game development. A single base prompt, one extended reasoning pass on the tesana engine, and a playable two-player boss-rush platformer emerged — without a single pre-existing asset or visual reference used as input. The actual prompt — shared in comments after prodding — is notable for its specificity and ambition: “Build a 2D platformer-inspired boss-rush shooter utilizing state-of-the-art procedural graphics… featuring 1930s rubber-hose style procedurally generated animations, multi-stage boss phases, frame-perfect hitboxes, fluid parry mechanics, procedural ink-and-paint textures, and authentic vintage jazz audio integration.” ...