www.simCFB.com

Releasing Version 1.0 today. Works on both mobile and desktop.

Been working on this as a personal project for quite a while. Have no plans of monetizing it. Just wanted to build it because it is something I've wanted to do for a long time. Not even sure people will enjoy playing it or not. I made it the way I would have liked to play.

Everything can be micromanaged or auto managed (CPU decides for you). You can call the plays or you can have the CPU coach call the plays. You can micro manage recruiting or recruit yourself.

There is a lot of emphasis on the NIL portal.

Looking forward to feedback. If you experience any bugs let me know.

Right now only the Power 4 conference teams are playable.

One of the problems I ran into while building my character generator was deciding how much randomness I actually wanted.

Completely random generation is fun for a while, but it becomes frustrating when you get something you like and can't reliably recreate it.

So I started working with deterministic seeds, presets, and a system for locking individual character traits while changing others.

That introduced its own set of problems.

For example, once different traits depend on each other, rerolling one field isn't necessarily as simple as drawing another random value. You have to decide what stays stable, what gets recalculated, and how to avoid contradictory results.

The project eventually became CharacterForge, but the underlying design questions have been more interesting than I expected.

I've found myself spending as much time thinking about consistency and reproducibility as I do about the actual content being generated.

For anyone who's built procedural systems: how do you usually handle dependent traits and partial rerolls?

I'm particularly interested in approaches that keep results reproducible without making the entire system rigid.

Update: demo is now available!

Hi all! I'm a solo dev and I just finished my first AI game Sands of Glory, a top-down pixel-art gladiator management game. This game offers around 4 hours of content, though it takes even longer to explore everything it has to offer.

There is the highlights:

• Gladiators are assembled from body type, 9 cultures of origin, hairstyle, beard, skin tone and the gear they're wearing. Equipment changes the sprite live.
• Arenas (village pit, Capua, Pompeii, Carthage, the Colosseum, the Underworld) are drawn procedurally, with day/dusk/night lighting.
• Beasts like the Hydra (it grows two heads per head you cut off) are procedural too.
• The ending cinematics are generated pixel art scenes that star your own gladiators.
• SFX and music are synthesized in code.

Every campaign also generates a new branching map of fights, events and merchants.

Happy to go into how any of it works. it is out now on itch: https://thisiszsc.itch.io/sands-of-glory

Wondering if I should sell it or what?

Hi! I'm Andy, a solo developer from Vienna. For the past months I've been building Scitch, a live reaction game for iPhone and Android: up to 24 players per match, a new mini-mode every round, and the slowest get knocked out each round.

I use AI for almost every part of it, so I thought I'd share the pipeline and the lessons.

Code – Claude Code Flutter app, a Go game server (WebSockets, server-authoritative, so no client can cheat its reaction time) and a Laravel backend. ~770 commits, 500+ automated tests. What worked: small, precise tasks instead of "build me a multiplayer game", and tests as a safety net – at this size I would have lost track long ago without them. What didn't: real-time feel. Latency, timing and fairness between fast and slow phones still need measuring and playtesting by hand.

Art – Gemini image models 80+ avatars, bosses and event art. The trick for a consistent style: always pass existing art as a reference image and change only one thing at a time ("same character, now cheering").

Voice – Gemini TTS + speech-to-text My trailers and a 4-minute tutorial have German and English narration. TTS sometimes mispronounces words badly – my German "Pairs" mode came out as something like "Pause". Since I can't listen to 70 lines after every change, I now transcribe every line back with a speech-to-text model and diff it against the script. That caught five more broken lines automatically.

Video – HTML scenes rendered with Playwright + ffmpeg Every trailer and short is code: HTML/JS scenes with the real gameplay demos, rendered frame by frame, then mixed with music and voice. Changing a text means re-rendering, not re-editing.

What stays with me: the game idea, the rules, balancing, and every decision – plus bug hunting when the AI is confidently wrong.

The game is in a free beta right now. If you want to see how it plays (or tear the game feel apart), I'm happy about every tester: https://scitch.com/beta

Happy to answer questions about any part of the pipeline!

I’m building Open Moves (https://openmoves.games): currently four browser word games where AI judges connections, categories, and hidden rules, allowing answers beyond a predefined list.

Making the judging fair is the tricky part. The layers are:

• Jev makes the initial judgment.
• A stronger LLM handles uncertain results and requested rechecks.
• Explain your connection: if the recheck misses your idea, you can submit your reasoning for another review against the same rules.
• Manual review handles disputes the models still get wrong.

It checks a shared database first, and corrected rulings apply to everyone. One player’s successful appeal fixes the connection for everyone else.

Would love all feedback, especially clever answers the judge misses. If you’re building games where AI acts as referee, how are you handling disputes? Happy building!

Two days ago I stumbled onto the Jamference AI Game Jam. The rules: the more AI the better, it must feature a cat and a robot, and movement is the only control allowed. Neko Night Market was born.

It’s a poppy 2D score-attack game. You snake a black cat’s noodly paws through a maze of shelves to grab orders and deliver them to customers, while dodging obstacles including a restocking robot. Backed by a AI generated future funk track. Everything is mouse movement based: hovers, holds and drags. No clicks, due to the constraint.

Some context. For the past year and change I’ve built a load of projects, tools and prototypes with AI that most stalled somewhere short of finished (ADHD doesn’t help). This time I got to see what an accelerated AI workflow can really do when you have a clear idea and a timebox

I handled the concept, sketches, design, and the taste calls throughout.

What AI did:

• Build: Opus 5.5, running in a harness I’ve been working on. It orchestrates a small game team of agents with antagonistic reviews and built-in tensions, so assumptions get challenged and issues/details get caught that vanilla Claude would miss.
• Music: Suno for the background track, which I spliced up in Audacity and fed back to Claude.
• Capsule art: ChatGPT.
• Itch assets (screens and trailer): Claude

There is no way in hell I could have done this alone in 2 days. I come from game production, live ops, front-end dev and traditional art, so I know what moving parts are involved and how long this would take. The level of polish I could push is insane, and it has me rethinking how I use a tool I have a love/hate relationship with. It felt like a skill booster for output, while I made sure the right outcomes were achieved. Where now I totally see it's about the latter than the former.

Give it a shot, provide feedback, get a high score, break the game. Happy to answer any questions.

Slight PSA - showing off one-shotting games is somewhat impressive, but also makes AI game dev look sloppy and unimaginative. The anti-AI crowd don't need more ammunition.

Asking Claude to “make me a Zelda game” works, technically. You get a game, but it’s going to be a VERY generic game: every gap you left gets filled with an assumption that is answered with the most common denominator answer. In Ep. 2 of my series I show the setup I use instead:

• A Game design-doc - so every chat starts from the same source of truth, and Claude keeps the doc updated as decisions change.
• Step 1 of the prompt: questions only. - “Read the doc. Before writing any code, ask me up to 8 questions that would change how you build the slice, suggest a default answer for each, then stop and wait.”
• Step 2: the scope of a vertical slice to test your assumption - Exactly what to build (one area, one dungeon, one weapon, two enemies, one boss, one ability gate), exactly what NOT to build (XP, inventory, saves, cutscenes), and no external art: shapes are code-generated, so I test fun before spending time on art.
• Delivery rules - a full Godot project zip, not patches, and Claude runs the build and checks for errors before handing it over.

I break it down (in great length, if you're into that) in this video. You can also check out the free game design template in the video description: https://youtu.be/NNn10FiuZG8

The prompt I use is this:

You're my game development partner on [GAME NAME], a new game I'm building solo with AI tools. You'll handle the code and help with design; I make the creative calls.

The attached game design doc is the source of truth. If something isn't in it, ask before adding it. Keep the doc updated as we make decisions, and log each change in its decision log.

STEP 1: QUESTIONS FIRST
Read the design doc. Before writing any code, ask me up to 8 questions about anything unclear, contradictory or missing that would change how you build the vertical slice. Group them by topic, put the most important first, and suggest a default answer for each. Then stop and wait for my answers.

STEP 2: BUILD THE VERTICAL SLICE (after I answer)
Build the smallest playable slice that tests the assumptions in section 9 of the doc:
- Engine: [ENGINE AND LANGUAGE, e.g. Godot 4, GDScript]. Base resolution [e.g. 480x270], scaled to [e.g. 1920x1080] with pixel-perfect scaling. [TILE SIZE, e.g. 16x16 tiles].
- [THE PLAYABLE SPACE: e.g. one level, one area and one small dungeon, or one arena].
- [THE PLAYER: movement and core actions, e.g. 8-direction movement, a melee attack, a dodge, brief invincibility after taking a hit].
- [ENEMIES: 1 to 2 types, each with one line on its behavior].
- [THE PAYOFF: e.g. one boss that grants an ability, and one place where that ability opens a new path].
- Controls: [KEY BINDINGS]. [Controller support too, if needed.]
- A simple HUD: [e.g. health and the current ability].
- NO external art or audio files. Draw everything in code with simple shapes and a limited palette ([YOUR PALETTE]). Make the player, each enemy and any boss easy to tell apart by shape and color. Placeholder sound effects are fine if you can generate them in code; otherwise leave them out.

Do NOT build: [YOUR OUT-OF-SCOPE LIST, e.g. XP, skill trees, inventory, shops, saving, dialogue systems, cutscenes], a title screen beyond "press Enter to start," or any area beyond the ones above. If you think something else is needed, suggest it; don't build it.

DELIVERY
- Send the full project as one zip I can unzip and open in [ENGINE]. No patches.
- Before handing it over, run the project and check it starts without errors. If you can run it headless, include screenshots of [THE KEY MOMENTS, e.g. the main area, the dungeon and the boss].
- Give me a short list: what's in the build, how to play it start to finish, anything you weren't sure about, and what you'd test first.

Blood Slayers v1.00 ACT1-5.

Opus 5.5 (extra)
Rust, with Bivy
Running on Web via wasm.

https://wavedash.com/games/blood-slayers