Thymio plays Tic-tac-toe

# Introduction :

This project was completed as part of the optional computer course 2013-2014 at the Beaulieu High School of Lousanne. The purpose of this rated work was to implement an application allowing two people to play "Tic-tac-toe" (Noughts and Crosses) with Thymios robots.

## Material :

• 2 Thymios
• A3/A2 paper sheet
• Ballpen

# Approach

## General concept :

This project uses two Thymios. The first is used to draw the shapes on the 3 x 3 Tic-tac-toe area, it is called "designer". The second deals with the management of user turns and boxes (wins/draw), the user actions, verification of their validity as well as the sending of the selected coordinates to the designer robot, this robot is called "master".

## Operation of the "designer" :

The designer code is separated into 3 blocks, the first represents the basic motor functions setting the engine speed for forward, backward, rotate, etc. These are used in the second block, represented by loops in an //onevent timer // allowing the Thymio to create such complex figures as a cross, a square, rotations and linear movement. All figures are based on incrementing a counter that indicates to the Thymio which motor function to use and when (based on the Thymio drawing model).

The third block is capable of giving a set of instructions for the second block to perform according to its destination square. It could be summarised thus: reception of the destination square by the prox.comm box → moving on the x-axis → movement on the y-axis → drawing of the appropriate shape depending on the player's turn. The designer uses the following features of the Thymio:

• Motors
• Inter-robot communication
• Ballpen for drawing
• Leds for visual information

## Operation of the "master" :

The behaviour of the master can be described thus: start of the game → perform the moves → game ends with a win/draw. A move is composed of different parts: beginning of the move → column/x-coordinate selection → confirmation → line/y-coordinate selection→ confirmation → validation/refusal of the coordinate entry → checking the status of the boxes (win/ or not) → If not: sending the "designer" the destination coordinate, waiting for the response of the designer and end of the round, if no win: end.

The choice of the column and row is made with the side buttons of the Thymio, confirmation with the centre button. Information is currently passed via light and sound, the leds and the speaker indicates: which player must play (bottom right: green/red), is the player selecting the column/row (bottom left: green/violet), what is the current value of x/y (/ / leds.circle//)

The game is managed by a list (array) of 9 integers, allowing a real 3 x 3 table to be simulated. Each of these integers can take 3 values:-1 if it was played by the player 2, 0 if it is empty, 1 if it was played by player 1. For a coordinate to be accepted, the destination box must be empty, otherwise an exception is raised. This array also serves to manage the victory of one of the players, it is enough when verifying to total each row/column/diagonal. If one of these sums gives 3 or - 3, we know that one of the two players has won. If the coordinate is validated, it is sent to the designer in the form "xy", and is there extracted.

The master therefore uses the following features of the Thymio:

• Inter-robot communication
• LEDs and speaker to transmit the information concerning the progress of the game
• Buttons to manage the game

# Implementation

Here is a typical example of a game:

## Discussion and possible improvements :

### Concerning the "designer" :

Motor rotation speed varies depending on the state of charge of the robot. This implies that when the robot should turn through a right angle, the angle turned is not always correct. It is similar for the rest of the drawings even if the effect is less noticeable. In the instructions the motor speed passes through zero between each change of speed in order to keep the shapes as similar as possible over time.

### Concerning the "master" :

The onevent button seems to trigger much too often, certainly at a frequency of 50 Hz. This implies that one simple touch of a button executes the associated loop about 3 to 5 times. To circumvent this problem, I use a timer with a flag allowing to have direct control over the duration of a button touch and the time between 2 touches. The whens seem to want to trigger randomly once the condition is met. I therefore did not rely on this possibility during the creation of the master.:
To make less random and more accurate drawings, it would have been possible to change the way the designer moves on the game area. For example, one could represent the boxes by black lines and make sure that the designer follows them. However, such a change would require a rethink of the whole operation of the designer. For the master, one might wonder about the idea of a feature that allows to play new games maintaining an evolving tally, because it is rare in real life to play only one game of tic tac toe. A way should however be found so as not to confuse the games, for example by changing the pen.
Adding a playing heuristic to the master, allowing to chose if to play against thymio or against another user.