## Entanglement

# Entanglement?

Some time ago there was a game popular over there, called Entanglement:

There are a few implementations of this game under Android:

But there was no such game for iOS. And as I pursued my second M. Sc. degree, I have had a course “iOS development”, where we were learning to use Swift and iOS platform.

As a course project I decided to implement this game. In Swift. Originally the game was implemented
in Swift 2 *(there was no Swift 3 back those days)*.

And recently I decided to refactor the game a bit and update it to the most recent Swift version
*(which is Swift 3 by the moment of writing this post)*.

In this post I’ll describe some interesting decisions I made while creating this game.

# The game

The idea of the game is to prolong the line as much as possible by using the tiles with pieces of path for a line. At the beginning of the game, a single tile is placed at the center of a hexagonal field and the line starts from that tile. You are also given a tile in the “pocket”, which you can swap with the currently active one. At each turn, a game will place a new tile at the end of the line and you have three actions available:

- rotate the current tile clockwise or counter-clockwise, as many times as you want
- swap the current tile with one in the pocket; you can repeat this action as many times as you want too
- place the tile; this action is performed once and can not be undone

But the trick here is: each tile contains six line pieces. And by using one of them, be aware that other pieces might be used later as well.

When you place a tile, you get one point for the first piece of the line, which prolongs it. You also get one point more for the next piece, if it prolongs the line too. For the third line piece you’ll get 3 points and so on. The point here is: the more pieces you connect in a single move - the more points you get.

# Implementation

My implementation contains several core elements:

- tiles
- field
- tile renderer
- game itself

Tiles contain information on the line pieces they contain and provide methods to rotate themselves and find connections with neighbour tiles.

Field contains information on all the tiles on the field - where they are placed and how they are rotated.

Tile renderer simply draws tiles into an image. Doing so allows to have animation for tile rotation.

Game holds all the data on the game state - tile in the pocket, currently selected tile, line path done so far and a score.

# Field

The core of the game are tiles. The tiles are hexagons. And the whole field is hexagonal. The problem was to handle the positions of all the tiles in a handy manner. Thus I decided to go from a standard cartesian coordinate system, which has 90° angle between axes and go for a one with 120°:

Here, `u`

and `v`

vectors represent coordinate axes and `w`

vector is a diagonal. So the tiles
could now be allocated so their centers are at the points of the coordinate system with integer
coordinates:

Now, there’s a tricky thing regarding this coordinate system: how should we know, where to render the actual tile image on a screen? E. g. how can we convert coordinates in this system back to a cartesian one?

After short math on a piece of paper, I’ve implemented a function, which does that:

As you can see, it depends on tile side length. This is the major tile parameter. Since I render tiles based on that parameter.

# Tiles

Each tile should have six lines. To do that, I created 12 *“connection slots”*, two on each
side of a tile, as shown below:

Then, by generating six random pairs of integer numbers from range `[1, 12]`

, we can obtain actual
connections inside a single tile. Then a tile might look like this:

To display a tile, I’ve developed a prototype tile in SVG:

And to make this template re-usable, I’ve dropped in a *“side length”* parameter. Pre-calculating
pins’ slots positions and hexagon’s vertex positions and making it parametric *(with a side length
parameter)*, I’ve got this function, which generates a tile:

Now, if I want to draw connection lines, I can just spicy that code with pre-calculated pin slots connections coordinates and, using some neat line stroke technique, draw tile exactly as shown above:

As you can see, two major things happened here:

- I encapsulated all the parameters like line stroke width and line colors ina a separate class,
`RenderingParams`

- I added rendering lines using two-time rendering technique to emulate borders over connection lines; e. g. I first draw a thick line, filled with the stroke color, which should be applied, and then I render a thinner line with exactly the same coordinates, but different color; doing so, the bottom line becomes just a background for the top one

Now, tiles should be rotated. To do that, two tricks have been applied:

- as we have our tiles drawn as
`UIImage`

, we can simply rotate that image around its center to create the visual effect of rotation - as we have our connection pins as a plain array, we can just re-calculate the indices of connection’s
*“input”*and*“output”*

There are a couple of points, which should be described previous to the algorithm of a tile rotation.

The tiles are connected using those connection pins. And based on the coordinates of a tile and its neighbour, we can tell, which pins of those two will be connected. And since our game goal is to prolong a single line, by keeping track of which connections of which tiles form a line, we may define a couple rules:

- given connected pins inside one tile, we may describe that connection in two pins’ indices, namely
*“input”*and*“output”* - connections of a tile, not involved in forming a line, can be treated in either way - input and output could be named in a reversed order
*(again,***unless they are forming line**, otherwise it’s essential to say where the line comes from and where it ends inside a given tile) - the central tile will have only one output - the one, where the line starts its journey; let it be the connection pair
`(0, 0)`

- one can easily calculate the neighbour’s output, given the last tile of a line path and its successor

Let’s define a class `Tile`

:

Simple enough, right? Now let’s assume our program will fill out `connections`

list automatically and
all the tiles will be assigned the correct list of connections. Given that, we may define two helper
methods on a `Tile`

class:

The first one, `output(from input: Int)`

will return us the output index inside a given tile, where the line
will come out from, when entering our tile from input with index `from`

.

So, for example, given a tile with connections

the call `t.output(from: 11)`

will give us `8`

, which could be easily found from the list of connections
by hand.

The second method will give us the input index inside the neighbour tile, which is connected to an output of the given tile.

And for the example above, the call `t.input(from: 0)`

will give us `7`

. And here’s an image to show why:

Since there is only one way of correctly placing each next tile, this behavior is constant for any of two successive tiles.

And now it’s finally the time to explain the rotation of the tiles!

After a tile has been assigned a set of connected pins, the rotation should preserve those connections.
The rotation operation uses modulo operation, as in case with calculating neighbour tile’s input pin index,
but in a scale of each connection pair *(pair of input and output)*:

Here, `direction`

is either `1`

for clockwise rotation or `-1`

for counter-clockwise rotation.

# Path prediction

Finding a place where to put the next tile is an iterative process, which hardly depends on a current tile (its connections and position) and the tiles which are already placed on the field.

At the very beginning of the game, the next place could be set as a constant and is always above the
central tile *(so if the central tile has position (4, 4), then the next place would be (5, 5) - along the diagonal in our coordinate system)*.

To track the boundaries of a field and the beginning of the line *(in other words - the places, where the line can not go)*, I inherited a `Tile`

class with a set of other classes just to track if the game can
continue or not: `ZeroTile`

and `BorderTile`

represent restricted bounds of a game field.

Now, given the output of a current tile, which the line will use to continue through the tile, we can predict where the next tile should be put on a field:

If, however, there is a tile at the next place on the field, we should use its connections to determine the next position.

Otherwise, if the next position is either the border of a field or an empty space - we stop the search.

Search itself is just as simple as that:

# Counting points

This task is quite simple, compared to the others described above. When a user places a tile, we estimate
the length of a predicted path and add numbers from `[1..L]`

*(where L is the length of the predicted path)*
to score. This could be expressed as a sum of a finite arithmetic sequence with a step of

`1`

:

# UI, AppStore and others

The end result of this coding excercise looks like at the very top of this post:

During the course at the university, I was made to add a database, networking and a couple more views
to the game *(to show that I did learn something during the course)*. But for the end-user those are
not necessary. I’ve added Facebook login, local database of high scores and views for those. But at its core,
the game does need some refactoring, which is what happening right now *(the code in this post does not strictly correspond to the one on a GitHub, but rather has major enhancements)*. Unless it is done - the game probably won’t appear in
the AppStore. But hopely it will come to your phone once!