Checkers-Drafts Game: AI App Dev Style


Using AI Code development tools such as GitHub Copilot and Windsurf can not only speed up code development, testing and deployment nut also enables generation of project documentation including release notes in a methodical and consistent manner.

Specification

Specification is now the name of the game! Rather than directly writing code you can now efficiently specify the code and get AI to generate it. It doesn’t come out of thin air though. “When we build, we build on the shoulders of those who cme before us.” AI is making use of what others have done previously (publicly) and by parsing existing formal documentation. Make the specs succinct whilst comprehensive and correct and you are away! Take an iterative approach in that you might specify at high but internally complete manner then add complexity as each step is complete and correct, drilling into the apps functionality.

Make sure you have a definitive specification of what the app should do. This can take the form of a document that is then fed into AI. For example, you might specify the functionality of a new feature in a markdown file and then use that as a basis for writing the code and tests (whether coded or user functionality) for that feature. This way you have a clear specification of what you are trying to achieve and can ensure that your code meets that specification. When a stage is complete you can also use AI, using its reflection, to generate technical and release notes documentation. This documentation, the before and after, can then be used to remind the AI tools of what is going on with the app when you come back to the project; or when AI needs to be restarted because it gets into one of those endless hallucination loops!

Specify a Game

As outlined in Checkers-Drafts Game: Overview and Creation of Drafts-Checkers Game in Blazor with LAN multiplayer support , the aim is to create a fully functional online version of Checkers using Blazor, with features such as LAN multiplayer support, game state management, and a user-friendly interface. The project serves as a demonstration of using AI coding tools to rapidly develop a web application while adhering to best practices in software development.

There is one Admin “player” who can set overall and default player apps settings. Each game has an initiating player who starts a game and a player who elects to join. When starting the game, the initiator nominates the game’s group from the groups they are are a member of. Only players in that group can join.

A game is played in typical fashion by players making a move in turn. Multi-jumps have been implemented but there is a time limit after which the other player can move stopping further multi-jumps. If a player can’t move then the game detects that they have lost. There is also a player concede option. Indeed, originally it was note that whilst a game may end the app could not detect that so the end-game event was implemented.

There is lobby chat that goes to all players in one of the same groups as the chatter who are in the lobby, awaiting a game start. There is similarly in-game text chat between the two players plus voice chat between them.

Each player is a member of one or more groups and games are started in a nominated group.

So that the game can be hosted publicly on Azure, the app has a number of timeouts with garbage collection to clear dead games. A player has a limit to how long they can take for a move, how long a game can last and how long a a player can be logged in. This is important given that there is only a limited number of publicly know players:

Bob Ted Carol and Alice, each with a pin 9999

each player can only be logged in once. So the timeouts stop one person from hogging app resources.

Players, groups and other app settings are stored in a SQLite database using Entity Framework Core. The app is hosted on Azure Web Services and is available publicly. The app is designed to be responsive and works well on both desktop and mobile devices. Most game events are logged into the database for later analysis and inspection by Admin (only).

Pre and post game development documentation is available at:

About Voice Issues

An exercise in specifications and what can be implemented.

One of the features of the Checkers-Drafts in-game is voice chat. This is a complex feature that requires careful implementation and testing. The voice chat system was designed to be full-duplex, allowing players to communicate with each other in real-time. However, there have been some issues with the voice chat system that needed to be addressed. Initially text chat between players was implemented. This was used as a basis for Text to Speech (TTS) voice communications. This was simple to implement by AI and worked well.

Assigning supported TTS Voices was a bit problematic though as different voices are supported on different system, desktop-v-phone and OS-Windows-v-Android etc. Supported languages, regions and countries was also the mix. Desktop Windows also supports a number of male and female voices for each, for example English-Country. As far as it could be ascertained, Android phone only has one voice per country.

Full duplex voice chat sending audio bites was implemented at one stage but did not work well in a fully universal manner across all platforms. So, the voice chat system was redesigned to be half-duplex TTS button controlled like a walkie-talkie allowing players to take turns speaking. This has worked well and has been well received by players. The voice chat system is now fully functional and is a key feature of the Checkers-Drafts game.

A player can select a voice that the other player hears when they send voice chat if the first player is on a Windows desktop. When a player receives voice chat from another player a voice when no voice is specified (eg on desktop from a phone) a specific voice can be specified for the sender.

More information on TTS Speech: Text_Chat_Feature_Implementation and Speech Chat Feature Implementation

For more information on the failed approach see: voice-system-choice-implementation and voice-chat-implementation-summary

Conclusion

AI Code development tools can substantially lift coding productivity allowing developers to operate at a specification level rather than focused upn syntax etc. Though at times ,it is important to be able to hand code so as to short-circuit the iterations that the AI tools may take on a problem. Yes it is still important to be able code. Its a bit like the early days of compilers. Either you hardcoded in assembler or someone had to hardcode a programming language compiler in assembler for you.

 TopicSubtopic
<  Prev:   Checkers-Drafts Game
   
 This Category Links 
Category:Application Dev Index:Application Dev
<  Prev:   GitHub