COP 701

Assignment 2 - LudoBot
Date: 01-Aug-2017

Objective
The aim is to design a bot to play the game of Ludo. If you are unaware about
the game, we are providing the rules of Ludo here (Notice they are somewhat
different from the traditional Ludo you might have played). The main objective
here is to design a bot which is able to play Ludo.

Algorithm
You are free to implement any algorithms of your choice to make your bot more
skillful. You may find some algorithms taught to you in the COL671 useful. For
those who are not enrolled in the course, here you go.

Provided
You will be provided a server program for communication between 2 bots (more
on this later).

Inter-bot communication
The master/server program will initialise the environment variables like
game type, port no., time limit and ip-address (intra IIT).
The client program executable will be a bash script which will start your
bot and keep it running while playing the game.
After both the client are connected to the master program, they will re-
ceive the game-vars ie initialisation variables.
The player which connects first will be Player-1 and will be notified there
and then.
The moves will be sent to the master which will forward it to the other
player.
Master program will be responsible for the dice throwing and will com-
municate to the players.
Your moves will be simple strings based on piece color and moves.
Whoever connects to the server program first will be get the first chance
to throw the dice. Note this is in conflict to the Ludo rules provided.
(Some rules will be clarified soon, you are free to raise doubts on Piazza).

1
What to implement
The bot and its algorithms.
GUI:
You will also have to implement a Board-drawing function in your
client programs to draw a board and keep updating it with every
move.
It will be your choice to draw the board or not on your end. Note,
this does not mean that you may not implement it. Implementing
the function draw-board is compulsory just that drawing it on your
system while playing the game is a choice.
For example: Say 2 players Matt and Danny are competing with
their bots from their hostel rooms. It will be their choice that who
will run the master program. Then when connecting to the server,
they should be able to decide whether they want to see the board on
their systems or not. This should be enabled with the passing of a
command-line argument while connecting to the server.
How you draw your board is completely up to you. But it must
comply with the standard colors of the Ludo game-board and must
also abide to the game-variables (Number of players etc).
While testing your bot, you can just run the master program on your
system and connect 1 client with board-on and 1 with board-off.

Scoring
There will be a tournament. We will score this assignment based on the following
factors:
Game: Complete handling of all the rules and no error encountered while
your bot plays.(40)
GUI: How well you design the board and tokens!(20)
Tournament: How well you perform in the tournament.(30)
Piazza Participation: How well do you engage in Piazza discussions.(10)

Instructions
You are being provided a zip file which contains 3 folders.
demo1
demo2
code
In each of the demo folders, there are 2 folder client and server.

2
 You will start the server on 1st terminal by executing the command:

server/server {port_number}

More details about server executable can be found by

server/server -h

Similarly start the client program as:

client/client {Server IP} {Server port} {your_bot_executable}

On initialisation your bot will receive a string from server (via client)
something like:

{player_id} {time_limit} {game_mode}

player id : Whether you are player 1 or 2

time limit : If you fail to provide a move within this time limit, your
bot fails.
game mode : 0 means P1 is RED and P2 YELLOW, while 1 means
P1 is BLUE and P2 is GREEN.

You will send and receive moves via STDIN and STDOUT only. You can
print your own verbose in your bot (for debugging puposes) on STDERR.
After this P1 will send a <THROW>message (STDOUT).
The Server will provide you with a string YOU ROLLED 6 6 6 (exam-
ple).
At this time your bot processes the dice input and formulates its move in
the permissible time limit.
Then you send your move(s) to STDOUT.
After this you wait for dice throw of P2 and then its move. (dice message)
and then (move message).
All this should be updated on your GUI mode.
HOW TO HANDLE REPEATS: While designing your bot, you should
handle 2 cases of repeat. Either you get to repeat your turn or the other
player does.
If you get to repeat, that means you have just sent your move and
now you are waiting for the dice of other player. If the message
received at this point is REPEAT instead of a dice message, you
get to go again. Now you have to <THROW>again.

3
 If other player gets to repeat, that means you will be waiting for other
players move. Check if that list of moves is appended by REPEAT.
If yes, skip to the part where you will receive another dice message
and another move message.
MOVES:

Nomenclature for tokens is R0, R1, R2, R3 (similar for other col-
ors). You send moves as R0 4 where 4 will be the no of steps to
take.
You append different moves with a \n as : R0 4\nR1 3.
The appended REPEAT will be done by the server itself.
Any illegal moves will lead to closing of the server and client and
the error message will be shown on the faulty players terminal along
with the terminal of server.
A demo will be explained in the piazza post.