Gamedev

An r/aigamedev thread argues that most AI games are slop for an entirely human reason: the tools got easy, but the design work didn’t. At ~85 upvotes, it turns into a real argument about what separates a game from slop — and nobody blames the AI. The OP’s core claim: The problem isn’t that AI is bad or that the games look bad — it’s a lack of ideas and originality The more accessible a tool gets, the more people assume the thing is easy: “AI makes games? So now it’s super easy to make my own game. Right?” Result: people try to go from A to Z and skip every step between — no idea, no story, no substance The pushback is what makes the thread worth reading. Nobody defends the slop; they just disagree on the diagnosis: ...

Wasin Thonkaew (haxpor) looks back on CatAstroFree, his Ludum Dare 27 entry: a 72-hour jam built by 4 people in two countries who had never worked together, in an engine (Unity) the lead was using for the first time. The theme was “10 Seconds,” which became a falling cat with nine lives and a slow-motion ghost trick. The team finished 7 of 10 planned levels and scored best on humor — on purpose. ...

A r/gamedev thread asked whether solo devs feel discouraged by the volume of AI-generated games in their feeds. The answer, at ~260 upvotes, was a familiar mix: yes, the noise is real — but the flood is mostly a discoverability problem, not a quality one. The core argument from the OP: Standing out was already hard; AI posts and ads now bury human-made games 10x more effectively Most AI games are “obvious trash,” but trash still drowns out signal Communities are less useful — a hidden gem now means finding a human post about a human game The thread’s counterpoints are the useful part: ...

A write-up of designer Brian Cronin’s GDC 2026 talk, “Playtesting Process for Ultra Small Teams.” His case: the format every team should use is one designer, one playtester, and a live video call on a running build. It costs nothing, and it answers the questions surveys cannot. Why the format wins: The setup — a synchronous call, the designer runs the build, primes the tester for useful feedback, and notes pain points, confusion, and emotional reactions as they happen It’s effectively free — no tooling, no recruiting pipeline, no budget: just one hour of the designer’s attention Emotional impact is the superpower — watching someone play and hearing the “little subtle things” and body language is the best way to tell whether the game is having the impact you want The core premise — “Devs are bad at knowing if their game is fun, often… Things that I think are super obvious are not!” Patterns repeat — run enough sessions and the same confusion keeps surfacing: “It’s never a them problem, it’s always a me problem” Testers become community — about 70% of the Discord for his current game are playtesters, and some keep coming back to play more Process the feedback systematically — a tracking spreadsheet, prioritized action items, and actually shipping the high-level fixes; a few good sessions alone change nothing Respect the gift — “Time and attention are the most valuable resource on earth right now,” so acknowledge testers up front, avoid defensive language, and prime them for honest answers The takeaway scales down to a solo dev: the cost is an hour of your time, and the return is ground truth on whether the game is fun and understandable — plus, handled well, the start of a community.

RUSuper’s week-four update on the fully AI-built fishing game is mostly polish and infrastructure. The interesting part is where the effort actually went: not generating more content, but redoing AI output by hand — and paying the token bill for judgment work. The week in bullets: Toolchain and cost, four weeks in — Godot for the game; Claude Code in Blender via MCP plus Tripo 3D for models; $300 total spent ($200 Claude Max plan, ~$30 image generation, $12 StableAudio, ~$15 Tripo 3D) Feedback drove the biggest rework — a comment on last week’s thread (houses facing the wrong way in Harbour) triggered a from-scratch rebuild: the harbour is now a real 3D Blender scene instead of a ChatGPT-generated image, positioned by hand. “Maybe it doesn’t look as fancy, but it is authentic.” Custom in-scene editor — to place objects properly he built an editor that picks any 3D object in a scene, moves/rotates/scales it, and saves the position. No more overlapping houses. Water is the token sink — the shader looks wrong around islands at golden hour, dawn, and night, “like it was emitting particles from islands itself.” Removing the offending pass would ruin the deep-water look he likes, so he is tuning it — and “it is eating most of my tokens.” Also this week — a new landmass, UI polish, buggy graphic options, and a loading screen that shows real world-load progress instead of looking frozen Community flags — fishing mechanics aren’t readable from the video (“may mean there’s not enough feedback there for the user too”), and the title screen still shows GPT-image artifacts The pattern keeps repeating across this series: AI generates, human composes. The week’s best improvements came from the human redoing AI output — layout, positioning, camera — and the costs concentrate where AI output needs taste. Four weeks in, a full-AI solo project runs about $300 in tools, with Claude eating most of it.

A solo dev built Nelly Jellies with Codex over about six months, a few hours a week. Six months ago 174 people played it. Last month more than 16,000 did — without a storefront push. The strategy is a distribution funnel: Only the free browser version ever gets shared — click and play, no download, no account The native app carries the monetization: rewarded ads plus a Jelly Pro unlock with extra bonuses Browser players who enjoy it self-select into the app; the web build acts as the demo Growth comes from re-sharing the link as updates accumulate, not a one-time launch spike The numbers, stated plainly in the comments: ...

Invoke Studios is making Warlock, a D&D-adjacent single-player action-adventure, and creative lead Jeff Hattem says the heart they are preserving is not monsters, dungeons, or a found party — it is “ultimate player agency.” Since a linear narrative cannot offer boundless choice, the team concentrates all of it into one deep, systemic magic system. The design moves that make it work: The D&D distillation: ask what the game is really about instead of listing features — “it would have been a trap to try and do everything” A systemic magic system: spells interact with environment, weather, monsters, and terrain, which “really forced us to change the way we make the game” Bug-to-feature playtesting: a tester daisy-chained an eldritch-tentacle spell to reach areas the designers never envisioned — instead of nerfing it, Invoke turned those spots into secret treasure troves Opt-in lore: stop overexposing players to worldbuilding; build readable, optional systems instead of forced cinematics and companion banter Iterate from the shit version: Hattem’s rule after 25 years is that you “always fuck it up somehow” on the first try — set a vague destination and iterate The reusable lesson is the playtest philosophy: when a player breaks your system, that is a design signal, not a bug report — reward the emergent move instead of patching it away. And the scoping move is a good template for any design: pick the one system you can go deep on rather than trying to be everything.

A junior game programmer with a five-year degree landed a freelance gig in their dream field — then two new devs pushed AI hard “for the sake of going fast.” Architecture, systems, and docs are all AI-written, and the breaking point was a submit of 300+ files, some over a thousand lines. The OP avoids AI to actually learn, gets told they are “too slow,” and is weighing a move to better-paying non-game programming. ...

Carl Berglund’s 2017 dev blog documents the first AI for a nameless 2.5D plane shooter in Unity — a modern take on Sopwith and Triplane Turmoil. After scrapping multiplayer, the team lost its dogfight test loop, so they sat down to build a simple enemy AI. Behavior trees were tempting, but a Finite State Machine was the right scope for iteration one. Their process, best done in this order: Identify the states — Follow a unit, Pursue an enemy, Avoid ground, Patrol an area. Conceptualize features as behaviors with variable effort, plus how to start, stop, pause, and resume them. Define transitions before any logic — write entry and exit conditions for every state first, so the machine stays finite and nothing gets stuck. Doing this with a second person covers more angles. Manage flow with priority — a switch loop in the update handles all states; “Avoid ground” (Darwinism) overrides everything and cannot exit until the plane is out of harm’s way. One rule prevents circular states. The pursuit state shows the pattern: trigger on the player entering the enemy’s sphere of awareness (or on being hit), chase by minimizing the delta angle, fire when close — and exit to Darwinism, a squadron takeover, or death. ...

A solo indie dev posted a goodbye note to the AI-in-gamedev argument after OpenAI announced it is shutting down the image model his game Fusiomon is built around. The mechanic — fuse any two monsters into a new one on the fly, then fuse the results again — only became buildable for him with generative image AI. When he posted about the shutdown, r/gamedev’s replies went straight to “AI slop” and “hire an artist” instead of engaging with the game. ...

An r/aigamedev thread (99 points) reacts to the comment section of an anti-AI gamedev YouTube video — the familiar “AI games will never be good, AI devs have no taste or passion” story. The OP’s counter: most people who call themselves game devs never ship a game and never will, so why does the industry hate on something that increases velocity in a space where most games never ship? The replies carry the real substance: ...

A 10-year game dev, a year into AI-assisted development, posts a reality check: 8+ months into an AI-coded farming sim he has no playable demo and barely any screenshots — but has finished a huge amount of infrastructure underneath. The thread (140 points, 50+ comments) settles on a shared pattern: generation is the fast part, deciding is the slow part. “Oneshotting with AI just means you’re getting AI slop. Game dev is about decisions, art direction and design, and the AI is definitely useful, but it doesn’t replace your vision” “The fastest part is often generating something. The slow part is deciding if it actually belongs in the game, testing it, breaking it, rebuilding it” — an 18-month solo dev Iteration is the real bottleneck: one system through 5 redesigns, a UI screen through ~10 before it was “decent enough”; brainstorming with AI yields “12 ideas to reject and 1 idea that’s kind of shaped right” The invisible work dominates: NPC pathfinding, schedules, dialogue, animation (“AI cannot make my animations”); pure code systems are a minute, anything needing visual input is not “The AI is a code machinegun. It is not a UI/UX guru. It is not a balance guru. It is not a modularity guru” Infrastructure-first development — databases, admin tools, refactors — is “the hard and invisible part,” not flashy enough for Twitter but essential; “don’t create games, create systems” The counterpoint got voiced too: industry makes a playable prototype first thing even without AI, so eight months without one reads as a red flag (“smells like cope”) “AI slop” has collapsed into “I think this looks like low effort” — the same accusation that used to be shovelware or asset flip, now aimed even at pre-AI games The useful mental model: AI compresses implementation, not judgment. The constraint that used to be “writing the code takes forever” has moved to “deciding what to build and making it coherent takes forever” — which is exactly where the human work lives. ...

Fingle was Game Oven’s first commercial game: a two-player iPad title where you and a partner drag your fingers across the screen to solve touch-puzzle levels, hands inevitably interlacing. Designer Adriaan de Jongh and programmer Bojan Endrovski built it in five months on a €2,000 budget, and it won the Dutch Game Award for Best Mobile and Best Casual game. This postmortem (originally published 2013) is a compact lesson in making an interaction — not a genre — the entire identity of a game. ...

A laid-off software developer, two years into a failed job search, found the joy again in Unreal Engine — then started worrying that AI would hollow out game dev the way it hollowed out web development for him. The post is honest about the fear: a CS master’s, years of experience, and a career that now feels like “babysitting AI” while people with no technical background ship full-stack apps by prompting. ...

David Hellman joined Braid as its visual artist in the summer of 2006 — after the game had appeared at two GDCs and won a design award. Gameplay was nearly finished; the visuals were still utilitarian blocks, spikes, and ladders. The level-intro prose, musing on regret, relationships, and temporal paradoxes, made clear the game wanted a real identity. The process distilled into a few rules: The brief was to present mechanics clearly and carry a non-literal story — “part anecdote, part artifice, part philosophy.” World 2 introduces the rewind mechanic, where any mistake can be erased, so its art had to convey forgiveness and positivity: brown rocks, a blue sky, an optimistic start. The rule that shaped everything: no visual interest contrary to gameplay. A background arch made the cliff appear to continue off-screen, fighting the player’s perception of the actual geometry — it was cut. Visual interest earns its place only when it reinforces what is true to the gameplay. The lesson outlives the era: when art and readability collide, readability wins — especially in a game where the mechanic is the message. Braid’s painterly look came from iterative passes and disciplined cuts, not a top-down art bible.

Glauber Kotaki was the single contracted artist for Cellar Door Games’ Rogue Legacy. In this 2013 postmortem he explains how a 15-hour roguelite shipped on an art package he delivered over one year — and why fresh design, not asset count, is what carries a small team. His techniques, in brief: Layered body-part animation — each armor piece is its own layer group, so animation comes from repositioning layers instead of drawing new frames, and revising an animation is just pushing layers around. Tinting instead of redrawing — one armor design, partially tinted per piece, yields multiple armor sets; class details, skin tones, gender swaps, and stronger enemy tiers all come from color math rather than new art. Homogeneous art direction — a second artist’s full-resolution environments clashed with the pixel knight, so Kotaki took over backgrounds and built each area from tilesets of essentially three tiles (background, foreground, floor). Shared props — tables, chairs, and bookcases are one entity reused across areas with different sprites and collision boxes. Retro is cheap in every sense — double/triple-sized pixel art resized in code is one of the most accessible styles, which is why almost everyone who commissions pixel art is an indie dev. He’s also honest about what got cut: a three-hit combo became one heavy swing, wizards were meant to teleport, and several enemies died because enemy behavior is tightly coupled to how foes pair in a room. ...

Matt Allmer (EA, Page 44 Studios) was frustrated by game-design writing that was either too broad or too obvious — so he did what the industry does best and borrowed from Disney. He re-imagined the 12 Principles of Animation for gameplay and added a 13th, framing the list as a reference sheet to cover your bases before presenting a design. The principles group into six compartments: Direction — 1. Focal Point: never let the player guess what to focus on. 2. Anticipation: always factor in time to signal something is about to happen. 3. Announce Change: communicate changes, scaled to rarity — a cue needed five times per game is worth far more than one needed a hundred times an hour. Behavior — 4. Believable Events: every action and reaction must pass the player’s subconscious acceptance test. 5. Overlapping Events: dynamism dies when only one thing happens at a time. 6. Physics: start from known physical logic, don’t be limited by it. 7. Sound: “what sound does it make when ___ happens?” Progression — 8. Pacing: spread out moments of high concentration and mix the sense of urgency. Environment — 9. Spacing: understand on-screen and in-world space and the relationships between elements. Method — 10. Linear Design vs Component Breakdown: solving challenges as they come versus systemic categorization — pre-production favors breakdown, late publisher changes favor linear. Foundation — 11. Player: if the player isn’t into it, change or scrap it. 12. Communication: an idea you can’t communicate correctly might as well be a bad idea. 13. Appeal: does it draw in the player, the spectator, and your fellow developers? The strength is the execution, not the novelty: every principle gets worked examples across level design, system design, UI, and story, which makes it a self-review checklist rather than another theory of fun. The stated goal — an anchor that tells you which rules you can safely break — is the right way to use any design framework.

While building his own shmup, Michael Molinari spent years reverse-engineering why commercial shoot-em-ups feel fair and why so many free and indie ones don’t. The result is a checklist for scrolling and arena shooters, and nearly every rule reduces to one idea: the player must always be able to read what is dangerous, what is hittable, and what is coming. The rules that matter most: Enemy bullets must always be visible — on top of explosions, pickups, and enemies. Hidden bullets mean unearned deaths, and the only sanctioned hiding place is the HUD. Off-screen enemies shouldn’t shoot, and bosses must be telegraphed — a warning, a siren, or a lull in enemies so the stakes register before the fight. Bullet collision should be accurate, and a small hitbox must be visibly obvious — players need their sweet spot readable in the few frames they have. High bullet/background contrast — Cave’s signature pink-and-blue bullet palette is a deliberate legibility choice. Hit feedback is non-negotiable: enemies flicker or spark when shot, everything destroyed explodes, and boss explosions should be a spectacle. Levels need flow — structure that forces you to zig and zag, with “popcorn” enemies filling the gaps and making the player feel powerful. There is always a way out — a bomb or invincibility move, and bullet patterns designed so an escape route exists (the craft known as bullet herding). Camera shake is a privilege, not a right — overuse adds noise and dulls the effect. Molinari closes by naming free shmups that get it right — Arcanacra, Cube Colossus, Death vs. Monstars, Heavy Weapons — so the checklist reads as observed practice, not armchair theory. His final warning is the most transferable: even a single out-of-place sound effect can ruin the whole experience.

Forbidden Solitaire — a 90s-analog-horror spin on the card game — sold 10,000 copies in 48 hours and peaked at 880 concurrent Steam players. That dwarfs Grey Alien Games’ earlier solitaire titles, which peaked at 98 and 20 concurrent. The seventeenth game from a studio that “shouldn’t” have a Steam hit in this genre, it’s a case study in the proven-formula-plus-twist playbook. What made it work: Tri-peaks/golf ruleset instead of Klondike — fast, arcade-y, combo-friendly (“you tidy up, you clear the layout”) A combat system refined across Regency Solitaire → Shadowhand → Ancient Enemy; Forbidden Solitaire is “the best iteration of that combat system” A teaser trailer went viral before any gameplay existed — 7,000 wishlists overnight Co-developer Night Signal’s cult following (Home Safety Hotline) tried it for the vibe; the solitaire loop made them stay Data-driven positioning: horror sells on Steam, so a horror solitaire “can’t sell worse than Regency Solitaire 3” The studio is candid about the tradeoff: success has “cemented” them as a solitaire studio — a safe bet that funds the next game, but a hard niche to escape. ...

Stone Librande’s 2013 GDC talk “Simulating a City, One Page at a Time” chronicles an experiment: run the entire SimCity (2013) design — pre-production to ship — using only one-page documents. He expected it to fail; he wanted to find out why. It mostly worked. The one-page paradigm: Replace “design bible” docs with a single page of diagrams, printed and displayed physically to build team buy-in Forces clarity early — messy multiplayer trading mechanics were cut before resources were wasted on them Even spreadsheets got the treatment: consolidated, color-coded charts posted around the office The “design fairy” habit: “don’t rely on people to come to you… if you really have something important to say to your team, you need to get it to them” Failures counted too: bespoke printed magnets were delightful but time-intensive; a card game was “too cute” to work The payoff was longevity. In postmortems years later, diagrams from 3.5 years earlier were still valid and in active use. ...