I 'Vibe-Coded' a Wargame in 30 minutes. Finishing it took me over 300 prompts.

I do not know how to code. Yet less than half an hour after giving ChatGPT the rules for a solitaire wargame and a PNG of its map, I had a playable browser version.

The prototype was the easy part. Turning it into a stable professional military education game took roughly 20 to 25 hours of active development, more than 300 prompts, over 100 coding iterations and at least 60 numbered builds. Vibe coding made the first 80 per cent remarkably easy. The final 20 per cent became the real project.

From rules and a PNG to a playable game

I did not start with a blank sheet. Professor Phil Sabin created the unpublished Paratrooper concept, and Dr Ian Robinson developed the analogue Take That Bridge game from it. My role was to lead the digital redesign, drawing on criticism and ideas from Fight Club International playtesters. ChatGPT generated the code, but the decisions about what entered the game, what changed and what was rejected remained mine.

One prompt for the project was Robinson and Trevor Lipscombe's paper on Kill Zone Probability Field Theory. It examined part of the combat system mathematically: range, cover, line of sight and the difference between concentrated and distributed fire. The paper offered a mathematical snapshot of selected mechanics. I wanted to see what happened when players had to use the whole game to accomplish a mission.

Destroying Red may help, but it is not the mission. Blue has to cross exposed ground, reach the bridge, defuse the demolition charges and retain enough combat power to hold what it has taken. Players choose routes, use terrain, concentrate force, bypass threats, accept risk and decide when not to fire. I did not build the digital game to validate or disprove the paper. I wanted people arguing about how they would use their forces to take the bridge, not simply about what an equation said should happen in a firefight.

I began by giving a coding GPT Ian's rules and almost nothing else. It struggled with the map, so I supplied that as a PNG. From there the method was simple: play the build, find what felt wrong, describe the result I wanted, test the change and repeat. I never edited the code myself.

How the game escaped its original design

The first build looked much like the analogue game: Blue rifle sections, machine-gun sections and a headquarters against their Red equivalents. It worked, but it was bland. Vehicles were considered and rejected because armour, penetration, facing and flank shots would have brought a large new rules burden. I still wanted combined arms, particularly if the game was to follow Take That Hill, so I added mortars.

That left us with a combined-arms game whose technology still felt rooted in the 1940s. FPVs came next. Once they existed, an ISR drone that could observe for mortars seemed logical. Then came UGVs and electronic warfare. I kept them generic. The game represents what those capabilities do to a tactical problem without pretending that its percentages can predict the performance of a particular drone, jammer or weapon.

Then players started doing something I had not expected. In the early game they pushed their headquarters forward for its rallying benefit and because it was good at defusing the bridge charges. Once the headquarters also enabled ISR, EW and other capabilities, they held it back and protected it as a command node. They also started hunting the enemy headquarters as a shaping action. Adding the new systems had changed how players thought about command, not merely given them more buttons to press.

The scoring also had to make the mission unmistakable. The bridge award rose from 10 to 25 points. Blue casualties still hurt, while surviving Red forces reduce the score because a shattered force sitting on the bridge with enemy troops nearby has not secured much. Hidden Red counters and their zones of control force Blue to stop and clear possible threats rather than exploit the player's suspicion that a marker is probably a dummy.

The game is solitaire because it is meant to support student-directed learning. A player can select easy, medium or hard opposition, choose from five terrain settings, generate a new map and enemy layout, write a plan, fight the battle, run an after-action review and export it as a PDF. The forthcoming configurable PME version will also let an instructor vary the forces, enemy strength, electronic-warfare conditions and enemy deployment.

Solo play comes with a price. A human Red player could manoeuvre, counterattack, hide the headquarters among plausible alternatives, use dummies intelligently and choose when to open fire. The solitaire opponent follows concealed protocols and difficulty adjustments, but it cannot read Blue's intent or deceive in the same way. FCI is now developing a two-player analogue version with separate views and reciprocal fog of war. That is a much harder technical problem than simply allowing Red counters to move.

No language model is involved during play. The finished HTML file runs ordinary rules and probability logic locally in a browser. Nor are its combat probabilities validated operational data. They are there to create decisions and uncertainty. The game can help someone practice sequencing EW, ISR, FPVs, mortars and manoeuvre. It should not be used to predict real weapon performance or force requirements.

The difficult final 20 per cent

Every improvement risked breaking something that already worked. Replacing status-marker artwork once made the Blue and Red units disappear. An attempt at multilingual support translated the headings but left buttons, orders, logs and generated text in English. A new Red headquarters image appeared to be installed, only for an older embedded asset to override it later in the script. New sound effects coexisted with references to the files they had replaced.

A successful syntax check proved very little. The JavaScript could be valid while the game in front of me was unusable. When a requested outcome failed, I asked the GPT to inspect the relevant code and trace what was overriding what. I could not judge whether the code was elegant, but I could keep forcing its attention back onto the gap between what I had asked for and what the build actually did.

The GPT also did not understand what the counters represented unless I told it. A UAS could block a ground unit's line of sight because both were objects on the map. UGVs caused similar problems. Red initially opened fire at maximum range and burned through its ammunition because the code knew when firing was permitted, not why a defender might wait. Reveal protocols, engagement ranges and ammunition conservation all had to be made explicit.

As the single HTML file grew, broad rewrites became dangerous. My prompts changed from creative requests into defensive instructions: replace this, keep those dimensions, preserve that outline, do not change anything else. I had begun by conversationally prototyping a game. I ended up managing a legacy codebase without being able to read it.

What vibe coding changes for wargame designers

Take That Bridge is not the only example. Fight Club member Sam Katz has vibe-coded Road to War, a long-term force-design and force-management simulation linked to periodic Command: Modern Operations activity. The Women's Wargaming Network has also run a game jam using Claude Code to move from concept to prototype in an hour. Its warning was right: without a sound game design, AI only helps you build something broken faster.

That is why I would not start by asking an AI to invent and code a game at the same time. Begin with a game design. A known ruleset gives the model boundaries and gives you something against which to test its output. I broke my own advice by allowing a simple game to grow organically, without planned development sprints followed by protected periods of playtesting. That was manageable when the game was small. It became expensive once dozens of systems interacted.

Vibe coding does not remove the need for professional developers. Architecture, testing, security, networking and maintainability become more important as a prototype turns into a product. What it changes is the price of getting started. Many hobby and professional wargames serve audiences too small to justify conventional development costs. A subject-matter expert can now build and test the idea before the economics kill it.

The AI generated the code. I specified, tested, rejected and redirected the product. It did not decide what the game should teach, whether a mechanic represented warfare sensibly or when a build was actually good enough.

Play and read

Play Take That Bridge on the Fight Club International website.

Read Kill Zone Probability Field Theory Applied to a Simple Fire and Maneuver Wargame by Trevor C. Lipscombe and Ian M. Robinson.

Review of Take That Bridge (early version) by Wargaming Weekly