Building Cyber Gomoku with AI assistance

Publishing an online competitive game safely requires knowledge of client code, servers, authentication, and deployment. Cyber Gomoku was built by combining prior programming experience with AI-assisted implementation and debugging.

Adding information warfare to the classic Gomoku

The project began with the idea of adding mechanics that only a digital format could provide to an old, easy-to-understand game. The board and win condition come from Gomoku, with three new abilities:

• Stealth Stones that the opponent cannot see
• Stone Bombs that destroy surrounding stones when triggered
• Stone Radar that reveals hidden stones and bombs

These mechanics add prediction, traps, and information gathering to a traditionally perfect-information game. Players must read an opponent's intentions as well as the visible board.

Why I chose browser games

A browser game can start as soon as a player opens the URL, with no installation required. It also lets an independent developer deliver fixes to everyone without an app-store review or a separate client update.

Each part of the technical stack was selected with long-term maintenance by one developer in mind:

• Client: React, TypeScript, and Vite. Type checking catches many errors in AI-generated code during the build.
• Match server: Node.js and Socket.io. WebSockets carry moves in real time.
• Authentication and data: Firebase Authentication and Firestore. Using a managed authentication service reduces the risk of building that sensitive layer from scratch.
• Hosting: Cloudflare Pages for the game and Render for the match server, both practical for a small project.

The stack is intentionally conventional. Choosing established tools made it possible to focus the project's originality on the game design and carry the work through to release.

Using AI to isolate problems, not just write code

Effective AI assistance required more than describing a desired feature. The generated implementation still had to be checked against the game rules, and each defect had to be traced to the browser, server, authentication, or storage layer.

For example, Google sign-in failed after the first production release. Organizing the visible error, affected environment, reproduction steps, and differences from local development made it possible to identify a missing setting. Precise observations were far more useful than a general report that “it doesn't work.”

Daily development was more or less a repetition of the following cycle.

1. Reduce a requirement to one behavior: Instead of asking for “online matches,” define a smaller rule such as “only the active player can place a stone.”
2. Check the result against the rules: An implementation may look correct while still mishandling forbidden moves or hidden information.
3. Try to break it: Deliberately attempt illegal actions, such as moving during the opponent's turn, and confirm which layer rejects them.

AI can greatly increase the speed of implementation, but defining what is right remains the developer's job. Once I became aware of this division of work, development began to progress steadily.

The server decides the authoritative game state

An online match cannot trust a board state or result reported by a player's browser. The server revalidates the active turn, coordinates, remaining ability uses, and win condition; the client handles presentation and input.

Core Gomoku decisions live in a pure module shared by the client and server, so both sides apply the same rules. Deciding this trust boundary remains a developer responsibility, regardless of how much code is AI-assisted.

Continue to improve even after publication

After release, the game gained a first-time tutorial, accessibility options, CPU missions, and separate builds for overseas portals. The most valuable part of AI-assisted development was not receiving finished code; it was breaking a large problem into testable pieces and using each result to guide the next improvement.

Related reports cover the overseas portal submission process, presentation changes based on play data, and accessibility design.

For those who are about to start personal development

Three lessons from the project may help other independent developers using AI assistance:

• Write the rules yourself: Clear first-party specifications make AI output easier to request and verify. Cyber Gomoku's shared rules module became the foundation for later features.
• Set the trust boundary early: Retrofitting server validation is difficult. Design online features on the assumption that client claims will be revalidated.
• Treat release as the start of another cycle: Real devices and player behavior will challenge development assumptions. Leave time to publish, observe, and fix.

AI-generated output is not used without review. A human checks game-rule accuracy, security decisions, type-check results, and production builds.