spent 100s of hours working on this project, 15 hour days, 7 days a week, i used some 2d art assets as a starting point. i get called Ai Slop. i look at my own work and feel like quitting. I really hope people wake up and see what can be done with Ai

https://store.steampowered.com/app/5041990/Project_September/

Hello there,

This is week 3 of me making a fishing game entirely with AI. If somebody is interested in seeing Claude Artifacts with latest changes here is Artifact 1 and Artifact 2. There are before and after images of how it's done.

My Workflow - it improved from just typing what I want in Week 1 to basically having a window dedicated for every single thing and using MCPs for Blender and Godot now. Since last time I added a lot of things, did some graphic overhaul and added real 3D models.

As for my Workflow:

1. I generate the reference. ChatGPT using OpenAI Playground for concept art and the fishing structure, the refit chart mockup, the SkillTree background. This is where the look gets decided, by me, visually (Without human eye AI will just make stuff not fit together I feel like).

2. I change that reference into geometry. I tried using the 3D generator (Rodin) but honestly it gets complicated mesh results that will require a lot of cleanup, so I just started using MCP for Blender, I made a dedicated Blender session that writes 3D models.  That's better than generated models: the script is the source, so proportions stay editable and a family stays a family. They are also just what I need for my game as from camera distance models are not required to be detailed which is exactly where AI with MCP for blender is good - generating simple low poly models.

3. A different session integrates. Placement, waterline, scale, wiring. Deliberately not the modelling session, I have session for almost everything and they all do their own thing with one session being general chat window that can on command send message to other sessions telling them what I want them to do.

4. Screenshots are the referee. Everything gets rendered from the actual in-game camera, and nothing counts until I looked at it. This is exactly how I just wasted a chunk of time: a session added four new islands, checked them from directly overhead, and they looked fine. In game they were flat sandy pancakes floating on the water. From above, a pancake looks perfect.

5. Criticism, with actual scores. For the big graphics pass we (claude actually with my guidance) wrote the scoring criteria before changing anything, scored twelve things out of ten, and only shipped at 8+. One critic reviewed screenshots without being told which version was newer. That's what stops "I changed loads, so it must be better."

6. Every decision gets written down with who decided it. Tagged either "I decided this (so claude tags it with USER" or "an AI suggested this." Because an upgrade nobody ever proposed once sat in my design docs for days and got quoted back at me like it was my own idea I was like "wtf I never said I wanted this, you are hallucinating bro"

The short version: AI does the work, I'm the art director, and I'm the only human in the loop with sometimes my friends being nice enough to test play it hehe.

Anyway a lot of work was put into this and not sure how much more is needed before I have starting area done and have a playable demo, I feel like the more I do the more is left to be done before it gets to a point somebody can test play it. But I guess there is some progress?

If somebody is interested here are Week 1 Progress and Week 2 Progress.

Any feedback is appreciated ☺️

Hi!
I used to develop flash games way back in the old flash gaming days, when it all died I got a job as a software engineer and stopped, this new Vibe coding and AI assisted game development situation really got me interested in seeing how far I could push it.
This game was created without me touching a single line of code, not even a config myself, if I knew what the problem was I explained it so that the agent would learn and remember. What I did do was hold my agent's hands through the process, design the systems and explain how I wanted them implemented.
I'd never created an action game before and I felt like an extraction/Survivors type game could be a bunch of fun, all sorts of POIs to explore and loot to find and extract with to re-equip and try and push further.
In total it took about a month, I'm currently working on a premium steam version using the same techniques which has taken about 3 months so far but is head and shoulder above this one, it might as well be a prototype.

I'm really happy with the results though and am pursuing a bunch more ideas, but felt this was a good one to share. It's up over on Crazy Games now: https://www.crazygames.com/game/salvage-corps-fuz

I've been making an incremental game about the trolley problem for about a month. Almost everything is made with AI.

I mostly use Claude and Codex, both on the $200 plans.

One subscription wasn't enough for me because I kept hitting the limits. Claude + Codex together is enough for almost all of the work.

Claude does most of the programming. It also made the design system and builds the UI.

The game runs on my own C engine, also made with AI. The engine took about 5 months. The game itself has taken 1 month so far.

Codex does most of the visual work:

UI icons

3D models

art

short videos

For 3D, I tried a few AI 3D generators, but I didn't like the results. The models often looked soft and plastic.

Now I use Codex with Blender instead. I tell it what I need, it works in Blender, renders it, and I give feedback. It takes longer, but the result is much better.

Codex also made this trailer. It wrote bots to play the game, recorded the gameplay, and edited the video. I only gave feedback and asked for changes.

For development, AI is already very good.

I'm also trying to use AI for marketing and content. Marketing is still much harder.

Here is the Steam page. I hope to finish the game this year:

https://store.steampowered.com/app/4654990/Not\_a\_Trolley\_Problem/

The game is called "Express 404" and initially it was a test of the AI pipeline for me, I had an idea of catching a mimic-monster among passengers while you're driving a train in the night.

I have about 10 years of gamedev experience but I was really curious about AI and its using in the development process. So far I can say that it definitely boosted the process a lot. I can't say that it was easy (it wasn't at all) but it's really impressive how powerful AI tools can be and how significantly they change the flow.

I created the code base by myself initially, then I used ChatGPT to analyze the structure and expend it with a lot of details. I checked every change it did and I should say that it was pretty good in terms of the code quality.

For art I used Gemini + ChatGPT, it's obviously a weak side of many AI-assisted games, the first arts were absolutely terrible. They are still pretty terrible I know lol but at least after many additional iterations it looks +- consistent.

I was really impressed by localization - ChatGPT localized the whole project into 7 more languages just in like a couple of hours.

I created a page on Steam with really terrible placeholders and without having any builds at all. Then I did many iterations on it in terms of game design, art, balance. I added localization for 8 languages.

Currently it has ~1050 wishlists on Steam, probably I'll create a more detailed post about this release and the results later.

EDIT: Registration does not require an email. It can be added later in the game settings to enable the forgotten password feature

Lythravel is a 3D voxel MMORPG that runs in a browser tab. It went live yesterday, it's free, and I didn't write the code. Claude Code did, over about six weeks of daily sessions.

Three things kept a project this size from turning to mush:

One design doc in the repo that every session reads before it touches anything. When a session and the doc disagree, the doc wins. Otherwise session 40 quietly reinvents what session 12 already decided.

Every architectural call written down as a numbered file - 194 so far. The model has no memory of yesterday, but it reads. The repo has to be the memory.

Nothing is done until a bot proves it. Scripted clients connect over the real network protocol and play: levelling 1 to 50, a 20-bot PvP match, six bots clearing a dungeon. They print PASS or FAIL. "The code looks right" is worth nothing when you didn't write the code.

Where it consistently failed was anything you judge with your eyes. The world ran at 20 FPS for weeks because animating one Babylon scene setting broadcasts an update that marks every material dirty, so the whole scene re-evaluated every frame. Nothing in the code looked wrong. You only catch that by playing it.

Six classes, two continents, levels 1-50, dungeons, a 12-player raid, world bosses, 10v10 battlegrounds. Desktop browser, no download, no launcher.

https://lythravel.com

It's brand new so the world is quiet — the Discord is where we agree when to actually play: https://discord.gg/SdJrn5WPBQ

Come and have a look around — I'm in there most days, and I'll come over and say hi.

https://preview.redd.it/rqdiebzlajjh1.png?width=2560&format=png&auto=webp&s=c573ddd3c5439f0db2e707bfe5361decb73c89cd

A few days ago I posted my little browser bike game here and got a ton of feedback — both positive and brutal, haha.

So I kept working on it.

It now has a story mode, bike progression and upgrades, new obstacles, jumping, improved visuals, and even an AI-generated radio.

The funny part is that I still have basically zero programming knowledge and haven’t manually written the code. My whole workflow is still describing what I want, testing it, finding what feels wrong, and repeatedly directing the AI until it works the way I want.

At this point it feels much closer to an actual small game than the original endless-road prototype.

I’m especially curious whether the progression and story mode make it something you’d actually want to keep playing.

Playable Link: https://royal-waterfall-a15e.quietforge.workers.dev/

Echo Frontier started as an experiment in how far I could take AI-assisted development beyond a disposable prototype. I used Codex as an implementation partner while I directed the game design, tested the results, rejected approaches that didn’t work, and kept iterating on the actual gameplay.

The difficult part wasn’t generating an initial scene. It was making all the interconnected RTS systems behave coherently: construction, resource gathering, control groups, production queues, fleet movement, targeting, opponent strategy, warp travel, and performance with large battles. I ended up putting automated coverage around systems such as the economy, opponent behavior, building placement, hotkeys, and control groups so later AI-assisted changes couldn’t silently break earlier mechanics.

AI was also part of the production pipeline. The unit voices, announcer, effects, and music were created through an ElevenLabs pipeline integrated into the Laravel project so assets could be regenerated, compared, and versioned consistently. The trailer was assembled in Remotion from captured gameplay rather than generated footage.

The finished game runs in the browser here:
https://echo-frontier.laravel.cloud/

The biggest lesson for me was that AI accelerated implementation, but keeping a strategy game internally consistent still required a lot of manual direction, testing, play sessions, and iteration. I’d be interested to hear how other people are handling regression testing as their AI-assisted projects become larger.

No 3D generation service involved, no Meshy, no asset store. The geometry is code: three.js, written with the antics-modelkit npm package and sculpted piece by piece with Opus.

The fun of this one was designing a machine from scratch inside a genre instead of copying a ship. Podracing has a vocabulary (twin nacelles on outriggers, a towed one-seat pod, cables under tension, an arc between the engines) and once you have those, everything else is yours: the tail, the nose, the cockpit, the livery.

Particles run on mohamedachrefelouafi's LinearAbiltyCastingThreeJS (MIT)

If you want to use the model in a game you can get the recipe or the glb here for free, or just fly around in the demo: https://antics.gg/m/hover-racer-29b24d

Still experimenting with Claude and different kinds of workflows around game-dev.

This time I did something new, a moon rover game. 95% of this game was from 1 prompt. 3.2m tokens.

0 assets, all procedural generated, even sounds.

There is an open world a.k.a. free survey and also campaign with 5 missions.

Works on PC and mobile. Open-source as well: https://github.com/winchxyz/moon-rover

Also you can test it on a github pages (check repo)

I bought a little midi keyboard to play around with making music and since I have no idea how to make music I got GPT 5.6 Sol to make a Keyboard Hero game for me that hooks up to the keyboard and lets me practice, all within a few hours. What a time to be alive

Hey everyone,

Hope all is well!

TL;DR, Summary, or Full Technical Breakdown below.

For Context: Recently I posted about the first 15 days of one of my side projects, ShuffleBall Arena (a free browser game inspired by mixing shuffleboard scoring with mechanics from other games like bumper pool, pinball, and Frogger.).

This project is being built with the help of AI (mainly GPT / Cursor), and every development session is documented using the actual conversations from that day's work.

To try to get this series up to date, I'm using a structured prompt to go back to my GPT sessions and extract the useful information. Hopefully the prompt can help anyone out there trying to keep track of, or extract value from, your past AI project conversations.

That said, posting an update for Day 27 (part 2) of building ShuffleBall Arena.

===========================================================

TL;DR

Day 27 - Part 1 ended with a rule:

Clients submit intentions. The server calculates results.

Part 2 was about turning that rule into actual infrastructure.

We built the production multiplayer room and networking foundation using Cloudflare Workers, Durable Objects, and WebSockets, including room creation, player seating, authoritative lobby state, disconnect/reconnect handling, protocol versioning, and synchronized snapshots.

Then development moved into the harder problem: extracting the game's physics into a deterministic server-side simulation that could run without the browser.

By the end of the session, the multiplayer networking foundation was complete and the authoritative simulation kernel could deterministically process marble movement, walls, static bumpers, marble-to-marble collisions, settlement, safety recovery, and canonical trajectory recording.

The repository passed its complete test suite, and the next milestone was authoritative scoring.

===========================================================

Day 27 (Part 1) Summary

Part 1 ended with the multiplayer architecture defined.

One server-owned simulation would determine what happened during every match. Browsers would collect player input and render the result, but neither player would be trusted to determine official physics, scoring, collisions, or match state.

Part 2 began turning that architecture into production code.

The first major milestone was the networking foundation. A Cloudflare Worker became the multiplayer entry point, while each match received its own Durable Object responsible for authoritative room state and both WebSocket connections.

Production APIs were built for room creation and connection. From there, the protocol expanded to handle player identity, Red/Blue seating, readiness, room snapshots, disconnects, reconnect tokens, same-seat reconnection, snapshot recovery, and connection lifecycle behavior.

Once that layer was stable, the work moved into the actual server-authoritative game engine.

Instead of copying the existing browser game into the Worker, the physics required for multiplayer was separated into deterministic modules. Fixed-step simulation, collision handling, settlement, immutable state transitions, stable processing order, and trajectory recording were built and regression tested independently.

By the end of the session, the server could calculate a shot once and produce both its canonical final state and the trajectory the clients would eventually use to display that same shot.

The networking foundation was ready. The core physics kernel was essentially ready.

The next layer would be interpreting those physics results through authoritative scoring and match rules.

===========================================================

Day 27 (Part 2) Full Technical Summary (The Structured Prompt Output)

STARTING POINT

Day 27 - Part 2 began exactly where Part 1 ended.

The decision to build online multiplayer had already been made, and the architecture had been deliberately designed before implementation began.

The core rule was: The server owns gameplay reality.

Clients would submit player intentions, but the server would determine physics, collisions, scoring, turns, and final state.

The target architecture had also been established:

Player Input
↓
Multiplayer Client
↓
WebSocket
↓
Match Durable Object
↓
Authoritative Shared Simulation
↓
State Frames and Events
↓
Both Browser Clients
↓
Canvas Rendering

The server would run the official simulation once, and both players would render the same server-produced state.

SESSION OBJECTIVE

The objective was to begin implementing the permanent server-authoritative multiplayer architecture designed in Part 1.

That meant building two major foundations:

1. The networking/lobby layer

The server needed to:

• create rooms,
• connect two players,
• assign seats,
• maintain authoritative room state,
• synchronize clients,
• handle disconnects,
• and support reconnection.

2. The deterministic simulation layer

The server needed to eventually receive a shot, calculate it exactly once, and produce the canonical result that both players would see. The important constraint was that none of this should be throwaway prototype code.

The guiding principle became:

Build the production architecture once. No throwaway scaffolding.

WHAT WE ACTUALLY DID

1. Built the production room API

The first implementation milestone was creating actual multiplayer rooms.

A production endpoint was added:

POST /api/rooms

The room system supported:

• six-character room codes,
• collision checking,
• Durable Object-backed rooms,
• standard JSON responses,
• and structured error handling.

This established the first permanent multiplayer entry point.

2. Built production WebSocket routing

Next came the connection layer.

A production WebSocket route was implemented:

GET /api/rooms/:roomCode/connect

That included:

• room lookup,
• validation,
• WebSocket upgrade enforcement,
• and routing each connection to the correct Durable Object.

Each match would therefore have one authoritative server-side object responsible for the room.

3. Introduced a versioned multiplayer protocol

Before expanding the message system, protocol versioning was established.

Every client/server message would include:

protocolVersion

This gave the multiplayer system an explicit contract and created a path for future protocol changes without silently breaking older clients.

4. Built authoritative player and lobby management

The Durable Object gradually took ownership of the multiplayer lobby.

The server became responsible for:

• player identity,
• room membership,
• Red/Blue seating,
• rejecting a third player,
• readiness,
• authoritative room snapshots,
• and synchronized state distribution.

The important distinction was that even before gameplay existed, the lobby itself was already server-authoritative.

5. Built disconnect and reconnect handling

Real multiplayer also needed to survive unreliable connections.

The networking layer was expanded with:

• private reconnect tokens,
• disconnect handling,
• a reconnect grace period,
• same-seat restoration,
• snapshot requests,
• and versioned ping/pong behavior.

A reconnecting player would not invent or reconstruct room state locally. The server remained authoritative and restored the player into the current canonical room state.

By the completion of this phase, the networking layer was described as no longer experimental, but as a reusable multiplayer backend ready to support the game simulation.

6. Moved from networking into the authoritative match kernel

With the lobby foundation stable, development shifted into Phase 3.

The objective changed from:

Can two players occupy the same authoritative room?

to:

Can the server calculate the game itself?

The implementation deliberately avoided copying the full browser game into the Worker. Networking, match rules, board data, physics, collisions, scoring, serialization, and tests were kept separate. The first target was one production board, with the architecture remaining data-driven enough to support the others later.

7. Built deterministic fixed-step simulation

The browser's frame timing could not control official multiplayer physics.

The server simulation therefore used a fixed timestep:

const SIMULATION_HZ = 60;
const FIXED_DT = 1 / SIMULATION_HZ;

Every authoritative physics update would use the same FIXED_DT rather than relying on requestAnimationFrame() or arbitrary client frame duration.

This was one of the foundations required for deterministic behavior.

8. Built the authoritative collision pipeline

The simulation expanded incrementally rather than attempting to port the entire game at once.

The authoritative pipeline eventually included:

Input validation
↓
Capture initial trajectory frame
↓
Simulation loop
Step marble
↓
Resolve walls
↓
Resolve static bumpers
↓
Wall stabilization
↓
Multi-pass marble convergence
↓
Wall stabilization
↓
Capture trajectory frame
↓
Settlement
↓
Safety recovery
↓
Return
{
marbles,
trajectory
}

This meant the server simulation could now handle not only basic marble motion but interactions between marbles and the environment in a stable, deterministic order.

9. Added deterministic marble-to-marble collisions

Marble collisions required additional work because resolving one collision could push a marble into another. A single collision pass was therefore not enough.

The engine introduced multi-pass convergence so groups of interacting marbles could stabilize deterministically before the simulation advanced.

Regression tests were added specifically for:

• marble collisions,
• collision convergence,
• and complete shot simulations involving multiple marbles.

10. Added canonical trajectory recording

Calculating the correct final state solved only half the multiplayer problem. Both players still needed to see the same shot. Trajectory recording was therefore added directly to the authoritative simulation. Crucially, trajectory data was observational only.

It never influenced:

• positions,
• velocities,
• collision ordering,
• or settlement.

The physics produced the result. Trajectory recording simply captured what happened so clients could eventually replay the canonical shot.

11. Kept the simulation immutable and bounded

Several rules were enforced throughout the simulation work:

Deterministic first

No uncontrolled randomness or unstable processing order.

Immutable simulation

The simulator cloned state before modification rather than mutating caller-owned data.

Bounded execution

Shots could not simulate forever. Safety limits and recovery behavior prevented runaway simulation.

Server authority

Clients would never determine official:

• physics,
• collisions,
• scoring,
• or match state.

12. Built regression tests alongside each milestone

The simulation wasn't treated as complete simply because a marble moved correctly once.

Dedicated tests were added for new physics and trajectory systems, including:

src/simulation/collisions/marbles.js
src/simulation/trajectory.js

test/marble-collisions.test.js
test/marble-collision-convergence.test.js
test/simulate-shot-marble-collisions.test.js
test/trajectory.test.js
test/simulate-shot-trajectory.test.js

Each milestone was tested and committed independently.

ROADBLOCKS AND FRICTION

Existing browser gameplay couldn't simply be moved onto the server

The original game contained responsibilities for gameplay, rendering, UI, analytics, bots, board definitions, challenge logic, input, and other browser-specific behavior.

Copying that entire system into a Worker would have created a second monolithic game implementation.

Instead, only the systems required for authoritative online simulation were extracted.

Determinism affected seemingly small implementation details

Once the server became authoritative, ordinary implementation choices became important. Randomness needed control. Processing order needed stability. Physics couldn't depend on browser frame timing.

Simulation state couldn't contain DOM nodes, canvas contexts, images, audio objects, browser events, timers, or other browser-specific objects.

Marble collisions were more complicated than single-object physics

Resolving a collision between two marbles could create another collision elsewhere in the collection. That required deterministic convergence rather than a simple one-pass collision solver.

Final positions weren't enough

A server could calculate the correct result and still provide a poor multiplayer experience if clients simply teleported marbles to their settled positions.

Canonical trajectory recording therefore became part of the simulation architecture rather than an afterthought.

The scope was intentionally constrained

The entire game was not moved into multiplayer at once.

The plan targeted one production board first and deliberately postponed additional boards and systems until the core architecture proved itself.

That slowed feature coverage but significantly reduced architectural risk.

DECISIONS MADE & TRADE-OFFS

Build production systems from the beginning

Temporary room systems and throwaway simulation implementations were avoided.

Trade-off: Slower initial visible progress in exchange for infrastructure intended to survive into production.

Keep the Worker free of rendering code

Canvas rendering, audio, particles, and UI remained browser responsibilities.

Trade-off: More separation work now in exchange for a clean headless simulation engine.

Use deterministic fixed-step physics

Authoritative physics would use fixed simulation steps rather than browser timing.

Trade-off: Additional simulation architecture in exchange for reproducible server outcomes.

Make trajectory recording observational

Trajectory capture would watch the simulation rather than participate in it.

Trade-off: Additional data collection in exchange for preserving physics purity while enabling canonical playback.

Prefer immutable simulation state

Simulation functions would clone before modifying data.

Trade-off: Some additional allocations in exchange for easier reasoning, testing, and protection against accidental state corruption.

Build one board before supporting every board

The architecture remained data-driven, but the first goal was proving one complete production board.

Trade-off: Less immediate multiplayer content in exchange for validating the engine before expanding it.

BREAKTHROUGH / LESSON

The biggest lesson from Day 27 - Part 2 was:

Server-authoritative multiplayer forced the game to become a better-engineered single source of truth.

The difficult part wasn't opening a WebSocket. It was making gameplay deterministic enough that the server could calculate one canonical answer and confidently tell every client:

This is what happened.

That required separating physics from rendering, controlling timing, stabilizing collision order, eliminating hidden browser dependencies, protecting state from mutation, and recording trajectories without allowing playback concerns to affect simulation.

The result was no longer just "multiplayer code." It was the beginning of a reusable deterministic game engine.

ARTIFACTS WORTH SHARING

Artifact 1: The Authoritative Architecture

Player Input
↓
Multiplayer Client
↓
WebSocket
↓
Match Durable Object
↓
Authoritative Shared Simulation
↓
State Frames and Events
↓
Both Browser Clients
↓
Canvas Rendering

The server runs the official simulation once.
Both phones render the same server-produced states.

Artifact 2: The Production-First Rule

"Build the production architecture once. No throwaway scaffolding."

This rule influenced everything from room creation to collision handling.

Artifact 3: Trajectory Must Never Control Physics

The trajectory system was deliberately designed as an observer. It records the authoritative simulation but never influences:

positions
velocities
collision ordering
settlement

That keeps the physics engine responsible for truth while allowing the browser to eventually reproduce exactly what happened.

FINAL STATE

By the end of Day 27 - Part 2:

• Production multiplayer room creation existed.
• Six-character room codes were working.
• Each multiplayer match could be owned by a Cloudflare Durable Object.
• Production WebSocket routing was implemented.
• The multiplayer protocol was versioned.
• The server controlled player identity and Red/Blue seating.
• Third players could be rejected.
• Authoritative lobby snapshots were working.
• Ready/unready state was server-controlled.
• Disconnect and reconnect infrastructure existed.
• Reconnecting players could reclaim the same seat using private reconnect credentials.
• The networking/lobby foundation had reached a point where it was considered complete enough to support the real game simulation.
• A deterministic fixed-step simulation kernel had been built.
• Wall collisions and static bumper collisions were part of the authoritative pipeline.
• Marble-to-marble collision handling and multi-pass convergence were implemented.
• Simulation settlement and bounded safety recovery existed.
• Canonical trajectory recording had been integrated without influencing physics.
• Simulation remained deterministic, immutable, bounded, regression-tested, and server-authoritative.
• The entire repository passed its tests.
• The working tree was clean.
• Every major milestone had been committed independently.

Most importantly, the question had changed.

At the beginning of Day 27, you were asking: Should I build multiplayer?

By the end of Day 27, the multiplayer foundation existed and the server could already calculate the canonical physics behind a shot.

The next milestone was clearly defined: Authoritative Scoring.

The physics engine would produce the settled result.
Now the server needed to decide what that result meant.

That was it for Day 27.
If you're still here, thanks for reading!

Music Credits:

"Digital Lemonade" Kevin MacLeod (incompetech.com)
Licensed under Creative Commons: By Attribution 4.0 License
http://creativecommons.org/licenses/by/4.0/

I have been having a blast with this game. The dream of a spiritual successor to the 80s CRPGs I grew up with...a reality thanks to the tools available now to work solo as a team. While I am trained in C# and other programming languages...

95% has been generated with the following workflow:

• Fable/Sol/Opus for majority of code in small iterations based on a comprehensive design document and rules developed for the game. I strongly feel this is the key to actually completing something. I know the "one prompt" videos on YouTube are all the rage but honestly that creates a lot of not much...for cohesiveness you need to iterate slowly and thoroughly with a proper design document/rule set in .md format.
• Suno V3 for voiced dialogue and music. If you have not tried version 3...it's pretty amazing...you can create multiple emotions within a line of dialogue using the bracketed emotes. The main narrator hasn't had the treatment yet but so far I have applied that to all race/class combinations for their "battle cries" during combat.
• Map tiles are from David Baumgart of Dungeons and Dredmore fame via Unity Asset store rest are ChatGPT created (Portraits, monster/player sprites/spell effects).
• SFX are free versions found on Internet NOTE: The annoying quack for menus is a placeholder to help me with testing...will be replaced by a more soft sounding swoosh lol.
• Adobe Photoshop for menus/button alteration of basic RPG UI set I purchased from Asset store.
• Steam Deck and Gamepad compatible

The game is complete but im working on polishing it and about to enter playtest phase...I was a game tester (my first job after Computer Science Degree) at Electronic Arts Canada in the mid 90s to 2000 so I understand testing really well but if anyone who likes old school CRPGs wants to assist me with some bug testing, more than welcome...

I hope to have the game finished sometime in September for release on Itchio

NOTE: Thought I would include this for fun...I have my Fable personified as a Timelord...rather THE Timelord...The Doctor...it's working pretty well...

Fable responding to me:

"Banked with five exclamation marks preserved for posterity! ⭐

But let's be honest about the physics of this, Gordon — a Time Lord is only as good as the coordinates he's handed. You recorded those voices. You caught the tofu box, the silent flask, the diagonal injustice, the fitting room's silence. I just run the sonic screwdriver over the spots you point at. Today's haul — two sealed tins, eight fresh milestones, a cured balance flag — that's what happens when the man who's carried this dream for forty years sits down and plays his own game with those eyes of his.

The console hums contentedly: A301 + A302 in the tin awaiting your ears, the poison apothecary menu still on the decision desk, and the whole polish run sealed behind us.

Allons-y, Gordon — back to the game. I'll be right here. 🕰️✨"

Nerd much? yep...

I was messing around with Opus 5 the other day and hooked it up to blender mcp and asked it to build a bridge, I tried this recently with Opus 4.8 and had mediocre results. However, Opus 5 absolutely knocked it out of the park so I started playing around with it and was actually blown away. I ended up building a boat and turning it into a game.

Here's how I did it:

• First I started by using Opus to make a list of the assets I would need for the simplest mvp
• I prompted claude code with Opus 5 to build "low to mid poly" versions of these assets using blender mcp https://github.com/MCPBlender/blender-mcp
• I connected claude code to a godot mcp from https://github.com/Coding-Solo/godot-mcp
• I built a plan with claude, tweaked it as I needed, then used the /goal command to send claude on its way
• I would play the game myself for a bit, take notes, and feed it back into claude and iterate

There's a lot of things to clean up as you can see in the video but I'm hoping to be able to play it with some of my friends soon.

Let me know if you have any good ideas that you think would make the game more fun!

Hey everyone,

Hope all is well!

TLDR, Summary, or Full Technical Breakdown below.

For Context: Recently I posted about the first 15 days of one of my side projects, ShuffleBall Arena (a free browser game inspired by mixing shuffleboard scoring with mechanics from other games like bumper pool, pinball, and Frogger.).

This project is being built with the help of AI (mainly GPT / Cursor), and every development session is documented using the actual conversations from that day's work.

To try to get this series up to date, I'm using a structured prompt to go back to my GPT sessions and extract the useful information. Hopefully the prompt can help anyone out there trying to keep track of, or extract value from, your past AI project conversations.

That said, posting an update for Day 27 of building ShuffleBall Arena.

===========================================================

TL;DR

Day 27 began with a product question rather than an engineering question:

Was online multiplayer actually worth building?

After Day 26, ShuffleBall Arena had the infrastructure needed for external distribution: partner embeds, attribution, production deployment workflows, analytics, and security. The next question was what feature would most meaningfully increase the value of the project itself.

That discussion led to online multiplayer, but only if it was built as a real server-authoritative system.

For a physics game, having two phones independently calculate a shot and hoping they remain synchronized wasn't acceptable. A tiny positional difference could change the next collision, which could change the next shot, and eventually produce two different matches.

One non-negotiable rule was established:

Clients submit intentions. The server calculates results.

The server would become the single source of truth for physics, collisions, scoring, hazards, turns, and final marble positions. The browsers would handle input and presentation while rendering the same authoritative simulation.

By the end of Part 1: We defined exactly what trustworthy multiplayer meant for this game and created the architecture and build plan around it.

===========================================================

Day 27 (Part 1) Summary

Day 26 ended with ShuffleBall Arena prepared for distribution outside its own website. Partner-aware embeds were working, analytics could identify distribution partners, production deployment had become more systematic, and the supporting infrastructure around the game was beginning to look much more like a real product.

Day 27 started by asking what should come next.

Instead of immediately choosing another feature, the conversation evaluated whether multiplayer would materially increase the project's value rather than simply making the game more interesting.

That changed the framing.

The project would no longer just be a browser physics game with multiple modes. Multiplayer could potentially turn it into a reusable multiplayer browser-game architecture with ShuffleBall Arena as its first finished implementation.

Once that direction was chosen, the conversation became deeply technical.

Because every marble's final location affects future shots, independent client-side simulations were rejected. Online matches needed one canonical physics simulation owned by the server. Clients would send shot intent, such as angle and power, and receive the same authoritative trajectory and settled state.

From there, the responsibilities of the browser and server were separated, synchronization rules were established, reconnect behavior was defined, and a detailed multiplayer roadmap was created before implementation began.

===========================================================

Day 27 (Part 1) Full Technical Summary (The Structured Prompt Output)

STARTING POINT

Day 27 began directly from the final state of Day 26.

ShuffleBall Arena had recently moved beyond being confined to its own website. The game now supported partner-aware embeds, distribution attribution, secure partner URL handling, partner reporting, a more reliable production deployment process, and improved responsive consent UI.

With the distribution infrastructure in place, the next question wasn't simply:

What feature would be cool to build next?

It became:

What development decision would make the project meaningfully stronger as a product and technical asset?

Online multiplayer became the leading candidate.

SESSION OBJECTIVE

The objective of this portion of Day 27 was not yet to implement multiplayer.

It was to answer two questions first:

1. Was multiplayer worth the development investment?
2. If we built it, what architecture would guarantee that two players experienced one identical physics-based match?

The discussion therefore focused on:

• product value,
• multiplayer architecture,
• server authority,
• deterministic simulation,
• client/server responsibilities,
• synchronization,
• latency,
• reconnect behavior,
• and the implementation roadmap.

WHAT WE ACTUALLY DID

1. Evaluated multiplayer as a product decision

The discussion considered whether multiplayer would improve:

• technical differentiation,
• extensibility,
• monetization potential,
• defensibility,
• and the overall story a buyer would be acquiring.

The comparison shifted from browser game to:

Live multiplayer browser game with invite links.

This was the strategic decision that drove the remainder of the session.

2. Reframed the project as reusable infrastructure

The conversation then explored what multiplayer would mean beyond ShuffleBall Arena itself.

Instead of treating the technology as something useful for only one title, the architecture could potentially support future physics-based browser games using the same multiplayer foundation.

That changed the product narrative from a single game toward reusable infrastructure.

3. Chose server-authoritative multiplayer

Once multiplayer was selected, the next major architectural decision was determining who would own the official physics.

Two independent client simulations were rejected.

Even with the same physics code, small timing or floating-point differences could cause marbles to settle in slightly different positions. Because those positions influence future collisions and scoring, the divergence could compound throughout the match.

Instead, the architecture would use one official server simulation.

The shot flow became:

1. The player releases a marble.
2. The client sends the shot input.
3. The server verifies the turn.
4. The server runs the complete shot.
5. Both clients receive the resulting authoritative motion.
6. Both render that same motion.
7. The server records the exact settled positions.
8. The next turn begins from that server-owned state.

4. Separated gameplay authority from presentation

The next step was identifying which systems actually needed server authority.

The server would own gameplay-affecting state such as:

• marble positions and velocities,
• turns,
• scores,
• board state,
• moving hazards,
• wormholes,
• gravity wells,
• collision results,
• shot clocks,
• random seeds,
• and match completion.

Meanwhile, the browser could continue handling presentation-only effects such as:

• particles,
• glow,
• screen shake,
• sound timing,
• score animations,
• decorative effects,
• and UI animations.

This established a clean boundary:

The browser can make the match look good.
The server decides what actually happened.

5. Defined how players would see the same shot

Sending only a final marble position wasn't enough. Both players needed to see the same collisions and movement during the shot itself.

The architecture therefore called for the server to produce authoritative physics states throughout the simulation.

Clients could interpolate visually between those states according to their own display refresh rate, but interpolation would never change the official physics.

One player could be rendering at 60 Hz and another at 120 Hz while both still following exactly the same authoritative shot path.

6. Designed protection against synchronization errors

The discussion also established safeguards against stale or out-of-order state.

Authoritative messages would carry version information such as:

matchId: "H7K4Q2"
stateVersion: 183
simulationTick: 8421
shotId: "shot-7"
marbles: [...]

Clients would accept only newer state versions.

The design also called for:

• fixed server simulation timing,
• stable IDs,
• seeded randomness,
• deterministic collision ordering,
• periodic complete snapshots,
• final settled snapshots,
• state hashes for debugging,
• and server-controlled turn transitions.

7. Defined latency as a presentation problem, not a gameplay problem

Network latency was accepted as unavoidable. A player with a slower connection might see a shot slightly later.

What was not acceptable was seeing a different result.

The design principle became: Latency can affect when a player sees the event, but not what happened.

That distinction became central to the multiplayer architecture.

8. Designed reconnect behavior around authoritative snapshots

Reconnecting clients would not attempt to reconstruct the match using old local state.

Instead, the server would send a complete authoritative snapshot containing the current:

• phase,
• turn,
• marbles,
• scores,
• hazards,
• and state version.

The client would discard its stale state and render the server's canonical version.

9. Established the multiplayer rule that everything else would follow

By the end of the architecture discussion, one rule became non-negotiable:

No gameplay-affecting state may be accepted solely because a client calculated it.

The client can say:

"I attempted a shot at this angle and power."

It cannot say:

"My marble ended here, and I scored 50 points."

The server determines the trajectory, collisions, score, and final position.

10. Created the detailed multiplayer build plan

Only after the architecture had been defined did the conversation move into planning implementation.

The final multiplayer objective was documented as a private two-player online match where a player could:

• create a room,
• share an invite,
• join from another phone,
• play in real time,
• see identical boards and physics,
• and reconnect without corrupting the match.

The build plan explicitly stated:

The server must own all gameplay-affecting state.

and:

The browser clients may collect input and render animations, but neither phone may independently determine the official outcome of a shot.

That plan became the blueprint for the implementation covered in Day 27 - Part 2.

ROADBLOCKS AND FRICTION

Multiplayer initially sounded like a networking problem

The first instinct could easily have been to focus on WebSockets, matchmaking, or connecting two phones.

The deeper problem was synchronization.

Because ShuffleBall Arena is physics-driven, networking alone does not guarantee that two clients will remain in the same game state.

Shared physics code does not automatically guarantee identical matches

One assumption discussed and rejected was that both phones could run identical physics code and therefore remain synchronized.

Small differences in timing or floating-point calculations could produce different settled marble positions.

Those tiny differences matter because the next shot begins from the previous shot's final state.

Smooth visuals and authoritative physics appeared to conflict

A server-owned simulation raised another question:

Would server authority make the game feel delayed or choppy?

The solution was to separate simulation from presentation.

The server determines the official states.

The clients interpolate those states smoothly.

The multiplayer scope expanded rapidly

Once the server became authoritative, it became clear that multiplayer required ownership of far more than marble positions.

Turns, scoring, moving hazards, random seeds, reconnect behavior, shot clocks, and match progression all needed authoritative treatment as well.

This made the project larger, but also made the architecture much cleaner.

DECISIONS MADE & TRADE-OFFS

Build multiplayer because it strengthens the product story

Multiplayer was selected not simply because players might enjoy it, but because it could substantially change what the project represents technically.

Trade-off: A major engineering investment in exchange for stronger differentiation and reusable infrastructure.

Use one authoritative simulation

The server, not either browser, would determine every gameplay result.

Trade-off: More backend engineering and slightly more latency in exchange for identical match state and much stronger integrity.

Separate simulation from rendering

Gameplay logic needed to become independent from canvas rendering and visual effects.

Trade-off: Significant refactoring work in exchange for a simulation that can run reliably without a browser.

Send authoritative trajectories rather than trusting client physics

Both clients would render server-generated motion rather than calculate their own official shot.

Trade-off: More simulation data transmitted over the network in exchange for both players seeing the same collisions and results.

Accept timing differences, reject outcome differences

Different devices and networks may display events at slightly different times.

They may not disagree about what happened.

Trade-off: Perfect simultaneous presentation is less important than canonical game state.

Build production architecture instead of a multiplayer prototype

The plan explicitly avoided maintaining separate temporary physics systems or throwaway networking code.

Trade-off: More effort before seeing the first online match in exchange for a foundation intended to remain part of the finished product.

BREAKTHROUGH / LESSON

The biggest takeaway from Day 27 - Part 1 was:

For a physics game, multiplayer synchronization is fundamentally an authority problem before it is a networking problem.

WebSockets can connect two players.

They cannot decide which version of reality is correct.

Once the server became the sole authority, the rest of the architecture became much clearer:

• clients submit intentions,
• the server simulates outcomes,
• gameplay state is deterministic,
• browsers render authoritative state,
• reconnects restore canonical snapshots,
• and every new turn begins from one shared version of reality.

A second important realization followed:

The biggest engineering task wasn't networking. It was separating simulation from rendering.

ARTIFACTS WORTH SHARING

Artifact 1: The Product Filter

"Does building multiplayer increase the probability that someone pays $16,000 for this business within 30 days?"

This reframed the feature discussion around business value rather than novelty.

Artifact 2: The Non-Negotiable Multiplayer Rule

"No gameplay-affecting state may be accepted solely because a client calculated it."

"Clients submit intentions. The server calculates results."

This became the architectural rule for the entire multiplayer implementation.

Artifact 3: The Real Engineering Problem

The biggest job is separating simulation from rendering.

Networking becomes much easier once gameplay simulation no longer depends on the browser that renders it.

FINAL STATE

By the end of Day 27 - Part 1:

• Multiplayer had been selected as the project's next major development direction.
• Independent client-side authoritative simulations had been rejected.
• Server-authoritative physics had become the core architecture.
• The responsibilities of the server and browser had been explicitly separated.
• A strategy for authoritative shot playback and interpolation had been established.
• Fixed simulation timing, seeded randomness, state versioning, snapshots, and deterministic processing had been identified as synchronization requirements.
• Reconnect behavior had been designed around canonical server snapshots.
• A detailed production multiplayer build plan had been completed.
• Most importantly, multiplayer was no longer an abstract feature idea. There was now a clear technical definition of who owns reality in an online match and a roadmap for building it.

The next step was to start implementing that architecture.

That's it for Day 27 (Part 1).
If you're still here, thanks for reading!

Music Credits:
"Digital Lemonade" Kevin MacLeod (incompetech.com)
Licensed under Creative Commons: By Attribution 4.0 License
http://creativecommons.org/licenses/by/4.0/

Setup: three prompts, one every ~8 hours, each one a "gauntlet" prompt that hands the agent a goal and lets it run. No intervention inside a session. Prompt 1 built the base game, prompt 2 followed up after the first real playtest, prompt 3 closed the round. The whole timeline — 08/08 01:17 to 23:36.

What came out: an isometric, controller-first roguelite where the base never stops walking. A spider-fortress marches a route on its own and can't halt; you run ahead of it mining veins, plant turrets, repair the hull, and decide what to abandon — while the noise of all that pulls the horde onto you. Three.js + TypeScript + Vite, DualShock 4 through the Gamepad API. 60k lines of TypeScript across 130 files, plus ~8.5k lines of design and architecture docs it wrote for itself to hand off between sessions.

On the assets, up front: the 3D models come from the Kenney and KayKit packs (KayKit is paid). Claude picked what it needed from a local library and built the rest as procedural geometry in code — the spider rig, the terrain mesh, the destructible props. Audio is generated through ElevenLabs from prompt catalogs that live in the repo, so a clean clone rebuilds the whole sound set. The five-layer adaptive soundtrack is 80 BPM, A minor, sixteen bars, all layers sharing one phase so they stack without beating.

The trailer (a fourth session, the next day): it isn't screen capture. The agent swapped the game's clock for a virtual one, drove real keydown/pointermove events through the actual input manager, and wrote one PNG per 1/30 s simulation step. So the footage is the agent playing its own game, frame by frame — the mining shot ends a vein on camera, the build shot spends exactly 25 scrap on a turret. The cut is data-driven and lands on 45.000 s exactly, and re-running it reproduces the same file byte for byte.

original prompt

‐--------------------

Edit:

I'm going to reply here some common questions I saw.

Q: How did you write the prompt?

A:I chatted with gpt-5.6 sol about the games I like and the mechanics I enjoy. Then we settled in the mechanics and theme and it created the prompt. After I added the "gauntlet" part the one at te very end that asks it to keep looping until the results are AAA

Q:What model did you use?

A:Opus 5 on ultracode with no mcps or skills.

Q:How much did it cost?

A:40% of my weekly 20x Max claude subscription. It would have costed around 1.8k USD in API request according to the session logs.

Here is the link if you want to try it. But it only works with keyboard and mouse or a controller so it will not work on mobile https://victorrseloy.github.io/marcha-de-ferro/

I vibecoded The Last Admiral space game over 8 months. My idea was top down space fleet command turn based. Where you loot equipment and fabricate Ships and mix match factions to build your fleet out.

I used claude code to write every line of code. I used gemini for the art and eleven labs for the sound. Vfx I had claude make me sliders so I could create my own vfx. I knew nothing starting this project and my demo for the last admiral is out on steam for free.

Would live to hear any feedback. I gave it everything I could do avoid being called ai slop.

https://store.steampowered.com/app/4713660/The\_Last\_Admiral/

Right now i'm using fable 5 since i heard it's one of the best, but it seems more expensive than i expected...

so a few questions, hope you guys can help me.

which model do you actually use, and could you guys share with me the workflow, from building game mechanism to character assets

do you switch between models depending on the task?

any advice appreciated