Extraction of JSettler "AI" for Physical Implementation

[benjaminpsmith]

Hello everyone,

I'm not sure if this is the right platform to post this question, but I wanted to check in.

I am a 4th year Computer Science student at Conestoga College in Kitchener, Canada, and I am currently creating a capstone project. I am interested in making a physical implementation (camera and a screen mounted on a stand) that can use existing bots/AI for multiple games (Chess, GO, hopefully Catan as well) to allow people to play their physical board games with a computer player. For example, if you have two humans that want to play a game of Catan but can't find two more, set up the camera and use JSettlers to play as the other two players.

I believe that GPLv3 would allow this, but I wanted to confirm that the extraction of the AI logic (if possible) is allowed. This would not be a paid product and would be used as a proof of concept of being worth playing compared to using a computer to play.

Thanks for any time spent reading and any information!

EDIT: typo

[jdmonin]

Hi, thanks for reaching out. Your project is a really fun concept!

JSettlers started as an academic project, so it's always cool to see someone finding new things to do with it. Your extraction is definitely allowed and encouraged. :)

Right now the AI bots are pretty closely tied into the project's game data structures and message sequences, so that kind of reuse isn't as easy as I'd want it to be unfortunately.

You've probably taken a look at the code already, but here's a few thoughts:

The AI logic builds on and relies on the game representation data classes like SOCBoard and SOCPlayer, and reacting to the current game state (SOCGame.ROLL_OR_CARD, PLACING_ROBBER, etc). It also relies on receiving and sending JSettlers message sequences.

Depending on how much extraction, refactoring, etc you want to do, it may make sense to either make a new "server" which handles the human players and interacts with the JSettlers AI bot clients, or treat the human players as clients to the current JSettlers server. Or try to completely extract the bot from its current surroundings and network environment.

The AI logic's message-driven main loop is SOCRobotBrain.run() which examines the current game data and if current player, forms a plan and takes its next action. (Or if not current player, it can react to trade offers and ask for Special Building Phase in a 6-player game.) Other important AI bot classes are SOCRobotDM where it plans and makes strategic decisions, SOCPlayerTracker with information and estimates about other players, and SOCDisplaylessPlayerClient to update game data and send its actions to the server.

There's more info in Readme.developer.md:

• Project structure and important classes
• Board layouts and coordinates

More about the message sequences:

The AI bot's information about game data and other players' actions arrives as SOCMessages from the server.
Its run loop directly reacts to some game action messages when they are received, like dice roll results (SOCDiceResult), piece placements (SOCPutPiece), and game state changes (SOCGameState). It also sometimes waits for a (SOCTimingPing) which the bot client sends itself once per second, so it can wait long enough for human players to react to situations and trade offers before the bot takes action.

To take actions it sends SOCMessages to the server; doing so is mostly abstracted by having the bot call methods like SOCDisplaylessPlayerClient.putPiece.
So to use the bot "as is", you'll also be working with those messages.
The message sequence for when the bot joins a game and receives game data, board layout, etc starts with SOCJoinGameAuth and is described in the SOCGameMembers javadoc.
Game play messages are documented in Message-Sequences-for-Game-Actions.md, with details in the message class javadocs.

Another way to explore the JSettlers message sequnces is to run the player client with arg -Djsettlers.debug.traffic=Y which prints all messages to the terminal.

Often the bot takes action by setting its flags to expect a certain game state like PLACING_ROBBER, then calling a method which sends a message to server which leads to that game state.

Although the bot's game action message sends are abstracted through those client method calls, there are a few places (joining or leaving games, debug prints) where it directly calls SOCDisplaylessPlayerClient.put(SOCMessage) to send a message. If you're abstracting away from the network, watch for those too.

I hope all this helps. Let me know what you think.

-Jeremy Monin