Improving Game Modeling for the Quoridor Game State Using Graph Databases
Abstract
Artificial intelligence has gained great importance in the last decades because based on its techniques, it is possible to make autonomous systems. In addition, it is possible to make those systems able to learn based on the previous interactions with users. This paper presents one proposal for an agent to play the Quoridor game based on some improvements in the graph model of the board. It is done by using artificial intelligence techniques to provide the capacity to learn through games played against users. Thus, learning is achieved through the use of game trees, where some of the nodes are going to be stored using a graph database. Since graph databases are one of the subgroup of the noSQL databases, which focuses in the relation representation between nodes, such databases are suitable for this kind of approaches.
Keywords
Game tree Quoridor Graph databases Minimax1 Introduction
The Quoridor game was designed by Mirko Marchesi and published by Gigamic Games in 1997. It received the Mensa Mind Game award in 1997 and the Game Of The Year in USA, France, Canada and Belgium. It has gained attention in the research community since several studies are being made to mastering this game. The reason is that despite its rules are simple, it has complex strategies to study. Furthermore, the game has a big branch factor and game tree order, which is similar to the chess game.
In the last thirty years, the studies around the game theory has increased in order to make proposals that improve the way as an artificial agent can deal with games with a certain complexity. Of course, the use of a strong hardware is a really important aspect. For instance, Deep Blue was able to review explore 200.000.000 of positions per second, which means that it was able to make a deeper search in the game tree in less time [1]. In this paper, we focus on the model of the game state since there is no a lot of research in defining its heuristics.
Graph databases are in the group of noSQL databases, which are focused on the relations between the data stored in the database, among other facilities like the semantic of the model, which can be shared directly to an expert (in this case a game player).
The rest of the paper is structured as follows: Sect. 2  explanation of the game, Sect. 3  an explanation of the features of graph databases, Cypher and Neo4J, Sect. 4  representation of the board as a graph, Sect. 5  future work and, finally Sect. 6  conclusions.
2 Quoridor Game
2.1 Game Rules
The Quoridor consists of a board of 9x9 spaces and can be played by 2 or 4 players; however, in this work we just focus on 2 players, the COM and the human player. Each player has one pawn and ten fences that can be placed horizontally or vertically as shown in Fig. 1a. A player wins the game when he puts its pawn in the row where the opponent pawn starts.
2.2 Game Notation

Each square on the board is identified by a letternumber combination.

The columns are labeled with letters a to i from left to right. The rows are labeled with numbers 1 to 9 from top to bottom (see Fig. 2).

The black pawn begins at square e9, while the white pawn at square e1.

A pawn move is identified by the square that the pawn is moved to.

A fence move is identified by the fence’s northwest square. This square identification is followed by h or v to identify whether the fence is placed horizontally or vertically.

A sequence of moves should be identified by the turn number, where a turn is ended after both players have moved, first black then white.
2.3 Game Complexity
Complexity comparison
GAME  log (statespace)  log (gametree)  Average (branching factor)  Source 

Tic tac toe  3  5  4  
Nine Men’s Morris  10  50  10  [3] 
Awari  12  32  3.5  [3] 
Pentominoes  12  18  75  
Connect Four  13  21  4  
Checkers  20 or 18  31  2.8  
Lines of Action  23  64  29  [8] 
Othello  28  58  10  [3] 
Xiangqi  40  150  38  
Quoridor  42  162  60  [2] 
Arimaa  43  402  17281  
Chess  47  123  35  [14] 
Shogi  71  226  92  
Go (19\(\,\times \,\)19)  170  360  250  
Connect6  172  140  46000  [18] 
 1.The statespace complexity: It refers to the different positions that may be raised in the game. For the Quoridor, it corresponds to the possible amount of positions for the pawns multiplied by the available positions to place the fences. Since the amount of illegal positions are hard to calculate; then, the upper bound is calculated. The possible pawns movements is presented in Eq. 1:Where 81 is the amount of possible pawns movements and 80 is the possible movements of the other pawn minus the position occupied for the first pawn. With this in mind, when a player places a fence on the board, both players are enabled to place another fence in four spaces. Thus, it uses the required space to put other 4 fences as shown in Fig. 3$$\begin{aligned} S(p) = 81 * 80 = 6480 \end{aligned}$$(1)Then, it is possible to put 8 fences in 8 columns horizontally, having 64 possible positions, and 8 fences in 8 rows vertically. So the possible movements of the fences are presented in Eq. 2. Therefore, the total value of the statespace is presented in Eq. 3.$$\begin{aligned} S(f) = \sum _{i=0}^{20} \prod _{j=0}^{i} (1284i) = 6.1582 * 10^{38} \end{aligned}$$(2)$$\begin{aligned} S = S(p)S(f) = (6480)(6.1582 *10^{38}) = 3.9905 * 10^{42} \end{aligned}$$(3)
 2.The gametree complexity: The total amount of games that can be played. This is estimated by raising the average branching factor (the number of possible game state nodes that can be derived from a game state node). According to [2] this is 60.4 and the average game length is 91.1, so the gametree complexity is estimated with the Eq. 4$$\begin{aligned} G = 60.4^{91.1} = 1.7884 10^{162} \end{aligned}$$(4)
A little comparison between the complexities of some games similar to Quoridor is presented Table 1.
3 Quoridor Game Using Graph Databases
Normally, this kind of games are treated as an adversarial search problem. In this proposal, we use an approach to model the game trees to generate one leaf that represents each of the states of the game. We have the MIN and MAX players, who take turns to play, until the game finishes. Then, at the end of the game, it makes one evaluation of the movements, in order to know which is the best movement. In this moment, we are not focusing our attention in the algorithm or the heuristic function to evaluate the best movement, but instead we are focusing on representing the states of the game. It is important to mention that this approach requires a lot of processing for generating movements and visiting them. Then, in order to reduce the impact of high processing, we improve the approach by using a graph database in order to store efficiently all states of the game. Thus, we present graph databases and their useful characteristics for this kind of problems.
In this work, we used Neo4j^{1}, which is a graph database engine. In addition, we use Cypher^{2}, which is a declarative language, inspired on SQL to manage the required operations in Graph Databases. Some features of Cypher are: (1) matches nodes and relations in the graph database in order to extract information or modify data, (2) allows to create, update and delete nodes, relations and properties, and (3) manages indexes and constraints.
Furthermore, we used Python for connecting to Neo4j sending Cypher queries through the Bolt protocol^{3}, which is a connectionoriented protocol that uses a compact binary encoding over TCP or web sockets for higher throughput and lower latency^{4}.
3.1 Relational Vs Graph Databases
According to Hunger et al., [19], a Graph database is one technology which centers its attention in the representation of the data using nodes and relationships between those nodes, forming a graph structure.
Currently, data is increasing in volume, velocity and variety. As a result, data relationships are gaining more importance than the data itself. Traditional relational databases are not designed to capture this rich relationships. In this case, when storing tree nodes in a relational database; then, series of JOINS are require, which impacts considerably the system performance. On the contrary, graph databases have better response for this kind of queries.
There are a lot of different database options, including a set of NoSQL data stores, but none of them are explicitly designed to handle and store relationships like Graph databases.
Nowadays, organizations use graph database technology in a diversity of ways, including these six most common use cases: (1) fraud detection, (2) realtime recommendation engines, (3) master data management (MDM), (4) network and IT operations, (5) identity and access management (IAM), and (6) graphbased search.
4 Representation of the Quoridor Board
Several works such as [2, 20, 21] have evaluated the mechanisms to represent the state of the board, concluding that the best one is to model it with an undirected graph. Nevertheless, we consider that some of the connections between the spaces could be directed, this might offer a better representation because according to our evaluation, there are some situations in which some directed connections are useful. For instance, consider the situation in which a pawn needs to jump the opponent’s pawn with a fence behind him.
Thus, we have create a bidirected graph using Neo4J. Figure 4 presents the initial state of the game from the perspective of the black player. In this state, the graph indicates the possible movements towards their neighbors direction with the possibility to return to the current position. In this initial graph the only unidirectional relation is towards the edges in the objective position.
Another example is the board state presented in Fig. 5, which is representing the perspective of the black pawn in the graph of the Fig. 6. Since it is not possible to place the black pawn in the white position, then that pawn is not modeled in the graph representation.
Figure 7 presents a zoom of the graph focusing on the center. The graph shows one connection from e5 to d4 (Jump1). However, from d4 is not possible to jump to e5 because reaching the d4 position; then, the pawn can jump the enemy through the pawn straight to the f4 position (Jump2). In this case, it is valuable having the representation as a directed relations in those specific edges.
In addition, albeit our own pawn is not in front of the opponent’s pawn, the approach calculates the graph with the available jumps over the opponent’s pawn because we hypothesized that this feature might improve the minimax calculation. Moreover, based on the graph observation, it is possible to lead some unexplored heuristics.
5 Future Work
There is a tradeoff regarding the depth explored in the game tree; thus, accuracy demands computational resources. We believe that graph databases might provide a great picture of the study of the Quoridor game. In addition, graph databases allow seeing the behavior of the search algorithms. Thus, one opportunity based on the results of this project is testing this graphs databases in business projects. Regarding to the minimax algorithm, in the last thirty years there have been a lot of research in this area. Nevertheless, we are evaluating the idea to help minimax algorithms using Graph Databases.
Having in mind the big size of the gametree of the Quoridor game, it is not possible to save all the possible movements in the Graph Database. Hence, we will work on saving just the eligible paths of the minimax evaluation for one node, and the minimax value calculated in some depth. Based on that, the following iteration could use those values to improve its evaluation podding by avoiding the unnecessary calculation of some nodes. In addition, it would be possible to evaluate the shortest path to the end of the game directly in the graph database [22]. Using the concepts of the network science applied in games, we plan to make a simpler representation of the moves in order to have an improvement of the space used. So far, we have focused this model in the fact that the Cypher queries can be more specific filtering the values of only one node at time and retrieve its related nodes.
6 Conclusions
Approaches based on trees are simple models applied in machine learning, but in this case, it has a great potential to represent semantically the states of the Quoridor game. Graph databases seems to be a good tool to apply in this kind of scenarios.
Python is a suitable language to apply in the data analysis problems because it has buildin several functionalities like the list comprehension to deal with data collections in a natural way like the mathematician used to do. In addition, the asciiart syntax used for Cypher looks great and an easy way to create nodes and connection using Cypher into the database on Neo4j.
The bidirected graphs help us to calculate different paths from the current position of the pawn and the objective row, or even the enemy pawn in order to identify which one is in the better position in the state of the game. Moreover, graph databases help us to create dynamically data structures at the same time the data is added into the database, without having a static structure defined from the beginning like the relational databases.
Footnotes
References
 1.Mertens, P.J.: A quoridorplaying agent. Bachelor thesis, Department of Knowledge Engineering, Maastricht University (2006)Google Scholar
 2.Glendenning, L., et al.: Mastering quoridor. Bachelor thesis, Department of Computer Science, The University of New Mexico (2005)Google Scholar
 3.Allis, L.V., et al.: Searching for Solutions in Games and Artificial Intelligence. Wageningen, Ponsen & Looijen (1994)Google Scholar
 4.Van Den Herik, H.J., Uiterwijk, J.W., Van Rijswijck, J.: Games solved: now and in the future. Artif. Intell. 134(1–2), 277–311 (2002)CrossRefMATHGoogle Scholar
 5.Orman, H.K.: Pentominoes: a first player win. In: Games of No Chance, vol. 29, pp. 339–344 (1996)Google Scholar
 6.Tromp, J.: Johns connect four playground (1995)Google Scholar
 7.Schaeffer, J., Burch, N., Björnsson, Y., Kishimoto, A., Müller, M., Lake, R., Lu, P., Sutphen, S.: Checkers is solved. Science 317(5844), 1518–1522 (2007)MathSciNetCrossRefMATHGoogle Scholar
 8.Winands, M.: Informed search in complex games. Universitaire Pers Maastricht (2004)Google Scholar
 9.Chen, S.J.Y.J.C., Yang, T.N., Hsu, S.C.: Computer chinese chess. ICGA J. 27(1), 3–18 (2004)Google Scholar
 10.Park, D.: Spacestate complexity of korean chess and chinese chess. arXiv preprint arXiv:1507.06401 (2015)
 11.Cox, C.J.: Analysis and implementation of the game arimaa. M. Sc. diss., Universiteit Maastricht, The Netherlands (2006)Google Scholar
 12.Wu, D.J.: Move Ranking and Evaluation in the game of Arimaa. Ph.D. thesis, Harvard University (2011)Google Scholar
 13.Brian, H.: A look at the arimaa branching factor (2006)Google Scholar
 14.Shannon, C.E.: Programming a computer for playing chess. In: Computer Chess Compendium, pp. 2–13. Springer (1988)Google Scholar
 15.Iida, H., Sakuta, M., Rollason, J.: Computer shogi. Artif. Intell. 134(1–2), 121–144 (2002)CrossRefMATHGoogle Scholar
 16.Tromp, J., Farnebäck, G.: Combinatorics of go. In: International Conference on Computers and Games, pp. 84–99. Springer (2006)Google Scholar
 17.Tromp, J.: The number of legal go positions. In: International Conference on Computers and Games, pp. 183–190. Springer (2016)Google Scholar
 18.Xu, C.M., Ma, Z., Tao, J.J., Xu, X.H.: Enhancements of proof number search in connect6. In: Control and Decision Conference, CCDC 2009, pp. 4525–4529, Chinese. IEEE (2009)Google Scholar
 19.Hunger, M., Boyd, R., Lyon, W.: The Definitive Guide to Graph Databases for the RDBMS Developer. Neo4j (2016)Google Scholar
 20.Quinlan, J.R.: Induction of decision trees. Mach. Learn. 1(1), 81–106 (1986)Google Scholar
 21.Tsur, G., Segev, Y.: Quoridor agent. http://www.cs.huji.ac.il/ai/projects/2012/Quoridor/files/report.pdf
 22.Castelltort, A., Laurent, A.: Fuzzy queries over NoSQL graph databases: perspectives for extending the cypher language. In: International Conference on Information Processing and Management of Uncertainty in KnowledgeBased Systems, pp. 384–395. Springer (2014)Google Scholar