The story behind the new Gomoku “CYBER GOMOKU” created with AI

Even if you have a little programming experience, you will need to learn many areas in order to safely publish an online competitive game that uses a server by yourself. Cyber Gomoku is a project that takes shape by making up for this deficiency with the support of AI.

Adding information warfare to the classic Gomoku

The starting point for the project was the idea of ``adding elements that would only be possible digitally to an old, easy-to-understand game.'' The board and victory conditions are based on Gomoku, but the following three abilities have been added.

• Stealth Stones placed where the opponent cannot see them
• A Go stone bomb that erases surrounding stones when you step on a designated square.
• Stone Radar to discover hidden stones and bombs

Our goal is to add prediction, traps, and exploration to Gomoku, which used to be a perfect-information game, and make it a game where you can read not only the opponent's board but also their intentions.

Why I chose browser games

We made it into a browser game with the emphasis on being able to play immediately by opening the URL, without the need to install an app. Another point that is compatible with individual development is that modifications can be immediately delivered to all players without worrying about app store reviews or distribution fees.

The technical configuration is as follows: Each was selected based on whether it could be continued to be operated by an individual.

• Client:React + TypeScript + Vite. With type checking, errors in AI-generated code can be noticed at the build stage.
• Competitive server:Node.js + Socket.io. Exchange of moves in real-time battles is done using WebSocket.
• Login and data storage:Firebase Authentication and Firestore. By not creating the authentication infrastructure ourselves, we have reduced security risks.
• Delivery:The game itself is Cloudflare Pages, and the battle server is Render. Both can be operated at low cost on a small scale.

None of the configurations are special, but I think the decision to ``choose old combinations and focus the originality on the game rules'' was the reason why we were able to reach completion.

Ask AI to help with problem isolation, not just implementation.

It's not just about conveying your requests to the AI. We had to check whether the generated implementation matched the game rules and isolate where the problem was in the browser, server, authentication, or data storage.

At the time of the live release, there was an issue where Google Login did not work. At this time, by specifically organizing the errors that appeared on the screen, the environment in which they occurred, and the differences from local, and passing them on to the AI, we were able to identify insufficient settings. I learned the importance of sharing the reproduction conditions and observation results, rather than just telling people that it doesn't work.

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

1. Reduce requirements to one feature:Instead of ``creating an online match'', we will break it down to ``allow only the player whose turn it is to start the game'' and then make the request.
2. Match products to rules:Even if the implementation seems correct, boundary conditions such as forbidden moves and hidden moves can only be determined by someone who knows the game specifications.
3. Move and break:Deliberately try illegal operations (such as taking your opponent's turn) and see in which layer you are defeated.

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 correct answer in the game is determined by the server side.

In online matches, you cannot rely on the board or the results sent from your browser. Currently, the server side re-verifies the turn, coordinates, number of remaining items, and wins and losses, and the client is in charge of display and operation.

Gomoku's decision logic has been consolidated into a pure module that can be used by the client and server, and the same rules can be implemented separately to ensure consistent results. Even when using AI, developers need to decide where to set the trust boundary.

Continue to improve even after publication

After publishing the game, we added initial instructions, accessibility, goals for CPU battles, builds for overseas portals, etc. Rather than obtaining a completed code, the most useful aspect of developing with AI was breaking down the problem into smaller parts, verifying them, and connecting them to the next improvement.

Specific improvements made after publication are recorded in separate articles. Application record to overseas portal、Improving presentation based on play data、Designed for playability Please also take a look.

For those who are about to start personal development

Here are three lessons learned from this development for those who are also trying to develop games with the support of AI.

• Write the primary information for the rules yourself:If you clearly state the specifications of the game rules in your own words, you will be able to request and verify the AI without any hesitation. Cyber Gomoku consolidated the decision logic into one module, which became the foundation for all later functionality.
• Determine the trust boundary first:It is difficult to correct the question ``to what extent you believe the client's declaration'' afterwards. If you have an online element, we recommend designing it from the beginning with the assumption that it will be revalidated on the server.
• After publishing, the real development begins:Actual player environments and actions always betray assumptions made during development. Plan your schedule based on a cycle of publishing, observing, and fixing.

We do not use the content generated by AI as is, but rather have humans check the game rules, security, type checks, and build results.