Hamiltonian MakerBreaker games on small graphs
Abstract
We look at the unbiased MakerBreaker Hamiltonicity game played on the edge set of a complete graph , where Maker’s goal is to claim a Hamiltonian cycle. First, we prove that, independent of who starts, Maker can win the game for and . Then we use an inductive argument to show that, independent of who starts, Maker can win the game if and only if . This, in particular, resolves in the affirmative the longstanding conjecture of Papaioannou from [11].
We also study two standard positional games related to Hamiltonicity game. For Hamiltonian Path game, we show that Maker can claim a Hamiltonian path if and only if , independent of who starts. Next, we look at Fixed Hamiltonian Path game, where the goal of Maker is to claim a Hamiltonian path between two predetermined vertices. We prove that if Maker starts the game, he wins if and only if , and if Breaker starts, Maker wins if and only if . Using this result, we are able to improve the previously best upper bound on the smallest number of edges a graph on vertices can have, knowing that Maker can win the MakerBreaker Hamiltonicity game played on its edges.
To resolve the outcomes of the mentioned games on small (finite) boards, we devise algorithms for efficiently searching game trees and then obtain our results with the help of a computer.
1 Introduction
A positional game is a hypergraph , where is a finite set representing the board of the game, and is a family of sets that we call winning sets. In MakerBreaker positional games, the players are called Maker and Breaker. In the course of the game, Maker and Breaker alternately claim unclaimed elements of the board , one element at a time, until all of the elements are claimed. Maker wins the game if he claims all elements of a winning set, while Breaker wins if he claims an element in every winning set. Each game can be observed in two variants, depending on which player is to play first.
The positional games we intend to study are played on graphs, and in particular, on the edge set of a complete graph . Our prime interest lies with Hamiltonicity game , where the winning sets are the edge sets of all Hamiltonian cycles in . The game was first introduced by Chvátal and Erdős in [1], and since then it has been one of the most studied positional games on graphs, see [4, 6]. It was shown in [1] that Maker has a winning strategy for all sufficiently large . Papaioannou [11] later proved that Maker wins the game for all , and at the same time conjectured that the smallest for which Maker can win is . Hefetz and Stich [5] further improved the upper bound by showing that Maker wins for all . We note that these statements hold under the assumption that Maker is the first to play.
In the present paper, we determine the outcome of Hamiltonicity game for every value of , and for each of the players starting the game. In particular, this resolves the mentioned longstanding conjecture of Papaioannou in the affirmative.
Theorem 1.
In the MakerBreaker game on , Maker, as first or second player, wins if and only if .
Next, we look at two games where Maker’s goal is to claim a Hamiltonian path. In Hamiltonian Path game , first introduced in [11], the winning sets are the edge sets of all Hamiltonian paths in . We are able to show the following.
Theorem 2.
In the MakerBreaker Hamiltonian Path game on , Maker, as first or second player, wins if and only if .
This theorem is a strengthening of Papaioannou’s result from [11] where he proved that Maker, as first player, can win if and only if .
In Fixed Hamiltonian Path game , the goal of Maker is to claim a Hamiltonian path between two fixed (predetermined) vertices, . Even though in the literature this game does not draw as much interest as and , it has appeared as an auxiliary game when studying some other games on graphs, see e.g. [2].
Theorem 3.
In the MakerBreaker Fixed Hamiltonian Path game on , Maker, as first player, wins if and only if , and as second player he wins if and only if .
Note that in the game the edge between the fixed vertices and actually does not participate in any winning set, so right away we obtain the same result for the game played on .
Here we also want to mention two other standard positional games, Connectivity and Perfect Matching, where Maker’s goal is to claim, respectively, a spanning tree and a perfect matching. For both of these games it is straightforward to determine the outcome for every size of the board. Maker wins the Connectivity game as first player for every , and as second player if and only if . In Perfect Matching game, where is even, Maker can win as first or second when is at least . On top of that, he wins also for when he plays first.
Let us note that even though answering the question of who wins a game on a small board (with fixed) is a finite problem, it still may have a greater scientific impact for several reasons. First of all, the approaches we use to resolve standard positional games when is large often do not apply for small , and in that case in order to determine the outcome we need to develop new methods. As we saw, resolving the “small cases” is straightforward for some games, but not for all.
Also, standard positional games, like Hamiltonicity, Hamiltonian Path, Connectivity, etc. are often used as auxiliary games when studying other positional games on graphs. Sometimes these auxiliary games have boards of fixed size, and knowing their outcome is essential for completing the analysis. An example of that can be found in [3], where one of the problems tackled was to estimate the smallest number of edges a graph on vertices can have, knowing that Maker as first player can win the MakerBreaker Hamiltonicity game played on its edges. It was proved in [3] that , for all . We show how to apply our results about Hamiltonicity game in Theorem 1 and Fixed Hamiltonian Path game in Theorem 3 to improve this upper bound, eventually obtaining the following.
Theorem 4.
For , we have .
Positional games are combinatorial games (sequential two player games with perfect information and no randomness involved), and it is well known (see, e.g., [12]) that we can find out which of the players has a strategy to win by simply traversing the whole game tree of the game. But this fact alone is of limited practical use, knowing that already for games on relatively small boards the game trees are way too big (they are exponentially large in the size of the game board) to be completely traversed by a computer. In particular, if the board of the game is , its size is , so there are different game plays.
Often there is no need to search through the whole game tree, as some moves are “analogue” to the others, we may arrive to the same game position more than once, and on top of that some game positions are “similar” to the others. In Section 5 we devise a sophisticated set of algorithms that formalizes and exploits these “similarities” as part of the optimization of the brute force search algorithm. This enables us to write a computer program that efficiently calculates the outcome of all three mentioned games for enough initial values of to inductively determine the outcome of the game for every .
When implementing the algorithms we aimed at doing it in a generic way to make our code easily adaptable for other positional games on graphs. Even though some algorithms are tailored to fit the particularities of the games we analyzed, most of them are generally applicable for determining the outcome of positional games on graphs with the help of a computer. Having that in mind, our software can be seen as a general framework for computer based attacks on positional games.
1.1 Preliminaries and organization
Our graphtheoretic notation is standard and follows the one from [16]. In particular, we use the following. For a graph , let denote its set of vertices and its set of edges, where and . For a set , let denote the subgraph of induced on the vertex set and let denote the set of edges of with both endpoints in .
Results presented in this paper rely on the following statement, see e.g. [4].
Theorem 5.
If Maker (or Breaker) has a winning strategy in some positional game as second player, then he also has a winning strategy if he starts the game.
If a MakerBreaker game played on edges of a graph is in progress, Maker’s (respectively, Breaker’s) vertex degree of a vertex , denoted by (respectively, ), is the number of edges incident to that are claimed by Maker (respectively, Breaker). Maker’s edge degree of an edge , denoted by , is defined to be , and Breaker’s edge degree is .
The rest of the paper is organized as follows. In Section 2 we prove Theorem 1, in Section 3 we prove Theorem 2 and in Section 4 we prove Theorem 3. Section 5 contains the description of the algorithms and optimization methods used in our computer programs, as well as the results we obtain with their help. In Section 6 we show how our results can be applied in solving other problems in theory of positional games, by proving Theorem 4. Finally, in Section 7 we give some open problems and ideas for future work.
2 Hamiltonicity game
The following lemma lies in the foundation of our proof of Theorem 1.
Lemma 6.
Independent of who starts the game , Breaker wins for , and Maker wins for and .
We prove this result with the help of a computer. Description of the approach used is postponed to Section 5.
The previous result gives us a firm induction base for proving that Maker can win for all . We note that Papaioannou already proved the induction step of size for Maker as first player, which can be paired up with our Lemma 6 to resolve the case when Maker is first. Inspired by his work, in the following lemma we prove the same induction step for Maker playing as second player, which eventually completes the proof of Theorem 1.
Lemma 7.
If Maker, as second player, wins , he can also win as second player.
Proof.
Suppose that Maker, as second player, has a strategy to win . We will present Maker’s winning strategy for .
At the beginning of the game, Breaker will claim some edge and Maker’s response will be to claim an edge for some . Let . We can now partition the set of all unclaimed edges into two sets, the first set being and the second one . These edge sets are shown in the Figure 1.
From this point on, Maker will try to respond to every move of Breaker by claiming the edge in the same edge set as Breaker e.g. whenever Breaker claims an edge in Maker will also try to claim an edge from , . If this is not possible, he will claim an arbitrary edge in the other set. It is generally true that such “extra” edges can be “forgotten”, i.e. if Maker can accomplish something in the other set without the extra edge, he will still manage to do it with the extra edge, see e.g. [4].
Maker will play in using his winning strategy for , meaning that by the time all edges in are claimed he will fully occupy some cycle in .
When playing in Maker’s goal is to make sure that by the time all the edges are claimed (in both and ) he claimed a Hamiltonian cycle. This Hamiltonian cycle will be an extension of to a cycle on two more vertices, now also containing the edge . More precisely, in order to extend the cycle , Maker wants to claim edges , such that the edge and . That way, Maker would claim a Hamiltonian cycle , as shown in Figure 2.
During the game, if for a vertex both edges and are claimed by Maker (Breaker), we say the vertex is isolated by Maker (Breaker). If one of the edges and is claimed by Maker (Breaker) and the other one is unclaimed, we say the the vertex is half isolated by Maker (Breaker). Finally, if both edges and are unclaimed, we say that the vertex is free. When all the edges are claimed, we observe the following two situations.
Situation 1: Breaker isolated at most one vertex, and Maker claimed an edge in incident to each of vertices and .
Situation 2: Breaker isolated two vertices, Maker has one isolated vertex , and Maker claimed an edge from incident to each of vertices and .
First, let us prove that in each of the two above mentioned situations Maker created a Hamiltonian cycle and thus won the game. We can apply simple labeling procedure, assigning a label set to each vertex . This set contains if and only if edge is claimed by Maker and if and only if edge is claimed by Maker.
In Situation 1, since Maker claimed an edge in incident to each of vertices and , at least one vertex is labeled with , and at least one vertex is labeled with . Also, there is at most one vertex with empty label set, so in every Hamiltonian cycle there must exist two adjacent vertices and containing labels 0 and 1, respectively. Maker will then use these vertices and to extend the cycle .
In Situation 2 there is a vertex with label set . If this vertex is adjacent to some vertex whose label set is not empty, Maker can extend the cycle using and . Otherwise, if vertex is adjacent to vertices whose label set is empty (two vertices isolated by Breaker), then Maker will be able to extend for the same reasons as in Situation 1, since he claimed an edge from incident to each of vertices and .
Next, we are going to give a strategy for Maker that will enable him to always end up in one of these two situations.
Maker’s strategy on .
In each move, Maker will apply the first applicable rule in the following list:

If there is only one free vertex left, and Maker has not claimed any edges incident to a vertex , he claims the edge .

If there exists a vertex half isolated by Breaker, Maker picks an arbitrarily half isolated vertex and claims the other edge incident to .

If there exists a free vertex, Maker picks an arbitrarily free vertex and claims one of its free edges. Of the two edges, he prefers the edge incident with the vertex in incident with less edges claimed by Maker (if such vertex exists).

Maker claims a free edge incident to a vertex half isolated by Maker. Of all such edges, he prefers edges incident with the vertex in incident with less edges claimed by Maker (if such vertex exists), breaking ties arbitrarily.
As any free edge is incident either with a vertex half isolated by Breaker, or a free vertex, or a vertex half isolated by Maker, this is a valid strategy.
Initially, Breaker has claimed one edge, the edge . For his first move in he essentially has only three different choices, shown in Figure 3 (along with the move of Maker that will follow in each of the cases).



Now, let us analyze each of the three cases from Figure 3 individually.
Case (a): In this case, Breaker first has an option to isolate a vertex . If he indeed does so, Maker will apply Rule 3 and claim an edge incident to a vertex , otherwise Maker will apply Rule 2 and claim an edge incident to . When Breaker isolates a vertex, Maker will apply Rule 2 in the remainder of the game to prevent Breaker from isolating more vertices. The proposed strategy thus inevitably puts Maker in Situation 1.
Case (b): Again, Breaker can start by isolating a vertex which inevitably puts Maker in Situation 1 as this is analogous to Case (a). Otherwise, Maker will wait (by applying Rule 2) for Breaker to isolate some vertex, until there is only one free vertex left. If Breaker isolates a vertex during this period of the game Maker will apply Rule 3 claiming an edge incident to and he will spend the remainder of the game applying Rule 2 in order to prevent Breaker from isolating more vertices. It can happen that Breaker does not isolate any vertex by the time there is only one free vertex left, in which case Maker will end the game by applying the Rule 1 as shown in Figure 4. Therefore, Maker will inevitably find himself in Situation 1.
…  
Case (c): In this case we will need to further analyze each of the three possible Breaker’s moves. Breaker can either claim an edge incident to the only vertex half isolated by Maker, or for some free vertex he can claim or . These three possibilities are shown in Figure 5 (along with the move of Maker that will follow in each of the cases).



In cases (i) and (ii), which are essentially the same, Maker claimed an edge incident to each of vertices and while Breaker already isolated a vertex . Maker will continue the game with only goal to prevent Breaker from isolating more vertices, by applying Rule 2 whenever it is possible, and hence the game will eventually end up in Situation 1.
In the third case we will first analyse the game until there is only one free vertex left. Maker is again focused on preventing the Breaker from isolating a vertex by applying Rule 2 whenever possible. If during this period of the game Maker claims some edge incident to , Rule 1 will not be applied, and the game will finish in Situation 1. If it happens that Rule 1 needs to be applied, Maker will claim an edge , where is the last free vertex. Depending if Breaker now isolates a vertex or not, the game can end up in different situations. If Breaker does not isolate the game ends in Situation 1. Otherwise, after vertex is isolated by Breaker, Maker isolates and the game ends in Situation 2.
Hence, Maker can always create one of the two winning situations. ∎
3 Hamiltonian path game
In order to complete the proof of Theorem 2 we used our computer program to obtain following result.
Lemma 8.
Independent of who starts the game , Breaker wins for , and Maker wins for .
Description of the proof and the approach used is postponed to Section 5.
Proof of Theorem 2.
It is easy to see that Maker’s win in Hamiltonicity game implies Maker’s win in Hamiltonian path game since each Hamiltonian cycle contains a Hamiltonian path. This means that Theorem 1 also tells us that Maker can win for all as second player. When we combine this with the result from Lemma 8 proof of Theorem 2 is complete. ∎
4 Fixed Hamiltonian Path game
The following lemma will cover several finite cases in the proof of Theorem 3.
Lemma 9.
When Maker starts the game , Breaker wins for , and Maker wins for .
When Breaker is the one who starts, he wins for , while Maker wins for .
We prove this result with the help of a computer. Description of the approach used is postponed to the following section.
It remains to determine the outcome of the game for larger values of . We will not perform an induction step, but rather rely on our knowledge of the outcome of . Combining the following result with Theorem 1, along with Lemma 9 that covers the few initial cases, we readily prove Theorem 3.
Lemma 10.
If Maker, as second player, wins , he can also win as second player.
Proof.
Suppose that Maker, as second player, has a strategy to win . We will present Maker’s winning strategy for , with two fixed vertices and .
As we already noted, the edge is not interesting to either of the players since it is not contained in any of the winning sets. Let . We can partition the set of all unclaimed edges into two sets, the first set being and the second one .
Now the goal of Maker is exactly the same as in the proof of Lemma 7 – he wants to build an cycle on , and he wants to play on to connect vertices and to two neighboring vertices of that cycle. As the structure of and here is exactly the same, with exception of having one more unclaimed edge (which is only beneficial for Maker), he can follow the same strategy as in the proof of Lemma 7 and win the game. ∎
5 Algorithmic analysis
In this section we present the techniques and approaches used in our computer program to solve games , and when game boards are relatively small, as well as some of the major challenges we encountered during the process.
Our program is available at http://people.dmi.uns.ac.rs/~nikola.trkulja/ham.html, where one can find all the information on how to run and use it, along with the source code.
5.1 Traversing the game tree
As we already noted, in order to determine the winner of a particular game, we need to completely traverse the game three, which essentially comes down to simulation of all possible plays. This means that in each round we need to explore all valid moves a player can play. To achieve this we used the following algorithm which represents an adaptation of the standard and wellknown game theoretic algorithm – Minimax [12].
Main procedure of our algorithm is procedure Play, in charge of recursively exploring the whole game subtree starting from the given tree node (containing the current game board , and the identity of the player whose turn it is). The value returned by procedure Play corresponds to the player winning the game on board , when player moves first. As the name suggests, procedures and are used to mark and unmark, respectively, the edge as claimed by player on board .
The winner detection is an essential part of the algorithm, done by procedure PlayerWins. Every time the winner is not immediately detected by procedure PlayerWins, we continue recursively exploring the game tree. The algorithm stops processing the remaining possible moves for current player as soon there is a move which guaranties the win. On the other hand, if it turns out that there is no such move, we know that the other player wins the game.
5.2 Isomorphism pruning
Basic version of the algorithm we just described can be improved so that the same game subtrees are not explored multiple times. This is where transposition table [10] jumps into picture. Straightforward application of transposition table would be to store the winner for each game tree node, and then use these values to skip processing identical nodes. But the exponential size of the game tree renders such solution impossible because it would require huge amounts of computer memory. Much more efficient way of handling this situation is to recognize the isomorphic nodes of the game tree. For this task we implemented Brendan McKay’s canonical labeling algorithm [7]. Canonical labeling of a graph is defined in the following way.
Definition 11.
Canonical labeling is a function mapping graphs to graphs, such that every graph is isomorphic to , and for every graph isomorphic with we have .
In other words, canonical labeling gives a unique representative for each class of isomorphic graphs, and with McKay’s algorithm we can define and compute this graph in an efficient manner. That enables us to prune the game tree significantly, as we can store the winner only for canonical labelings.
5.2.1 Edge colored graphs
When a MakerBreaker game is played on the edge set of a graph, the situation on the game board can be seen as a 3coloring of the edges, as each edge is either unclaimed (black), claimed by Maker (red), or claimed by Breaker (blue).
One of the issues in application of McKay’s canonical labeling algorithm emerges right here because the original version only handles noncolored and vertex colored graphs out of the box. In [9] the author of the algorithm described how edge colored graph can be transformed into equivalent vertex colored graph which can then be fed as an input to canonical labeling algorithm (an interested reader can find more details in [13]). Unfortunately this transformation produces a graph with more vertices than the original graph (even when we have just two colors, the number of vertices doubles), so we did the implementation from scratch, having [15] in mind.
5.2.2 Nontransitive winning sets
Another issue with detection of isomorphic game tree nodes emerges when dealing with Fixed Hamiltonian path game since this game has an additional property compared to the other two games we worked on – there are two predefined vertices that require special attention. Therefore, we have to incorporate an additional condition, only taking into account the isomorphisms which map those two vertices to themselves.
We further slice down each isomorphism class into subclasses defined in the following way.
Definition 12.
We say that graph with predefined vertices is in the same isomorphism subclass as graph with predefined vertices if and only if , and isomorphism functions and transforming and into , respectively, are such that .
Applying this definition to our problem, we chose sets and to be sets of endpoints of winning sets in , meaning that Maker wins the game on if and only if he wins on .
5.3 Move ordering
Our algorithm is not processing the whole game tree but rather skipping some of the subtrees whenever it is sure about the outcome of that particular subtree. For example, when Maker is the one to claim an edge, we will test all the possible moves that he can play, one after another, until we find the one that guarantees his win (provided that such a move exists). Of course, it would be better that we probe a winning move as early as possible. Having this in mind we tested a number of heuristics for defining the order of the iteration over free edges in line LABEL:al:move_ordering of Algorithm 1.
We relied on sorting the free edges according to a predefined criterion. Particularly, free edges are sorted in nondecreasing order according to Maker’s edge degree for Maker’s moves, and in nonincreasing order according to Breaker’s edge degree for Breaker’s moves. The idea behind this is that, informally speaking, Maker may want to prefer playing where his “weakest link” is, while Breaker may prefer choosing to enforce his “strongest disconnecting point” first.
It turned out this optimization technique, implemented as described, is one of the most important ones, and it had a tremendous impact on the performance of our algorithm making the number of traversed game tree nodes significantly smaller.
5.4 Winner detection
Procedure is essential for checking if the board of the game is such that the player won the game^{2}^{2}2If is Maker, he won if he claimed a whole winning set, and if is Breaker, he won if he claimed an edge in each of the winning sets.. In order to efficiently implement this task we always did precomputation of the set of winning sets that are free of Breaker’s edges. E.g. in game we pregenerate the set of all Hamiltonian cycles in , and then we constantly update so that in each moment it contains only the winning sets without any edges claimed by Breaker.
5.5 Optimization of memory usage
Several optimization techniques applied in our software are on the technical i.e. implementation level, and majority of them are computer memory related. This is natural since we rely on transposition table in order to keep track of calculated values for visited game tree nodes, or more precisely their isomorphism classes, and even for relatively small graphs the number of these classes is extremely large.
Utilizing sets in many components of our program we are able to achieve optimal ratio of time and memory efficiency. Sets are used to implement graphs, canonical labelings, winning sets and most importantly transposition tables. Of course, we needed efficient implementations of sets and for that job we used bitsets and highperformance 3rd party set implementations (in the form of Trove library [14]).
After all this effort, our transposition tables were still not able to cope with the required amount of entries because of the limited computer memory. To solve this problem, we applied various heuristics to clean the tables i.e. to remove the “less important” entries and free up the memory for the “more important” ones. One efficient technique to do this was to focus mainly on entries coming from lower depths of the game tree, say depths less than or equal to a fixed integer , so whenever we detect that table is full all entries coming from depths larger than are removed from the table.
5.6 Implementation, testing and results
Implementation was done using Java programming language, relying only on standard Java libraries with just one additional component, the already mentioned 3rd party high performance collections library – Trove [14]. There are two main parts of our computer program, Minimax algorithm and Brendan McKay’s canonical labeling algorithm. We chose to implement canonical labeling algorithm on our own in order to be more flexible and tailor the algorithm fully to our needs. We note that there are implementations of related algorithms available online (e.g. [8]).
While implementing the algorithm we followed the idea of doing it in a generic way to make our code easily adaptable for solving other positional games on graphs as well. Examples of this can be seen when browsing through our code since for all three games we exploited this approach, using the same code base with just minor modifications for each particular game.
For testing purposes we used various revisions of Java version 6 and 7, and on top of that we ran the program on a number of different versions of three different operating systems, Windows, Mac OSX and Linux, all in the effort to minimize the possibility of error coming from any of these layers. We further conducted thorough testing of both of the main parts of our implementation using unit tests, in order to eliminate the possibility of errors coming from smaller components of our program. In the end, we put a lot of additional effort to verify that our implementation of Brendan McKay’s algorithm is correct by comparing output of our implementation with the one provided by the author [8] for many different types of graphs.
Thr machine used for testing was Fujitsu Celsius M730 with Intel Xeon E51620 processor running at 3.7 GHz, 32GB of RAM and with Ubuntu operating system. We were able to prove following statements using this machine.
Proof of Lemma 6.

0s  0s  0.1s  1s  2s  30s  

Winner  Breaker  Breaker  Breaker  Breaker  Maker  Maker 

0s  0s  0.1s  1s  3s  68s  

Winner  Breaker  Breaker  Breaker  Breaker  Maker  Maker 
∎
Proof of Lemma 8.

0s  0s  0s  0.3s  

Winner  Breaker  Maker  Maker  Maker 

0s  0s  0.1s  0.3s  

Winner  Breaker  Maker  Maker  Maker 
∎
Proof of Lemma 9.

0s  0s  0.5s  3s  110s  3990s  

Winner  Breaker  Breaker  Breaker  Maker  Maker  Maker 

0s  0s  0.1s  2s  230s  16286s  

Winner  Breaker  Breaker  Breaker  Breaker  Maker  Maker 
∎
6 An application
Generally speaking, the most direct way to show that a player wins a positional game is to exhibit an explicit strategy for the player, proving that it is a winning one. There are numerous cases (see [4] for examples) that such a strategy relies on strategies for one or more auxiliary positional games, where the auxiliary games are often confined to some part of the board and/or some stage of the game play.
Our results are applicable when such auxiliary games have Hamiltonian cycles or Hamiltonian paths as winning sets, and they are played on boards of fixed size. An example of that can be found in [3, Theorem 1.4], when estimating the smallest number of edges a graph on vertices can have, knowing that Maker as first player can win the MakerBreaker Hamiltonicity game played on its edges. Using our results from Theorem 1 and Theorem 3, we are able to improve the upper bound on .
In [3] it was showed that for , by explicit construction of a graph with vertices and edges, along with a proof that Maker can win the game playing on . The graph was constructed by dividing vertices into sets , with , such that , where , and contains exactly vertices. As for the edges of , for every , every two vertices in are connected with an edge (i.e. the graph induced on is a clique), and on top of that, for every , there is an edge between and every vertex of both and (indices are observed modulo ). All of this totals to no more than edges.
To prove that Maker can win Hamiltonicity game on , the authors of [3] relied on the fact that Maker wins on for all , as was the smallest known such at the time. This was later improved by Hefetz and Stich [5] to , and now our Theorem 1 gives the optimal . Having this in mind we can repeat the exact same proof with an adjusted construction of , reducing the size of all by setting , and getting an immediate improvement of the upper bound to .
But, it turns out that with the help of Fixed Hamiltonian Path game we are able to alter the construction and get an even better upper bound.
Proof of Theorem 4.
We will first describe our construction of the graph whose edge set will be the board of the game, and then we will prove that on this board Maker indeed can win Hamiltonicity game.
Let , and let and be integers such that . The vertices of are partitioned into sets , such that , , and , . Next, we arbitrarily pick vertices , , and define , where indices are observed modulo . The set of edges of is defined with
In other words, the graph consists of a “cycle” of cliques, where each two consecutive cliques overlap on a vertex, and each clique is missing exactly one edge (between the two vertices it shares with the neighboring cliques). The number of edges in is
If , this is upper bounded by .
To win Hamiltonicity game on , Maker simply plays Fixed Hamiltonian Path games in parallel, one on each of graphs , . More precisely, in each of those games Maker, as the second player, plays the game , with fixed vertices and . As we previously observed, the edge does not participate in any winning sets, so Theorem 3 guarantees Maker’s win in all those games. Hence, for every , Maker can claim a Hamiltonian path on with endpoints and . These paths together form a cycle that covers all vertices of , so Maker wins the Hamiltonicity game on . ∎
Even though our proof works for , we can similarly obtain a nontrivial upper bound for any . Indeed, we can construct a graph consisting of a “cycle” of (two or more) cliques in the exact same way as in the previous proof, just making sure that each clique has at least vertices. Then we can borrow Maker’s strategy from the previous proof, as well as the argument that he can claim a Hamiltonian cycle playing on that graph.
7 Future work
We have resolved three unbiased games played on the edges of a complete graph, Hamiltonicity game, Hamiltonian Path game and Fixed Hamiltonian Path game, for every and for each of the players starting the game. One related game that remains out of reach is the socalled HamiltonianConnectivity game, where Maker’s goal is to claim all edges of some spanning Hamiltonianconnected graph (a graph in which every two vertices are connected by a Hamiltonian path). This game may be utilized in a similar way as Fixed Hamiltonian Path game, but with more freedom – what were two fixed (predetermined) vertices in Fixed Hamiltonian Path game, become any two vertices in HamiltonianConnectivity game. For that reason, we think that knowing the outcome of the game for every would be valuable.
One consequence of finding the winner of a game using a computer is that typically we do not have a compact graphtheoretic description of a winning strategy for the winner. This is true for all games on small boards that we looked at – we know who wins, but this knowledge is not accompanied by a coherent strategy (other than a huge list of winning moves, one for each game position).
Because our computer program is implemented in a generic way it could be fairly easily adapted for attacking other positional games when played on small (enough) boards. We are hoping that other positional games can be solved using the tools developed in this paper.
References
 [1] V. Chvátal and P. Erdős. Biased positional games. Annals of Discrete Mathematics, 2:221–229, 1978.
 [2] D. Clemens, A. Ferber, R. Glebov, D. Hefetz, and A. Liebenau. Building spanning trees quickly in MakerBreaker games. SIAM Journal on Discrete Mathematics, 29(3):1683–1705, 2015.
 [3] D. Hefetz, M. Krivelevich, M. Stojaković, and T. Szabó. Global Maker–Breaker games on sparse graphs. European Journal of Combinatorics, 32(2):162–177, 2011.
 [4] D. Hefetz, M. Krivelevich, M. Stojaković, and T. Szabó. Positional Games. Oberwolfach Seminars 44. Birkhäuser, 2014.
 [5] D. Hefetz and S. Stich. On two problems regarding the Hamiltonian cycle game. The Electronic Journal of Combinatorics, 16(1):R28, 2009.
 [6] M. Krivelevich. The critical bias for the Hamiltonicity game is . Journal of the American Mathematical Society, 24(1):125–131, 2011.
 [7] B. D. McKay. Practical graph isomorphism. Congressus Numerantium, 30:45–87, 1981.
 [8] B. D. McKay and A. Piperno. Practical graph isomorphism, II. Journal of Symbolic Computation, 60(0):94–112, 2014.
 [9] B. D. McKay and A. Piperno. Nauty and Traces User’s Guide (Version 2.6). Technical report, 2016.
 [10] I. Millington and J. Funge. Artificial Intelligence for Games, Second Edition. Morgan Kaufmann Publishers Inc., 2nd edition, 2009.
 [11] A. Papaioannou. A Hamiltonian game. Annals of Discrete Math, 13:171–178, 1982.
 [12] S. Russell and P. Norvig. Artificial Intelligence: A Modern Approach. Prentice Hall Press, 3rd edition, 2009.
 [13] C. Spermann and M. Leuschel. ProB gets Nauty: Effective Symmetry Reduction for B and Z Models. In TASE, 15–22. IEEE Computer Society, 2008.
 [14] Trove. Trove  High Performance Collections for Java. http://trove.starlightsystems.com. Online; accessed December 19, 2016.
 [15] E. Turner, M. Leuschel, C. Spermann, and M. Butler. Symmetry Reduced Model Checking for B. In TASE, 25–34. IEEE Computer Society, 2007.
 [16] D. West. Introduction to Graph Theory. Prentice Hall, 2001.