Applying Suitable Artifical Intelligence Techniques to a ...mdv/courses/CM30082/projects.bho/2006-7/... · Applying Suitable Artificial Intelligence Techniques to a Game of Dominos

Applying Suitable Artificial Intelligence Techniques to a Game of Dominos

I

Applying Suitable Artifical Intelligence

Techniques to a Game of Dominos

Richard J Walklate

Bachelor of Science in Computer Science with Honours

The University of Bath

3 May 2007

This dissertation may be made available for consultation within the University Library and may be photocopied or lent to other libraries for the purposes of consultation.

Signed:


I


Submitted by: Richard J Walklate

COPYRIGHT

Attention is drawn to the fact that copyright of this dissertation rests with its author. The Intellectual Property Rights of the products produced as part of the project belong to the University of Bath (see http://www.bath.ac.uk/ordinances/#intelprop).

This copy of the dissertation has been supplied on condition that anyone who consults it is understood to recognise that its copyright rests with its author and that no quotation from the dissertation and no information derived from it may be published without the prior written consent of the author.

Declaration

This dissertation is submitted to the University of Bath in accordance with the requirements of the degree of Bachelor of Science in the Department of Computer Science. No portion of the work in this dissertation has been submitted in support of an application for any other degree or qualification of this or any other university or institution of learning. Except where specifically acknowledged, it is the work of the author.

Signed:


II

Department of Computer Science

Individual Coursework Submission

Cover Sheet

PLEASE USE BLOCK CAPITALS

for office use

Date received:

CONFIRMATION OF HAND-IN

This section will be retained by the Department Office as proof of hand-in

Note:

You must keep a copy of your assignment.

Assignments are retained for scrutiny by External

Examiners.

Declaration: I certify that I have read and understood the entry in

the Student Handbook for the Department of

Computer Science on Cheating and Plagiarism and

that all material in this assignment is my own work,

except where I have indicated with appropriate

references. I agree that, in line with Regulation

15.3(e), if requested I will submit an electronic copy

of this work for submission to a Plagiarism Detection

Service for quality assurance purposes.

How to use this form:

1. Fill in sections 1-14 below. 2. Bind all pages of your assignment (including

this submission sheet) so that all pages can be read by the marker without having to loosen or undo the binding. Ensure that the binding you use is secure. Missing pages cannot be marked.

3. If you are required to submit part of the work on a disk, place the disk in a sealed envelope and bind the envelope into the submission.

4. Place your work in the appropriate coursework box located outside of the Department Office.

1. Family Name Walklate

8. Family Name Walklate

2. Given Name (s) Richard James

9. Given Name (s) Richard James

3. Unit Code CM30076/CM30082

10. Unit code CM30076/CM30082

4. Unit Title Double Module Project

11. Unit Title Double Module Project

5. Deadline Date & Time Thursday 3rd May 2007

12. Deadline Date & Time Thursday 3rd May 2007

6. Coursework Part (if applicable)

- 13. Coursework Part (if applicable)

-

7. Signature 14. Signature


III

ABSTRACT

The project looks at creating intelligent algorithms in order to allow the computer to simulate players in a game of dominos. In order to find the best algorithms, competitions were run where the competitors played each other for several games. The best algorithms use a weighted composition of multiple strategies, where the weighting dynamically changes based upon the state of the game.

The project also looks at designing and implementing a user interface for people to play a game of dominos. Simple networking has been introduced to allow multiple humans to play.

Testing was achieved via a co-operative evaluation technique. The participants completed certain tasks including playing against the algorithms. The Master algorithm won all its matches against every human opponent.


i

CONTENTS

Abstract ....................................................................................................................................III Contents...................................................................................................................................... i List Of Figures.......................................................................................................................... iv List Of Tables.............................................................................................................................v Acknowledgements .................................................................................................................. vi 1. Introduction....................................................................................................................... 1 2. Literature Survey .............................................................................................................. 2

2.1. Dominos Overview .................................................................................................. 2 2.1.1. Dominos History ............................................................................................. 2 2.1.2. Dominos Uses.................................................................................................. 2 2.1.3. Dominos Popularity......................................................................................... 3

2.2. Making a Game........................................................................................................ 3 2.2.1. Users................................................................................................................ 4 2.2.2. Game Design ................................................................................................... 5

2.3. Algorithm Development .......................................................................................... 5 2.3.1. Game Theory................................................................................................... 5 2.3.2. Artificial Intelligence Techniques ................................................................... 6 2.3.3. Strategy Games................................................................................................ 8 2.3.4. Agents............................................................................................................ 12

2.4. Summary ................................................................................................................ 13 3. Requirements .................................................................................................................. 15

3.1. Requirements Elicitation........................................................................................ 15 3.1.1. Questionnaire................................................................................................. 15 3.1.2. Current Systems ............................................................................................ 19

3.2. Requirements Specification ................................................................................... 24 3.2.1. Functional...................................................................................................... 24 3.2.2. Non-Functional.............................................................................................. 26 3.2.3. Optional......................................................................................................... 26 3.2.4. Not Included.................................................................................................. 26

4. Design ............................................................................................................................. 28 4.1. High Level Design ................................................................................................. 28

4.1.1. Process Structure ........................................................................................... 28 4.1.2. Class Structure............................................................................................... 30 4.1.3. Language Choice........................................................................................... 31

4.2. Low Level .............................................................................................................. 31 4.2.1. Data ............................................................................................................... 31 4.2.2. Networking.................................................................................................... 32 4.2.3. Board ............................................................................................................. 32 4.2.4. AI................................................................................................................... 35 4.2.5. Class Diagram ............................................................................................... 35

4.3. GUI Design ............................................................................................................ 36 4.3.1. Overview ....................................................................................................... 36 4.3.2. Dominos Board.............................................................................................. 37 4.3.3. Non Functional .............................................................................................. 38

5. Algorithm Development ................................................................................................. 39 5.1. Claims .................................................................................................................... 39

5.1.1. Definitions..................................................................................................... 39 5.1.2. List of Claims ................................................................................................ 39

5.2. Algorithm Overview .............................................................................................. 40 5.3. Basic Algorithms.................................................................................................... 40

5.3.1. Trivial ............................................................................................................ 40


ii

5.3.2. Diversity ........................................................................................................ 40 5.3.3. Conservative.................................................................................................. 42 5.3.4. Domino Prediction ........................................................................................ 43 5.3.5. Friendly ......................................................................................................... 45 5.3.6. Grumpy.......................................................................................................... 47 5.3.7. Competition................................................................................................... 47 5.3.8. Analysis of Results........................................................................................ 47

5.4. Merging Algorithms............................................................................................... 49 5.4.1. PrioritiseDC................................................................................................... 49 5.4.2. MergeDC....................................................................................................... 49 5.4.3. Competition II ............................................................................................... 52

5.5. Diversity Algorithm ............................................................................................... 53 5.5.1. DiversityII ..................................................................................................... 54 5.5.2. PrioritiseDIIC & MergeDIIC ........................................................................ 55 5.5.3. Competition III .............................................................................................. 55

5.6. New Probabilities................................................................................................... 56 5.6.1. Statistics ........................................................................................................ 56 5.6.2. FriendlyII and GrumpyII ............................................................................... 58 5.6.3. Competition IV.............................................................................................. 58

5.7. Friendly Last Chance ............................................................................................. 59 5.7.1. Competition V ............................................................................................... 59

5.8. Grumpy Improvement............................................................................................ 60 5.8.1. Grumpy Both................................................................................................. 60 5.8.2. Competition VI.............................................................................................. 60 5.8.3. Grumpy Dynamic .......................................................................................... 61 5.8.4. Competition VII ............................................................................................ 62

5.9. Merge ..................................................................................................................... 62 5.9.1. MergeDGC and MergeDGC2 ....................................................................... 62 5.9.2. Competition VIII ........................................................................................... 64

5.10. Conclusion ......................................................................................................... 64 5.10.1. Classification of Algorithms ......................................................................... 65 5.10.2. Overview with Relation to Claims ................................................................ 67

6. Testing ............................................................................................................................ 69 6.1. Functional, Optional and Not Included Requirements........................................... 69

6.1.1. Functional Requirements............................................................................... 69 6.1.2. Optional Requirements.................................................................................. 69 6.1.3. Not Included.................................................................................................. 69

6.2. Non Functional Requirements................................................................................ 69 6.3. Interface Testing .................................................................................................... 70

6.3.1. Main Screen................................................................................................... 70 6.3.2. Dominos Game.............................................................................................. 72 6.3.3. Help Screens.................................................................................................. 73

6.4. Algorithm Testing .................................................................................................. 74 6.4.1. Overview ....................................................................................................... 74 6.4.2. Results ........................................................................................................... 74 6.4.3. Analysis of Results........................................................................................ 75

7. Conclusion ...................................................................................................................... 77 7.1. Brief Desription...................................................................................................... 77

7.1.1. Aim................................................................................................................ 77 7.1.2. Main Achievements....................................................................................... 77

7.2. Critical Evaluation ................................................................................................. 77 7.2.1. GUI................................................................................................................ 77 7.2.2. Algorithm ...................................................................................................... 78

7.3. Further Work.......................................................................................................... 78 7.3.1. GUI................................................................................................................ 79


iii

7.3.2. Algorithm ...................................................................................................... 79 7.4. Final Remark.......................................................................................................... 80

A Requirements .................................................................................................................. 81 A.1. Questionnaire ......................................................................................................... 81 A.2. Questionnaire Results ............................................................................................ 88

B Design ............................................................................................................................. 96 B.1. Class diagram......................................................................................................... 96

C Algorithms ...................................................................................................................... 98 C.1. Competition IX ...................................................................................................... 98 C.2. Competition X...................................................................................................... 100

D Testing .......................................................................................................................... 101 D.1. Functional Requirements ..................................................................................... 101 D.2. Optional Requirements ........................................................................................ 110 D.3. Co-operative Evaluation Test............................................................................... 112 D.4. Notes on Tests...................................................................................................... 117 D.5. Questionnaire ....................................................................................................... 121 D.6. Questionnaire Results .......................................................................................... 126 D.7. Non Functional Requirements.............................................................................. 129

E Source Code.................................................................................................................. 133 E.1. MainScreen .......................................................................................................... 134 E.2. Server ................................................................................................................... 141 E.3. CheckLayedDomino ............................................................................................ 147 E.4. Algorithm............................................................................................................. 152 E.5. MergeDGCAlgorithm .......................................................................................... 157

F Help Screens ................................................................................................................. 160 F.1. Main Screen Help................................................................................................. 160 F.2. About Dominos .................................................................................................... 168 F.3. Help Dominos Game............................................................................................ 173 F.4. Product Information ............................................................................................. 177

Bibliography.......................................................................................................................... 179


iv

LIST OF FIGURES Figure 1. Online dominos game. ............................................................................................. 20 Figure 2. Domino Ace 1.0. ...................................................................................................... 21 Figure 3. Ultimate Dominos. ................................................................................................... 22 Figure 4. Shark Dominos......................................................................................................... 23 Figure 5. Process diagram displaying the application’s main functionality. ........................... 29 Figure 6. Application’s main sections and how they relate to each other. .............................. 30 Figure 7. The integer representation of the dominos board..................................................... 33 Figure 8. Laying next to a domino horizontal. ........................................................................ 34 Figure 9. Laying next to a vertical domino. ............................................................................ 34 Figure 10. Initial design of the dominos board........................................................................ 37 Figure 11. Dominos used for Diversity algorithm example. ................................................... 41 Figure 12. Dominos used for Conservative algorithm example. ............................................. 42 Figure 13. Dominos used to illustrate problems with Diversity algorithm. ............................ 53 Figure 14. Dominos where Diversity algorithm has no preference......................................... 54 Figure 15. Algorithms grouped by skill level.......................................................................... 65 Figure 16. Competition of difficulty levels. ............................................................................ 67 Figure 17. Main Screen – original. .......................................................................................... 70 Figure 18. Main Screen – updated (server tab). ...................................................................... 71 Figure 19. Main Screen – updated (client tab). ....................................................................... 71 Figure 20. Dominos Board – original...................................................................................... 72 Figure 21. Dominos Board – updated...................................................................................... 73 Figure 22. Humans players vs Computer players.................................................................... 75 Figure 23. Class diagram......................................................................................................... 97


v

LIST OF TABLES Table 1. Results of questionnaire implying what features the users would like...................... 18 Table 2. States that a domino can be in upon being laid. ........................................................ 34 Table 3. Diversity algorithm; occurrences of domino values.................................................. 41 Table 4. Diversity algorithm; values assigned to each domino. .............................................. 41 Table 5. Diversity algorithm; an ordering of dominos. ........................................................... 42 Table 6. Conservative algorithm; values assigned to each domino......................................... 43 Table 7. Conservative algorithm; an ordering of dominos. ..................................................... 43 Table 8. Friendly algorithm; probabilities of team mate owning dominos. ............................ 46 Table 9. Friendly algorithm; values assigned to each face value of a domino 0-6.................. 46 Table 10. Friendly algorithm; values assigned to dominos on first turn. ................................ 46 Table 11. Friendly algorithm; values assigned to dominos not on first turn. .......................... 46 Table 12. Competition. ............................................................................................................ 47 Table 13. Linear heuristics applied to Diversity algorithm. .................................................... 50 Table 14. Logarithmic heuristics applied to Diversity algorithm............................................ 51 Table 15. Linear heuristic applied to Conservative algorithm. ............................................... 51 Table 16. Competition II. ........................................................................................................ 53 Table 17. Competition II. ........................................................................................................ 53 Table 18. Competition III. ....................................................................................................... 56 Table 19. Competition III. ....................................................................................................... 56 Table 20. Values used to alter the probability of a player owning a domino. ......................... 57 Table 21. Competition IV........................................................................................................ 58 Table 22. Competition IV........................................................................................................ 58 Table 23. Competition V. ........................................................................................................ 59 Table 24. Competition V. ........................................................................................................ 59 Table 25. Competition VI........................................................................................................ 60 Table 26. Competition VI........................................................................................................ 61 Table 27. Competition VI........................................................................................................ 61 Table 28. Competition VII. ..................................................................................................... 62 Table 29. Competition VIII. .................................................................................................... 64 Table 30. Assigning skill levels to algorithms. ....................................................................... 65 Table 31. Competition of skill levels....................................................................................... 66 Table 32. Human players vs Computer players....................................................................... 74 Table 33. Myself vs Computer players.................................................................................... 75 Table 34. Competition of all algorithms.................................................................................. 99 Table 35. MergeDGC vs all algorithms................................................................................. 100 Table 36. Testing the functional requirements. ..................................................................... 109 Table 37. Testing the optional requirements. ........................................................................ 111 Table 38. Testing the functional requirements. ..................................................................... 132


vi

ACKNOWLEDGEMENTS

I would like to acknowledge my supervisor Nicolai Vorobjov for his help with the project. I would also like to thank the people who completed the questionnaires to help gather the requirements. I would like to thank my family; Steve, Jane, Rachel and Anna for their feedback on the application.

Additional thanks to Sam Crawford who let me use his many servers for testing purposes. Also, my dogs, Pepper, Sootie and Charlie for keeping me company during the hard times of this dissertation.

1

1. INTRODUCTION

Dominos is a game that has been around for many years. The game has evolved; so many variants currently exist. Many people are of the opinion that dominos is a child’s game, consisting of pure luck. This project attempts to remove these assumptions, by developing tactical strategies in order to play the game.

As previously stated, there are many versions of the game of dominos. This project concentrates on one version which is similar to what is called the block game. The specific rules are detailed in appendix F.2.

There are many reasons for completing this project. The first reason is for personal reasons. It was in the author’s interests to work on a mathematically based project, which also involved creating a functional program. Strategy and board games have also been a hobby of the author’s, but there has never been an opportunity to implement a board game with suitable algorithms.

There are several games that involve inventing strategies in order to be successful, so the next question is: “Why choose dominos?”. The first advantage of dominos relates to its complexity. The time span for this project is approximately nine months. At the end of this project it would be nice to have an algorithm which is capable of giving a human a good game, or beating actual people. If a game of chess, draughts, go, or poker was implemented, this would be infeasible.

Dominos is not simple enough to solve using brute force methods. Games like Connect 4, or Tic-tac-toe are relatively simple and these techniques are feasible. This makes the task challenging enough to take between eight and nine months to develop suitable solutions.

The most amount of work completed on implementing an algorithm for a game is arguably chess. Not a lot of effort has been put in to implementing suitable domino algorithms. Therefore the algorithms created from this project may be based upon similar games, but will be unique.

The reason for choosing dominos over a game like backgammon is because there are four different players in dominos. Each player is in a different state and should play different tactics based upon the current state of the game. This diversity of tactics is not available in backgammon as there are only two players.

The major disadvantage to selecting this project is the lack of effect on society. People do not consider game implementation to be of great effect, when compared to other applications which can be used more in a working environment. The fact is that much money is put into making games and many people play games, making this project important.

However, there are few (if any) successful dominos games, so there is the fear that no-one will want to play the game. Hopefully the application will change people’s opinions of the game of dominos and it will increase the popularity of the game.

The following paper discusses the application created. The project discusses the interface requirements. This is mainly achieved via user interaction. The project also talks about the algorithms implemented. This is achieved via analysis of other games and by playing the dominos game.

2

2. LITERATURE SURVEY

The literature survey is used to give an understanding of the domain and gain potential insights in to how to solve the task. This is achieved by first giving an overview of the game and then discussing the important parts of making a game and how this differs from implementing other applications. Finally, techniques are analysed in order to help create successful algorithms. No requirements, design decisions, or potential algorithms shall be covered in this section. Instead, the literature review aims to provide an understanding of what is required in order to gather requirements, what to consider in the design and what to consider when creating algorithms.

2.1. Dominos Overview

Many people may remember playing dominos from when they were younger. Some are of the opinion that dominos is a child’s game consisting of pure luck. However, this is far from the truth and this section will allow the reader to gain a greater understanding of the game.

2.1.1. Dominos History

It is not clear when and where dominos originated. Armaninio [1] claims that it originally began as far back as 1355 BC, although references such as Tidwell [2] and Masters [3] differ. Most people agree that it was being played at 1120 AD by the Chinese. Tidwell [2] and Masters [3] discuss the evolution of the game. Originally, in China it is thought that the game consisted of all permutations of tiles that could result from throwing two dice; tiles [1, 1] to [6, 6]. It is also believed that there were two different kinds of tiles; Military and Civilian.

It first appeared in Europe in Italy in the early 18th century. However, the game played in Italy was played with ivory bones. The game showed similarities with the Chinese version as the dominos consisted of all values that could be obtained from rolling two dice. However, a blank value was also introduced representing the values obtained from rolling one die and also the domino containing two blank values, most likely for completeness. Also, the Italian version did not contain the two types of domino; Military and Civilian. Because the game developed in Italy was so different to the one developed in China, it is not known whether it was a product of the game from China, or whether it was invented in Italy.

The game of dominos from China evolved into the game Mah-Jong. This game also uses tiles, but they are much more diverse and complex. As with the dominos first played in China, Mah-Jong also classifies tiles, however, this time into Suit tiles, Honor tiles and Bonus tiles. Each tile again has a numerical value associated with it. This game spread across to the Western world in the 1920s where it became popular in the US. To find out more about Mah-Jong consult [4].

The game of dominos first reached Britain in the late 18th century. It is believed to have come from France. It is currently played in many countries of the world. There are also many variants of the game, which shall be discussed in the next section. The most common set used for dominos is the one which was originally used in Italy. This consists of all combinations of values on dominos from 0 to 6. However, there are also some variations of sets including ones which go from 0 to 9 and even 0 to 12.

2.1.2. Dominos Uses

Dominos are currently used in many ways. McGowan [5] describes a way of teaching school children maths using a set of dominos. Domino chains can also be created and [6] shows the world record for the most number of dominos being knocked over; 4 079 381. However, this section will be used to discuss common games of dominos that can be played.


3

Tidwell [7] and Masters Games [8] describe a wide variety of dominos games that can be played. Most dominos games have certain similarities. The basic structure involves each player taking a certain amount of dominos. Regardless of whether you are playing as part of a team, or against other people, each person is only allowed to see their own dominos. The turns go around the table. A train of dominos is formed on the table. On each player’s turn they attempt to add a domino to the train, by laying a domino with a value equal to a value at one of the ends of the train. When no-one can go, or when so many people have laid all their dominos, the round is over and scores are calculated for each team, or player.

Games quite similar to the one which will be implemented in this project are described in Masters Games 8. It describes block games where the idea is to lay all your dominos. Points are calculated at the end of a round by performing some function on the opponents’ remaining dominos. Play can be done in a team, or individually. This game can also be played with a dominos set with values 0 to 9.

For a contrast between Western and Eastern domino games, Tidwell [7] is a good source. The Western games mainly involve playing dominos in order to score immediate points. Example games are Five-Up and Bergen. These involve laying dominos onto the end of the train. If the values on the end of the train add to multiples of 5, or are equal, then certain points are earned. Most of the Western games are fairly similar to this style of play.

The Eastern domino games appear to follow a different trend. In some cases the actual domino sets used are different; the 0 domino is sometimes not used and the dominos can be longer and thinner to allow for them to be held. There are also two types of dominos Military and Civilian. The Eastern games appear to have more states and rules. Many different combinations of dominos are called different names and each relate to different point values.

2.1.3. Dominos Popularity

The above sections give an overview of the history of dominos and the many different types of dominos games. They also suggest that different variations of the game are played in many different countries. There was even talk of Eskimos playing the game by Tidwell [2]. However, do many people still play the game today?

In the Western world the answer is that the games have been popular recently. The National English Domino tournament has been running since 1985 according to Masters [3]. This is an annual tournament played in Stoke. However, the game is more popular in the US. AngelFire [9] shows a site devoted to running a league and tournament where regular players such as TexasTinCup, Redneck and Dixie frequently compete against each other. For a list of online rooms where dominos can be played consult reference [10]. The largest of all these tournaments is shown in reference [11] which is the World Championships, where prize money is more than $500000. This shows the popularity of the game and the number of participants.

However, the above world championships and leagues do not take into account the Eastern world of dominos. No evidence has been found of similar tournaments or leagues in China. However, this does not mean the game is not still played on a similar scale. What is known is that the Chinese do play variants of dominos games; including Mah-Jong. The fact that dominos was created almost 1000 years ago and the game (or variants of it) is still played today is a testament to its lasting popularity.

2.2. Making a Game

When implementing any kind of product, usability is a big issue. No matter how many features the application has, if people cannot figure out how to use them then it becomes


4

useless. This section will discuss what is required in order to implement an interface close to the users’ needs. It also discusses some of the differences between game design and other application design.

2.2.1. Users

In order to write this section Tidwell [12], Noyes [13] and Faulkner [14] have been used. One of the key considerations when implementing a system is user interaction. This should not occur only at the end of the project, it should be present throughout the project. There are many ways of interacting with the user, which will be discussed below;

• Questionnaires – written down on paper and distributed to many people. The main advantages of a questionnaire are that it can be given to many people and therefore it can collect many results. It can also be answered anonymously, implying people are more likely to answer truthfully. The disadvantage is that it lacks freedom. People may have useful ideas which can be discussed in more detail using other approaches; for example, an interview. It also runs the risk that people cannot understand the question, meaning the user can write down misleading answers.

• Interviews – formally or informally asking questions to one person at a time. The main advantage of an interview is the freedom element. The interviewer can discuss certain interesting topics with the user. However, it can be quite hard to gain an understanding of how structured to make the interview. If the interview is too structured there is no real advantage of an interview over a questionnaire. If it is too unstructured, it can be hard to draw results from the interview.

• Observational – the user is asked to complete certain tasks and they are observed to see how they interact with the system. The main advantage of this technique is that the user can actually interact with the system and see what they like and dislike. A potential problem which can occur here is that the observer may not notice all the points the user has made about the system.

• Activity sampling and activity logging – the user completes the task and their activities are recorded, or the output is logged. This has the advantage that the user may feel less pressured if they are not immediately being watched. However, this is time consuming as the tests must be done and each output must be analysed afterwards.

• Co-operative evaluation – the user completes a number of tasks and the observer talks through with the user about the tasks being completed. This has a huge advantage of the user interacting with the system and mentioning all features about the system as they are using it. However, this is again a time consuming technique.

When implementing the system several of the above techniques will have to be used at appropriate times. It is important to remember that no one technique is better than anotherl it depends upon the situation. It is also important to notice that several techniques can be combined together; for example, an observation test could be completed followed by an interview.

Another important piece of information not yet mentioned is the discovery of the potential users. At this stage the users of the system can be potentially anybody. It will be an important part of the research to discover potential users. There are several classifications of users that can relate to different features when designing an interface. An example of this is shown by UPA Minnesota [15] where it claims that older people find it easier to read larger text and listen to louder sounds. Another more abstract example is described by Marcus and Gould in


5

[16], where they discuss how a person’s culture affects how they believe an interface will look and how an application will behave.

2.2.2. Game Design

The application is a computer game. So how much difference is there in creating a game compared with creating another kind of application? In order to write this next section the Harbour [17] is used. Although this is a user guide, chapter 1 goes into detail about the importance of game writing.

The importance of game creation in current times is discussed. The fact that many thousands of people work for games companies and many millions of pounds are spent on games makes it an important part of modern day life. The writer also explains how 2 dimensional games are not out of date, saying that recently he created and sold some simple 2 dimensional games. It is also mentioned how important it is to have the option to play against other people.

There are many important points implied from the text that make creating a game and creating an application different. These differences are described below;

• The first important point is the writer’s relaxed attitude. When implementing a game error checking is not of huge importance. It is important to ensure a game functions correctly, but minor errors are not going to cause lives to be lost, or even sales to drop dramatically.

• The relaxed attitude also implies that most users will have more of a laid back attitude about the application. This is opposed to a product used within a work environment. For this reason a less formal interface maybe tolerated.

• Similar to the first point, much more of an emphasis must be placed upon making the system work well. When performing updates in real time, graphical approximations that give the appearance of a smooth approximation may have to be used. This is better than waiting for a perfect image to be drawn if it takes an excessive amount of time.

• Many more input and output devices are mentioned than with the majority of applications. If a game is quite interactive the user is quite likely not just to use the keyboard. The user is also likely to use the mouse for more than just clicking on text boxes and buttons. In the text controllers and joy-sticks are mentioned. In terms of outputs, specific information about the screen’s resolution is taken into account. Other forms of output may also be required; for example, sound.

• Harbour’s book describes graphics in a large amount of detail. It goes into detail about trigonometry and calculating surfaces and shapes. However, this will probably not be overly used when implementing the dominos application.

The above points give an overview of what should be considered when creating the game and how it differs from creating other applications.

2.3. Algorithm Development

In order to develop the algorithms used in the project suitable strategies shall be analysed. The strategies are illustrated below. At the end of each section the advantages and disadvantages are detailed, saying whether or not the strategy is likely to be used.

2.3.1. Game Theory


6

The information about game theory has been discovered using help from McCain [18]. Game theory is used to find an optimal payoff between multiple users as a result of an encounter. Basically, the way this is achieved is by creating a table of values, or payoffs. Each different action for a player results in different payoffs. So if each user chooses an action then the appropriate payoffs can be calculated. Using techniques like the Nash equilibrium an optimal payoff can be discovered.

The main advantage of game theory is it can be used, and in certain cases it selects the optimal strategy for any game. This means an optimal strategy could be developed for dominos such that it is most likely to beat any other strategy.

However, game theory also has many disadvantages. Game theory can be used to develop an optimal strategy for all finite games like chess [19], but the number of different strategies involved is too large to calculate at the moment. The complexity increases exponentially as the number of players in a game is increased. The number of outcomes for a game with n players each with (n1, n2, n3, ... , nn) choices will be (n1 * n2 * n3 * ... * nn), or O(nn).

When the size of the payoff table is large, the Nash algorithms also become complex. This will mean that although the payoff table can be calculated beforehand and is therefore of constant size, selecting the optimal strategy will take a very large amount of time.

Game theory can produce an unrealistic model for this application. If a payoff matrix is used then it assumes that all players choose their strategy simultaneously. However, in a game such as dominos this is not the case because it is likely that a player’s strategy will adapt to different scenarios. This implies either much more complex tactics are used, which makes the payoff table ridiculously large, or more complex measurements are used, which makes calculating the Nash equilibrium harder.

There are cases when the Nash equilibrium does not produce an answer. There are also cases when it produces multiple answers. When these cases occur it is unclear what the algorithm should do. Game theory can be adapted to always select one answer, but this increases the complexity.

Game theory can be used to take previous results into consideration. This is where the probability of the opponents’ options are altered depending upon previous results. However, this adds more complexity to the scenario.

For the reasons stated above game theory does not seem an appropriate technique to use for this project and will not be used in the algorithm development stage.

2.3.2. Artificial Intelligence Techniques

The artificial intelligence (AI) community has spent much time researching into how to develop algorithms for game play. However, they have specialised in certain games; mainly chess, but also draughts, Go and few others. [20] provides an insight into several techniques used to play games. When an algorithm is created to play any game, at any point within the game it must select a move from a finite list of options. Therefore a tree of potential moves can be created. Each branch of the tree represents a move and each node represents a heuristic which is basically a value indicating how successful the move is. At each level of the tree it represents a certain player’s options; hence in two-player games player 1’s options will be displayed on all odd levels of the tree and player 2’s options on all even levels of the tree (or vice-versa depending upon who goes first). The idea is to analyse the tree, using appropriate techniques, in order to obtain the best move. There are several problems with this description. Firstly, how to choose the heuristics to label the branches and secondly due to the size of the tree, whether it can be stored and traversed. These problems will be discussed in the next few paragraphs.


7

The first issue with the tree is how to assign heuristics for each node. The immediate thought is that heuristic values must be assigned based upon the end result; however, this is not the case. Heuristics can be assigned based upon sub-goals, an example of which is the pieces captured in chess, or the squares occupied in checkers, or even a combination of many factors. This still leads to problems because a move by player 1 may result in losing a piece, or capturing a piece depending upon player 2’s move. Therefore an algorithm must be used to decide the heuristic that should be applied to this node. The most common approach is to use the minimax procedure, which keeps with the game theory idea, of assuming that all players in the game will select the most profitable option for themselves. Assume there is a tree consisting of several nodes. Node A does not have a heuristic, but its children; nodes A1, A2 and A3 have heuristics of 0.5, 0.6 and 0.1 respectively. A higher value represents a better outcome for player 1, and player 1 has the choice of A1, A2 or A3. In this case node A will have heuristic 0.6 as it is assumed that player 1 will choose the best option (A2). Another similar approach is called the negmax procedure. Because the game is competitive a profitable move for player 1 is likely to hinder player 2. Therefore it is required to record which player is making each move, so that player 1 will select larger heuristic values and player 2 will select smaller ones. However, it can be computationally simpler to inverse heuristics at certain stages, so on all levels every player’s best option is to choose the largest heuristic. The minimax and negmax functions will play a cautious tactic, as it assumes the opponent will play the most dangerous strategy.

Most games are too large to completely model in a tree, therefore all pruning techniques (techniques of removing some of the tree) are of the utmost importance. One technique is called the alpha-beta cutoff heuristic and is based upon not calculating any of the resulting moves after a certain move has been deemed to be poor. If node A has a heuristic of 0.9 and node B has not yet been fully calculated, but one of its children has a heuristic of 0.1, then the minimax, or negmax algorithm will not let node B have a result of greater than 0.1 so all the sub-branches of this node need not be calculated (assuming the highest value is the best value). There are also other pruning techniques such as immediately discarding illegal or ridiculously poor moves. Also, removing combinations of moves which result in a loop with no real gain, such as moving a chess piece back and forth with no improvement. It is worth mentioning that most pruning techniques must be taken with a pinch of salt as it can be hard to say what a ridiculously poor move is, or whether moving a chess piece back and forth will never be of use.

Even with many pruning techniques most trees are still too large to model. Therefore the ply must be taken into consideration. The ply is the number of moves to look ahead, or the depth of the tree. The problem with not using a large enough ply is that a move which may initially seem to be poor, will result in a very strong position in a few moves time, and vice-versa. This is known as the horizon effect.

[21] describes AI techniques being applied to game play. One algorithm created by Arthur Samuel to play checkers is of particular interest for two reasons. The first is that the algorithm breaks the game down into smaller subgoals, applies weightings to moves and then combines these weightings in order to select the best move. Also, the algorithm learns as it plays, based upon previous encounters. The algorithm uses several constant values and it continually alters these values and plays itself. If the previous algorithm loses, the new constant values are used. This algorithm improved not only to beat one of the best checkers players in the world, but also its creator; Arthur Samuel. The significance of this is huge as it implies the algorithm has taught itself how to play better than its creator.

Even though the AI world has had much input in the creation of games, most of their efforts have been placed on chess and draughts. A discussion of whether these techniques can be transfered to a dominos algorithm will now be presented. The main strategy is to model games using a tree. However, in the dominos game it is unknown what dominos certain players own, and also the effect of laying each domino. This implies the tree idea may not be


8

too appropriate for the algorithm development. A technique of applying heurstics to specific moves, or dominos is a useful idea. This is because several strategies can apply heuristics to each move and then these heuristics could be combined in order to find the best move to make.

The checkers game created by Arthur Samuel is of high importance. The technique of using multiple strategies and combining them appears to be an appropriate solution. Also, the ability to build up information as the game is played is indeed a very intelligent strategy. Many constant values are likely to be used in the creation of the dominos algorithms so this idea maybe utilised. However, it maybe hard to improve an algorithm significantly by just changing the constants, if the main strategy behind it is poor. The main bulk of the work will be concentrated on implementing the general strategies, and then if there is time, the idea of improving the algorithm’s constants will be implemented.

2.3.3. Strategy Games

Arguably, the game with the most amount of work completed on it is chess. In 1997 the computer Deep Blue became the first computer to beat a world chess champion, Gary Kasparov. Hopefully, this paragraph will hopefully summarise the key tactics Deep Blue uses with the help of Campbell [22]. Deep Blue works with a number of databases. The databases are vast in size and store details about several parts of the chess game. Particular attention has been paid to the opening sequences in the chess game where many different scenarios can be selected. The databases are also used to rank how effective a particular move is. Deep Blue contains much historical data about grand masters and their moves. Information including the number of grand masters who have made the move and the effectiveness of the move are stored. From this information a score can be assigned to the move. When a similar situation arises Deep Blue searches its databases for relevant moves.

Deep Blue is also capable of analysing 200 million positions per second. It also has a ply normally between 6 and 12 with a maximum of 40. It is capable of performing many billions of floating point functions per second.

Although Deep Blue is more powerful than most modern computers it is still not powerful enough to use game theory to calculate the correct chess moves. This implies that for this project, game theory would also be too complex to implement. Although this project will not be anywhere near as complex as the Deep Blue project, some of the techniques used by Deep Blue may still be able to be used in order to create the algorithms.

Levy [23] provides information about how to develop algorithms for a range of games. Some of these are described in the next few paragraphs.

Backgammon

A backgammon algorithm beat the world champion in the late 1970s. The algorithm mainly looked at probabilities when in certain situations. The algorithm paid attention to blot1 and used probabilities to decide when it was acceptable. However, the main focus of the algorithm was to analyse the end sequence where statistics have been used to analyse the most effective scenario.

There is some gambling in the game, known as doubling. The backgammon algorithm goes into detail about when to double and when to accept or reject the opponent’s proposition to double. The important tactic here is not to double too early; it is best to double when there is a 65% chance of winning, rather than an 80% chance of winning. This should obtain the player more points as it will not scare the opponent off.

1 Blot – a piece by itself and therefore in danger of being reset.


9

Chess

In Levy’s chapter theoretical algorithms are stated which involve analysing every move. These algorithms cannot be implemented, purely because of the lack of computational power. However, the algorithms look at reducing the search space, firstly by removing illegal moves, then by removing obviously unnecessary or repeated moves. The algorithms also go into detail about the ply. This is an important factor especially when sacrificing pieces. An intelligent algorithm will sacrifice pieces to gain an advantage, but the ply must be large enough to analyse an appropriate number of moves ahead.

More advanced algorithms break the chess problem down into specific tactics. These include the safety of the King and balancing materials on each side. There are also much more advanced programs mentioned within Levy’s book. The way in which these programs operate is to analyse the importance of squares on the chess board. The program attempts to occupy the most promising squares. The recent algorithms go into detail about using historical data, which involves building up information as they play. They also look at set opening sequences and closing sequences. It is worth noting that Levy’s work was created before Deep Blue, so the chess game was still being won by humans.

Checkers

Checkers is not as computationally complex as chess. The algorithms take the approach of arranging the available moves in a tree. This tree is then pruned, to remove all illegal moves and moves which hold no gain to the player. The nodes of the tree are given a weighting depending upon the effectiveness of the moves. The branches are then supplied a weighting, always taking the lowest value available. When choosing the move the highest weighted branch is chosen (a minimax approach).

There is also talk of using historical data within the program. This data can be used to aid further moves and also to increase the ply of the algorithm. The ply of the algorithm is a very important consideration. There are certain problems with not looking far enough ahead, mainly whether it is worth sacrificing a piece for a better position, as the position may eventually result in capturing more pieces. Intelligent options may be pruned if they seem ineffective based upon an inadequate ply.

Scrabble

Scrabble can be seen as quite dissimilar to the previous games. However, it does involve using strategies and selecting the best possible moves based upon the environment. There are two main ways to select a good move, either select a word to lay and find a position to lay it, or select a position and try to fit a word into it. There is also a program which takes in a list of letters and produces a list of legal words which can be formed from the letters. There is little to no evidence of looking ahead to try to open up opportunities to obtain effective positions on the board. This may be because both players can take advantages of good positions.

Bridge

Bridge is a game which involves working with a player against a team of two. It is similar to chess in that the search tree is too large to analyse. There are two main tactics used in bridge; one is to play offence, trying to win tricks; the other is defensive, attempting to lose tricks. Based upon the initial hand, the program will adopt somewhere in between one of these strategies. The player may change tactics during the round depending upon how the game is going.

When bridge is played each player does not know enough information, namely the other players’ cards. One tactic in bridge is to attempt to discover what cards they have, based upon


10

what cards they have laid and how they have bid2. From this information the algorithm can discover what tactics to adopt. Although bridge involves playing with a team mate, there are very few tactics displayed in Levy’s chapter which use this information.

Go

Go is arguably the most popular board game. However, Go is much more complex than all other board games. Computationally it is much harder to program than chess. Because of Go’s computational complexity it shall not be analysed in anywhere near as much detail as in Levy [23]. Previous games could be broken down into smaller problems; for example, in chess, tactics included defending the King and occupying important spaces. Another advantage in chess is that there is a direct goal, namely to capture the opponent’s King. In Go the goal is not as simple as in chess. It is hard to break the goal down into sub-goals as well. This makes the game much more complex, as algorithms which have small ply in chess will not work in Go. The main problem is that in games like chess and checkers the algorithms are continually changing but in Go the goals are so much larger and the algorithm cannot afford to be flexible. However, the algorithm must adapt depending upon the opponent’s moves. It is also worth mentioning that Deep Blue has beaten the world chess champion, but for Go:

“no computer has managed to even compete with any professional players. The best programs in the world are beaten regularly by smart school-children!” [24].

Othello

There many strategies that can be applied to Othello. The grumpy approaches involve maximising the number of a colour of disc, or minimising a colour of the opposing disc. The less grumpy approaches involve trying to obtain the most effective position, the corner places. The game can also be split up into a beginning, middle and end. As with many other games opening sequences become set play and the Othello algorithm has a database of many set opening plays. The end algorithm attempts to either maximise the win, or minimise the loss. The middle algorithm concentrates on keeping as many options open for oneself while limiting those of the opponent. This can force the opponent into a poor position and their game can become predictable.

Poker

Poker is different to the above games. This is because the Poker algorithm does not pay much attention to changing cards. The main part of the algorithm is devoted to strategic gambling techniques. The difference between Poker and other games is that the purely mathematical approach of always committing a certain amount of money depending upon the hand you own does not seem to work. Because Poker opens up a whole new style of play, other sources have been consulted. Steele [25] implies that a purely mathematical approach gives away too much information about one’s hand, which intelligent opponents can pick up on. A sense of randomness and bluffing3 is very useful.

The chapter in Levy [23] goes into detail about different types of players; for example, intimidating high bidding high risk players, cautious low bidding low risk players and players who use a purely mathematical strategy. The chapter states the importance of algorithms which learn information rather than ones which work with a predefined pool of information.

One item mentioned by Bochan [26] is how to read the opponents’ reactions. Some of these reactions may only be applicable to a human opponent; for example, increased heart rate,

2 Bidding is what determines the number of tricks a team should win and the trump suit. 3 Bluffing – deliberately disguising your cards by either raising large amounts on a weak hand, or not

raising on a strong hand.


11

shaking hands; but others maybe applicable to all types of players; for example, the amount of time taken to respond. Some of these may be simple to monitor and others are obviously harder to observe, but they are all options when designing a Poker algorithm.

Qubic

Qubic is a game which can be referred to as 3 dimensional noughts and crosses. The tactics of this are again similar to chess and involve creating a tree of possible moves. Obviously the tree is smaller than the tree in chess. In fact at any given time all the possibilities can be analysed to 1 ply. Again there is a problem of how big to make the ply. The basic tactic in this game is to try and get to two winning positions, namely two rows with three counters in it. The tree obviously helps to get to this position. Also, attention must be paid to defending against the opponent’s attacks.

Chemin-de-Fer

Chemin-de-Fer is a game played using cards. The complexity of this game is low and Levy’s chapter describes how to model this game using game theory. This shows that, in practice, games can be won using game theory if they are not computationally complex.

Dominoes

Levy’s [23] game of dominos is different to the one being created in this project. The game in the book relates to making the sum of the values at the end of the lines equal to a multiple of 5. It also uses a boneyard4. The rules for the game created in this project are shown in section F.2. However, the ideas stated in Levy’s chapter may still be transferable to the algorithms used in this project. The idea that dominoes is too large to model by a complete tree search is mentioned and that moves should take less than 20 seconds. There is also a great emphasis on using data from previous games and one particular algorithm successfully achieved this. In the first few games it made crucial errors, but in later games, after it had learnt tactics, it managed to become successful. However, unlike the previous games, different players are in different situations. Each player’s goal should be the same, but the way it is achieved could be different. Some example tactics include:

• Set up the play to score a large number of points.

• Hinder the opponent by not letting them score or even play.

• Aid the partner by letting them play and helping them to score.

• Think of the future – always try to maximise one’s options and conversely minimise those of the opponents.

Another interesting point raised is that the information that each player knows is incomplete. Ideally, each player would like to know the distribution of all the dominos. One way to achieve this is to assign a probability that a certain domino belongs to a certain player. For each domino the probabilities total to 1 and default to 1/3 at the start. There are ways of increasing or decreasing the probabilities. One is when a player is unable to move; all of the dominos containing available numbers cannot belong to that player. Another way is to gather tactics about opponents and then assume what dominos they are likely or unlikely to own.

4 Boneyard – in some versions of dominos not all the dominos are dealt, the remainder are left in a

‘boneyard’. When a player cannot lay, they draw dominos from the boneyard until it is empty.


12

An explanation is now presented of how the above information can be used to help with creating the algorithms for the dominos application. One thing that is clearly implied is that game theory cannot be used to model high complexity games. As quoted by Minsky (1968):

“It is not that the games and mathematical problems are chosen because they are clear and simple; rather it is that they give us, for the smallest initial structures,

the greatest complexity, so that one can engage some really formidable situations

after a relatively minimal diversion into programming.”

Many games enforce a tree search with a small ply, that is, they only attempt to look a small number of moves into the future. This could be used by analysing all the possible moves and extracting the potential outcomes. The problem obviously relates to how big to make the ply. One move which may look potentially poor may result in a great success a few moves into the future. If a strategy like this is implemented it will require testing to ensure the program runs fast.

Another tactic which is used is the idea of continually building up knowledge. This can be taken in two ways: either building up knowledge about the game in general from playing talented opposition, or building up information about the way an opponent plays. Building up knowledge about the game by monitoring other people playing is potentially a very good idea, because the algorithm can continue learning. However, this could be very hard to implement because the algorithm would have to be able to distinguish between a player making a skilful move and a player being fortunate. Deep Blue uses tactics to solve this problem by monitoring how many times a move has been made and how successful the move has been each time.

The idea of the algorithm building up knowledge about the opponents throughout the game has the potential to be a very useful tactic. This can be used to imply what dominos the opponents own and also what their strengths and weaknesses are. Again this idea must be taken with a pinch of salt, as too many assumptions should not be made. A possible extension to this (almost certainly outside the scope of this project) is to see if human signs give away the dominos they have left. In poker many signs can be used to indicate a strong hand, the same ideas might be applicable for dominos.

Many games have databases of pre-defined opening plays; for example, chess and othello. This is logical in games where the initial scenario is always the same, but in dominos the start of the game can vary as the players can own different dominos. Therefore a database of initial moves does not seem applicable in this case.

The dominos game mentioned by Levy [23]; dominoes, provides some useful ideas. The idea of applying different tactics to different states of the game can definitely be applied to the version of dominos described in this project. The strategy of keeping the options open; a high level of diversity is likely to be an effective strategy. The idea of predicting what dominos the other players’ own may also be a critical part of the game.

2.3.4. Agents

The following section uses Wooldridge [27] and course notes from a course I am currently studying at Bath University [28]. Essentially the algorithm that will be developed will allow a program to make the most appropriate decisions based upon a number of parameters. This is relatively similar to another course I am currently studying called E-commerce and Agents. An agent is an autonomous computer system capable of making decisions based upon parameters in a stable or unstable environment.

Agents can be seen as being different from AI and game theory. Agents are different from AI primarily because they have the ability to interact with other agents. Game theory looks at


13

theoretically solving problems. Creating algorithms based upon game theory is a challenging problem, because the algorithms can have high complexity. Also, it can be argued that the Nash equilibrium does not always produce the most appropriate solution.

There are a number of environments agents can work in. For this dominos application the environment will be inaccessible, meaning the agent will not know all of the information; for example, who has what domino. It will also be non-deterministic; meaning that an agent cannot be sure of the outcome of their own action. In dominos an agent can lay a particular domino, however, they will not know what dominos the other players will lay. Because outside factors will not affect the game5, the game shall be static. The number of options, although large is finite. This is because there are a finite number of dominos and a finite number of moves that can be made, therefore the environment is discrete.

The above is a description of an agent an identification of its environment, but the question is how it can help us with the dominos algorithm. An agent is an intelligent system which should live by a set of predetermined rules. Because the environment may be continuous or very large, not all scenarios maybe considered by the programmer. The agent may need to resolve a problem which has not been anticipated by the programmer, but it should use its rules to choose the most appropriate action. This is a good way to approach the dominos problem as it does not require all the scenarios to be taken into consideration. Agents may also have the ability to learn and update their knowledge based upon previous information.

Agents are also designed to communicate and in certain cases work with other agents. This idea maybe applicable here. Although players cannot discuss what dominos they own, messages maybe sent between rounds so that agents can discuss what tactics to use. Messages can also be sent to gain a bigger picture of the game as the team mates can analyse what dominos they have left at the end of a round in order to discover what dominos the opponents own. This can help with predicting what tactics the opponents are using.

Because agents may be working in non-deterministic and/or dynamic environments they should be continually updating their strategies. The agent should be continually evaluating the environment and making new ideas based upon it. Most agents are working in these types of environments and continually read in new parameters to make new plans. This is similar to dominos as the environment changes with every domino lay. The agent should be designed to formulate new plays each time a new domino has been laid.

The agent may be working in inaccessible environments where not all the information is available. In this case the agent must attempt to obtain more information. Agents can analyse many different scenarios identifying in what scenarios a certain proposition is true and when it is false. From this the agent can obtain a probability that a certain proposition is true. However, this type of idea may be very complex, so a simpler solution may have to be developed. The agent can construct information about what it knows to be true and what it believes to be true. The agent can also gather more information from the community; this is known as common knowledge. The basic idea is if everyone else knows something then the agent can assume it is true. Although in dominos there is no specific way to communicate, the agent can observe why other players are laying certain dominos. It may be because they know some information. The agent can then assume or believe this piece of information is true.

In summary agents should have a strong contribution towards the final algorithms. This is because they can be used to produce an effective algorithm which is not too computationally complex, but operates in a complex environment.

2.4. Summary 5 Obviously, ignoring irregularities like power cuts, or human players being distracted. Outside factors

should not be a part of the game of dominos.


14

Dominos has been around for approximately 1000 years. However, it has evolved from its original format and now many variants are played in several locations, including the U.S.A., China and in some places in the UK.

When implementing the interface user interaction is essential. One must remember that this can be achieved in several ways, including questionnaires, interviews, observations, or combinations of approaches. It should also be remembered that a game is being developed, therefore the emphasis of what is important should be placed upon trends like the input and output devices to use, and not ensuring that the game is completely bug free, or making timings accurate to the nearest millisecond.

There are many features to consider when creating the appropriate algorithm. Game theory, although effective seems far too computationally complex for this problem. The most important tactic gathered from analysing the AI work completed is the idea of assigning a heuristic to a move, in order to gain an understanding of its importance and thus being able to combine strategies. Many strategies shown in games such as chess, checkers and qubic appear to be transferrable to a dominos application. An intelligent agent system certainly does seem like a promising ideal; and coincides with a tactic mentioned within the AI section of the algorithm learning and improving the more it plays. However, for this idea to work initial strategies must be implemented. Discoversing the initial strategies will involve playing the dominos game and seeing what is effective.


15

3. REQUIREMENTS

This section provides a detailed list of requirements for the dominos application. These requirements cover not only all functionality of the system, but also details features that will not be implemented with appropriate explanations. The document is structured to show the evaluation of the requirements, from the elicitation stage, to the final list. Several requirements maybe modified over these stages, but clarification will be given relating to the decisions made.

3.1. Requirements Elicitation

The requirements elicitation part of the document looks into techniques of gathering the requirements. Two techniques are described and at the end of each a brief list of requirements is presented. These lists are written in natural language and can therefore be ambiguous. The two techniques used are a questionnaire and analysing current systems. They are detailed over the next few sections.

3.1.1. Questionnaire

The idea of the questionnaire is to gain many results and ideas in a fast way. One advantage of doing a questionnaire is that many results can be obtained quickly. The disadvantage of doing a questionnaire is that the structure is rather rigid, therefore if someone has an idea they may not be able to fully describe it the way they would in an interview. Also, there is the worry that people may not understand questions and tick random boxes, whereas in an interview the interviewer can be more precise when asking the questions.

With all these disadvantages, the reader may be wondering “Why do the questionnaire?” “Why not interview the users?”. The reason is that at this early stage in the project it is best to get a basic understanding of what the users want. It is likely that not many people play dominos regularly and they will not be entirely sure what they want from the system. Based upon the requirements gathered a prototype can be implemented. The prototype can be used to perform more interactive tests (observational) in order to refine the requirements of the system.

A questionnaire was created, distributed and received 27 responses. A diverse range of subjects were chosen; people of different ages, genders and with different occupations. No-one on my degree course (Computer Science) was asked as these people have more computing experience than the average person and therefore they would not be a random sample of users. This does not mean that no computer scientists have been involved in the survey, as this would also mean the sample would not be random, but no-one from my specific course was asked. The users could remain anonymous, by not being asked to put their name down. This should have encouraged them to be more honest with their answers. Over the next few paragraphs each question in the questionnaire is analysed and details about the answers are discussed. The questionnaire can be found in A.1 and a summary of the results gathered in A.2.

• Section 1 – this section is used to classify the users into groups. This can identify whether specific types of users play dominos. This section will be referenced whilst analysing the answers to others questions. In order to maximise the users tested this questionnaire was given to a range of people. However, only one user is under 18 and there are twice as many males as females. This information will be remembered when analysing the results.

• Section 2 – people’s computing experience is analysed in this section. This is used to find out how complex to make the system and how people expect an application to function:


16

− Question 2 – this question is supposed to find out how often people use a computer. From this information an estimate can be made as to how computer literate people are. 21 people use a computer at least once a day and 5 at least three times a week. Only 1 person does not use a computer. This implies that most people have access to a computer and use it very regularly. Also, the people who use a computer no more than five times a week are all female and the person under 18. For people who use a computer less frequently a simpler interface with fewer features is required.

− Question 3 – this question is supposed to derive similar information to question 2. It is supposed to gain an understanding of the types of application people will use, therefore discovering what interfaces people are used to. The majority of people use Microsoft Office programs and surf the web (~85%). Approximately 40% of people watch films and listen to music, play games and use tools to create or view pictures. Very few people program or create films or music. Therefore, when creating the application consideration should be made as to what the Microsoft Office and common web browsing tools do well. Microsoft Office tools normally have many features and many ways of activating these features; for example, bolding text can be achieved via a keyboard shortcut, clicking a button, right clicking on the text and following the options or via the Format tab at the top. The popularity of web browsers amongst repsondents implies that people use the Internet regularly and would not be averse to having networking features in the application.

− Question 4 – this question may appear to be a bit obvious; of course a font size can be too small and there are obvious colours which do not go well together. However, the information gathered for this question should relate to whether users have specific problems with certain colours of font, or if some people cannot read fonts smaller than size 14, for example. Surprisingly few people said that they did not find this much of a problem. This implies that it should be suitable for the application to use similar font colours and sizes to websites, or other games. It is also mostly males who have problems reading the text from the screen. If a higher proportion of males like to play dominos more attention will have to be paid to this.

− Question 5 – the idea of this question is to find out how people like to interact with the computer. Many people will use the keyboard when given the opportunity; therefore it is something which should be implemented. Only 1 person said they did not use keyboard shortcuts and this was the person who did not use a computer.

− Questions 6 and 7 – are supposed to find out how much people would like to use the mouse to interact with the computer. Approximately 75% of people use the mouse for what they consider to be an extensive period of time. The people who do not use the mouse are mainly females who are over 40. However, approximately 50% of these people occasionally feel some pain or discomfort. These results imply that users will not be too averse to using the mouse, but they would prefer not to, if they are going to play the game for a long period of time.

− Question 8 – is supposed to ascertain how good people are at using two hands to simultaneously enter commands into the computer. It is mainly people over 40 who have issues with this. In total, approximately 15% find it hard to use a keyboard with two hands and very few (under 1%) find it hard to use a keyboard and mouse simultaneously.

− Question 9 – an open ended question for people to enter any more information they thought relevant. Some people responded with answers which encouraged new requirements. The first answer someone wrote down related to the speed of their computer and the size of their hard drive. An obvious requirement for the dominos


17

application would relate to the efficiency of the application and not taking up too much CPU or disk space. Another user wrote about the ‘Alt+Tab’ function, which allows changing of windows. This implies that many users require keyboard shortcuts.

• Section 3 – gathers information about what activities people like to play. In particular what is important to people when they play these activities, especially if they were to play a computerised dominos game.

− Question 10 – is an attempt to identify if there are other games the users of dominos also like to play. If there are specific games, the trends of these games could be analysed and used when designing the dominos application. Unfortunately, from the results there is no obvious pattern of people who would want to play dominos (based upon question 12) and the type of activities people play.

− Question 11 – this question is useful to see if people would prefer to play the dominos game against other people, or just against a computer. The majority of people would prefer to play the game against a computer (~40%). However, approximately 30% said they preferred playing against other people and the remaining 30% said they liked playing both. This implies the game should be based around playing against a computer, but also to have the option to play against other people.

− Question 12 – this question can be used to see how interested people are in playing dominos. Also, to see if there is a particular age group who would like to play dominos. From the results, not many people would play it regularly. Informally speaking to people about the game implied that they are unsure of the rules and are under the assumption that it is a game of pure luck (strong evidence against this claim is provided in the algorithms section). Hopefully, if people play this game they may enjoy it and continue to play it. The results show no specific group who would be interested in playing the game. In every case approximately two thirds of people said they would try it and one third said they would not. This implies the user base cannot be narrowed down.

− Question 14 – the reason behind this question is fairly obvious, the identification of the types of features people would like. The most popular features were being able to change difficulty levels, help screen, access to the rules of dominos and access to the scores. Table 1 shows which features people want (Scores go from 1 to 5 where 1 means it would be almost essential and 5 means the user would prefer not to have it.):


18

Table 1. Results of questionnaire implying what features the users would like.

People also made some other suggestions for this question. One person made a point relating to having different coloured dominos. They elaborated in the last question by saying that this could be an option for child players, possibly for simple difficulty settings. Another person wanted the ability to be able to save games, gather statistics from games and be able to change the domino pieces. Another idea someone mentioned would be to try and theme the levels. This would involve completing an easy level with a certain theme and then progressing forward to a final boss.

• Section 4 – the point of this section was to gather any additional information people had not mentioned earlier on. People came up with different ideas, one user mentioned that most gamers (possibly my target users) would run UNIX; therefore the product should be created in something which will run on UNIX. Another user mentioned how coloured dominos would be useful (stated in the paragraph above). One user said they probably would not play a computerised version of dominos because they do not play the board version. This is added incentive to promote dominos and users may become interested if they played it once or twice. This person also talked about the ability to use the game for gambling purposes. Another point made was the importance of the multiplayer dominos.

Based upon the above information the following user based requirements can be derived:

Functional

• The system must allow users to be able to play against other human players.

• There must be many different difficulty settings for the computer players.

• The users must have the options of changing how many points a game is played to, their player name and the difficulty settings of the computer opponent.

• The font size must always be at least 12pt. This is because most people have no problems reading what is on screen most of the time.

• Help menus on using the system must be implemented.

• The rules of playing dominos must be available to the user.

• All users must be able to access the current scores of the game at any time.

Games Mean Score

Able to choose difficulty levels for computer players 1.3

Help menus on how to use the system 1.4

Accessibility to the dominos rules 1.4

Anytime access to the current scores in a game 1.7

A display of your current moves/options 2

Be able to change the score a game is played to 2.4

A display of your recommended moves/options 2.5

Set your own name 2.5

A time-limit for players to move 2.5

Message human players during the game 2.6

Change your own name 2.7

Access a history of moves made in the current game 2.7

Ability to play multiple games simultaneously 3


19

• Statistics about previous games and players must be made available to the users.

• The current moves for the users must be available if requested.

Non-Functional

• Care must be taken when combining colours together. This is especially true when putting certain colour text on another colour background. Analysis must be done into websites and current applications.

• As many features as possible will have keyboard shortcuts.

• The user must not be forced to constantly use the mouse.

• The interface shall be appealing.

• Users shall be given as much freedom as possible in the way they lay the domino.

Optional Functional requirements

The following functional requirements are optional; they shall be implemented if there is time. The reason why these are optional requirements is based upon how much users want these requirements and how hard they are to implement.

• Optional access to a recommended display of moves/options. This must have the option of being disabled otherwise certain players may get annoyed that their opponent is constantly using this help system.

• A time-limit for players to move.

• The ability to message other human players during the game.

• The ability to change one’s name.

• Access to a history of moves made in the current game.

• The ability to play multiple games simultaneously.

• The options to use coloured dominos, where each number has a colour.

• Some form of gambling system, from the point of view of the values changing hands, not so much from the security side.

3.1.2. Current Systems

There are several dominos games available online. The following section shows a summary of the games’ strengths and weaknesses. Although the specific rules of these games may differ to the application being created in this project, a reasonable idea of how these applications operate can still be obtained.

Each application also allows for the computer to play against humans and therefore implements some form of intelligent algorithm. Although the rules of the games maybe different to the specific dominos game being created within this project, some ideas for potential algorithms may still be gained. Unfortunately, no details of how the algorithms work are displayed within any of the applications.


20

Application 1: [29]

Figure 1. Online dominos game.

+ Very simple interface.

+ Rules of dominos are shown below.

+ The appropriate information is displayed; including number of dominos remaining for both players.

+ Not CPU intensive, allows for multi-tasking.

- Dull interface, with minimal features.

- Dominos are quite small; it can be hard to distinguish between dominos.

- The scores are not accessible at all times, which can be irritating.

- There is only one skill level.

- It can be difficult to identify which domino the opponent has just laid.

~ The train of dominos is fixed; the user cannot lay dominos in any direction.


21

Application 2: [30]

Figure 2. Domino Ace 1.0.

+ Appealing interface; uses sound clips.

+ Opponent takes time to play; therefore it is easy to identify what they have laid.

+ Very basic rules of dominos and how to use the system is available.

+ Options of where to lay are displayed.

- It is hard to play this game whilst performing other tasks because it is quite CPU intensive and must be played as full screen.

- Either the code is very buggy, or the interface does not make it obvious how to play the game.

- Not all information is available; for example, what to do if you are unable to move.

- At the end of a round a screen appears saying who has won. This can be irritating if you only want to see the final board.

- There is only one skill level

~ There is no attempt to score for a game, hence only the result of one round is shown. This may be because it is a demo version.

~ The current scores for each person are shown all the way through (this may not be a good feature as it may give away too much information).


22

Application 3: [31]

Figure 3. Ultimate Dominos.

+ Appealing interface, informative messages, also with music and sound effects.

+ The interface is very easy to use and it is clear how to operate it.

+ Animation shows what domino the opponent has laid.

+ Options of where to lay dominos are clearly displayed.

+ The placement of the dominos is either done by the system giving the user very little choice, or is done by the user. A re-ordering function is implemented to allow the laid dominos to be re-ordered.

+ The rules are clearly displayed.

+ Option of changing background colours and domino colours.

- Hard to multi-task because very CPU intensive and must be played as full screen.

- There are few keyboard shortcuts, the game is very mouse orientated.

- There is only one skill level of computer.

~ The game is a win, lose, draw game meaning no statistics are gathered about previous rounds.


23

Application 4: [32]

Figure 4. Shark Dominos.

+ The interface is simple and informative.

+ The current scores are available all the time.

+ Rules and help menus for the system are available.

+ Different skill levels available.

+ Not very CPU intensive.

- The interface is relatively dull.

- It can be hard to tell what the computer player has laid as it moves very quickly.

- The fact that it is your turn is displayed, but in small letters at the top left.

~ The user cannot choose where to lay each domino.

~ The current scores for each person is shown all the way through (this may not be a good feature as it may give away too much information).

Using the information gathered from the above games the following requirements can be produced;

Functional

• The user must have access to the current scores in a game.

• The user must be able to lay any appropriate domino on either side of the train.


24

• Appropriate help menus must be made available for the user.

• The rules of the game must be available to the user.

• A way of identifying which player’s turn it is must be implemented.

• A way of identifying which player laid which domino must be implemented.

• Multiple difficulty levels must be implemented.

• The user must have an option to knock, or pass a turn.

Non-Functional

• An appealing background must be implemented.

• All basic functionality must be clearly implemented, so that a non-technical person can negotiate the system.

• The system should not be very CPU intensive; most users should be able to multi-task while playing the game.

Optional

• The user must be able to change the background colour.

• There must be a way of identifying which dominos can be laid.

• Appropriate sound effects and music clips must be added to the game.

3.2. Requirements Specification

The above two sets of requirements are fairly open ended. There is also some degree of overlap and ambiguity. This section merges the two sets of requirements to produce the final requirements document. Some new requirements must be introduced for completeness and some requirements will be altered slightly to remove ambiguity. Some requirements are completely removed, but corresponding reasons for this are detailed. These can be found in the Not Included section 3.2.4. The requirements are split into four sections; functional, non-functional, optional and not included. Some requirements may relate to the rules of dominos which are detailed in F.2.

3.2.1. Functional

• Each participant in the game must have a name. The user must be able to define their name. All computer players must also have names, which at least one user must be able to define.

• Outlines of potential moves must be shown. However, some users may not want this feature therefore it must be optional.

• A player must be able to check the current score during any stage of the game.

• A ‘knock’ option must be available to the user. This is used to pass a turn when nothing is available.


25

• A font size of at least 11pt must always be used.

• Instructions must be available to users. These instructions should help the users set up a game over a network and also describe how the specific system works.

• Dominos rules must be made available to the users. These instructions must explain how to play a game of dominos.

• Some identification of which players’ turn it is must be clearly displayed at all times during a round.

• The points needed to win a game must be editable by at least one user.

• The number of games played must be editable by at least one user.

• Some identification of which player has just laid which domino must be available to each user. A history up to each player’s last move must be made available.

• The number of computer/human players must be defined by at least one user. The total number of players must equal 4 and all combinations involving one human being player 1 must be available.

• At least one player must be able to set the difficulty settings of the computer player(s). At least 3 difficulty settings must be available.

• The users must only be allowed to lay dominos on their turn and in a correct location. If an attempt is made to lay an incorrect domino, then the application must reject this move and it must not affect the state of the game.

• The application must not reject any correct moves the user makes. If a user lays a domino in an acceptable location on their turn then the system must accept this move.

• All accepted moves made by a player must be broadcast to all other players. This change must then be displayed on all the player’s views. In the case of computer players, they must also be updated of this change.

• The application must be able to identify when a round is over. The application must then update the scores appropriately and inform all users the round is over and give them the new scores.

• The application must keep track of the score for each team. The application must also inform all that the game is over when the score for a team reaches a certain level.

• A player may only ‘knock’ (pass a turn) when it is their turn and they are unable to move. An attempt to ‘knock’ at any other stage of the game must not affect the state of the game.

• If a player ‘knocks’ (passes a turn) on their turn when they are unable to move, this must be accepted by the system. This must be broadcast to each human and computer player.

• Users must be able to play the game over a network (including the Internet). Users must be able to connect to other users and send appropriate information about the game. This includes having a method of including any computer players in the game.

• The systems mean response time when playing as a computer should be under 10 seconds. Also, the worst case time must not exceed 30 seconds.


26

3.2.2. Non-Functional

• The GUI should be clearly laid out so that the same level of functionality is as easily available to people with minimal computing experience as to people with a higher level of experience.

• Care must be taken when overlaying colours, especially with text.

• A suitably simple screen must be available for the users to connect up over a network.

• The system must provide keyboard shortcuts wherever possible.

• The system must not force the users to use the mouse for an extensive period of time.

• This is an application in which multiple users can alter settings, therefore there is potential for confusion to occur, if multiple users can alter the same settings simultaneously. The system should be designed to avoid these areas of conflict.

• The system must be relatively secure, so that it is not easy for an opponent to see another player’s dominos.

• The system must not be too CPU intensive. Users should be able to multi-task when playing the game.

• The game must be portable to many operating systems.

• The application must be durable and must be able to handle sensibly all kinds of user activity; for example, players leaving a game.

3.2.3. Optional

These requirements will be implemented if there is time.

• Each player must have the ability to change their own name at any stage in the game.

• Coloured dominos (where a colour identifies a different value) must be available to the user.

• A message log detailing which player made which move must be available.

• Statistics about previous games and players must be stored.

• Each user must have the ability to change the background image of the application.

• Each user must be able to play multiple games simultaneously.

• Each player must make a move within a set time.

3.2.4. Not Included

Below shows a list of requirements that will not be included, with appropriate reasons why.

• Allowing the system to recommend suggested moves will not be implemented. This is because some users may see it as cheating. Some people did vote against this when completing the questionnaire.


27

• Users will not be able to communicate via messages. This is because it is outside the scope of the project. Also, users can easily communicate via MSN or another messaging protocol if they really wish to.

• The game of dominos will not be used to gamble. This is because it is outside the scope of the project. It may be a nice feature to implement if more time was available.

• The application will consist of no more than one set of dominos. Again this comes down to the time to complete the project.


28

4. DESIGN

The design section gives an overview of the way the project will be implemented. A top down approach is used. First a process model describes the main features of the application, and then the main areas are discussed. These main areas are then broken down and analysed at a much lower level. Finally, important comments are made about the GUI. Throughout the design references are made indicating how the requirements are being met.

4.1. High Level Design

The high level design gives a brief overview of how the system will meet its main goals. The main processes are described, which is followed by a brief overview of the classes.

4.1.1. Process Structure

Figure 5 shows the main functionality of the system. The figure shows the main processes which will have to be implemented. Not all functionality has been shown; for example; accessing the help screens. Let us start from the top. Upon running the application some form of initial entry screen should be displayed. This will allow the user to enter the appropriate information about the game. The application must allow for networking (as stated in the requirements). Normally, the way to network an application is to have one server and many clients connecting to the server. For this reason the user will select whether they wish to be a server or a client. The user will also enter the appropriate information about the game, including their name, IP address and port information, the number and skill levels of the computer players and possibly more.

If the user chooses to be a server, they must wait for all other clients to connect. The requirements stated that all combinations of players with at least one human must be allowed. Therefore if there is only one human, no waiting will be done, because everyone has joined the game. If there are four human players then every human must connect to the server in order to play the game.

The server’s role in this game is to be in charge of the game. This includes responsibilities such as informing clients whose turn it is, identifying if a game or match is over and distributing as much information as possible to all the clients. Each player must also be given unique dominos. Therefore it makes sense if the server selects the dominos and distributes them to each client6. The server may also distribute other information, including names of players, number of games to play and other information.

At this point everyone is involved in the game. The server is involved in a loop. Each time the server receives some new information; they distribute it to the other players and update their display accordingly. There are four possible events that can occur to trigger the receiving of new information. If it is the server’s turn to move then they wait for the user to lay a domino. Upon laying the domino they distribute the information and update their own display. The second is another player is going to lay a domino. Regardless of whether this is a computer or human player the server must still wait for the information, inform other players and update their display. If the round or current game is over because certain scores have been reached then the same process of informing others and updating the display occurs. The final option is the match is over. This is either because the correct number of games has been played or someone has left the game (possibly caused by a connection error). In this case the user must make a new game if they wish to play again.

6 There is a potential conflict of requirements here as having the server send the clients’ dominos over a

network makes it easy for a user to cheat. A possible way round this is to encrypt the information being sent in the packets.


29

Figure 5. Process diagram displaying the application’s main functionality.

Key;

= the current state the system is in and the appropriate action it must perform

= the event which caused the system to switch states Event

Current state

do: action to perform

End of round/game

do: display

scores

End of match

do: display scores

Initial Screen

do: display Main Screen

Game Created

do: display waiting

Information entered

Client Server

Connection

All players have joined

Waiting for players to join

Players joined

do: setup game

Game loaded

Ready

do: display current state

Game

do: inform others

Have game

information

Own move

do: wait for move

Opponent’s move

do: wait for opponent input

Match Over

do: display scores

Back to the start

End of round/game

do: display

scores

Connecting

do: connect to server

Failed to connect

Joined successfully

Waiting

do: wait for server confirmation

Receive game information

Own move

do: wait for move

Own Information

do: display information

Opponent’s move

do: wait for

server information

Back to the

start

Move made

do: inform

server


30

On the other hand, the user may wish to play as a client. If this is the case then the client must connect to a specific server. However, the user may fail to connect to the server, possibly because the IP address is incorrect, or the server is not waiting. In this case an error message is shown and the client returns to the start screen. Assuming the client successfully connects up then they must wait for all other clients to join the game. Again the client should display the appropriate information to the user to inform them of the progress.

Once the appropriate number of people have joined the server will send information to the client about the game. This is the client’s cue that the game is in progress. The client will enter a similar loop to the server, except the client is not concerned with distributing the information. The client plays more of a passive role; it receives information from the server and updates its display accordingly. Again there are four possible events which result in the client updating their display and communicating with the server. When someone other than the client has made a move or the round is over, the client receives the information from the server and updates their display. When it is the client’s turn to move they receive the input from the user, send the move to the server and display the appropriate information. When the match is over, again either because of someone leaving or the appropriate number of games has been played, the client must set up or join a new game to play again.

4.1.2. Class Structure

From the above diagram and description it is possible to break the system down into sections. The above diagram shows three main sections of functionality for the system. The first is the data display. The application displays and requests much data from the user. Data is mainly required when setting up the game; the initial screen. There are also waiting screens and error messages shown reporting the current status of the application. After the game has been initiated, there are many networking options to choose from. This involves allowing users to connect to each other in order to play the game. This is the second main section. The third section is to allow for users to play a game of dominos. This handles the displaying of the appropriate information about the game and also allowing users to lay dominos in the correct places.

The above three sections take into account most parts of the system; however, it has not yet been discussed how the algorithms will be implemented. Therefore the fourth and final part of the system will look after the algorithms implemented; the AI section.

Figure 6 illustrates a simple diagram of how the four sections fit together and a brief description of each is summarised below.

Figure 6. Application’s main sections and how they relate to each other.

Data

Board

Networking

AI


31

•••• Data – allows the user to enter information about the type of game they wish to play.

•••• Networking – allows communication between users over a network.

•••• Board – controls where each player can lay a domino and the status of the current game.

•••• AI – a variety of different algorithms.

The arrows show the basic flow of which areas call which others. As discussed above, the basic structure involves a user entering their information into the system via the data area. When this is done the information is passed on to a server or a client in the networking section. The game is then set up. The board communicates with both clients and servers in order to negotiate where to lay dominos and the current status of the display. However, only a server will negotiate with algorithms in the AI section, when it is an algorithm’s turn.

4.1.3. Language Choice

In order to program this application a programming language must be chosen. This language must be able to support graphics and user events. Also, networking must be possible in this language. Obvious choices of languages which meet these requirements are Java, C# and C++. It is probably best not to allow this section to turn into a large discussion of which language is better or worse. For this project, Java will be used, mainly because it meets the above requirements. One of the non-functional requirements was to create a portable application and C# is only supported by Windows whereas Java and C++ can run on a variety of OS’s. It has also been mentioned by Sommerville [32] page 291 when discussing which languages are best for real-time systems as being a good choice for real-time programming, if exact timing is not too much of an issue. In this application, random events cause the system to change regularly; for example, when waiting for users to move. However, exact timing is never really required.

4.2. Low Level

The previous section gave a very high level overview of how the application should operate. Java has also been chosen as the programming language has also been chosen; Java. It makes sense if the four areas discussed in the above section Java packages. The following will give an overview of what classes will be used and also detail any suitable algorithms used. It does not go into detail about the specific domino laying algorithms. These are discussed in the algorithms section.

4.2.1. Data

This package will contain all information which allows the user to begin a game of dominos. The first class required is a data entry screen which will allow the users to enter the following information about the game;

• How many points a round is played to.

• How many games to play.

• Which players are human and which are computerised.

• The difficulty levels of the computer players.


32

This package will contain other types of data screens. This includes waiting screens, loading screens, and possibly a scoreboard, or message log. There will not really be any interesting algorithms or complex design decisions in this package.

4.2.2. Networking

As previously stated when playing the game; one user shall be a server and the rest clients. If two clients wish to communicate they achieve this via the server.

This approach will be used in the dominos game in the following way. When a game is created, the user who creates the game shall be the server. They listen for the appropriate number of connections from clients. When a client connects to the server they send down their player number and player name. If the server is awaiting a connection for that particular player they send a success message. The server also informs the client of the current status of the other users so the client is aware of who has joined the game. When playing a game the server is in communication with all the clients and all the computer players. The server receives the move from the appropriate player and distributes it to the other players. The server also tells the clients when the game or match is over. This is achieved by sending a Boolean value at the end of each move.

In order to implement this technique the following classes will be used:

•••• Server – defines the actions of the user who is a server. This includes waiting for connections from clients and distributing the moves.

•••• Client – defines the actions of the user who is a client. This will mainly involve listening for information from the server and informing the server of new moves.

•••• ServerConnection – a class which will make connections for the clients. In order to allow a client to connect while the server listens for other connections this class will be a thread.

•••• WaitForClientConnection – a class which monitors the current status of which clients have connected. This will be used to update the users of the current situation.

4.2.3. Board

The board package displays the information about the dominos board to the user. It also ensures users adhere to the rules of dominos by only allowing correct moves to be made.

The first class required for the board package is an entry screen which allows users to lay dominos. The class will be the most important class in the board package and will contact most other classes to ensure correct moves have been made. In order to handle the drawing of dominos an inner class can be used. This class will use the Java graphics packages. This class shall implement double buffering7 to allow for smoother animation when repainting.

The second class will allow for a mapping between integer and domino. This will help in the process of randomly selecting dominos which can be achieved by putting each domino into a Collection, selecting a random number, then removing the selected domino from the collection.

Two classes willll be used to manage the dominos; one for dominos and one for laid dominos. The class which stores information about a domino will include its values and its orientation. The second class inherits from the first and includes information about dominos that have

7 Double buffering is where the image is rendered off the screen and then translated back on to the

screen in order to reduce flickering.


33

been laid; for example, its location, the player who laid it and its position within the train of dominos.

A class will be used to store information about the train of laid dominos. This shall be a linked list. The list will be in order of the position of the domino in the train, not the time when the domino was laid. Dominos can only be added to the start or end of the train. When repainting the board the train will be used to discover dominos.

A class will be used to store information about theboard. The board shall be represented as a 2-dimensional array of Integers. Each square in the grid covers an eighth of a domino in order to allow for all possible moves described in the rules of dominos; section F.2. An Integer value of -1000 normally means that the current square is empty. A value not of -1000 means that part of a domino is occupying the square. When a domino is laid it is either laid at the start of the train, the end of the train, or both (the first domino, or any domino that completes the train). When a domino is laid there must be a way of knowing that each square relates to the same domino. When a domino is laid two negative values are created. These are inserted into the top left squares that each half of the domino covers. In the case of a double domino only one value is used and it is placed in the top left square. The remaining squares contain an Integer pointer to the appropriate negative value. The question is; what negative values does one choose to put in the top left corner? The only information required is whether the domino is the first or last item in the train, as this is the only place new dominos can be added. Therefore two Integer values are used, one to store the value of the first item in the train, one to store the value of the last item in the train. Both the startTrain and endTrain values start at -100. When a domino is added to the end of the train the endTrain value is incremented, when a value is added to the start of the train the startTrain value is decremented.

Let us analyse the example shown in figure 7;

Figure 7. The integer representation of the dominos board.

The above diagram shows the grid after three dominos have been laid. The thick squares show each domino. The thin line shows the divide, half way into the domino, separating the two values. The first domino has been laid with its top left corner in column 4, row 2. Because it is the first domino both its sides are active allowing other dominos to be laid next to it. This domino is currently the train. The top half of it is the start of the train8. Its value is -101 and the other three 18 values all point to the -101. The bottom half is the end of the train. The value of the end of the train is -99 and the three 32 values all point to the -99 square.

Either of the other two dominos could have been laid next. Let us assume the domino at the top left was laid next. Because this is being laid at the start of the train the start value is decremented to -102. The appropriate pointers are also used, in this case; 14. The -1000 is used on the other half of the domino because no new domino can be laid next to this half of

8 On the first domino lay it is unimportant which half of the domino is the start, or end of the train.

0 1 2 3 4 5 6

0 -1000 -1000 -1000 -1000 -1000 -1000 -1000 1 -1000 -1000 -1000 -1000 -1000 -1000 -1000

2 -102 14 -1000 16 -101 18 -1000 3 14 14 16 16 18 18 -1000

4 -1000 -1000 -1000 -1000 -99 32 -1000 5 -1000 -1000 -1000 -1000 32 32 -1000

6 -1000 -1000 -1000 -98 45 45 45 7 -1000 -1000 -1000 45 45 45 45

8 -1000 -1000 -1000 -1000 -1000 -1000 -1000 9 -1000 -1000 -1000 -1000 -1000 -1000 -1000


34

the domino. The -1000 implies that the domino is not of interest. The new domino has been laid onto the start of the train. This means that if a domino is going to be laid onto the start of the train it must be laid next to a domino of value -102.

The final domino is laid onto the end of the train. This domino is a double. This is known because there is only one value used, the rest of the squares are pointers to this value. The end value is incremented to -98 so now a domino laid onto the end of the train must be laid next to a domino of value -98.

The pointer system works by flattening the 2-dimensional array into a 1-dimensional array; so for value [i, j] the new value can be calculated by;

iCOLSjvaluenew += *_

The board class contains the board 2D array and will handle adding dominos to the board, checking if a domino will overlap with another on the board and returning the value of a square, taking pointers into consideration.

Another class is needed to assess whether or not a domino can be laid in a certain location. The way to check if a domino can be laid in a specified location is to check each of the sides. A display of all the sides is shown in figures 8 and 9:

Figure 8. Laying next to a domino horizontal. Figure 9. Laying next to a vertical domino.

The highlighted blocks show the sides which are analysed to see if a domino can be laid in a certain place. When analysing a side the adjacent block in the grid is analysed. A domino can be in one of four states as shown in table 2:

Table 2. States that a domino can be in upon being laid.

Each side is analysed and one of the states is returned. The domino’s new state is equal to its old state multiplied by the returned value. The domino starts off with the value DOMINO_UNKNOWN. If the side is adjacent to a domino which is not the start or end of the train, or is of a different value to the side then the value returned is DOMINO_INVALID. This always sets the domino’s value to DOMINO_INVALID, as any value multiplied by 0 will always be 0. The domino’s value will not change and the domino will not be able to be laid.

State Numeric

Value

Meaning

DOMINO_INVALID 0 The domino cannot be laid at this location, because it overlaps, or is adjacent to another incorrect domino

DOMINO_UNKNOWN 1 The domino maybe laid at this location if we check more sides, but at the moment it does not contact any other laid dominos

DOMINO_FIRST 2 The domino joins onto the start of the train

DOMINO_LAST 3 The domino joins onto the end of the train

DOMINO_BOTH 6 The domino joins onto both the start and end of the train

1 2

3 4

5 6

7

8

1

2

3

4

5

6

7 8


35

When checking the side, if it is not adjacent to any other domino, or the inner side of area 1, 2, 3 or 4, or either side of area 7 or 8 is next to another domino and the other half is not DOMINO_UNKNOWN is returned. DOMINO_UNKNOWN means that the domino has not been laid next to anything to imply that it should be laid in the specified location. It also means that it does not overlap with any other dominos which will hinder it from being laid in this location. Multiplying by 1 will not change the domino’s value.

If the side is next to the side of the first domino in the train and the numeric values match then DOMINO_FIRST is returned. If all the sides are tested, this can only match once. If the domino originally had the value DOMINO_INVALID then the value is unchanged, because 0*2=0. If the domino originally had the value DOMINO_UNKNOWN then the value becomes DOMINO_FIRST because 1*2=2. If the domino originally had the value DOMINO_LAST then the value becomes DOMINO_BOTH because 2*3=6, which means it is connected to both the start and end of the train.

The DOMINO_LAST behaves identically to the domino first value, except with the last domino in the train.

The DOMINO_BOTH value is reached when both the DOMINO_FIRST and DOMINO_LAST values are returned, as 2*3=6.

The above process is not used when laying the first domino, as no checks have to be performed.

The images for the dominos and potential backgrounds will be stored in image files. Painting an image to screen from a file can be a slow process. For this reason each image will be cached, so it only has to be loaded once. A class which caches all these images will be called on game start up.

4.2.4. AI

The AI package will contain all the algorithms used in order for the computer to play a game of dominos. A super class called Algorithm will be used allowing all other classes to extend from it. This will contain common functions and will also make it easier to implement skill levels as polymorphism can be used.

If the algorithms execute slowly then threading will have to be implemented. This would allow for algorithms to think of moves on other players’ turns. This will be dependent upon the algorithm and will be considered at a later stage. It is important to remember this and deign the algorithms to allow for this change to be relatively easy.

4.2.5. Class Diagram

A class diagram for the application is shown in appendix B.1. This gives an overview of the important classes and how they will fit together.


36

4.3. GUI Design

The following section describes how the GUI will look. Firstly, a brief overview of all the screens within the GUI is presented. This is followed by going into more detail on the one particular screen; the dominos board. Finally, a brief not is presented describing how the non-functional requirements are met.

4.3.1. Overview

The GUI should contain many screens. The first is the initial screen in which users enter their information about the game. Looking back at the requirements the following information is required from the user in order to play the game;

• Whether the user is a client or a server

• If they are a server:

− The port number to play the application.

− Their player name.

• If they are a client:

− Their player number.

− Their player name.

− The IP address and port number of the server

• At least one player must enter:

− Which players are computer players and which players are humans.

− The skill level of the computer players.

− The names of the computer players.

− The number of points in a game.

− The number of games to play.

It makes sense only allowing the server to alter the final five options. This is because it is easier to have only one person altering these values, in order to avoid conflicts and the server seems like the most logical choice. The server also distributes information to each client; therefore each client will obtain this information when the game starts.

After initiating a game the server and client can wait for others to join. This screen should simply inform the user that the application is waiting for other players. It should tell the users the types of players who are playing the game.

Images should be used when playing the game. Many images can be used as there are 28 dominos and allowing each of these to be rotated four ways makes 112 images. Also, background images and icons may be used. Painting from a file in Java is slow. It is much more efficient to cache images. For this reason a loading screen should be displayed when the images are being cached. This will inform the user that an error has not occurred and that the system is loading.

Information screens are essential to users. For this reason they must be included in the application. An information screen informing users how to play dominos and how to use the system is a minimum requirement.

There are other types of screen which may be included, such as score boards, chat rooms, information logs of dominos played and error messages.


37

4.3.2. Dominos Board

The most important screen that has not been mentioned in the above section is the dominos board. This screen will allow for users to play the game of dominos. It should allow them to make moves and also display moves made by other players. A diagram of how this will look is shown in figure 10:

Figure 10. Initial design of the dominos board.

This meets the requirements by displaying the appropriate information. The number of dominos remaining is available for each player. The player can identify whose turn it is by looking at the information displayed in the top left corner, or by analysing the highlighted quarter of the screen, shown by the trapezium. In terms of laying dominos the system will allow a user to select anyone of their dominos using a single mouse click and they will then be able to move the domino onto the screen and lay it. The reason for not using drag and drop is because some users complained about pains they get when using the mouse for extended periods of time, therefore using a single click requires less mouse interaction. In order to rotate the domino, either hold ‘Shift’ and click, or right click, or use the scroll wheel in the mouse. The reason for providing so many options is because some people found it hard to use both the keyboard and mouse, but others seemed to prefer using the keyboard. Allowing the user to scroll using the mouse wheel is a suitable option. However, some users may not have a scroll wheel in their mouse, therefore the options are required. Providing many methods of performing the same task is not very complex and can be of great benefit. When a user holds a domino over the board (in this case domino [1, 4]) their options are displayed by marking the areas where the domino can be laid.

The Menu bar at the top shows several options. The File menu will only contain an option to exit the game. The Option menu bar will contain options including; whether the user wants to see the options, the current scores, the ability to knock and to view a message log of the previous moves made this game. This incorporates several requirements as the user must be able to see the scores at any point, they must be able to disable the options being displayed

Player C

Player B

Player A

Player D

File Options Help

Player A’s turn

KNOCK KNOCK


38

and they must be able to see which user has laid which domino. Other optional requirements can also go in here; for example, the ability to change the colours of the dominos.

The Help menu bar contains information about how to play the game of dominos and also how to use this screen. This was considered in the requirements section as many users do not know how to play dominos.

The above options all have keyboard shortcuts. Many users like the idea of using keyboard shortcuts and it is a non-functional requirement.

4.3.3. Non Functional

Although it is hard to justify here, care will be taken to ensure non-functional requirements are met. The system will be easy to use and appropriate layouts and colours will be chosen. The functional and non-functional testing will be covered later on in the project.


39

5. ALGORITHM DEVELOPMENT

The algorithms section goes into detail about the algorithms developed within the application. The section covers, in detail, all algorithms implemented with basic reasons why they have been implemented. The section uses an iterative structure to describe the development, by continually creating algorithms, testing them and then building upon them.

5.1. Claims

This section shows a brief list of claims that will be used throughout the algorithm development. Claims are used instead of hypotheses because during the algorithm development none of the claims will be proven to be true or false. Instead, strong evidence will be presented which implies whether these claims are true or false. Although mathematical formulas could be used to prove these claims, the process of doing this would be much longer and more complex than the techniques described in the following section.

5.1.1. Definitions

Below some terms are described informally. These terms may be used throughout the algorithm development section.

• Better – algorithm A is better than algorithm B if when given a random distribution of dominos a team consisting of algorithm A is more likely to win against some opposition C, than a team consisting of algorithm B against opposition C. Team C can consist of any algorithms.

• Good – algorithm A is said to be a good algorithm if it is better than an algorithm which randomly selects dominos.

5.1.2. List of Claims

C1) Some algorithms are better than other algorithms.

C2) An algorithm which plays a diverse strategy is good. A diverse strategy involves maintaining a range of values on the player’s dominos.

C3) An algorithm which plays a conservative strategy is good. A conservative strategy will attempt to lay dominos containing high values.

C4) An algorithm which plays a friendly strategy is good. A friendly strategy will involve trying to help the player’s team mate.

C5) An algorithm which plays a grumpy strategy is good. A grumpy strategy attempts to lay dominos to leave the opponent(s) with no options.

C6) Certain algorithms which combine combinations of good algorithms are better than the algorithms by themselves.

C7) Certain algorithms which alter their tactics based upon the current state of the game are better than ones which do not. This claim is of much importance, and is based upon the main trait of dominos that distinguishes it from other games. When playing most games, the location of each player is not of huge significance. Although in a game such as chess, playing as white and making the first move has a small advantage, it is not thought not be of huge significance. However, there are four possible starting places in dominos and


40

a player’s location should alter how they play. This tactic should also change depending upon how the game progresses..

C8) The ‘better’ relationship is not reflexive, not symmetric, but is transitive.

5.2. Algorithm Overview

The following section describes the algorithms implemented in this project. It gives a mathematical overview as to how the algorithms work, why they have been implemented and estimations of their skill level.

When playing dominos there are many tactics that can be used. The claims imply that certain tactics are better than others. It is true that in some rounds a player can be dealt a poor hand and they are a lot less likely to win the round, but it can be argued that there is an element of luck in any game. Within this section the aim is to develop optimal algorithms.

As stated in the literature review game theory is not a useful tactic to use in this case. The reasons being because game theory is not necessarily designed for zero-sum encounters, as it tries to maximise the profit for each player. It is also far too computationally complex as there are many different scenarios in dominos.

For this reason, the algorithms developed are computationally simpler. These algorithms are based upon trends which were found by doing some research on what people had done in similar games (and dominos) and by playing the game.

On a more practical note, a test suite has been implemented. This allows computer players to play against each other for a set number of games. Algorithms can then be compared in order to gain an understanding of how effective they are.

The algorithms implemented are discussed below. They all have two properties in common. On the first lay of the round they lay the domino in a central position on the board. This is to encourage the round to last longer and not get into a situation where parts of the train become trapped. Each algorithm also returns an order of dominos based upon their importance. On the player’s turn this list is iterated through and the highest domino on the list that can be played is played.

5.3. Basic Algorithms

The first set of algorithms created are based upon very simple,very general tactics. Each algorithm is descibed in the following section.

5.3.1. Trivial

This algorithm is the default naive algorithm. The domino ordering is random. This algorithm is mainly used to test against other algorithms. Any algorithm better than this algorithm is said to be good.

5.3.2. Diversity

This algorithm plays a tactic which is to ensure a high level of diversity amongst its dominos. Diversity means it attempts to hold as many different numbers as possible. The idea behind this tactic is that a player is more likely to be able to lay if they have more options and therefore more likely to win.

The algorithm is described below:


41

1. Loop over the dominos owned and create an array of how many of each value there is. Only count doubles as one number. From the sequence displayed in figure 11:

Figure 11. Dominos used for Diversity algorithm example. Table 3 can be calculated:

Table 3. Diversity algorithm; occurrences of domino values.

Note how there are only two 3s and four 4s as the double is only counted once.

2. Loop back over the list of dominos and create a new array relating to how diverse each domino is. This is achieved by assigning the results calculated in part 1 to the appropriate value of the domino. Therefore each domino will have 2 values assigned to it. In the case of double dominos one value assigned to it will be the value of the domino, and the other is a value larger than all others (number of dominos + 1). If we apply this to the previous scenario we get the values shown in table 4:

Table 4. Diversity algorithm; values assigned to each domino.

3. The above table is then quick sorted based upon the data in the Values column. Each cell in the Values column consists of two numbers; a larger and a smaller number. When comparing this data, the first comparison is done using the smallest number, moving the biggest of these small numbers to the top of the list. In cases where the small numbers are equal the larger numbers are compared moving the bigger ones to the top of the list. In cases where both are equal, no distinction is made. The results of the quick sort on the above data is shown in table 5:

Face value Number of occurrences

0 0

1 2

2 1

3 2

4 4

5 1

6 2

Domino Values

[4, 6] 4, 2

[1, 2] 2, 1

[4, 4] 4, 8

[3, 3] 2, 8

[1, 6] 2, 2

[3, 4] 2, 4

[4, 5] 4, 1


42

Table 5. Diversity algorithm; an ordering of dominos.

The lines have been removed for all values that are equal.

4. The list is returned. The higher the domino on the list, the more likely it is to be played. The domino [4, 4] is the best option.

The above algorithm seems to produce a rational ordering in the above example. The reason for using this algorithm is described in the next few paragraphs. The first step in the algorithm is to count the number of each type of domino a player has. This is to give a guide as to how important a domino is. Doubles are only counted once. The reason for this is because a double domino can only be laid once. Therefore once it has been laid both values are lost, meaning it only contains one option.

In step 2 values are assigned to each domino. This is based upon how much it occurs. In the case of doubles a high value is used for the second number. This is because from a diversity point of view there is no obvious advantage of laying domino [X, Y], where X ≠ Y over laying domino [X, X]9. Therefore this algorithm will always lay [X, X] before laying [X, Y], when given the choice.

The third step quick sorts the data to get the appropriate order. The reason why the comparisons work in the above way is because the algorithm is cautious and always try to avoid laying a domino if it is the last of its number, as this is a situation to be avoided. The example above shows that domino [1, 6] is more likely to be laid than [4, 5], even though there are more 4s than any other value. However, if domino [4, 5] were to be laid, then we would not own any 5s and would be less likely to be able to lay on our next turn.

5.3.3. Conservative

This algorithm attempts to minimise the effects of losing a round. If a team loses a round the total number of dots they have on their remaining dominos contribute to the other team’s score. Therefore the algorithm’s tactic is to always lay dominos of high values.

As with the diversity algorithm a quick sort is used. This algorithm simply sorts the dominos into order based upon the sum of their dots. Let us take the example shown in figure 12:

Figure 12. Dominos used for Conservative algorithm example.

The results shown in tables 6 and 7 would be created:

9 There may be an advantage in some rare cases; for example, if thinking moves ahead. This is

discussed later on in this report in section 5.5.

Domino Values

[4, 4] 4, 8

[3, 3] 2, 8

[4, 6] 4, 2 [3, 4] 2, 4

[1, 6] 2, 2

[4, 5] 4, 1

[1, 2] 2, 1


43

Table 6. Conservative algorithm; Table 7. Conservative algorithm; values assigned to each domino. an ordering of dominos.

The sorted data is on the right. The quick sort is much simpler and moves larger values to the top of the list; there is no preference with identical values. As with the Diversity algorithm, the highest value is most likely to be played. In this case the [3, 6] domino is the most optimal solution.

5.3.4. Domino Prediction

The next three algorithms are all very similar and all work with estimations of what dominos other players own.

In total there are 28 dominos. There are 4 players within the game. If there is no information about the dominos the probability that domino X belongs to player 1 is 1/4. Also, if player 1 owns one domino and there are 28 dominos in total, the probability they own domino X is 1/28. The above formulas may seem obvious, but they lead to important equations 1 and 2:

∑=

=N

n

n

dp

1

1 Ddd ≤≤⋅Ν∈∀ 1 (1)

∑=

=D

d

n

d

n

pD1

Nnn ≤≤⋅Ν∈∀ 1 (2)

Where:

D is the total number of dominos left

Dn is the total number of dominos owned by player n

d is a natural number representing a domino

N is the number of players

n is a natural number representing a player

pn

d is the probability between 0 and 1 inclusively of player n owning domino d

It is important to realise that N will always be 4 as there are 4 players in the game

of dominos. However, D changes throughout the game as it relates the number of dominos that have not been laid.

Informally, the first of the above formulas means that for any given domino the probability it belongs to any player is 1. This is obviously true, as a domino must belong to a player. The second formula means that for any player, the sum of the probabilities that they own dominos is equal to the number of dominos they own. Again this must be true as it implies the probability a person owns their number of dominos is 1.

In theory, all that is needed to calculate these probabilities are matrices as described below:

Domino Value

[2, 4] 6

[3, 6] 9

[0, 2] 2

[0, 3] 3

[3, 3] 6

[1, 2] 3

[2, 3] 5

Domino Value

[3, 6] 9

[2, 4] 6 [3, 3] 6

[2, 3] 5

[0, 3] 3 [1, 2] 3

[0, 2] 2


44

ppp

ppp

ppp

N

D

NN

D

D

P

⋅⋅⋅

⋅⋅⋅⋅⋅⋅⋅⋅⋅⋅⋅⋅

⋅⋅⋅

⋅⋅⋅

=

21

22

2

2

1

11

2

1

1

A matrix of the probabilities of the dominos

1

1

1

1 ⋅⋅⋅=

CD A column matrix of depth D

1111 ⋅⋅⋅=RD

A row matrix of length D

D

DD

N

D⋅⋅⋅

=2

1

A column matrix of the number of dominos owned by each player

From these matrices we can calculate equations 3 and 4:

CDRD IPI =⋅ (3)

DIP CD =⋅ (4)

After some equation rearranging and substitution we get equation 5:

( ) DPP RD =⋅⋅ 1 (5)

Equation 5 results in four simultaneous equations each with 112 variables.

In practice the above equation is not as complex as it may seem. When playing dominos, at the start the location of seven dominos is known, the ones you currently hold. Therefore the equations have a worst case where there are 84 unknowns.

This is still very complex and one way of solving this equation would be to by enter known values and obtain other values using the fact that most of the probabilities should be equal and between 0 and 1. However, this is a very computationally complex technique.

The following details another algorithm which is not as computationally complex; however, it obtains an approximate solution.

1. At the start 0 values are entered into all the probabilities, except for the dominos which can be seen (the dominos in the player’s hand), where the value 1 is used. Two lists are also created for each player which contains the dominos definitely owned by a player (own list) and the dominos definitely not owned by a player (not-own list).

2. The following events cause the probabilities to be updated:

a. At the start of the round after the above set up.


45

b. When a player lays a domino. c. When a player ‘knocks’. In this case the appropriate not-own list is updated, as the

player can not own certain dominos.

3. When changing the probabilities firstly the own and not-own lists are updated. This is done in two ways. If a domino appears on all but one not-own list then the other player must own it, hence it is updated on their own list. If a player owns N dominos and the total number of dominos available minus the number of dominos on their not-own list is equal to N, then they must own all these dominos. In other words if player 1 owns 2 dominos and all they can own is [0, 0] and [0, 1] then they must own these dominos. This is updated on their own list and also updated on every other player’s not-own list.

4. The other probability values are updated as follows. First the players are ordered so that the players with the most information about them (based upon the own and not-own lists) are analysed first. Next, the probability of each remaining domino for that player is calculated by doing the number of places that the domino could exist for that particular player divided by the total number of places that the domino could exist for all players. After the dominos have been analysed the dominos are normalised so the probabilities for a particular player sum to the total number of dominos that the player owns.

The above algorithm is computationally simple. It will also always say if a domino is definitely somewhere, or definitely not somewhere. The probabilities it gives of where other dominos are seem to be fairly accurate. However, although formula 2 holds, formula 1 does not. If a player knocks, the sum of the dominos can be approximately 0.3 out. The reason why formula 2 holds and formula 1 does not is because the dominos are normalised with respect to formula 2 after being normalised with respect to formula 1.

The reason for choosing to ensure formula 2 holds rather than formula 1 is because the results will be accurate over dominos within players rather than the dominos between players. When trying to decide if a player owns a domino this seems more important.

5.3.5. Friendly

The friendly algorithm tries to help its team mate. This is achieved by trying to keep their diversity high, so that they can always lay a domino. The Friendly algorithm uses the probabilities gathered in the previous section. The tactics used in the Friendly algorithm are almost identical to the Diversity algorithm. The process is described below:

1. Continually gather statistics for the probability a player owns a certain domino, as described above.

2. Loop over all the dominos the team mate could own and create an array for each number, the sum of the probabilities. As before doubles are only counted once. Tables 8 and 9 show an example of this (table 8 shows the statistics gathered, table 9 shows applying the statistics to the values):


46

Table 8. Friendly algorithm; probabilities Table 9. Friendly algorithm; values assigned of team mate owning dominos. to each face value of a domino 0-6.

3. Calculate a value for each domino. We must distinguish between which side of the domino joins onto the train, so the number of values shall be double the number of dominos. Assuming a domino will be laid where the face A is joining onto the train, the value shall be created in the following way; Guessed Number of Occurrences for B minus the Guessed Number of Occurrences for A. The exception is the first go, where no side shall be joined onto the train (as it does not exist), therefore the formula is Guessed Number of Occurrences for A plus Guessed Number of Occurrences for B. Tables 10 and 11 show an example of this:

Table 10. Friendly algorithm; Table 11. Friendly algorithm; values assigned to dominos on first turn. values assigned to dominos not on first turn.

Table 10 assumes it is the first go. Table 11 assumes it is not the first go. The values on the left in table 11 are assumed to be joining onto the train.

4. As with the previous algorithms the dominos with the largest values are chosen.

The reason for choosing an algorithm like this is because it attempts to keep the options completely open for the team mate. The first step attempts to be the same as the Diversity algorithm. However, the appropriate information is not available so the dominos the opponent owns are approximated via the probabilities. This is achieved by making predictions about what the other team mate owns.

The second step assigns values to the dominos. The idea is to keep the options open for the team mate by creating options for them and not covering up potential options. This is the reason for subtraction, because if the team mate does not own any 0s, but owns a lot of 1s, then a domino which covers up a 0 or opens up a 1 will be given a high value.

Face Value Guessed Number of Occurrences

0 0.5

1 0

2 1.25

3 1

4 0.5

5 0

6 0

Domino Probability

[0, 0] 0.5

[2, 3] 1

[2, 4] 0.25

[4, 4] 0.25

[5, 6] 0

Domino Value

[0, 1] 0.5

[2, 5] 1.25

[2, 6] 1.25

[3, 3] 2

[4, 6] 0.5

Domino Value

[0, 1] -0.5

[2, 5] -1.25

[2, 6] -1.25

[3, 3] 0

[4, 6] -0.5

[1, 0] 0.5

[5, 2] 1.25

[6, 2] 1.25

[3, 3] 0

[6, 4] 0.5


47

5.3.6. Grumpy

This algorithm attempts to hinder either of the opponents, not both of them. This is achieved by a process which is almost identical to the Friendly algorithm, except the emphasis is now on laying dominos which leave either of the opponents with no options. The algorithm is almost identical to the above process apart from if a domino is to be laid where the face A joins onto the train then the value for that domino is calculated using the formula; Guessed Number of Occurrences for A minus the Guessed Number of Occurrences for B. Also, on the first move the values are calculated by doing minus Guessed Number of Occurrences for A minus the Guessed Number of Occurrences for B. This will attempt to minimise the opponent’s options.

The reasons for creating this algorithm in this way are almost identical to the reasons given in the friendly algorithm in the above section.

5.3.7. Competition

In order to test the above tactics a simulator has been implemented. This allows computer players to play a number of games with the results written to a file. The tests completed involved playing 100 games up to 100 points. Every algorithm against every other algorithm. The results are shown in table 12:

Table 12. Competition.

Dominos is played in teams, so in each match a team of one sort of algorithm played a team of another sort. There are two reasons for making each algorithm play itself. The first as a basic check, to ensure that there is nothing obviously wrong with the algorithm. No algorithm should perform better or worse in a certain place. The second reason is to see how random a game of dominos is. This would indicate whether 100 games would be enough to gain an idea of what algorithms were best. The matches won column counts the number of other algorithms the particular algorithm wins against (not including when they played themselves). The games difference is the total number of games won minus the games lost. The position is based upon matches won. In the event of a tie, the winner of the match between the two tied competitors is significant. If there is still no winner then the games difference decides the outcome.

5.3.8. Analysis of Results

The first conclusion that can be drawn is that 100 games are enough to play to ensure a conclusive result; i.e. the results are representative of each algorithm’s skill level. When algorithms played each other they normally ended up with almost equal games won. The worst case was 54/46 which is acceptable.

The next conclusion is that the results back up claims 1 and 8. Claim 1 implies that some domino strategies are almost certainly better than others. This implies that dominos is mainly a game of skill and that it is also possible to design intelligent algorithms. One reason why

Algorithm T D C F GL GR Matches Won

Games Difference

Position

Trivial 49/51 17 28 79 13 13 1 -100 5th

Diversity 83 46/54 75 100 46 48 3 102 3rd

Conservative 72 25 50/50 97 24 24 2 -8 4th

Friendly 21 0 3 47/53 1 5 0 -220 6th

Grumpy left 83 54 76 99 48/52 56 5 118 1st

Grumpy right 87 52 76 95 44 49/51 4 104 2nd


48

this is clear is because when algorithms play each other there is almost no difference between the games won. However, when algorithms play each other there can be a huge spread of the games won. Claim 8 also holds as the results are not reflexive, not symmetric and but they are transitive (if A beats B and B beats C then A beats C).

Let us analyse the results of each algorithm in more detail. The algorithms can be split into four main groups;

• Friendly – this performed the worst. This algorithm actually did worse than Trivial algorithm, which chooses dominos randomly. This provides evidence against claim 4.

• Trivial – this algorithm was intended to be a base case as it chooses dominos randomly. The main surprise here is that it beat the Friendly algorithm.

• Conservative – this algorithm does not use such an intelligent approach. It does not attempt to win rounds, but merely attempts to minimise its loss. Because of this tactic, it seems obvious that it would lose to stronger algorithms, such as the Diversity algorithm. This algorithm also may slightly contradict Diversity as it tries to use its entire high value dominos, thus lowering the diversity of the dominos. This also implies claim 3 is true.

• Diversity, Grumpy Left and Grumpy Right – all performed very similarly. The results showed that the grumpy algorithms did slightly better than Diversity, but not by a lot. Grumpy Left performed slightly better than Grumpy Right. This is to be expected as it is easier to hinder the player playing directly after you. This backs up claims 2 and 5.

One reason why the Friendly algorithm performed so poorly and grumpy algorithms performed similarly to the Diversity algorithm is described below. Assume player A is playing a Friendly algorithm. They are working with player C against B and D. The Friendly algorithm predicts what dominos player C has. At the start of a round the only information known is the dominos currently owned by player A. Therefore player A assumes player C has different values. Thus if player A has many 5s then they will assume player C has few 5s. Player A will therefore try to avoid laying 5s, unless they cover up 5s. Bearing in mind player A has many 5s, very few other players will and therefore they will not get much chance to lay them. In effect the Friendly algorithm is almost like an inverse Diversity algorithm.

The grumpy algorithms are almost the opposite of the Friendly algorithm. Using the same logic presented in the last paragraph the grumpy algorithms maintain a high level of diversity towards the start of the round. This explains why their results are fairly similar to the Diversity algorithm.

The above results do not imply that the Friendly algorithm is of no use or the grumpy algorithms are identical to the Diversity algorithm, or to each other. However, these algorithms may need to be altered to be much more effective.

Over the next few sections several improvements and new algorithms are implemented, some of which are described briefly below.

• Many combinations or merges of the above algorithms could be implemented. This could involve making certain algorithms inactive until a certain point in the game. For example; Diversity could be used until a player knocks, then there is more information allowing either a Friendly or Grumpy algorithm to suggest dominos. This idea could be expanded to allow a variety of algorithms to suggest appropriate moves.

• The Diversity algorithm could be improved. Consider the scenario in which the Diversity algorithm is given a choice. If the optimal domino to lay is the domino [1, 2]


49

and on one end of the train there is a 1 and the other end there is a 2. Clearly which way round the domino should be placed is of importance, because the player may prefer to leave the two 2 values, or two 1 values exposed. Considering this, an extension to the Diversity algorithm is to allow it to look many dominos ahead to ensure a high level of Diversity.

• More statistics could be gathered in order to gain a bigger picture of the game earlier on. These statistics could be based upon tactics, for example; other players are likely to play diverse tactics. Hence if someone lays a 6 on the first move they are likely to have more 6s. This idea could then be extended to gather statistics about other players’ tactics.

• Work should be done on improving the Friendly algorithm. The above point looks into using new statistics, so a second Friendly algorithm could be made. Also, the Friendly algorithm could only be played at certain points in the game.

5.4. Merging Algorithms

Based upon the previous results let us assume that some algorithms are better than others. However, the better algorithms may still lack some desirable features. These algorithms may be best suited to 90% of the scenarios. The algorithms which perform worst may be best suited to 10% of the scenarios. If we can identify the scenarios in which algorithms perform best, we should be able to develop an algorithm which performs well all the time.

5.4.1. PrioritiseDC

Let us start simply and look at the Diversity and Conservative algorithms. From the tests it is safe to assume that both algorithms are good and Diversity is better than Conservative. From this information an algorithm which combines both Diversity and Conservative algorithms is implemented.

The PrioritiseDC algorithm uses the Diversity algorithm to order the dominos. However, there are cases where the Diversity algorithm cannot distinguish between certain dominos, because laying either one will have the same effect on the overall diversity. In such cases the PrioritiseDC uses the Conservative algorithm’s ordering to make a selection. Again there can be certain cases where there is no preference between dominos, but these cases will be less common.

It is probably worth mentioning here (for those analysing my code) that the actual implementation of this algorithm is quite different to the technique described above. However, the final ordering of the dominos is the same. The reason for not describing the process used to implement the ordering here is because it uses techniques described in the next section.

5.4.2. MergeDC

This algorithm still only works with the Diversity and Conservative algorithms. However, this algorithm works in a more complex way. The idea is to use heuristics, which means each algorithm assigns each domino a certain value. Then the MergeDC algorithm takes these values, applies a certain formula to them and produces a final value for each domino. The MergeDC algorithm then chooses the domino with the highest value from those which can be laid. The formula applied to each value will depend upon the current state of the game.

The question is how to produce the values for the dominos. These values really have to be within the same bounds, otherwise it will be unfair as the Diversity algorithm may give a


50

value of 1 and the Conservative may give a value of 100. The bounds will be between 0 and 1. Let us start by looking at the Diversity algorithm. Remember that the Diversity algorithm works by assigning each domino two values, a larger and smaller value, depending upon how diverse this domino is. One way would be to discover how many different combinations of values there are and assign a new value to this domino. This would work in the way shown in table 13:

Table 13. Linear heuristics applied to Diversity algorithm.

Equations 6 and 7 are used:

( ) bDsDsu ++−++−= )1(5.15.0 2 (6)

)(uMAX

un = (7)

Where D is the number of dominos and ( )MAX returns the largest number from a

list of numbers.

The table shows the values assigned when there are only 3 dominos remaining. The largest value can be four, because of the way of assigning values to double dominos. So a domino containing [2, 6] when there are two 2s and three 6s would be given a value of 0.6.

The above may look fairly accurate. However, the above is a polynomial function and has a constant increase. Therefore, the difference between choosing a domino with small and big values of {1, 1} and {1, 2} is 0.1 and the difference of choosing a domino with small and big values {3, 3} and {3, 4} is also 0.1. This does not accurately model the choices of moves in a dominos game. The difference between selecting a domino of {1, 1} and {1, 2} should be large and it should not make too much difference if a domino with values {3, 3} or {3, 4} is selected. Therefore a logarithmic function should be used as shown in table 14:

Smallest Value (s)

Biggest Value (b)

Unique Number (u)

Normalised Value (n)

1 1 1 0.1

1 2 2 0.2

1 3 3 0.3

1 4 4 0.4

2 2 5 0.5

2 3 6 0.6

2 4 7 0.7

3 3 8 0.8

3 4 9 0.9

4 4 10 1


51

Table 14. Logarithmic heuristics applied to Diversity algorithm.

( )( )( )uMAX

un

ln

ln= (8)

Now the difference between laying a domino with small and large values {1, 1} or {1, 2} is ~0.3 and the difference between laying a domino with values {3, 3} and {3, 4} is ~0.05.

The Conservative algorithm works by taking the sum of the spots on each domino and trying to minimise the values of the dominos, by laying ones with large values. Mapping the Conservative algorithm’s results to values is much simpler. Firstly, from a conservative point of view there are only ever 12 types of domino, whereas with the Diversity algorithm there can be up to 36 types of domino and this value will change in each round. Secondly, a polynomial mapping seems to be logical as the difference between laying a domino of value 11 or 12 should be the same as the difference between laying a domino of value 0 or 1. Therefore the mapping displayed in table 15 can be used:

Table 15. Linear heuristic applied to Conservative algorithm.

Sum (s) Normalised Value (n)

0 0

1 0.083333

2 0.166667

3 0.25

4 0.333333

5 0.416667

6 0.5

7 0.583333

8 0.666667

9 0.75

10 0.833333

11 0.916667

12 1

( )sMAX

sn = (9)

Smallest Value (s)

Biggest Value (b)

Unique Number (u)

Normalised Value (n)

1 1 1 0

1 2 2 0.30103

1 3 3 0.477121

1 4 4 0.60206

2 2 5 0.69897

2 3 6 0.778151

2 4 7 0.845098

3 3 8 0.90309

3 4 9 0.954243

4 4 10 1


52

Where ( )MAX is a function which returns the largest number from a list of numbers.

A function can now be created which uses the values from the Diversity and Conservative algorithms to return an ordering for the dominos. This function can also take into account the current state of the game. Let us look at the Diversity algorithm. The question is; when is this algorithm going to be most effective? The Diversity algorithm is used to win, therefore this algorithm will be most effective when being part of a winning team and when being ahead of your team mate. This is because you are most likely to win and therefore want to maintain that lead. The Conservative algorithm should be dissimilar. The Conservative algorithm actually assumes you will lose the round; therefore it should be most effective when you are part of a losing team.

Equations 10 and 11 can be calculated:

( )DDD

PBA

A

A +−= 1 (10) ( )DD

DP

21

1

11

+−= (11)

Equation 10 calculates the probability that team A will win. The symbols DA and

DB are the number of dominos owned by team A and team B respectively. Equation

11 calculates the probability that player 1 will finish before their team mate player 2.

Again the symbols D1 and D2

represent the number of dominos owned by players 1

and 2 respectively.

Equation 12 shows the formula used in the MergeDC algorithm:

)1(2

1Ai

Aii PCDSV

PP −⋅+

+⋅⋅= Nii ≤≤⋅Ν∈∀ 1 (12)

Where:

iV is the value assigned to domino i.

iD is the value assigned to domino i based upon the Diversity algorithm.

iC is the value assigned to domino i based upon the Conservative algorithm.

AP is the probability that team A will win based upon the current distribution of

dominos, assuming the player belongs to team A.

1P is the probability that player 1 (this player) will finish before their team mate, based

upon the current distribution of dominos.

S is a constant to multiply the Diversity value by, because the Diversity algorithm

seems to be better than the Conservative algorithm. At the moment this is 3, because Diversity beat Conservative 75-25, therefore a naive assumption is it is three times better.

N is the number of dominos owned by the player.

5.4.3. Competition II

A second competition was run with the new algorithms. The same rules as before, but the two new algorithms are pitted against the Trivial algorithm to see if they are good and against the top three algorithms to see if they are better than the previous best algorithms. The results are shown in table 16:


53

Table 16. Competition II.

The new ordering of the algorithms, based upon the previous and current results are:

1st Grumpy Left (has not lost a match) 2nd MergeDC (only lost 1 match, but lost to Grumpy Left) 3rd PrioritiseDC (lost 2 matches and beat Grumpy Right) 4th Grumpy Right (lost 2 matches, but lost to PrioritiseDC) The rest the same as before.

First of all these results back up claims 6 and 7, because merging algorithms together and changing their tactics based upon the current state of the game seems to make an improvement. However, although there is an ordering for the best algorithm there appears not to be much difference between the top five competitors. In order to gain a greater understanding of what is happening a new competition will be run consisting of the top five algorithms with matches up to 1000 games. The table 17 shows the results of the tests:

Table 17. Competition II.

By allowing matches consisting of 1000 games the proportion of error should be reduced. This should increase the confidence that algorithm A is better than algorithm B if A beats B. The above results show that the Diversity algorithm appears to perform worse than the other algorithms. The other algorithms all appear to be fairly similar; it is hard to distinguish an between these algorithms. Although the Merge algorithm wins overall, it appears to perform similarly to the Grumpy algorithms. However, the results of most of these matches are too close to define an ordering from. This test also produces evidence to falsify the claim that the term better is transitive, as there are some inconsistencies.

5.5. Diversity Algorithm

The Diversity algorithm can clearly be improved. This is because it does not think ahead; it only looks at the current selection of dominos. Let us take the example shown in figure 13:

Figure 13. Dominos used to illustrate problems with Diversity algorithm.

Suppose that we have the above dominos and we can only lay a domino containing the value 4. The current Diversity algorithm will only look at the current values and will recommend either [0, 4] or [4, 5] with no preference. From a Diversity point of view the best option is to

Algorithm T D GL GR P M Matches Won

Games Difference

PrioritiseDC 93 59 45 57 45/55 43 3 47

MergeDC 93 58 48 53 57 48/52 4 59

Algorithm D GL GR P M Matches Won

Games Difference

Position

Diversity 493/507 441 457 434 435 0 -223 5th

Grumpy left 559 484/516 513 511 481 3 64 3rd

Grumpy right 543 487 482/518 524 514 3 68 2nd

PrioritiseDC 566 489 476 500/500 491 1 22 4th

MergeDC 565 519 486 509 487/513 3 79 1st


54

lay the domino [0, 4] as this has the chance of leaving a 0 open for next time. Laying the dominos [0, 4] followed by [0, 0] is the more profitable from a diversity point of view than laying the sequence [4, 5] followed by [5, 6]. This is because the first sequence results in owning no 0s and the second results in owning no 5s or 6s. The Diversity algorithm should be able to identify this.

Figure 14. Dominos where Diversity algorithm has no preference.

If we take the example shown in figure 14 then we may have an option to lay a domino containing either a 2 or 3. The Diversity algorithm will choose the domino to lay randomly. However, clearly the best option here is to lay the domino of value [2, 3] leaving the 3 open. This is because there is more chance of being able to play on the next go.

5.5.1. DiversityII

The DiversityII algorithm is supposed to be an improvement on the Diversity algorithm. The new algorithm attempts to fix the flaws identified above in the previous Diversity algorithm.

The major problem with the previous algorithm is the fact that it does not look into the future. The idea of DiversityII is that it assumes a domino has been laid; it then looks at the Diversity created if this domino were to be laid. DiversityII uses the following algorithm:

1. Assign a value to each domino based purely on its Diversity (described in the MergeDC algorithm in 5.4.2).

2. For each value, increase it by a certain amount. The amount to increase it by cannot be more than the next value in the list. The amount to increase it by is also dependent upon the Diversity left after laying the domino. The following formula is used:

( )( )

( ) ( )( ) ( ) ( )

( ) ( ){ }∑=−

=∨=∧≠∈∀⋅−

−++=

D

j

j

DD

ii

D

i

i BjAiAjAiijjuuuD

uu

u

un

11

....lnln

1

ln1

ln1ln

ln

ln

(13)

The above formula may look very confusing; however, it is actually very simple. We are

trying to find a normalised value for domino i, in represents this value. I must apologise for

changing syntax since the previous example, but I had to find logical ways of representing

certain values. Now the iu represents the unique number for domino i and Du represents the

maximum unique number for D dominos. The first part of the formula, before the + is identical to the one previously mentioned.

The next part of the formula attempts to add on a certain value depending upon the Diversity after a domino has been laid. Adding on this value will not affect the overall diversity ordering, but it will sort out conflicts based upon the examples shown at the start of this section. Put another way, if domino A has unique number i and domino B has unique number j, where i > j then the Diversity function will choose A above B. The DiversityII function should also choose A above B. This next part of the formula maintains this. It finds the next unique number (i+1) finds its normalised value and subtracts i’s normalised value. It then divides through by the total that the increase could be (D – 1, where D is the number of dominos). The reason why this is the maximum the increase could be is because each domino can have a value of 1 and the next part of the equation tests each domino other than i.


55

The next part of the equation sums the values for each remaining domino. However, it only sums the values of the dominos that are not equal to i and also have one side matching A’s active side. This is how the DiversityII algorithm takes into account which way round a domino is laid and will try to ensure its uncovered side, or active side has a more diverse value. As usual to normalise these values they are divided through by the maximum value,

1−Du as there is now one less domino.

The above formula is quite complex, but understanding it is not an issue, as long as the reader knows that each domino’s value will increase by a certain proportion based upon the dominos remaining. Also, the original Diversity algorithm’s ordering is not changed, except when the algorithm cannot decide on the ordering.

Some readers may notice several problems with the DiversityII algorithm which are clarified below;

• The above DiversityII algorithm does not always produce a definite ordering. However, it will produce a definite ordering more often than the Diversity algorithm.

• The DiversityII algorithm should be recursive, so when getting the values for the remaining dominos, the algorithm should recurse deeper until no dominos are left. In theory this would be a good idea. However, in practice this will probably gain very little. The value function would almost certainly have to be readjusted so that when checking other values more of an impact is made on the current function.

• ( )1−D is not the maximum value that a domino can increase by for two reasons. The

first is that for a normalised value to be one under this new system it means that upon laying it, it must leave an optimal amount of Diversity. Since this function is not recursive, the Diversity of the remaining dominos is not analysed; hence the value 1 will never be reached. Secondly, because there are too many dominos it is physically impossible for them all to be completely diverse. However, this is a reasonable approximation without making the formula unnecessarily complicated.

• The question can be asked; “why bother increasing the value by such a small amount?”. Although the value to increase is relatively low, it does minimise indefinite decisions between dominos. This algorithm will also be combined with other algorithms (combining it with the Conservative algorithm is shown below). Although this increase may not affect the decision of which domino to lay, as the Conservative algorithm’s value will be much more of a dominating factor than the increase in the value, it should affect which way round to lay a domino. We shall see how much of a difference this makes.

5.5.2. PrioritiseDIIC & MergeDIIC

The PrioritiseDIIC and MergeDIIC are exactly the same as the PrioritiseDC and MergeDC algorithms created above in section 5.4, except they use the DiversityII algorithm instead of the Diversity algorithm.

5.5.3. Competition III

As a quick test the algorithms were run against the Trivial, Conservative and Diversity algorithms in a match consisting of 100 games:


56

Table 18. Competition III.

The results shown in table 18 look hopeful. The new algorithms have the potential to be better than the previous algorithms. The new algorithms are placed against the previous best algorithms in matches consisting of 1000 games. The results are shown below:

Table 19. Competition III.

The results show that the new algorithms are comparable to the old algorithms. Although the DiversityII algorithm seems to perform better than the Diversity algorithm, it does lose to all other algorithms. The PrioritiseII and MergeII algorithms seem to perform fairly similarly to the previous top four algorithms. An approximate ordering is shown below:

1st MergeDC, MergeDIIC, Grumpy Left, Grumpy Right 2nd PrioritiseDC, PrioritiseDIIC 4th DiversityII 5th Diversity

These tests back up claims 2, 6 and 7 but again contradict claim 1.

5.6. New Probabilities

The previous statistics algorithms worked with the assumption that the other players chose their dominos in a random way. Strong evidence has been discovered to support claim 2; a good strategy is likely to be based upon a somewhat diverse strategy. This section discusses a new strategy of deciding which players own which dominos by making assumptions based upon the dominos laid on previous turns.

5.6.1. Statistics

Depending upon when a player lays their domino we can make assumptions about the other dominos they have remaining. If a player plays a diverse strategy and they lay domino [0, 1] on the first turn, it is likely they have more dominos containing values 0 and 1. Towards the end of the game the player should have a relatively diverse hand and therefore if their 6th domino laid is [0, 1] their last domino is likely not to contain a 0 or 1.

From the above information the following algorithm can be derived:

Algorithm T C D Matches Won

DiversityII 90 80 49 2

PrioritiseDIIC 88 78 54 3

MergeDIIC 90 79 64 3

Algorithm D GL GR P M DII PII MII Matches Won

Games Difference

DiversityII 539 480 452 472 419 492/ 508

460 460 1 -218

PrioritiseDIIC 535 484 492 502 458 540 488/ 512

472 3 -17

MergeDIIC 564 502 511 502 481 540 528 473/ 527

6 128


57

1. For each domino and for each player create two values. The first value is the normalised probability that this domino belongs to this player. This value is between 0 and 1 inclusive. The sum of these values for a particular domino must always equal 1 (dominos that have been laid are not included). The second value is a pre-normalised value. This value starts at 1.

2. At the start the known dominos (the ones currently owned) are iterated through and the pre-normalised value is set to 0 for all the opponents. The update function is called and this updates the normalised values based upon the pre-normalised values in the following way.

a. For each domino the pre-normalised values are obtained. b. The sum of the pre-normalised values for these dominos is obtained. c. The normalised value is equal to its corresponding pre-normalised value divided

by the total of the pre-normalised values.

This means that the pre-normalised values are meaningless by themselves, they only have meaning when compared to other players’ pre-normalised values. It is also worth mentioning that if all but 1 player has a pre-normalised value of 0 then irrespective of the remaining player’s pre-normalised value, their normalised value will be 1, because x/x = 1. All the players cannot have pre-normalised values of 0.

3. The pre-normalised values are altered in the following way.

a. When a player lays a domino their other probability values are altered. This is dependent upon the domino laid and their remaining dominos. Table 20 is used:

Table 20. Values used to alter the probability of a player owning a domino.

Basically, the above table works so that if player A lays domino [0, 1] and they have four other dominos remaining, the probability that they own any other domino containing values 0 or 1 is multiplied by 1.1. It is also clear that if a probability is ever equal to 0 it will always remain on 0 as 0 * x = 0.

b. When a player ‘knocks’, their appropriate pre-normalised values are reduced to 0. So if player A ‘knocks’ when there is an option to lay a domino of value 3, then all their potential dominos containing value 3 are decreased to 0.

c. After someone has ‘knocked’ or someone has laid, a check function is run. This checks to see if certain dominos definitely do or do not belong to certain people. An example of this is if player A owns 2 dominos and they could possibly own the dominos [0, 0], or [0, 1] and no others. In this case all other players’ pre-normalised values are decreased to 0.

Dominos left

Increase Probability

6 2

5 1.3

4 1.1

3 1

2 0.9

1 0.7

0 0


58

5.6.2. FriendlyII and GrumpyII

Using the above technique to gather statistics new friendly and grumpy algorithms have been created. These algorithms work in exactly the same way as the ones before described in sections 5.3.5 and 5.3.6, except using the statistics gathered above.

5.6.3. Competition IV

A quick test against the Friendly, Trivial, Conservative and Diverse algorithms with matches up to 100 are shown in table 21:

Table 21. Competition IV.

*There appears to be an error with the GrumpyII right algorithm. This is because the algorithm performed much better as players 2 and 4 than as players 1 and 3. No algorithm should perform better when playing as a different player. This test was run twice more. The second results was that players 1 and 3 won 58, 42. The third test resulted in a score of 50, 50. This implies that the algorithm is functioning correctly. However, this also implies that my tests are not proof that one algorithm is better than another. Very strong assumptions can be drawn from the tests, as it is fairly easy to predict an approximate result when playing most of the algorithms together. However, this is the reason why so many tests are required and matches up to 1000 games must be played, because playing matches consisting of 100 games can result in non-representative results.

The FriendlyII algorithm seems to perform as poorly as the Friendly algorithm. The GrumpyII algorithms perform well. The competition shown in table 22 consists of the best algorithms and the new Grumpy algorithms.

Table 22. Competition IV.

The above results show that the new algorithms are comparable with the previous algorithms. The GrumpyII Left performs better than the GrumpyII Right which is to be expected as mentioned before; hindering the next player is much easier than hindering a player three moves away. An approximate ordering of which algorithms are best is shown below:

1st MergeDC, MergeDIIC, Grumpy Left, Grumpy Right 2nd GrumpyII Left 3rd PrioritiseDC, PrioritiseDIIC 4th DiversityII, GrumpyII Right 5th Diversity

Algorithm FII GIIL GIIR F T C D Matches Won

Games Difference

FriendlyII 50/50 2 0 44 12 0 3 0 -239

GrumpyII left

98 50/50 65 99 79 70 47 5 168

GrumpyII right

100 35 37/63* 96 76 69 54 5 130

Algorithm GIIL GIIR D GL GR P M DII PII MII Matches Won

Games Difference

GrumpyII left

490/ 510

547 576 475 493 512 496 540 518 509 6 166

GrumpyII right

453 486/ 514

495 452 458 456 412 502 463 436 1 -373


59

These results show more evidence that claim 4 is false, 5 is true and 8 is false.

5.7. Friendly Last Chance

The Friendly algorithms have both performed very poorly. One reason for this is the fact that they are designed to help their mate to succeed. A friendly tactic playing with another friendly tactic may not work well together as they have coinciding goals, to help each other. This next algorithm is supposed to give the friendly algorithms a last attempt to prove themselves to be a good tactic. Let us see if we can use them to improve the DiversityII algorithm.

The algorithm below describes which algorithm to listen to, the friendly or diverse algorithm. Both players can not play a friendly tactic at the same time;

If your team mate owns four or more dominos and they own at least two fewer than

you, use a friendly algorithm.

If your team mate owns fewer than four dominos and they own fewer than you, use a

friendly algorithm

Otherwise use a diverse algorithm.

The above algorithm means a friendly algorithm will be used if it is likely that your team mate shall win. If this is the case, the algorithm should not try to win, instead to help them to win.

The two algorithms created are the FriendlyLC, a combination of DiversityII and Friendly and FriendlyIILC, a combination of DiversityII and FriendlyII.

5.7.1. Competition V

Table 23 shows the results of a quick test against the weaker algorithms in matches consisting of 100 games:

Table 23. Competition V.

The results shown in table 23 imply that the new algorithms are better than the basic algorithms shown above. However, are the new algorithms an improvement on the DiversityII algorithm? In order to find out, the new algorithms are tested against the diversity algorithms in matches consisting of 1000 games.

Table 24. Competition V.

Algorithm F FII T C Matches Won

FriendlyLC 96 97 82 61 4

FriendlyIILC 95 95 85 60 4

Algorithm FLC FIILC D DII Matches Won

FriendlyLC 487/ 513

486 438 403 0

FriendlyIILC 514 525 423 408 1


60

The results shown in table 24 imply that the DiversityII algorithm has been hindered by the introduction of a friendly algorithm. This does not go against claim 6, because claim 6 talks about combining two good algorithms. So far there is no evidence to suggest either friendly algorithm is good. The tests enhance the evidence that falsifies claim 4. For this reason the friendly algorithms will no longer be used. I am not saying it is impossible to create a good friendly algorithm, but it seems very hard to develop one.

5.8. Grumpy Improvement

The following section describes a slight improvement to the grumpy algorithms. This improvement is expanded upon to allow it to dynamically alter based upon the state of the game.

5.8.1. Grumpy Both

The grumpy algorithms all appear to perform very well. At the moment there are two main types of grumpy algorithm; left and right (algorithms which hinder the player to the left or right respectively). Based upon this an idea would be to create an algorithm which attempts to hinder both opponents.

The Grumpy algorithm illustrated in section 5.3.6 counts the number of spots an opponent is estimated to have. This is then used to decide which domino to lay in order to hinder them. The idea of the Grumpy Both algorithm; is to count the number of spots both opponents are believed to own.

Two new algorithms are created. The Grumpy Both algorithm is based upon statistics gathered in 5.3.4 and GrumpyII Both works with the results gathered by the GrumpyII Left and Right algorithms described in section 5.6.1.

5.8.2. Competition VI

Table 25 shows the results of testing these algorithms against the current best algorithms (MW = Matches Won, GD = Games Difference).

Table 25. Competition VI.

The results look fairly encouraging, as the new algorithms lose very few matches. Let us alter these algorithms slightly. Because it is easier to attack the player to your left, the Grumpy Left algorithm should be better than the Grumpy Right algorithm. For this reason the results can be weighted towards the player on the left’s ordering. When counting the spots owned by each opponent, the left opponent’s values are multiplied by a constant, in this case 1.1. The reasoning behind choosing such a small weighting is to tip the balance towards attacking the player on the left if there is a disagreement. The results of the new algorithms are shown in tables 26 and 27 (MW = Matches Won, GD = Games Difference).

Algorithm GB GIIB D GL GR P M DII PII MII GIIL GIIR MW GD

Grumpy both

478/ 522

511 576 526 532 542 519 540 536 477 521 577 10 357

GrumpyII both

489 487/ 513

582 525 498 532 540 572 522 518 497 551 8 326


61



The results imply that the grumpy both are slightly better than all other algorithms. However, there still appears to be a grouping of the algorithms shown in the last few tests where there seems to be very little difference between them.

5.8.3. Grumpy Dynamic

The grumpy algorithms look at attacking both players. This seemed to be fairly successful. They then attacked both players but were weighted to attacking the player on the left, which was also successful. Now let us try to dynamically change this weighting based upon the state of the game.

A logical choice would be to prevent the opposing team from winning by attacking the player who is most likely to win. The probability of the player on the left finishing before the player on the right is shown in equation 14:

RL

LL

DD

DP

+−=1 (14)

Where LD is the total number of dominos owned by the player on the left and RD is the total

number of dominos owned by the player on the right.

This equation is very similar to equation 10, which calculates the probability of a player finishing before their team mate, section 5.4.2.

The previous section showed how to change the grumpy algorithms to create grumpy both algorithms. It also describes a way of weighting these algorithms towards attacking the player on the left. Basically, this algorithm dynamically changes the weighting based upon the situation of the game. This weighting can be less than 1 meaning prefer the dominos which attack the player on the right. This weighting is calculated using the following formula:

Algorithm GB (1.0)

GIIB (1.0)

GB (1.1)

GIIB (1.1)

Matches Won

Games Difference

Grumpy both (1.0)

- - 507 494 1 1

GrumpyII both (1.0)

- - 517 472 1 -11

Grumpy both (1.1)

493 483 - - 0 -24

GrumpyII both (1.1)

506 528 - - 2 34

Algorithm GB GIIB D GL GR P M DII PII MII GIIL GIIR MW GD

Grumpy both

497/ 503

483 563 507 549 539 531 570 550 539 522 559 10 412

GrumpyII both

517 482/ 518

557 518 514 551 549 556 538 508 514 539 11 361


62

L

L

P

PLw

−⋅=1

(15)

So the weighting is calculated as the probability of the player on the left winning divided by

the probability of the player on the right winning10 times some constant L . The constant value is set to 1.1 as it favours attacking the player on the left. Two of these algorithms are created, one for each type of grumpy algorithm.

5.8.4. Competition VII

The results of playing them against the other grumpy algorithms are shown in table 28.

Table 28. Competition VII.

The new grumpy algorithms do not seem to win or lose by a significant amount against the previous algorithms. Therefore this is not a major improvement. For this reason I shall not consider these algorithms any further.

5.9. Merge

Let us take a step back for a moment and look at the current situation. Many algorithms have been created, some of which seem to be better than others. Appendix C.1, table 34 shows the results of all the algorithms and how they fared against each other in a best of 1000 match. This table has some interesting properties.

The important point to notice is that although GrumpyII Both (1.1) wins and is unbeaten it does not win convincingly. There are some matches where it only wins by under 20 games, which is hardly convincing. This does imply that there are ways of improving the algorithms.

As an aside it is worth mentioning that an error was produced within some of the diverse and grumpy algorithms. Basically, the algorithm behaved the same whether it was laying the first domino, or not. This is an error as these algorithms should lay a different domino on the first go, as both sides of the domino will remain visible for the next move. The results displayed this error, as the algorithms performed much worse than in previous tests. This implies how important laying the first domino is, as the player has a choice of seven dominos to lay (the most amount of choice available on any move).

5.9.1. MergeDGC and MergeDGC2

The final set of algorithms that have been implemented is a merge of the best algorithms. If we look back at the claims, there is evidence to show that there are three types of good algorithm; diversity, conservative and grumpy. All attempts at creating a good friendly algorithm appear to have failed and resulted in making the algorithm perform worse.

10 In this case, the probability of the player on the right winning is equal to one minus the probability of

the player on the left winning.

Algorithm GB (1.0)

GIIB (1.0)

GB (1.1)

GIIB (1.1)

GD GIID Matches Won

Games Difference

Position

Grumpy dynamic

491 500 505 506 473/ 527

494 3 -4 1st

GrumpyII dynamic

496 508 472 497 506 487/ 513

2 -21 2nd


63

The idea of the last few algorithms is similar to the previous merging algorithms, but this time with all the best tactics. So again we must ask: at what point in the game will an algorithm perform better than another algorithm? Two equations 10 and 11 (shown in 5.4.2) show how to analyse the state of the game. Equation 16 is now introduced to gather additional information about the state of the game;

( )( )29ln

1ln +=

RI (16)

Equation 16 shows how much information the player knows at a given point in the round. This is based upon how many turns each player has had. Let us introduce a new term; if all four players have made a move (a move consisting of either laying a domino or knocking) then let this be called one rotation. In a round, a maximum of 28 rotations can occur as four ‘knocks’ in a row will terminate a game and there are 28 dominos. On each turn more information is gained regardless of whether the turn is a ‘knock’, or laying a domino. This information also increases logarithmically, so in the first few moves, more information can be assumed, than in the last few moves. Therefore the equation is the natural log of the number of the rotation divided by the natural log of the total number of rotations. However, because the above values are normally multiplied with a value from some algorithm, the above equation should not return 0. The above equation would return 0 on the first rotation; therefore one is added to the rotation number and also the total number of rotations. Also, some information is known on the first rotation, so it would not be realistic if this formula returned 0.

As before the diversity algorithms improve when the player is more likely to win and the team is more likely to win, so the value in the diversity algorithm is multiplied by the mean of the probability of the team winning and the probability of the player winning. The conservative algorithms are most useful when the team has less chance of winning therefore the conservative value is multiplied by the probability of the other team winning.

The grumpy algorithm is more likely to be of use when the opponent’s team is more likely to win and more information about the game is available. Therefore the grumpy algorithm’s value is multiplied by the mean of the probability of the opposing team winning and the information available.

The other point which has not been mentioned until now is how to assign the grumpy algorithms with values. In the grumpy algorithms each domino is assigned two values based upon the two face values of the dominos and the probability that the player owns these values. Ideally, just one value for each domino between 0 and 1 inclusive would be assigned to each domino. Currently, the values assigned to the dominos are between –D and D where D is the number of dominos owned by that player. One of the values is also positive and the other negative. The values are added together and divided by D. This results in a value between -1 and 1. 1 is then added to the value and it is divided by 2. This results in the values being normalised to between 0 and 1.

The increase is constant, not exponential. For the reasons stated in 5.4.2, for the Diversity algorithm’s values the increase in domino values here should also be exponential. Therefore each value is raised to the power of e and divided by e1. Equations 17 and 18:

2

1++

= D

ba

n

ii

i (17) 1

11−

−=eenv

i

i (18)


64

Equation 17 shows the normalised values for the dominos. The ia and ib values are the

original two values associated with the domino. Equation 18 makes the value have an exponential skew. The subtraction of 1 is so the value can be 0.

So now there are ways of assigning values to the diverse, conservative and grumpy algorithms. In order to get the final value for the domino the following formula is used:

( ) ( )G

IPgD

PPdPcv A

iA

iAii ⋅

+−⋅+⋅

+⋅+−⋅=

2

1

21 1 (19)

The formula shows how to calculate the value for each domino. The ic , id and ig represent

the values returned by the conservative, diverse and grumpy strategies respectively. These are then multiplied by the above formulas depending upon the state of the game. The constants

D and G weight the values of the diverse strategy and grumpy strategy respectively. This is

because some algorithms perform better than others. The values for these are 3 and 3.3 for the diversity and grumpy weighting respectively. This is because tests show that the DiversityII algorithm is approximately 3 times better than the Conservative algorithm and the GrumpyII Both (1.1) is approximately 10% better than the DiversityII algorithm.

Two merge algorithms in this format are created. MergeDGC is a combination of the best diversity, conservative and grumpy algorithms; DiversityII, Conservative and GrumpyII Both (1.1). The second uses Grumpy Both (1.0). The reason for the second one is because both types of grumpy algorithm have performed very similarly and therefore it seems worth while trying both of them.

5.9.2. Competition VIII

The table below shows the best algorithms against the new algorithms in matches consisting of 1000 games (MW = Matches Won, GD = Games Difference):

Table 29. Competition VIII.

The MergeDGC and MergeDGC2 algorithms are a significant improvement on the previous algorithms. The MergeDGC algorithm seems to be better. In C.2 the MergeDGC is tested against all other algorithms and it wins by a significant amount against all of them. This improves the information gathered to support most of the claims, especially claim 1, 6 and 7.

5.10. Conclusion

A brief overview of the algorithms work is presented. This section ties up the work completed, by classifying the algorithms into separate skill levels and analysing each level. Finally, the claims are discussed to see if there is sufficient evidence to accept, or reject each one.

Algorithm M MII GB (1.0)

GIIB (1.0)

GB (1.1)

GIIB (1.1)

GD GIID MDGC MDGC2 MW GD

MergeDGC 705 702 644 626 630 638 633 628 481/ 519

526 9 1732

MergeDGC2 689 672 616 645 647 619 654 625 474 477/ 523

8 1641


65

5.10.1. Classification of Algorithms

At this point many algorithms have been implemented. Some of these algorithms perform very similarly. Figure 15 shows a grouping of algorithms.

Although in some groups certain algorithms are better than others, the difference between most of these algorithms is minimal. There is never a case of an algorithm in a higher group losing to an algorithm in a lower group in a match to 1000. This ordering is sufficient, but it would be more appropriate to attach words to the groups. Table 30 shows a naming for each group and an appropriate algorithm selected to represent each group with a reason for this choice.

Table 31 shows the results of all these algorithms playing and figure 16 is a graphical representation of the results.

Figure 15. Algorithms grouped by skill level.

Table 30. Assigning skill levels to algorithms.

Group 1 Group 2 Group 3 Group 4 Group 5 Group 6

Friendly FriendlyII

Trivial Conservative FriendlyLC FriendlyIILC

Diversity Grumpy Left Grumpy Right Prioritise Merge DiversityII PrioritiseII MergeII GrumpyII Left GrumpyII Right Grumpy Both (1.0) GrumpyII Both (1.0) Grumpy Both (1.1) GrumpyII Both (1.1) Grumpy Dynamic GrumpyII Dynamic

MergeDGC MergeDGC2


66

Table 31. Competition of skill levels.

Group Algorithm Reason

Very Easy FriendlyII The very easy name is intended so that anybody can beat it. FriendlyII was statistically the worst algorithm, below the Trivial algorithm. This implies it employs tactics to make it lose and therefore will be beatable by almost any opponent.

Easy Trivial The Trivial algorithm chooses random dominos. In order to beat this algorithm a player must implement some form of simple tactic.

Medium Conservative The Conservative algorithm performs some basic tactic. Therefore someone with a basic knowledge of the game should be able to play this algorithm.

Hard FriendlyLC In the latter two groups an algorithm is chosen based upon the second style of probability assumptions. Therefore for this group an algorithm which is based upon the first style of probability assumptions would be suitable choice in order, to maximise the diversity of the strategies. This group is for fairly advanced users as it employs more AI.

Very Hard GrumpIIBoth (1.1)

As the name of this group is very hard, the best performing algorithm out of this group is selected.

Master MergeDGC This is the best algorithm created and therefore belongs in the top group.

Algorithm Very Easy

Easy Medium Hard Very Hard

Master

Very Easy 494/506 157 24 31 35 2

Easy 843 493/507 254 198 210 53

Medium 976 746 487/513 410 229 117

Hard 969 802 590 498/502 358 189

Very Hard 965 790 771 642 482/518 362

Master 998 947 883 811 638 481/519


67

Competition of Each Skill Level of Algorithm (1000 Games)

0

500

1000

Very Easy Easy Medium Hard Very Hard Master

Algorithm

Games W

on

Very Easy

Easy

Medium

Hard

Very Hard

Master

Figure 16. Competition of difficulty levels.

The results are relatively successful. There does seem to be quite a large gap between Very Easy and Easy. Also, the difference between the Medium and Hard algorithms is quite small. But, in general, the ordering is good.

5.10.2. Overview with Relation to Claims

The claims stated at the start of the section will be iterated through and evidence will be provided to indicate whether these claims are likely to be true, false, or if there is not enough evidence to say;

C1) True. There is very strong evidence to suggest that some algorithms are better than others. When putting the algorithms into groups, the scores of an algorithm from group A playing an algorithm from group B would be similar for all algorithms in groups A and B. The scores varied completely depending upon the algorithms playing each other from 500/500 to 2/998. This indicates more evidence that some algorithms are better than others. It is very unlikely that all these findings are the result of chance.

C2) True. An algorithm which uses a diverse strategy appears to be a good algorithm. This is because all algorithms with a diversity strategy in them always beat the Trivial algorithm by a significant margin.

C3) True. An algorithm which uses a conservative strategy appears to be a good algorithm. This is because all algorithms with a conservative strategy in them always beat the Trivial algorithm. This was not by such a significant margin, but there is still strong evidence to imply this algorithm is good.

C4) False. An algorithm which uses a friendly strategy appears not be a good algorithm. This is because both friendly algorithms lose to the Trivial algorithm by a significant amount. Also, when combining a friendly algorithm with a diverse algorithm the diverse algorithm appears to perform worse. There is a significant amount of evidence to indicate that the friendly strategy will not result in a good algorithm.


68

C5) True. An algorithm which uses a grumpy strategy appears to be a good algorithm. This is because all algorithms with a grumpy strategy always beat the Trivial algorithm by a significant margin.

C6) True. There is relatively little evidence to show this claim to be true, but some evidence still exists. Both prioritise and merge algorithms which combine solely diverse and conservative strategies appear to be just better than the diverse and conservative strategieson their own. The final algorithm is the best example of this claim. The MergeDGC seems to be quite a lot better than the individual DiversityII, Conservative and GrumpyII Both (1.1) algorithms. The FriendlyLC and FriendlyIILC algorithms may appear to be counter examples, but they do not fall into this category. The reason is because this claim is based upon combining two good algorithms and it appears that neither friendly algorithm is good.

C7) Not enough information. Although there are many algorithms which alter their information throughout the game and most of them appear to be better than the individual algorithms, this claim is asking whether the algorithm has improved because it alters its information based upon the state of the game. The only algorithms which can test this claim are the grumpy both versus the grumpy dynamic algorithms. Both these algorithms performed very similarly and so it must be concluded that there is not enough information to indicate this claim to be true or false.

C8) Not enough information. This is quite a hard claim to show information for or against. In general this claim holds as it is too hard to distinguish between certain algorithms, as to which one is better. So any evidence against transitivity can be regarded as a fluke. However, saying this belittles the tests completed and removes the basis implemented for judging how good the algorithms are. Therefore it must be concluded that there is not enough information to indicate whether this claim is true or false. However, it can be said that exists a transitive relationship, such that algorithms in a higher group are better than algorithms in a lower group. This new claim can be assumed to be true.


69

6. TESTING

Testing is used to gain a greater understanding of the system. The testing section is split into four sections. The first tests whether the system meets the functional and optional and does requirements but does not meet the not included. The second analyses whether the system meets the non-functional requirements based upon user feedback. The third section looks at the system’s interface. Finally, the algorithms are pitted against human players in order to see how good they are. This section covers any changes made to the system with appropriate justification.

6.1. Functional, Optional and Not Included Requirements

This section tests the functional, optional and not included requirements. This is achieved via black box testing. Basically, each requirement is analysed in order to produce a series of tests. The tests are designed to break the requirement, by testing the bounds of the system with a variety of different inputs. Each test has an expected output which is compared with the actual output. If the two are different then the test fails. If any test fails the requirement is not met.

6.1.1. Functional Requirements

Appendix D.1 table 36 shows the tests indicating whether or not the system has met the functional requirements. One test failed. When a client attempted to connect to a game that was already in progress then no error message is displayed. This is because the server is technically still listening for connections until the port is closed. In order to fix this problem, a new thread has been set up that continues to listens for connections once a game has been set up. The thread rejects all client connections. When running the test again the appropriate error message is displayed.

6.1.2. Optional Requirements

Appendix D.2, table 37 shows the tests indicating whether or not the system has met the optional requirements. Some of the optional requirements have been met. The ones which have not been met are due to timing constraints and the importance of the requirement as detailed in the table.

6.1.3. Not Included

None of the not included requirements have been implemented.

6.2. Non Functional Requirements

The non-functional requirements are non-measurable features of the system. In order to test these requirements user interaction is required. A co-operative evaluation test was set up. This involved setting up a series tasks and communicating with the user as they completed the tasks in order to gain an understanding of the logic behind their actions. Help is not provided to the user, unless they have no idea of what to do. The user is given a questionnaire after completing the tasks. The results of the questionnaire will be the main resource in testing the non-functional requirements.

The co-operative evaluation tests, questionnaires and results can be found in sections D.3 to D.6. Table 38 shows the results for testing the non-functional requirements and can be found in D.7. As can be seen by the results of the tests, the majority of non-functional requirements have been met. There are some issues, which mainly relate to confusion with the layout of the interface. These problems will be addressed in the next section.


70

6.3. Interface Testing

Testing the interface has been done by performing the co-operative evaluation test. Many issues arose and these are described in the following few sections.

6.3.1. Main Screen

Let us begin with the initial screen. Figure 17 shows a screen shot of the main screen:

Figure 17. Main Screen – original.

The users noticed many issues with this screen. One of the biggest issues was the number of irrelevant options which are displayed. If we want to create a game then we do not need to enter an IP address, port number or use the right hand side at all. Conversely, if we wish to join a game then the entire left hand side can be ignored. This is quite confusing and a way around this is to use tabs so that only the appropriate information is displayed. The only problem is that most of the time the server will not care about their port number. This text box will be moved lower down so that it does not look as important.

There were many other issues which are easy to fix. The most common issue raised is that there is no indication of which player is on which team. This can be fixed by renaming the labels. Several other wording issues were brought up by participants which are described in the results of the co-operative evaluation test D.4. The other issue which has been updated is there is now a character limit on the size of the players’ names, which was suggested by a user. The updated Main Screen is shown in figures 18 and 19 (two images are used as a tabbed pane allows the user to connect as a server or a client);


71

Figure 18. Main Screen – updated (server tab).

Figure 19. Main Screen – updated (client tab).


72

6.3.2. Dominos Game

Users were mainly pleased with the interface for playing a game of dominos. However, they did find issues with it. The previous layout is shown in figure 20;

Figure 20. Dominos Board – original.

When the users initially looked at this screen they were unsure of how to operate the system. The users did not know how to lay dominos and they originally thought they had to drag and drop the dominos onto the board. Although they eventually discovered how to operate the system, they did not appreciate having to search through the help screens in order to find basic instructions. For this reason a simple set of instructions has been displayed in the top right corner in the new design.

Once the user knew how to pick up and lay dominos they were fairly happy with the game. However, they did find it annoying that a simple mouse click has to be used to pick up a domino, rotate it and lay it, because it has to be precise. Now the system picks up a domino based upon when the mouse is pressed, making it much easier to pick up a domino. Rotating and picking up a domino can be achieved using keyboard shortcuts ALT+i will pick up a domino at position i and ALT+R and ALT+r will rotate the currently held domino clockwise and anti-clockwise respectively.

Users made other suggestions, some of which related to the scores and speed options. The score display shows statistics about the game. It shows the players’ and teams’ scores, but does not say which player is on which team. The new system makes this more obvious by putting the players’ names after the team name. The speed change option now describes how it works in more detail (which way is faster and which way is slower).

There were a few other rewording issues which have been updated. The new background screen is displayed in figure 21;


73

Figure 21. Dominos Board – updated.

Unfortunately, the main update that cannot be seen is how much easier it now is to pick up dominos. Feedback from users indicated that it was much improved.

One comment mentioned by two users is the fact that the board is of finite size, such that one end of the domino train can become cornered. The same situation can occur if blocking one end of the train against another part of it. One solution around this is to allow for a re-ordering function which re-orders the train to free up the two ends. This has not been implemented. The main reason for not implementing this is it would be quite hard to decide when to re-order the train, because it cannot be one person who decides, as they may only re-order the train at a profitable time. The layout of the train is also quite tactical as players can user the locations to their advantage.

6.3.3. Help Screens

The users found the help screens to be useful. However, they did suggest that much of the help screens should be re-worded. These changes have been made.

One user suggested making the help screens significantly smaller, so they could be used next to the other screens. Although the user can manually resize the screens this can become quite annoying if every time they load a help screen they have to resize it. For this reason a button has been placed on the screen which allows for all the help screens to have a smaller default size. The reason for not just making all the help screens smaller is because only one user opposed the help screens being large; therefore the assumption was that many other users preffered the large, originally sized, help screens. Therefore many other users are happy with the original size of the help screens.


74

6.4. Algorithm Testing

The algorithms have been tested against each other in order to find out how good they are. However, there has been no testing against human players. This section shows the results of algorithms playing against humans.

6.4.1. Overview

Each participant plays against two algorithms. Each game consists of 100 points and a match consists of 3 games. There are many potential problems with this test. The first is that only three games are being played, but when testing the algorithms against each other 1000 games were played. Making each person play 1000 games would be impractical! The tests will contain an element of luck. However, a good idea of the skill levels of the algorithms will be gained. The second problem is that different people will use different tactics. Therefore if the Very Easy algorithm wins and the Master algorithm loses, it could be because the participant playing the Master algorithm is using a much more complex tactic. In order to compensate for this an understanding of the tactics the players use will be discovered. Therefore an estimation of their skill level can be obtained. The final problem is that as the participant plays more games, they can learn new tactics. Therefore the participant should perform better on their second attempt. This will be taken into consideration by noting if a player’s tactics change. The results of this test are shown in table 32.

The author has aslo played each algorithm in a match. This was to gain an understanding of how someone who fully understood the strategies of dominos would do against these algorithms. The main problem is that someone with a detailed understanding of how the algorithms work has a clear advantage when playing them. However, the results should give a guide as to the success of the system. The results are shown in table 33.

Figure 22 shows the results from all the matches involving humans playing against algorithms. The graph shows the mean number of games won by the human players. Each match consisted of 3 games and each game was up to 100 points.

6.4.2. Results

Table 32. Human players vs Computer players.

Participant Algorithm Result (Human – Algorithm)

Tactics

1 Very Easy 2 – 1 Played a purely random tactic.

1 Medium 2 – 1 Played a conservative tactic, but played quite randomly.

2 Master 0 – 3 Started off by playing a conservative tactic of laying dominos with a high number of dots. Changed their tactic to incorporate a slightly diverse strategy.

2 Very Hard 2 – 1 Played a more diverse strategy, with a slightly conservative strategy wherever there is a conflict.

3 Very Hard 0 – 3 Played a mainly conservative strategy. Occasionally played a diverse strategy.

3 Master 1 – 2 Played a diverse strategy with a minor amount of conservative play.

4 Easy 1 – 2 Always tried to lay their double dominos, otherwise played randomly.

4 Hard 2 – 1 Same as above; did not change their tactic.


75

Table 33. Myself vs Computer players.

Humans vs Algorithms

0

1.5

3

Very

Easy

Easy

Medium

Hard

Very

Hard

Master

Difficulty Level

Mean # Games W

on

by Algorithms

Figure 22. Humans players vs Computer players.

6.4.3. Analysis of Results

Table 32 shows many important features. The first is that there appears to be a positive correlation between the difficulty level of the algorithm and how often it wins. Examples of these trends include the Master algorithm not losing a match and the Very Easy algorithm not winning a match. However, there are some inconsistencies. The most blatant of which is that the Hard algorithm loses to a human player the Easy algorithm beats and the player does not change their tactic. The trends which imply a negative correlation are greatly outweighed by the trends which imply a positive correlation.

The second trend is that the players pick up tactics and improve. Participants 2 and 3 began by playing conservative strategies and lost 3 – 0. They then started playing a more diverse strategy and started winning games. Participant 1 started using a more conservative strategy and beat the Medium algorithm 2 – 1, whereas before they used a random strategy and beat the Very Easy algorithm 2 – 1. The strategies the subjects started using were very similar to the strategies the algorithms implemented; implying that these are good strategies.

It appears that a person who has minimal experience playing dominos can beat the difficulty levels Very Easy to Hard. One player beat the difficulty level Very Hard, but they were using

Algorithm Result (Human – Algorithm)

Tactics

Very Easy 3 – 0

Easy 3 – 0

Medium 3 – 0

Hard 0 – 3

Very Hard 2 – 1

Master 1 – 2

Played a mixture of conservative and diverse strategies. Adapted the Diversity strategy slightly to lay double dominos more of the time. Also, probably a higher weighting towards a more conservative strategy than the merged algorithms.


76

quite a clever tactic. Ideally, it would be better if a person with minimal dominos experience could only beat difficulty levels Very Easy and Easy.

The results also imply there is a large amount of luck in the game. Each algorithm lost and won at least one game. Also, participant 4 lost to the Easy algorithm and beat the Hard algorithm.

Table 33 shows a positive correlation between the difficulty level and the number of games won by the computer player. However, it also implies there is a large amount of luck involved in the game, as the Hard algorithm performed the best. These are trends also shown in table 32.

Figure 22 reinforces the above points; the correlation between games won and difficulty level; the element of luck in the game. This is displayed in the graph as the later algorithms win more games. However, there is also an element of randomness implying there is luck involved. The graph also shows a cut off point. Algorithms past this cut off point win more games than they lose (bars which are smaller than 1.5 as matches consist of 3 games). Past algorithm Medium the algorithms win more games than lose.


77

7. CONCLUSION

The conclusion has been used to summarise the work completed. Firstly, a brief description of how successful the project has been, with relation to the main aim, is presented. A more detailed critical analysis of the project is then discussed. A section for future work is displayed, analysing areas relating to both GUI and algorithms. Finally, the author gives a final remark of the project.

7.1. Brief Desription

The main achievements of the project are discussed below, relating to the main aim of the project.

7.1.1. Aim

The main aim of this project was to create a dominos application for a variety of different users. The application must allow for humans and computers to play the game. The user base involved players who might have had minimal computer experience.

Additionally, the plan was to develop suitable algorithms in order for the computer to simulate the role(s) of the players. These algorithms needed to use a variety of techniques in order to be successful. Much work had to be completed in developing these algorithms with the goal of creating an algorithm that was capable of competing against human players and, if possible, beating them.

7.1.2. Main Achievements

The dominos application has been implemented with the required functionality. The users were happy with the application as it has the correct functionality. Most of the users also said informally that they enjoyed playing the game, which is a major success as prior to creating the application people did not seem very interested in playing the game.

Many algorithms were implemented. Very strong evidence has been provided implying that dominos is not a game of luck, but a game of skill. This is based upon the results of the algorithms playing each other. The main success from the algorithms is the fact that one algorithm did not lose a match to a human player. This algorithm played three players, myself and two people with 1st class degrees in mathematics.

7.2. Critical Evaluation

A critical evaluation of both the GUI and algorithms is presented. This evaluation states the good parts, bad parts and important features of the project. These points are based upon user feedback and also the author’s opinion of the project.

7.2.1. GUI

Overall the users seemed happy with the application. They seemed impressed by the number of features implemented. However, they did recommend many improvements based upon lack of clarity in certain areas. Although these changes have been implemented and the users have looked informally over the system and agreed that the changes make the system clearer, there has been no testing on new users. It is possible that the system may contain more areas with lack of clarity.


78

There have also been areas where certain improvements have not been made. One of these is to allow for the train of dominos to be re-ordered so that the train does not become trapped, making it impossible for people to lay dominos.

The initial screen was originally very complex. After upgrading it, users said they found it much more informative and liked the fact that certain unnecessary information was hidden. However, the main screen can still be fairly daunting for a person who has not used it before.

The networking side of the application can be confusing for someone with minimal computer experience. The main screen attempts to keep these boxes hidden unless needed. However, a player with minimal computing experience may wish to play over a network. They may find this hard to achieve.

The users enjoyed the freedom of laying dominos during the game. A drag and drop system was implemented as this was the way most users instinctively attempted to play the game. The users liked this adaptation.

Keyboard shortcuts were implemented to allow users to perform most tasks. Additional shortcuts were added to allow players to pick up and rotate dominos. Some users took advantage of these shortcuts and others did not. However, there is no way of laying a domino using just keyboard shortcuts.

In general users understood the options relating to the system. One area which lacked clarity was the scoreboard and scoring system. Users were confused as to how the system worked out the scores. This is explained in the help screens, but can still be rather confusing.

7.2.2. Algorithm

A wide variety of algorithms have been implemented. These can be categorised into six separate difficulty levels. When making the algorithms play each other in matches consisting of 1000 games the difficulty levels are fairly distinct. The differences between each successive difficulty level varies; as the Easy algorithm beat the Very Easy algorithm 843 – 157 and the Hard algorithm beat the Medium algorithm 590 – 410. Ideally the differences would be quite similar, and always around 750 – 250. This would result in a more natural increase in levels for the user.

It is a huge success that no human managed to beat the best algorithm in a match. It is also a success that human players can beat other algorithms, implying that the majority of people will be able to play against a variety of skill levels depending on how hard they want the game to be.

However, it would have been better if the algorithms had been more consistent, so that harder algorithms beat players which easier algorithms have beaten. Also, slightly better results would have involved the algorithms being harder, so that someone who does not use a strong tactic cannot beat algorithms Hard, Very Hard, or Master.

7.3. Further Work

Additional work which has not been implemented or researched is discussed. This work may not have been included purely based upon the time it takes to implement; or because it was not considered to be in the main scope of the project; or it may have taken a back seat to what has been considered more important features. The work is believed to be of importance if the reader is looking for ideas of how to improve the application.


79

7.3.1. GUI

An option to re-order the train should be introduced. This would prevent the train from getting backed into a corner preventing people from moving. Some way of discovering when to re-order the train would have to be implemented.

Additional user testing is required. The current system should be tested against a new set of users to discover how usable it is. Possibly broader tests should be used, including questionnaires, so that a wide variety of users can be tested. This process should be repeated until new users can complete a variety of instructions with minimal effort.

7.3.2. Algorithm

There are many areas of work not considered for the algorithms. The first area for further work is the amount of tests completed. Within a lot of the algorithms created several constant values were used; for example, the value of 1.1 which implies how much better Grumpy Left is than Grumpy Right. In order to develop better algorithms, a wider variety of constants could be tested. Also, more combinations of algorithms could be tested. For example; trying more grumpy algorithms in the final merge algorithm. The application could attempt to improve these constants by continually playing the game. As mentioned in the literature survey, [21] describes a checkers game that updated constant fields as it played the game based upon the results. This idea could be applied to the dominos the game so that the algorithms continually improve.

When testing algorithms more tests could be completed. These additional tests could look at playing different algorithms together, to find out if there are particular pairs of algorithms which perform well together. These tests could be used to create new merged algorithms, if there are certain combinations of algorithms that perform exceptionally well. Again this would require a vast amount of testing and time.

Mathematical proofs could be used to identify which algorithms are best in order to remove the testing process. This would remove the element of randomness, where two algorithms seem to be very similar. It would also be proof of the above claims and statements could be made like ‘algorithm A is good’. These proofs would be long and require more effort than doing the tests needed in this project. However, they may be useful if several hundred or thousand algorithms were used. They may also be useful when trying to find optimal constant values to use in the algorithms.

The algorithms could be used to remember information from previous matches. For example; the second set of grumpy algorithms operates under the assumption that the opponent plays a diverse strategy. If information could be gathered from each game to gain an understanding of the opponents’ tactics then a suitable algorithm could be chosen based upon this data.

With the current algorithms there are no tactics used to deduce the position of where to lay the domino. The positioning of the domino can cause the round to terminate early. This is due to the ends of the train being in certain positions where dominos can not be added to the end. Depending upon the situation this can be a profitable tactic. Also, the situation known as fish occurs when the train becomes cyclic. This is a very profitable situation. None of the algorithms above look for either of these situations and this would be an improvement.


80

Work should be done to try and balance out the differences between the difficulty levels. This should be done so that the difference between Easy and Very Easy should be the same as the difference between Medium and Easy, Hard and Medium, and so-on. This would make more sense to the user when choosing an opponent to play.

7.4. Final Remark

Dominos is a game that has been around for approximately 1000 years. However, the majority of recent work on developing algorithms to play strategic games has been devoted to chess. The users found the application created within the project to be enjoyable. Very strong evidence has also been presented to imply that dominos is a game of skill and that it is possible to create algorithms which are able to beat the majority of human players. Hopefully, people will continue to create applications that play strategic board games, but attempt to take the emphasis off chess and try to develop a wider variety of games.


81

A REQUIREMENTS

The appendix details additional information used in the requirements section.

A.1. Questionnaire

Below shows a blank copy of the questionnaire distributed to people to help in the requirements gathering stage.


82

Applying Suitable AI Techniques to a Game

of Dominos

After completing please email to [email protected]

Thank you for agreeing to complete the following questionnaire. The questionnaire will be used in requirements gathering process for a computerised dominos application. Please answer all questions as truthfully as possible. Even if you never intend to use a dominos application your feedback might still be of use. If you feel uncomfortable answering any questions, or if you think the specific question does not apply to you then leave it blank. Spaces at the end of sections can be used for writing any additional comments you feel appropriate.

SECTION 1: PERSONAL DATA

This section will be used to classify people into groups

1. Please mark the appropriate boxes to show your age and gender and then enter

your occupation. Age: Gender: Occupation:

Male Female

0-9 10-17 18-25 26-39 40+


83

SECTION 2: COMPUTING EXPERIENCE 2. How regularly would you say you used a computer? Please mark one box which

best applies to you.

3. What purposes would you use a computer for? Please mark any boxes you think

apply to you.

4. Do you ever find it difficult to read information on the screen? Please mark any

boxes you think apply to you.

5. Do you prefer to use keyboard shortcuts over using the mouse? Please mark one

box which best applies to you.

6. Do you ever use the mouse for extensive periods of time? Please mark one box

which best applies to you.

Less than once a week Once a week or more 3 times a week or more Once a day or more

Microsoft Office programs Programming Playing games Creating films or music Watching films/Listening to music Nothing, I don’t use a computer Surfing the web Photography or creating images Other (please specify)

No, this is never a problem Yes, I find the font size too small Yes, I find it hard to read certain colour texts, on certain backgrounds

Yes, I find some fonts hard to read Yes, for another reason (please specify)

For any Yes boxes you have marked, can you please elaborate further

I don’t know what keyboard shortcuts are, or I never use them I rarely use keyboard shortcuts I frequently use keyboard shortcuts, I always try to use keyboard shortcuts


84

If you answered no to question 6, go straight to question 8. 7. Do you ever experience any pain or discomfort caused by using the mouse for

extensive periods of time? Please mark one box which best applies to you.

8. Do you ever find it hard to use both hands to use the computer? Please mark one

box which best applies to you.

9. Any other comments about your computing experience, including any problems

you have had, or any features which you find particularly useful?

No, I don’t use the mouse for extended time periods Yes, I do use the mouse for extended time periods

I never feel any pain and/or discomfort I occasionally feel some pain and/or discomfort I regularly feel pain and/or discomfort

I never find this hard I find it hard to use the keyboard and mouse simultaneously I find it hard to use the keyboard with both hands


85

SECTION 3: GAMES EXPERIENCE 10. How often do you play the following types of games? Please mark one box in

each row which best applies to you.

1 = never 2 = up to once a month 3 = up to once a week 4 = up to three times a week 5 = more than three times a week

If you answered never to all of the above games please go straight to question 12. 11. How do you prefer to play the above games? Please mark one box which best

applies to you.

12. How often would you play a computer based dominos game if you owned one?

Please mark one box which best applies to you.

Games 1 2 3 4 5

Board/Card games not on a computer

Computerised versions of board/card games

1st person shooters

Fighting games

RPGs/Adventure games

Strategic/Army games (like Red Alert)

Sports not on a computer

Computerised versions of sports

Other;

If other, please specify

By myself Playing with or against other people Both

Never I would try it Regularly, about once a week Twice a week or more


86

13. If you were to play a computerised dominos game what features would you want? Please mark one box in each row which best applies to you.

1 = would be almost essential 2 = would be reasonably useful 3 = would be nice to have 4 = indifferent to the feature 5 = would prefer not to have the feature

14. Have you any other comments about any of the games you play, or would like to

play. This can include features you think are good, bad, or would like to see.

11 A game is normally played to a certain number of points. This question is asking whether you would

like to be able to change this value.

Games 1 2 3 4 5

Help menus on how to use the system

Accessibility to the dominos rules

Set your own name

Change your own name

A time-limit for players to move

Be able to change the score a game is played to11

Able to choose difficulty levels for computer players

Ability to play multiple games simultaneously

Access a history of moves made in the current game

A display of your current moves/options

A display of your recommended moves/options

Anytime access to the current scores in a game

Message human players during the game

Other;

If other, please specify


87

SECTION 4: ANY OTHER COMMENTS 15. Have you any comments relating to the creation of a computerised dominos

application. This can include your thoughts about the project, or any features you would, or would not like to see.


88

A.2. Questionnaire Results

A summary of the results gathered from the questionnaires is shown below:

Question 1; distribution of ages and genders

Question 2; how regularly people use a computer

Age

Group

Gender Counter

Male 0

Female 0 0-9

Both 0

Male 1

Female 0 10-17

Both 1

Male 6

Female 2 18-25

Both 8

Male 2

Female 3 26-39

Both 5

Male 9

Female 4 40+

Both 13

Male 18

Female 9 Total

Both 27

Occupation Counter

Student 7 Retired 5

Accountant 2 Actuary 2

Teacher 2 Apprentice Engineer

1

Bookseller 1

Buyer 1 Computer Programmer

1

Consultant 1 Investment Analyst

1

Radiographer 1

Shift manager 1 Unemployed 1

Age

Group

Gender Less than once

a week

Once a week

or more

3 times a week

or more

Once a day or

more

Male

Female 0-9

Both

Male 1

Female 10-17

Both 1

Male 6

Female 1 1 18-25

Both 1 7

Male 2

Female 3 26-39

Both 5

Male 9

Female 1 3 40+

Both 1 3 9

Male 1 17

Female 1 4 4 Total

Both 1 5 21


89

Question 3; what purposes people use a computer

Key;

1 = Microsoft Office Programs 2 = Playing games 3 = Watching films/Listening to music 4 = Surfing the web 5 = Programming 6 = Creating films or music 7 = Nothing, I don’t use a computer 8 = Photography or creating images 9 = Other

Question 4; difficulty with reading information on the screen

Key;

1 = No, this is never a problem 2 = Yes, I find the font size too small 3 = Yes, I find it hard to read certain colour texts, on certain backgrounds 4 = Yes, I find some fonts hard to read 5 = Yes, for another reason (please specify)

Age

Group

Gender 1 2 3 4 5 6 7 8 9

Male

Female 0-9

Both

Male 1 1 1 1

Female 10-17

Both 1 1 1 1

Male 5 2 6 6 1 2 2

Female 2 2 2 2 2 18-25

Both 7 4 8 8 1 2 4

Male 2 1 2 2

Female 2 1 1 3 2 1 26-39

Both 4 1 2 5 4 1

Male 9 4 2 9 3 4 1

Female 3 1 2 1 2 40+

Both 12 5 2 11 3 1 4 3

Male 16 7 10 18 4 2 8 2

Female 7 4 3 7 1 4 3 Total

Both 23 11 13 25 4 2 1 12 5

Other

Business Medical Applications Work

Educational MSN


90

Question 5; preference of using keyboard shortcuts

Key;

1 = I don’t know what keyboard shortcuts are, or I never use them 2 = I rarely use keyboard shortcuts 3 = I frequently use keyboard shortcuts 4 = I always try to use keyboard shortcuts

Question 6; length of time spent using the mouse

Age

Group

Gender 1 2 3 4 5

Male

Female 0-9

Both

Male 1

Female 10-17

Both 1

Male 4 1 2 1

Female 2 18-25

Both 6 1 2 1

Male 2

Female 2 1 26-39

Both 4 1

Male 7 2 1 1

Female 3 40+

Both 10 2 1 1

Male 14 3 3 2

Female 7 1 Total

Both 21 4 3 2

Occupation Reason why yes

Eg blue on purple

I only find the font size too small on a few websites.

Had to buy a new monitor to get clearer picture

It is always possible to combine fonts and colours to render text unreadable

Age

Group

Gender 1 2 3 4

Male

Female 0-9

Both

Male 1

Female 10-17

Both 1

Male 2 3 1

Female 1 1 18-25

Both 3 4 1

Male 1 1

Female 1 2 26-39

Both 2 3

Male 4 5

Female 1 1 1 1 40+

Both 1 5 6 1

Male 7 10 1

Female 1 3 4 1 Total

Both 1 10 14 2


91

Question 7; pain or discomfort caused by using the mouse

Question 8; how hard people find it using both hands to use the computer

Age

Group

Gender No, I don’t use the mouse for

extensive periods of time

Yes, I do use the mouse for

extensive periods of time

Male

Female 0-9

Both

Male 1

Female 10-17

Both 1

Male 1 5

Female 2 18-25

Both 1 7

Male 2

Female 3 26-39

Both 5

Male 2 7

Female 3 40+

Both 5 7

Male 3 15

Female 3 5 Total

Both 6 20

Age

Group

Gender I never feel any pain

and/or discomfort

I occasionally feel some

pain and/or discomfort

I regularly feel pain

and/or discomfort

Male

Female 0-9

Both

Male 1

Female 10-17

Both 1

Male 4 2

Female 2 18-25

Both 4 4

Male 2

Female 2 1 26-39

Both 2 3

Male 4 3

Female 40+

Both 4 3

Male 9 7

Female 2 3 Total

Both 11 10


92

Question 9; any other comments about computing experience

Question 10; frequency of playing games (the table shows the sum of people’s responses, 1 means they never play it, 5 means they play it on a daily basis)

Key;

1 = Board/Card games not on a computer 2 = Computerised versions of board/card games 3 = 1st person shooters 4 = Fighting games 5 = RPGs/Adventure games 6 = Strategic/Army games (like Red Alert) 7 = Sports not on a computer 8 = Computerised versions of sports

Age

Group

Gender I never find this hard I find it hard to use the

keyboard and mouse

simultaneously

I find it hard to use the

keyboard with both

hands

Male

Female 0-9

Both

Male 1

Female 10-17

Both 1

Male 6

Female 2 18-25

Both 8

Male 1 1

Female 3 26-39

Both 4 1

Male 5 1 4

Female 2 1 40+

Both 7 1 5

Male 13 2 4

Female 7 1 Total

Both 20 2 5

Comments

Until I obtained dual focus glasses (reading/computer screen), I found working on the computer very difficult. they're not quick enough, and I need more disk space Alt+Tab to change screens / programmes quickly - most useful at work!

Until I obtained dual focus glasses (reading/computer screen), I found working on the computer very difficult.


93

Question 11; how do people prefer to play these games

Question 12; how often people would play a computerised dominos game

Age

Group

Gender 1 2 3 4 5 6 7 8

Male

Female 0-9

Both

Male 2 2 2 2 2 2 4 2

Female 10-17

Both 2 2 2 2 2 2 4 2

Male 11 10 12 7 8 8 23 12

Female 3 6 3 4 6 6 5 3 18-25

Both 14 16 15 11 14 14 28 15

Male 3 3 2 2 2 2 4 2

Female 7 7 3 3 3 3 12 3 26-39

Both 10 10 5 5 5 5 16 5

Male 14 27 9 9 9 12 14 10

Female 5 6 3 3 3 3 9 3 40+

Both 19 33 12 12 12 15 23 13

Male 30 42 25 20 21 24 45 26

Female 15 19 9 10 12 12 26 9 Total

Both 45 61 34 30 33 36 71 35

Comments

Tetris Educational

Cricket scoring

Age

Group

Gender By myself Playing with or against

other people

Both

Male

Female 0-9

Both

Male 1

Female 10-17

Both 1

Male 1 4 1

Female 1 1 18-25

Both 2 4 2

Male 1

Female 1 1 1 26-39

Both 1 1 2

Male 7 1

Female 1 1 1 40+

Both 8 2 1

Male 8 5 3

Female 3 2 3 Total

Both 11 7 6


94

Question 13; what features people want from a computerised dominos game (the table below shows the sum of people’s responses, 1 means they would prefer not to have it, 5 means it would be essential)

Key

1 = Help menus on how to use the system 2 = Accessibility to the dominos rules 3 = Set your own name 4 = Change your own name 5 = A time-limit for players to move 6 = Be able to change the score a game is played to 7 = Able to choose difficulty levels for computer players 8 = Ability to play multiple games simultaneously 9 = Access a history of moves made in the current game 10 = A display of your current moves/options 11 = A display of your recommended moves/options 12 = Anytime access to the current scores in a game 13 = Message human players during the game

Age

Group

Gender Never Would try it Regularly,

about once a

week

Twice a week

or more

Male

Female 0-9

Both

Male 1

Female 10-17

Both 1

Male 2 4

Female 1 1 18-25

Both 3 5

Male 1 1

Female 1 2 26-39

Both 2 3

Male 3 6

Female 1 2 40+

Both 4 8

Male 6 12

Female 3 5 Total

Both 9 17


95

Age

Group

Gender 1 2 3 4 5 6 7 8 9 10 11 12 13

Male

Female 0-9

Both

Male 1 1 2 4 2 2 2 2 4 4 3 2 2

Female 10-17

Both 1 1 2 4 2 2 2 2 4 4 3 2 2

Male 13 8 15 14 15 11 6 18 17 12 16 9 13

Female 3 4 4 4 4 6 2 6 6 4 7 5 4 18-25

Both 16 12 19 18 19 17 8 24 23 16 23 14 17

Male 2 2 3 3 3 3 2 5 4 3 3 3 3

Female 4 4 11 11 11 11 4 10 7 5 6 4 9 26-39

Both 6 6 14 14 14 14 6 15 11 8 9 7 12

Male 11 17 25 28 24 23 15 29 26 21 24 17 29

Female 3 2 5 7 6 7 2 8 7 3 5 3 7 40+

Both 14 19 30 35 30 30 17 37 33 24 29 20 36

Male 27 28 45 49 44 39 25 54 51 40 46 31 47

Female 10 10 20 22 21 24 8 24 20 12 18 12 20 Total

Both 37 38 65 71 65 63 33 78 71 52 64 43 67

Other

Coloured Dominos Save/Pause game and stats

Question 14; any other comments about previous games played NONE Question 15; any other comments

Comments

Coloured dominos very useful for children - to access the rules of the game easily. I don't play dominoes for real - therefore, I don't think I would play a computerised version, unless there is perhaps an incentive; i.e. cash.

Just a thought - having this document in Word may not have been the best choice. You have the overhead of Word making the document size 150K - not a problem for broadband users but not simple for dial ups. Also, of course, many of the typical subscribers to games forums - perhaps your target audience - run browsers on UNIX so they woiuld have trouble opening the document at all. Good idea, to my knowledge not a widespred phenomenon! Think multiplayer would be the best feature as beating people you know is more satisfying than beating a computer who takes set moves.


96

B DESIGN

The appendix details additional information used in the design section.

B.1. Class diagram

Figure 23 shows a diagram of the classes used in the code and how they fit together.

Key:

= Java package = Java class called ClassA = Java class called OuterClass with an inner class called InnerClass = inheritance, so the class pointed to is the super class = class calling another class, so the class pointed to is the called class Not all of the calling references are shown in order to make the class diagram simpler.

ClassA

OuterClass

InnerClass


97

Figure 23. Class diagram.

Background Manage

Dominos

Load

Images

Background

Pane

Layed

Domino

Board

CheckLayed

Domino

board

Domino

Board Layout Train

Algorithm OrderDominos

Algorithm1 Algorithm2

Order1 Order2

Algorithmn

Ordern

ai

Domino

Simulator

Controller

networking

User

Server Client

Connection

Exception

Server

Connection

WaitForClient

Connections

ClientSocket

MainScreen SetSpeed InformationScreen MessageLog ScoreBoard Waiting

data


98

C ALGORITHMS

The appendix details additional information used in the algorithms section.

C.1. Competition IX

Table 34 shows the results of a competition of 20 algorithms. The matches are up to 1000 games (MW = Matches Won, GD = Games Difference).


99

Table 34. Competition of all algorithms.

Algorithm T D C F GL GR P M DII PII MII FII GIIL GIIR GB 1.0

GIIB 1.0

F LC

FII LC

GB 1.1

GIIB 1.1

MW GD Position

Trivial 493/

507

133 254 846 141 142 112 90 139 98 98 843 233 252 223 228 198 191 231 210 2 -4838 18th

Diversity 867 493/

507

738 972 441 457 434 435 461 465 436 979 424 505 424 418 544 540 437 443 7 920 13th

Conservative 746 262 487/

513

968 247 241 248 233 291 227 220 976 229 289 239 247 410 395 218 229 3 -2585 17th

Friendly 154 28 32 480/

520

22 24 17 11 21 14 19 515 56 58 37 27 42 55 30 40 1 -8298 19th

Grumpy Left 859 559 753 978 484/

516

513 511 481 520 516 498 979 525 548 474 475 621 595 493 482 13 1880 8th

Grumpy Right 858 543 759 976 487 482/

518

524 514 548 508 489 984 507 542 468 502 613 605 451 486 14 1864 7th

Prioritise 888 566 752 983 489 476 500/

500

491 528 498 498 992 488 544 458 468 638 644 461 449 9 1811 11th

Merge 910 565 767 989 519 486 509 487/

513

581 542 519 990 504 588 481 460 686 644 469 451 14 2160 5th

DiversityII 861 539 709 979 480 452 472 419 492/

508

460 460 984 460 498 460 428 612 609 430 444 7 1256 12th

PrioritiseII 902 535 773 986 484 492 502 458 540 488/

512

472 990 482 537 464 478 646 641 450 462 10 1794 10th

MergeII 902 564 780 981 502 511 502 481 540 528 473/

527

993 491 564 523 482 684 659 461 492 14 2140 6th

FriendlyII 157 21 24 485 21 16 8 10 16 10 7 494/

506

38 48 29 42 31 33 38 35 0 -8431 20th

GrumpyII Left 767 576 771 944 475 493 512 496 540 518 509 962 490/

510

547 479 503 620 635 478 486 13 1811 9th

GrumpyII Right

748 495 711 942 452 458 456 412 502 463 436 952 453 486/

514

423 449 587 571 441 461 7 912 14th

Grumpy Both (1.0)

777 576 761 963 526 532 542 519 540 536 477 971 521 577 478/

522

511 653 651 507 494 17 2134 2nd

GrumpyII Both (1.0)

772 582 753 973 525 498 532 540 572 522 518 958 497 551 489 487/

513

661 629 517 472 15 2061 4th

Friendly_LC 802 456 590 958 379 387 362 314 388 354 316 969 380 413 347 339 498/

502

485 375 358 4 -528 16th

FriendlyII_LC 809 460 605 945 405 395 356 356 391 359 341 967 365 429 349 371 515 498/

502

393 349 5 -340 15th

Grumpy Both (1.1)

769 563 782 970 507 549 539 531 570 550 539 962 522 559 493 483 625 607 497/

503

483 16 2103 3rd

GrumpyII Both (1.1)

790 557 771 960 518 514 551 549 556 538 508 965 514 539 506 528 642 651 517 482/

518

19 2174 1st

Table 34. Competition of all algorithms.


100

C.2. Competition X

Table 35 shows the results of the MergeDGC algorithm playing all other algorithms in matches up to 1000 games (MW = Matches Won, GD = Games Difference).

Table 35. MergeDGC vs all algorithms.

Alg T D C F GL GR P M MW GD

947 756 883 994 641 715 737 705

DII PII MII FII GIIL GIIR GB 1.0 GIIB 1.0

721 679 702 998 661 735 644 626

FLC FIILC GB 1.1 GIIB 1.1 GD GIID MDGC MDGC2

MDGC

811 786 630 638 633 628 481/519 526

23 5796


101

D TESTING

The appendix details additional information used in the testing section.

D.1. Functional Requirements

Table 36 shows the testing performed on the functional requirements.


102

Requirement Test Expected Outcome Outcome Pass

A game is set up consisting of one human player and three computer players. The human player is given the name ‘Human 1’ and the computer players are assigned the names ‘Computer 1’, ‘Computer 2’ and ‘Computer 3’.

Each screen shows the names ‘Human 1’, ‘Computer 1’, ‘Computer 2’ and ‘Computer 3’.

Each screen shows the names ‘Human 1’, ‘Computer 1’, ‘Computer 2’ and ‘Computer 3’.

Y

A game is set up consisting of human players at positions 1 and 2 and computer players at positions 3 and 4. The human players are assigned names ‘Human 1’ and ‘Human 2’ and the computer players are assigned names ‘Computer 3’ and ‘Computer 4’.

Each screen shows the names ‘Human 1’, ‘Human 2’, ‘Computer 1’ and ‘Computer 2’.

Each screen shows the names ‘Human 1’, ‘Human 2’, ‘Computer 1’ and ‘Computer 2’.

Y


Each screen shows the names ‘Human 1’, ‘Computer 1’, ‘Human 2’ and ‘Computer 2’.

Each screen shows the names ‘Human 1’, ‘Computer 1’, ‘Human 2’ and ‘Computer 2’.

Y


Each screen shows the names ‘Human 1’, ‘Computer 1’, ‘Computer 2’ and ‘Human 2’.

Each screen shows the names ‘Human 1’, ‘Computer 1’, ‘Computer 2’ and ‘Human 2’.

Y

Each participant in the game must have a name. The user must be able to define their name. All computer players must also have names, which at least one user must be able to define.

A game is set up consisting of four human players. The human players are assigned names ‘Human 1’, ‘Human 2’, ‘Human 3’ and ‘Human 4’.

Each screen shows the names ‘Human 1’, ‘Human 2’, ‘Human 3’ and ‘Human 4’.

Each screen shows the names ‘Human 1’, ‘Human 2’, ‘Human 3’ and ‘Human 4’.

Y

Many dominos are held over the board and rotated in many different scenarios. There are too many different scenarios to brute force test this option; instead this has been tested throughout the project in many different scenarios.

All the options are shown as defined in the rules of dominos, section F.2 and no other options are shown.

All the options are shown as defined in the rules of dominos, section F.2 and no other options are shown.

Y

The option is disabled and a domino which can be laid is held over the board. No options are displayed.

No options are displayed.

Y

A game is created consisting of two human players. One human player disables the option and the other enables the option. The human player with the option disabled holds a domino which can be laid over the board. The human player with the option enabled holds a domino over the board.

The player with the option disabled sees no options and the player with the option enabled sees their correct options.

The player with the option disabled sees no options and the player with the option enabled sees their correct options.

Y

A player disables the option and starts a new match. They hold a domino over the board which can be laid

The player sees no options.

The player sees no options.

Y

Outlines of potential moves must be shown. However, some users may not want this feature therefore it must be optional.

A player enables the option and starts a new match. They hold a domino over the board which can be laid.

The player sees their potential options.

The player sees their potential options.

Y


103


A player calls up the scores on their turn. The current scores are displayed. The current scores are displayed.

Y A player must be able to check the current score during any stage of the game.

A player calls up the scores on another players’ turn. The current scores are displayed. The current scores are displayed.

Y

The user ‘knocks’ on their turn when they cannot lay a domino. The turn is passed and the move is accepted by the system.

The turn is passed and the move is accepted by the system.

Y

The user ‘knocks’ on their turn when they can lay a domino. An error is displayed and it is still that player’s turn.

An error is displayed saying the player cannot knock as they have legal moves and it is still that player’s turn.

Y

The user ‘knocks’ when it is not their turn and they cannot lay a domino. An error is displayed and the game’s status does not change.

An error is displayed saying that the player cannot knock as it is not their turn and the game’s status is not changed.

Y

A ‘knock’ option must be available to the user. This is used to pass a turn when nothing is available. A player may only ‘knock’ (pass a turn) when it is their turn and they are unable to move. Attempting to knock at any other stage of the game must not affect the state of the game. If a player ‘knocks’ (passes a turn) on their turn when they are unable to move, this must be accepted by the system. This must be broadcasted to each human and computer player.

The user ‘knocks’ when it is not their turn and they can lay a domino. An error is displayed and the game’s status does not change.

An error is displayed saying that the player cannot knock as it is not their turn and the game’s status is not changed.

Y

A font size of at least 11pt must always be used.

On all screens the font size is checked. The font size is always at least 11pt. The font size is always at least 11pt.

Y

The help screen for the initial screen is loaded. The help menu successfully loads. The help menu successfully loads.

Y Instructions must be available to users. These instructions must help the users set up a game over a network and also how the specific system works.

A game is started and the help screen of how to use the system to play the game is loaded.

The help menu successfully loads. The help menu successfully loads.

Y

Dominos rules must be made available to the users. These instructions must explain how to play a game of dominos.

The rules of dominos screen is loaded. The rules of dominos successfully loads.

The rules of dominos successfully loads, but only when a game has been started.

Y


104


A player in the first position plays a round. The correct identifier is always displayed.

The correct identifier is always displayed.

Y

A player in the second position plays a round. The correct identifier is always displayed.


Y

A player in the third position plays a round. The correct identifier is always displayed.


Y

Some identification of which players’ turn it is must be clearly displayed at all times during a round.

A player in the fourth position plays a round. The correct identifier is always displayed.


Y

‘100’ is entered in the number of points to win a round and if possible a round is played. The round is over when a team reaches at least 101 points.

The round finished when team B reached 108 points.

Y

‘ 10 ’ is entered in the number of points to win a round and if possible a round is played. The round is over when a team reaches at least 11 points.


Y

‘0’ is entered in the number of points to win a round and if possible a round is played. The round is over when a team reaches at least 1 point.


Y

‘-1’ is entered in the number of points to win a round and if possible a round is played. An error is displayed and the round is not played.

An error is displayed saying the incorrect value and the round is not played.

Y

The points needed to win a game must be editable by at least one user.

‘Ten’ is entered in the number of points to win a round and if possible a round is played. An error is displayed and the round is not played.

An error is displayed saying the incorrect value and the round is not played.

Y

‘10’ is entered in the number of games to play and if possible a match is played. 10 games are played and then the match is over.

10 games are played then the match is over, the application asks if the user wants to play another match.

Y

‘ 1 ’ is entered in the number of games to play and if possible a match is played. 1 game is played and then the match is over.

1 game is played then the match is over, the application asks if the user wants to play another match.

Y The number of games played must be editable by at least one user.

‘0’ is entered in the number of games to play and if possible a match is played. An error is thrown and a match is not played.

An error is displayed saying the incorrect value and the match is not played.

Y


105


‘-1’ is entered in the number of games to play and if possible a match is played. An error is thrown and a match is not played.


Y

The number of games played must be editable by at least one user.

‘One’ is entered in the number of games to play and if possible a match is played. An error is thrown and a match is not played.


Y

A round is played with the message log open. All the moves are correctly displayed in the log in real time.

All the moves are correctly displayed in the log in real time.

Y Some identification of which player has just laid which domino must be available to each user. A history up to each player’s last move must be made available.

A round is played with the colour option enabled. The dominos are coloured correctly in relation to which player has laid which domino.

The dominos are coloured correctly in relation to which player has laid which domino.

Y

A match with one human player and three computer players is created. The match opens and the players can play.

The match opens and the players can play.

Y

A match with human players in places 1 and 4 and computer players is places 2 and 3 is created.



Y




Y




Y

A match with human players in places 1, 3 and 4 and a computer player in places 2 is created.



Y




Y




Y

A match with all human is created. The match opens and the players can play.


Y

A client attempts to join a match which has not been created. An error is produced and the client has not joined the game

An error is produced and the client has not joined the game

Y

The number of computer/human players must be defined by at least one user. The total number of players must equal 4 and all combinations involving one human being player 1 must be available. Users must be able to play the game over a network (including the Internet). Users must be able to connect to other users and send appropriate information about the game. This includes having a method of including any computer players in the game. A client attempts to join a match between two humans which is already in progress, by taking

the human’s place. An error is produced and the other game is not interrupted.

No error is produced, but the other game is not interrupted.

N


106


A match is set up where human players are to join in positions 2 and 3 and two human players try to join in position 2.

An error is produced and the first player to join in position 2 is the only one who can.

An error is produced and the first player to join in position 2 is the only one who can.

Y The number of computer/human players must be defined by at least one user. The total number of players must equal 4 and all combinations involving one human being player 1 must be available.

A match is set up where a human player is supposed to join in position 2 and they try to join in position 3.

An error is produced and the player cannot join in this position.

An error is produced and the player cannot join in this position.

Y

A match is set up with three computer players each on a skill level of ‘Very Easy’. The match opens with each computer player on skill level ‘Very Easy’.

The match opens with each computer player on skill level ‘Very Easy’.

Y

A match is set up with three computer players each on a skill level of ‘Easy’. The match opens with each computer player on skill level ‘Easy’.

The match opens with each computer player on skill level ‘Easy’.

Y

A match is set up with three computer players each on a skill level of ‘Medium’. The match opens with each computer player on skill level ‘Medium’.

The match opens with each computer player on skill level ‘Medium’.

Y

A match is set up with three computer players each on a skill level of ‘Hard’. The match opens with each computer player on skill level ‘Hard’.

The match opens with each computer player on skill level ‘Hard’.

Y

A match is set up with three computer players each on a skill level of ‘Very Hard’. The match opens with each computer player on skill level ‘Very Hard’.

The match opens with each computer player on skill level ‘Very Hard’.

Y

A match is set up with three computer players each on a skill level of ‘Master’. The match opens with each computer player on skill level ‘Master’.

The match opens with each computer player on skill level ‘Master’.

Y

A match is set up with three computer players with skill levels ‘Very Easy’, ‘Easy’ and ‘Medium’.

The match opens with the computer players on skill level ‘Very Easy’, ‘Easy’ and ‘Medium’.

The match opens with the computer players on skill level ‘Very Easy’, ‘Easy’ and ‘Medium’.

Y

At least one player must be able to set the difficulty settings of the computer player(s). At least 3 difficulty settings must be available.

A match is set up with three computer players with skill levels ‘Hard’, ‘Very Hard’ and ‘Master’.

The match opens with the computer players on skill level ‘Hard’, ‘Very Hard’ and ‘Master’.

The match opens with the computer players on skill level ‘Hard’, ‘Very Hard’ and ‘Master’.

Y


107


A match is set up with three computer players where the skill level option is left on ‘SKILL LEVEL’.



Y At least one player must be able to set the difficulty settings of the computer player(s). At least 3 difficulty settings must be available.

A match is set up with three computer players where the skill level option is left on ‘-----------’.



Y

On another players’ turn a domino is laid in a correct location. The domino is not laid and the status of the game is not changed.

The domino is not laid and the status of the game is not changed.

Y The users must only be allowed to lay dominos on their turn and in a correct location. If an incorrect domino is laid then this move must not affect the state of the game.

On another players’ turn a domino is laid in an incorrect location. The domino is not laid and the status of the game is not changed.


Y

On the player’s turn a domino is laid in a correct location. There are too many different scenarios to brute force test this option; instead this has been tested throughout the project in many different scenarios.

The domino is laid in the location and the game state is updated based upon the new information.

The domino is laid in the location and the game state is updated based upon the new information.

Y The application must not reject any correct moves the user makes. If a user lays a domino in an acceptable location on their turn then the system must accept this move.

On the player’s turn a domino is laid in an incorrect location. The domino is not laid and the status of the game is not changed.


Y

A match consisting of 2 humans and 2 computers is played and a domino is laid by a server. The client and the computer are updated about the move.

The client and the computer are updated about the move.

Y

A match consisting of 3 humans and 2 computers is played and a domino is laid by a client. The other client, the server and the computer are updated about the move.

The other client, the server and the computer are updated about the move.

Y

A match consisting of 2 humans and 2 computers is played and a domino is laid by a computer.

The other computer, the server and the client are updated about the move.

The other computer, the server and the client are updated about the move.

Y

All accepted moves made by a player must be broadcasted to all other players. This change must then be displayed on all the player’s views. In the case of computer players, they must also be updated of this change.

A match consisting of 2 humans and 2 computers is played and the server knocks. The client and computer are updated about the knock.

The client and computer are updated about the knock.

Y


108


A match consisting of 3 humans and 2 computers is played and a client knocks. The other client, the server and the computer are updated about the knock.

The other client, the server and the computer are updated about the knock.

Y All accepted moves made by a player must be broadcasted to all other players. This change must then be displayed on all the player’s views. In the case of computer players, they must also be updated of this change.

A match consisting of 2 humans and 2 computers is played and a computer knocks. The other computer, the server and the client are updated about the knock.

The other computer, the server and the client are updated about the knock.

Y

A player lays all of their dominos. The round is over and the correct scores are displayed.

The round is over and the correct scores are displayed.

Y

Four players knock in a row. The round is over and the correct scores are displayed.


Y

The application must be able to identify when a round is over. The application must then update the scores appropriately and inform all users the round is over and of the new scores.

A domino is laid such that the train becomes cyclic. The round is over and the correct scores are displayed.


Y

The application must keep track of the score for each team. The application must also inform all that the game is over when the score for a team reaches a certain level.

A game is initiated with 2 humans and 2 computers and a team reaches more than the number of points required to win a game.

The correct score is displayed for both the client and server.

The correct score is displayed for both the client and server.

Y

A test is set up, so 4 computer players on ‘Very Easy’ difficulty setting play a match of 10 games; first to 100 points. The total number of moves is counted and the total time to run the match is calculated.

The mean move time is under 10 seconds.

The mean move time is 0.027 seconds to 3 decimal places.

Y

A test is set up, so 4 computer players on ‘Easy’ difficulty setting play a match of 10 games; first to 100 points. The total number of moves is counted and the total time to run the match is calculated.



Y

A test is set up, so 4 computer players on ‘Medium’ difficulty setting play a match of 10 games; first to 100 points. The total number of moves is counted and the total time to run the match is calculated.



Y

A test is set up, so 4 computer players on ‘Hard’ difficulty setting play a match of 10 games; first to 100 points. The total number of moves is counted and the total time to run the match is calculated.



Y

The systems mean response time when playing as a computer should be under 10 seconds. Also, the worst case time must not exceed 30 seconds.

A test is set up, so 4 computer players on ‘Very Hard’ difficulty setting play a match of 10 games; first to 100 points. The total number of moves is counted and the total time to run the match is calculated.



Y


109

Table 36. Testing the functional requirements.


A test is set up, so 4 computer players on ‘Master’ difficulty setting play a match of 10 games; first to 100 points. The total number of moves is counted and the total time to run the match is calculated.



Y The systems mean response time when playing as a computer should be under 10 seconds. Also, the worst case time must not exceed 30 seconds.

Each time an algorithm is played the response time is timed. This test has been completed many times in very different scenarios.

The worst case is never above 30 seconds.

The worst case is never above 30 seconds.

Y


110

D.2. Optional Requirements

Table 37 shows the testing performed on the optional requirements.


111

Table 37. Testing the optional requirements.

Requirement Description of how it works Successfully Implemented

Justification

Each player must have the ability to change their own name at any stage in the game.

Each human can change their own name. This immediately updates on their own screen, but only updates on other players’ screens after the original player has moved. The computer players’ names cannot be changed.

N This requirement was attempted because it is very easy to allow for a user to change their name. On that player’s turn an additional string is sent to all other players stating the name of the player. This is done if a player has, or has not changed their name

Coloured dominos (where a colour identifies a different value) must be available to the user.

Not implemented. N The dominos have already been coloured to identify whose turn it is. Colouring the dominos in another way might become confusing.

A message log detailing which player made which move must be available.

The message log option can be enabled meaning a screen is displayed showing the moves up to and including the first game of the match, with a maximum of 100 messages. The message log dynamically updates as moves are made and displays knocks, dominos laid and the end of a round.

Y The message log was not that easy to implement, but it helped with debugging the application. It seemed logical to leave this feature in for the end user.

Statistics about previous games and players must be stored.

The scores of the previous rounds in the current game are available. The overall scores in games of Team A against Team B are stored. The final score at the end of each game played between team A and team B is stored.

Y This is quite a crucial requirement, at least to display a small amount of data about the previous and current rounds. This also was not too hard to implement.

Each user must have the ability to change the background image of the application.

Not implemented. N The background is used to identify whose turn it is, by highlighting the appropriate are of the screen. If the user can choose different backgrounds, then this feature will not be included.

Each user must be able to play multiple games simultaneously.

Not implemented. N This would be quite a complex requirement to implement. Also, if a user does wish to play multiple games simultaneously they can load up another copy of the application.

Each player must make a move within a set time.

Not implemented. N This would be a fairly tricky feature to implement, but it would be doable, using a separate thread in the User class which waits for a certain length of time then chooses a random domino to lay, or knocks if the user has not moved. However, this could be quite user unfriendly as they maybe adjusting options, or reading the rules when it reaches their turn. This feature could be editable so in a serious match if players do not want other players multi-tasking and taking large amounts of time on their moves, but in serious matches, players should not be multi-tasking anyway. For this reason I did not implement this feature.

Table 37. Testing the optional requirements.


112

D.3. Co-operative Evaluation Test

Below shows the co-operative evaluation test the participants completed.


113


of Dominos

Please complete under supervision of Richard Walklate

Thank you for agreeing to complete the co-operative evaluation test for the dominos application. The test should take approximately 2-3 hours. The test is split up into four sections. Between each section feel free to take a break before continuing, but if you could refrain from taking a break during a section 1, 2 or 3 it would be greatly appreciated. The point of the co-operative evaluation test is to gain an understanding of how a user finds interacting with the system. Therefore during the test you should communicate your actions with the observer. However, please do your best to try to complete each task without asking the observer for help.

SECTION 1: PLAYING THE GAME Please complete the following tasks. When completing the tasks you may use the help menus the system provides, or any resources, such as the Internet to help you. Please do not consult with the observer unless absolutely necessary. This section is to do with playing a game against the computer.

1. Run the dominos application called ‘Dominos.jar’.

2. Create a dominos game with the following properties:

a. The opponents are all computer players.

b. Enter your own name for your player.

c. Your team mate computer player is of skill level ‘Hard’.

d. Both your opponents’ have skill level ‘Easy’.

e. The number of points to win a game is 20.

f. The number of games in the match is 2.

3. Play one game, again any help screens can be used including the rules of dominos. A game consists of a number of rounds, until one team has a score of more than 20.

4. At the start of the second game set the following features:

a. Change your name to ‘Domino Pro’.

b. Stop the dominos screen from displaying your moves.

c. Stop the dominos screen from colouring the dominos.

d. Bring up a message log of the moves made.

5. Do not start a new match.

6. View the scores and see who won the most games and by how many points. Close all windows that are open, except for the main screen window and move on to section 2.


114

SECTION 2: BEING A SERVER Please complete the following tasks. When completing the tasks you may use the help menus the system provides, or any resources, such as the Internet to help you. Please do not consult with the observer unless absolutely necessary. This section is more to do with playing a game with a human opponent.

1. Create a dominos game with the following properties:

a. The two opponents are computer players.

b. Your team mate is a human player

c. The first opponent has skill level ‘Medium’

d. The second opponent has skill level ‘Very Easy’.

e. Set your name to be ‘Human Team’

f. Set both computer opponents’ name to be ‘Computer Team’

g. The number of points to win a game to be 10.

h. The number of games in the match to be 1.

2. Inform the instructor of your IP address and wait for them to connect to the game. You may communicate with the instructor about details specific to the game.

3. Lay one domino, after this set the speed of the computer players to be 50.

4. Lay another domino, after this set the speed of the computer players back to the default.

5. Finish the match and do not start a new one, close all windows open except the main screen and move onto section 3.


115

SECTION 3: BEING A CLIENT Please complete the following tasks. When completing the tasks you may use the help menus the system provides, or any resources, such as the Internet to help you. Please do not consult with the observer unless absolutely necessary. This section is more to do with playing a game against a human opponent, but this time being a client.

1. Wait for the observer to set up the appropriate settings.

2. Join a game with the following settings:

a. The IP address of the opponent is 192.168.1.65 and the port number is 4444.

b. You are player D with the name ‘Client Player’.

3. Play the match, you may ask the observer (the server) specifically about the dominos game.

4. When the match is over exit the application and move onto section 4.


116

SECTION 4: TESTING THE ALGORITHMS Please complete the following tasks. When completing the tasks you may use the help menus the system provides. You may use external resources, such as the Internet to gather appropriate tactics if you wish. However, try to avoid spending a long time gathering tactics; it is more effective if you think up your own tactics in order to play the game. Please do not consult with the observer unless absolutely necessary. This section may take a long amount of time. Feel free to take breaks during this section, preferably at suitable times, like at the end of a game. This section is relates to how skilful the algorithms are at playing against a human opponent.

1. Complete the following steps two times, each time selecting a new algorithm.

a. Run the Section4.jar application via command line using the command; “java –jar Section4.jar > YourNameAlgorithm.log” (the instructor should do this for you).

b. Select an algorithm from the list given to you by the observer.

c. Set up a new match, consisting of games up to 100 points and matches of 3 games.

d. The other players must all be computer players of whatever skill algorithm selected in part a.

e. Any options or features of the system can be used during the test including the message log, colouring dominos, changing the speed, etc.

f. At the end of a round please allow for the observer to examine the score.

g. Once you have finished the match close the application and return to step A.


117

D.4. Notes on Tests

Below shows the notes made from each subject completing their test.

Subject 1

Main Screen

• Immediate confusion about how to click buttons in Java, double clicked, instead of single clicking.

• Was not sure on Main Screen which player is on which team.

• Was unsure about the ‘Number of Points’ entry screen, thought it should state some relation with the word ‘Game’, eg; ‘Number of Points to Win Game’.

• Seeing both sides of the Main Screen confused the subject, as some options were not needed.

Dominos Game

• Immediately assumed that to lay a domino, drag and drop was used, instead of single clicking. Recommended that basic controls should be displayed more clearly.

• Had trouble picking up and laying the domino (single clicking).

• Understood the score board from the description. However, said it was too complicated to understand without using instructions.

• Recommended that a warning option should always be displayed when closing the current game.

• Was confused by the term ‘Configuration’ on the menu bar, recommended using the word ‘Options’.

• Assumed that when changing the speed of the computer players 50 meant faster and 0 meant slower, however, it is the other way around. Recommended putting in labels saying ‘slow’ and ‘fast’.

Help Menus

• Suggested making the Help Menus smaller, so they could see the application and use the help menus simultaneously.

• The words ‘cmd’ and ‘ipconfig’ were confusing to the subject, because they did not know if the ‘ ‘ character was part of the word. Subject recommended putting the words in bold.

Additional

• Some confusion about which application to open, the test said ‘Dominos.jar’, in Windows, it displays ‘Dominos’.


118

Subject 2

Main Screen

• On the whole, understood the Main Screen when setting up a game.

• Main confusion was which player was on which team.

• Thought there should be a maximum number of characters for the player names.

• Some confusion over the right and left side of the screens, for example; tried to enter their name on the left side of the screen when being a client, which is incorrect.

Dominos Game

• Immediately assumed that to lay a domino, drag and drop was used, instead of single clicking. Recommended that basic controls should be displayed more clearly.


• Had trouble finding the help screens.

• Used the keyboard shortcuts when given an opportunity.

• Wanted to look at scores when the application showed the box; ‘Press OK to proceed to next round’.

• Confusion when trying to not colour the dominos, as the application said ‘Colour Players’ not ‘Colour Dominos’.

• A bit of confusion about the wording when stopping the application from displaying the positions that dominos can be laid.

• Did not notice the lighting effect of deciding whose move it is.

• Noticed a spelling mistake when changing the speed ‘Canel’ was used instead of ‘Cancel’.

• Assumed that a speed of 50 was faster than a speed of 0.

• With the speed dialogue box, thought that pressing the ‘Reset Default’ button should reset the speed to the default, not just move the slider to the default position.

• Would prefer it if there was an option to colour the dominos, such that each value has a certain colour.

• When joining the game, did not know which player was human, or computer, but did not want to know.

• When playing would prefer to be told when it is the end of a game, not just the end of a round.

• Was annoyed at the fact that one end of the train could become cornered, so no-one could lay at that end.


119

Subject 3

Main Screen

• Unsure about which player was on which team. Identified the answer using the Help Screen.

• Said the ‘SKILL LEVEL’ box should either be changed to ‘DIFFICULTY LEVEL’, or the levels should be low to high, as easy and hard are not skill levels.

• Confused about the two different sides of the Main Screen. Tried to enter their name on the wrong side.

Dominos Game

• Assumed the rules of dominos would be on the Main Screen.

• Initially thought that in order to lay a domino drag and drop would be used.

• Understood how to rotate a domino by guessing how.


• Thought that changing the configurations was on the Main Screen, not the dominos screen. In order to solve this problem wanted the Main Screen name to be changed to Initial Setup.

• When changing the speed thought that a larger number would make the computer players play faster.

• Did not immediately recognise the lights going round the screen to identify whose turn it was. Recommended changing the colour of the text which says the player’s name, to match the colour scheme.

Help Menus

• Didn’t like the link in the ‘Dominos Game Help’ screen, which links directly to the ‘Rules of Dominos’ screen. This is because they did not like having one section which is basically a link.

• Had some grammatical issues with the rules.

• Did not pick up from the rules that dominos could only be laid at the ends of the train.


120

Subject 4

Main Screen

• Automatically assumed the second player was the team mate. Did not know how to identify who the team mate was.

• Some confusion over the two sides of the screen, attempted to press the ‘Create Game’ button instead of the ‘Join Game’ button.

Dominos Game

• Thought that to lay a domino drag and drop would be used.

• Quickly found options to change.


• Guessed how to rotate the domino.

• Thought that a larger number would increase the speed.

• Annoyed that ends of the train could become blocked and dominos could be laid because of this. Wanted a re-ordering feature to be added.

Help Menus

• Was against using Help Screens, said that they always try to avoid using them.

• Managed to use the Help Screen to discover their IP address.


121

D.5. Questionnaire

Below shows a blank copy of a questionnaire delivered to people after completing the co-operative evaluation test.


of Dominos

Please complete under supervision of Richard Walklate

You should have now completed the co-operative evaluation test. If you would not mind filling out this quick questionnaire about the test it would be greatly appreciated.

SECTION 1: INITIAL SCREEN 1. How easy was it to set up a game of dominos?

2. Was it harder to set up a game involving other humans than just with computer players?

3. Was it harder to join a game than set one up involving any players?

4. How useful was the help menu when creating a new game?

Very Easy Very Hard

Easier Harder

Easier Harder

I did not need to use the help menu The help menu was useful I used the help menu, but it did not help me to work the system


122

SECTION 2: DOMINOS GAME 5. How useful did you find the rules of how to play dominos?

6. How easy did you find it to lay dominos?

7. How easy did you find it to configure options like changing the speed of the algorithms, the colour of the dominos, the options being displayed or other similar features?

8. How obvious was the following information?

9. How useful was the help screen when using the system?

I did not need to use it, as I knew how to play dominos The help menu was useful I used the help menu, but I still did not understand how to play

Easy Hard

Easy Hard

Options Obvious Not Obvious

What dominos you own

How many dominos other people own

Which player is on which team

Which player’s move it is

The current score

What dominos people have laid

I did not need to use it, as I knew what I was doing The help menu was useful I used the help menu, but I still did not understand what to do


123

SECTION 3: OVERALL 10. Did you feel like you had access to all the features of the system you required? Please

mark one box which best applies to you?

11. Did you find any problems with the colouring system used? Please mark all boxes which apply to you.

12. Did you find there was a suitable amount of keyboard shortcuts? Please mark one box which best applies to you.

13. Did you feel like you had to use the mouse for longer than necessary? Please mark one box which best applies to you.

14. Was it clear which sections you should edit and what options you could decide? Please mark one box which best applies to you.

15. Was there ever an opportunity for you to cheat (without looking at the observer’s or opponent’s monitor)? Please mark one box which best applies to you.

16. Did you find the system too CPU intensive12? Please mark one box which best applies to you.

17. Did the system ever crash?

12 Meaning did the application perform slowly, or did it ever lag?

I could access all the features of the system I could access all the features of the system that I needed I could not access some features of the system that I needed

There were no problems with the colours used in the system I could not read some texts because of the colours used I could not see certain objects because of the colouring system used

There were enough keyboard shortcuts I did not use the keyboard shortcuts and I never wished to There were cases when I would have liked to use keyboard shortcuts If you marked the last box, please explain why

I did not feel like I used the mouse for longer than necessary I felt like I used the mouse for longer than necessary I felt like I used the mouse for longer than necessary and I felt some pain or discomfort

It was always clear which options I should edit There was some confusion at the start of the game as to which options I should edit, but after a small amount of time this became obvious

There was a lot of confusion about which options to edit

There was never an opportunity to cheat I could, or did cheat If you marked the box saying that you could, or did cheat please state how

The system performed fine The system used too much memory for my computer


124

No the system did not crash Yes the system crashed If the system crashed, please give details


125

SECTION 4: ANY OTHER COMMENTS 18. Please state any other comments you have about the application. This can include things

the application has done well, things it has done poorly, or any improvements that you would like to see.


126

D.6. Questionnaire Results

A summary of the results gathered from the questionnaires are shown below:

Question 1; how easy was it to set up a game of dominos

Question 2; was it harder to set up a game involving humans?

Question 3; was it harder to join a game than set one up?

Question 4; how useful was the help menu when creating the game?

Question 5; how useful were the rules on how to play dominos?

Question 6; how easy was it to lay dominos?

Question 7; how easy was it to alter the configurations during the game?

Question 8; how obvious was the following (the table below shows the mean of the responses, 1 means it was obvious and 5 means not obvious)?

Very Easy Easy Medium Hard Very Hard

2 2

Easier Same Harder

1 3

Easier Same Harder

1 2 1

I did not need to use the help menu

The help menu was useful 4

I used the help menu, but it did not help me to work the system

I did not need to use it, as I knew how to play dominos 3


I used the help menu, but I still did not understand how to play

Easy Medium Hard

1 1 2

Easy Medium Hard

3 1


127

Question 9; how useful was the help menu when playing?

Question 10; could you access all features of the system you required?

Question 11; were there problems with the colouring of the system?

Question 12; were there a suitable amount of keyboard shortcuts?

Question 13; did you have to use the mouse for an extensive period of time?

Question 14; was it clear which options to edit?

Options Results

What dominos you own 1

How many dominos other people own 1

Which player is on which team 3

Which player’s move it is 1.75

The current score 1.5

What dominos people have laid 1.75

I did not need to use it, as I knew what I was doing 1


I used the help menu, but I still did not understand what to do

I could access all the features of the system 1

I could access all the features of the system that I needed 2

I could not access some features of the system that I needed 1

There were no problems with the colours used in the system 4

I could not read some texts because of the colours used

I could not see certain objects because of the colouring system used

There were enough keyboard shortcuts 1

I did not use the keyboard shortcuts and I never wished to 3

There were cases when I would have liked to use keyboard shortcuts

I did not feel like I used the mouse for longer than necessary 4

I felt like I used the mouse for longer than necessary

I felt like I used the mouse for longer than necessary and I felt some pain or discomfort

It was always clear which options I should edit 2

There was some confusion at the start of the game as to which options I should edit, but after a small amount of time this became obvious

2

There was a lot of confusion about which options to edit


128

Question 15; was there an opportunity to cheat?

Question 16; was the system too CPU intensive?

Question 17; did the system ever crash?

Question 18; any other comments.

There was never an opportunity to cheat 4

I could, or did cheat

The system performed fine 4

The system used too much memory for my computer

No the system did not crash 4

Yes the system crashed

Comments

Wording in part needs changing to keep it simple for new players. It would also be useful to have visual access to "Help" when setting up a game. Some of the games ended because it was impossible to lay any more dominos. This was not because I didn't have any appropriate dominos to lay but because there was not enough room on the screen to put them in. It would have been useful to have a facility to rearrange the dominos into a better configuration so that the game could continue until someone was out or no-one had any dominos of the correct values. I'd change "Team A" and "Team B" so it's more obvious which team I'm in eg. "Bob's team" and "Opponent". At the end of a round, the scores come up for you to see (which is good) but the game automatically starts in the background. I'd rather have a "Start next round" button (or something similar!) so I don't miss the start of the next game.

Frustrating that ther was restricted space to lay dominoes. Liked the speed setting and ability to speed up the game Mouse clicking to move and rotate dominoes did not always work. Should be an option to turn the 'legal move' dialogue box off, so people pay for their mistakes!


129

D.7. Non Functional Requirements

Table 38 shows the information gathered to provide evidence as to whether the system meets the non functional requirements.


130

Requirement What has been done What the users say Action

The GUI should be clearly laid out so that the same level of functionality is easily available to people with minimal computing experience as to people with a higher level of experience.

The GUI has been laid out so I understand it perfectly well. However, I have had much computing experience. I have tried to make it easy to use for all people, but I am unable to say if other people will be able to use it. Help menus have been used in attempt to help people use the system.

All the users had some previous computing experience. Although some users found the interface confusing in places this was not because they did not have enough computer knowledge, but rather due to misleading labels or instructions. The results of the questionnaire show many areas in which this requirement applies. The main areas users found difficulty was setting up a game of dominos, laying the dominos and understanding which options to edit and when.

The system needs to be made clearer. This shall be analysed in more detail in section 6.3 when looking at testing the interface.

Care must be taken when overlaying colours, especially with text.

Care was taken in order to ensure that colour use was appropriate. The colouring of the background screen was specifically chosen as it is easy to look at and the text is easy to read.

No users mentioned a problem and their answers to question 11 implied that there was no problem with the colouring system.

Ensure similar standards are kept during updates to the system.

A suitably simple screen must be available for the users to connect up over a network.

I tried to keep this screen as simple as possible. However, it is hard to implement a complex concept and make it usable. Additional instructions were added as to how to connect to other players within the instructions.

Based on the results to questions 2 and 3 the users found it slightly harder to play a game against other humans. However, there seemed to be no real difference between joining, or initiating a game as they found both hard. When speaking to the users during the test they seemed to find the hardest parts being finding their IP address. They also found it hard to know which boxes to use on the Main Screen as there were some boxes which did not need to be used.

The Main Screen interface needs redoing to make this operation simpler. The updates are discussed in section 6.3 when looking at testing the interface.

The system must provide keyboard shortcuts wherever possible.

For almost every option I ensured an appropriate keyboard shortcut was used. These were displayed in help menus and next to the option.

Only one user used the keyboard shortcuts. The others did not think about it. This is most likely because keyboard shortcuts are used by people who have been using a system for a long time and who know what they are doing. If it is your first time using a system the main goal is to ensure you can use it, rather than using it a few seconds faster.

It is hard to make the keyboard shortcuts more obvious and taking them out holds no advantage. Therefore this feature shall be left in and not altered, with the logic that hopefully people will use these shortcuts if they play the game more often.


131


The user must not be forced to constantly use the mouse.

I have attempted to keep mouse use to a minimum. This has mainly been achieved by providing keyboard shortcuts for all configuration options. Also, by making laying the dominos two clicks of the mouse instead of drag and drop, I assumed this would also be an advantage.

No user complained they were using the mouse too much. The responses to question 13 of the questionnaire implied that no-one felt like they were using the mouse for excessive periods of time. There were a few issues with players finding it hard to pick up and lay dominos as the mouse was hard to use.

On the whole this requirement needs no more work. However, using the mouse may become annoying hence some keyboard would be nice. It is hard to simulate laying a domino using keyboard shortcuts, however, keyboard shortcuts for picking up a domino shall be implemented.

This is an application in which multiple users can alter settings, therefore there is potential for confusion to occur, if multiple users can alter the same settings simultaneously. The system should be designed to avoid these areas of conflict.

The system has been designed so multiple users cannot edit the same features. Each user can change their own name and lay their own dominos. Options which are specific to the game, such as the number of points to play to, the skill levels of the computer players and the speeds of the computer players are only editable by the server. This implies no areas of conflict should arise.

The users did not have a chance to break this requirement as they could not edit the incorrect settings. However, there was some confusion about which sections they should edit when initialising, or joining the game. This was mainly due to the layout of the initial screen. If we consult the results to question 14 of the questionnaire some users did not know which opions they should edit.

The system has been implemented to support this requirement. However, the system shall be updated in order to allow for the interface to be more obvious about which sections to edit. These updates are described in interface testing; section 6.3.

The system must be relatively secure, so that it is not easy for an opponent to see another player’s dominos.

The system does not allow a player to see other players’ dominos. However, the system cannot prevent people from communicating or looking at others screens. As the application is being played over the Internet and all the dominos originally start at the server’s side there are obviously ways to cheat and gain access to other players’ dominos.

No user noticed a problem with this (except for the fact the observer was in the same room and could therefore look at the player’s screen). The results to question 15 back up this claim.

No real work needs to be done on this requirement. This may be more of an issue of the game involved some kind of gambling as people would not want to lose money. In this case one central server would be used and all the players of the game would connect as clients. The dominos would be encrypted and sent.


132

Table 38. Testing the functional requirements.


The system must not be too CPU intensive. Users should be able to multi-task when playing the game.

Care has been taken when designing the system so that it does not use too much memory. Drawing images uses a large amount of memory. To compensate for this the images are drawn at the start and cached so a large amount of memory is used loading the system, after that it runs smoothly.

No complaints were made about this. The results of question 16 imply that the system is ok.

Continue to use similar techniques if adding new features.

The game must be portable to many operating systems.

Java is portable to many operating systems. The game has been tested on UNIX, Linux and Windows and it runs, as long as a visual display is available.

The users did not get a chance to test this. Ensure that no new features change this.

The application must be durable and must be able to sensibly handle all kinds of user activity; for example, players leaving a game.

A wide variety of tests have been performed (see the functional testing shown in section 6.1.1). However, there are still likely to be some small bugs in the system but it can handle the majority of user input.

There were no errors during the evaluation test. The users did not say it had crashed (results of question 17).

When adding new features test them rigorously to minimise the chances of bugs appearing.


133

E SOURCE CODE

The following is sample source code from the project. The entire code from the project has not been included as it would consume several hundred pages and much of it is not of great interest. The following section displays the most important sections. A brief description of the classes is displayed below, but full detail can be found in the design section; 4.

•••• MainScreen – displays the initial screen the user is presented with upon running the application. Allows the user to enter the appropriate information about the game.

•••• Server – the actions performed by the player of the game who is the server. This includes the game setup, displaying the current screen to the user and distributing all moves to all players.

•••• CheckLayedDomino – checks to see if a domino can be laid in a specific place. Also, returns all the possible locations where a domino can be laid; in order to see if a player is knocking when they are allowed to move and to display their options. This feature is also used by the algorithms to identify where they are allowed to lay dominos.

•••• Algorithm – the abstract super class of all the algorithms. Defines the important functions that are called; including, asking the algorithm to lay a domino layDomino() and informing the algorithms what domino has been laid dominoLaid(LaidDomino,playerNo).

•••• MergeDGCAlgorithm – the code for the Master algorithm. This algorithm relies on three other algorithms, which are coded in other classes. The workings of this algorithm is described within the algorithms section; 5.9.1.


134

E.1. MainScreen package data; import java.awt.*; import javax.swing.*; import board.Background; import board.Board; import board.Train; import networking.*; import java.awt.event.*; /** * The MainScreen class displays an appropriate interface allowing users to play * dominos. The user can either initiate, or join a game; * * Initiate - if the user chooses to initiate a game then they are the server. * This means they enter the details about the game including the types of * player within the game, computer or human, the difficulty levels of the * computer players, the number of points and the number of games in a match. * * Join - if the user is planning to join a game then they are the client. The * client connects to the server on the appropriate port. The IP address and * port of the server must be known. * * The GUI is split into two main sections via a tabbed pane. A help menu is * also available. The class also forbids players participating in more than 1 * game at once. * * * @author Richard Walklate * @date 03/05/2007. * @version 1.0 * */ public class MainScreen extends JFrame implements ActionListener, KeyListener { private static final long serialVersionUID = 1L; /* * Keeps track of whether the user is already a server or client in a game */ private Server s = null; private Client c = null; /* * The title bar and help button at the top of the screen */ private JButton help; private JButton logo;

private JLabel title; private JLabel screenInfoLabel; private JLabel tabInfoLabel; /* * Tabbed pane separates the server and client options */ private JTabbedPane tabbedPane; /* * Components for the server pane, allowing the user to initiate a new game * with the correct settings */ private JLabel serverLabel; private JRadioButton[][] playerType = new JRadioButton[4][2]; private JComboBox[] difficultyLevel = new JComboBox[4]; private static final String[] PLAYER_NAMES = { "You (Team A)", "Opponent 1 (Team B)", "Your Team Mate (Team A)", "Opponent 2 (Team B)" }; private JLabel[] playerNameLabel = new JLabel[4]; private JTextField[] playerNameLeft = new JTextField[4]; private JLabel portLabel1; private JTextField port1 = new JTextField(); private JLabel pointsLabel; private JTextField pointsField = new JTextField(); private JLabel gamesLabel; private JTextField gamesField = new JTextField(); private JButton initiateGame; /* * The client pane allows players to join a game created by a server */ private JLabel joinLabel; private JLabel IPLabel; private JLabel portLabel2;


135

private JTextField IP = new JTextField(); private JTextField port2 = new JTextField(); private JRadioButton[] playerLetter = new JRadioButton[3]; private JTextField[] playerNameRight = new JTextField[3]; private JButton join; /** * The constructor lays out the MainScreen. Does not lay out objects within * the tabbed pane, this is done in the getServerPanel() and * getClientPanel() functions. */ public MainScreen() { super("Main Screen"); setSize(650, 500); JPanel pane = new JPanel(); GridBagLayout layout = new GridBagLayout(); GridBagConstraints gbc = new GridBagConstraints(); pane.setLayout(layout); // Quits the application if the main screen is closed ExitWindow exit = new ExitWindow(); addWindowListener(exit); tabbedPane = new JTabbedPane(); // The server panel; allows users to initiate a game JPanel serverPanel = getServerPanel(); tabbedPane.addTab("Initiate Game", null, serverPanel,

"Initialise a game against human and/or computer opposition");

tabbedPane.setMnemonicAt(0, KeyEvent.VK_1); // The client panel; allows users to join a game JPanel clientPanel = getClientPanel(); tabbedPane.addTab("Join Game", null, clientPanel, "Join a game that has been set up by a human"); tabbedPane.setMnemonicAt(1, KeyEvent.VK_2); // Dominos logo, links to information about the product logo = new JButton(new ImageIcon("img/logo.jpg")); logo.setMargin(new Insets(0, 0, 0, 0)); logo.setBorderPainted(false); buildConstraints(gbc, 0, 0, 1, 3, 10, 10); gbc.anchor = GridBagConstraints.CENTER; gbc.fill = GridBagConstraints.NONE; layout.setConstraints(logo, gbc);

pane.add(logo); logo.addActionListener(this); // Title title = new JLabel(); title.setFont(new Font(title.getFont().getName(), Font.BOLD, 24)); title.setText("DOMINOS"); buildConstraints(gbc, 1, 0, 2, 1, 50, 10); gbc.anchor = GridBagConstraints.CENTER; gbc.fill = GridBagConstraints.NONE; layout.setConstraints(title, gbc); pane.add(title); // Information about the screen screenInfoLabel = new JLabel( "Use this screen to initiate, or join a game"); buildConstraints(gbc, 1, 1, 2, 1, 50, 10); gbc.anchor = GridBagConstraints.CENTER; gbc.fill = GridBagConstraints.NONE; layout.setConstraints(screenInfoLabel, gbc); pane.add(screenInfoLabel); // Information about the tabs tabInfoLabel = new JLabel("Click the tabs below to change the view"); buildConstraints(gbc, 1, 2, 2, 1, 50, 10); gbc.anchor = GridBagConstraints.CENTER; gbc.fill = GridBagConstraints.NONE; layout.setConstraints(tabInfoLabel, gbc); pane.add(tabInfoLabel); // Help button help = new JButton(new ImageIcon("img/help.jpg")); help.setMargin(new Insets(0, 0, 0, 0)); help.setBorderPainted(false); buildConstraints(gbc, 3, 0, 1, 3, 10, 10); gbc.anchor = GridBagConstraints.CENTER; gbc.fill = GridBagConstraints.NONE; layout.setConstraints(help, gbc); pane.add(help); help.addActionListener(this); // Tabbed pane buildConstraints(gbc, 0, 4, 4, 1, 100, 100); gbc.anchor = GridBagConstraints.CENTER; gbc.fill = GridBagConstraints.BOTH; layout.setConstraints(tabbedPane, gbc); pane.add(tabbedPane); setContentPane(pane); } /** * Sets the constraints for the layout, so the components are layed out in


136

* the appropriate places. * * @param gbc - * the layout * @param gx - * how far along the x-axis to put the component * @param gy - * how far along the y-axis to put the component * @param gw - * the width of the component * @param gh - * the height of the component * @param wx - * the weight of the width of the component as a proportion to * other components * @param wy - * the weight of the height of the component as a proportion to * other components */ private static void buildConstraints(GridBagConstraints gbc, int gx, int gy, int gw, int gh, int wx, int wy) { gbc.gridx = gx; gbc.gridy = gy; gbc.gridwidth = gw; gbc.gridheight = gh; gbc.weightx = wx; gbc.weighty = wy; } /** * Lays out the server panel, which allows users to initiate a game. * * @return - a JPanel with the appropriate layout. */ private JPanel getServerPanel() { JPanel serverPanel = new JPanel(); GridBagLayout layout = new GridBagLayout(); GridBagConstraints gbc = new GridBagConstraints(); serverPanel.setLayout(layout); // Top left label, stating the server side serverLabel = new JLabel( "Server Screen - use the screen to initialise a

game"); buildConstraints(gbc, 0, 0, 4, 1, 100, 100); gbc.anchor = GridBagConstraints.CENTER; gbc.fill = GridBagConstraints.NONE; layout.setConstraints(serverLabel, gbc); serverPanel.add(serverLabel);

// Radio buttons for whether each player should be a human or

// computer // The skill level of the computer players for (int i = 0; i < playerType.length; i++) { ButtonGroup bg = new ButtonGroup(); playerType[i][0] = new JRadioButton("Computer"); playerType[i][0].setSelected(true); playerType[i][1] = new JRadioButton("Human"); bg.add(playerType[i][0]); bg.add(playerType[i][1]); buildConstraints(gbc, 3, (2 * i) + 2, 1, 1, 100, 100); layout.setConstraints(playerType[i][0], gbc); serverPanel.add(playerType[i][0]); playerType[i][0].addActionListener(this); buildConstraints(gbc, 3, (2 * i) + 3, 1, 1, 100, 100); layout.setConstraints(playerType[i][1], gbc); serverPanel.add(playerType[i][1]); playerType[i][1].addActionListener(this); difficultyLevel[i] = new JComboBox(); difficultyLevel[i].addItem("DIFFICULTY LEVEL"); difficultyLevel[i].addItem("-----------"); difficultyLevel[i].addItem("Very Easy"); difficultyLevel[i].addItem("Easy"); difficultyLevel[i].addItem("Medium"); difficultyLevel[i].addItem("Hard"); difficultyLevel[i].addItem("Very Hard"); difficultyLevel[i].addItem("Master"); buildConstraints(gbc, 4, (2 * i) + 2, 1, 1, 100, 100); layout.setConstraints(difficultyLevel[i], gbc); serverPanel.add(difficultyLevel[i]); } // The first player can only be human playerType[0][0].setVisible(false); playerType[0][1].setSelected(true); difficultyLevel[0].setVisible(false); // Sets the name labels and textbox entry fields for each player for (int i = 0; i < playerNameLeft.length; i++) { playerNameLabel[i] = new JLabel(PLAYER_NAMES[i]); buildConstraints(gbc, 0, (2 * i) + 2, 1, 1, 100, 100); gbc.anchor = GridBagConstraints.WEST; layout.setConstraints(playerNameLabel[i], gbc); serverPanel.add(playerNameLabel[i]); buildConstraints(gbc, 1, (2 * i) + 2, 2, 1, 300, 100); playerNameLeft[i] = new JTextField("Player " + (i + 1)); gbc.anchor = GridBagConstraints.WEST; gbc.fill = GridBagConstraints.HORIZONTAL;


137

layout.setConstraints(playerNameLeft[i], gbc); serverPanel.add(playerNameLeft[i]); playerNameLeft[i].setEditable(true); playerNameLeft[i].addKeyListener(this); } playerNameLeft[0].setEditable(true); playerNameLeft[0].setText("Player 1"); // Allows the server to specify how many points will win a game pointsLabel = new JLabel("Points to Win Game"); buildConstraints(gbc, 0, 10, 1, 1, 100, 100); gbc.anchor = GridBagConstraints.WEST; gbc.fill = GridBagConstraints.NONE; layout.setConstraints(pointsLabel, gbc); serverPanel.add(pointsLabel); buildConstraints(gbc, 1, 10, 1, 1, 100, 100); gbc.anchor = GridBagConstraints.WEST; gbc.fill = GridBagConstraints.HORIZONTAL; layout.setConstraints(pointsField, gbc); serverPanel.add(pointsField); pointsField.setText("100"); // Allows the server to specify how many games to play gamesLabel = new JLabel("Number of Games"); buildConstraints(gbc, 0, 11, 1, 1, 100, 100); gbc.anchor = GridBagConstraints.WEST; gbc.fill = GridBagConstraints.NONE; layout.setConstraints(gamesLabel, gbc); serverPanel.add(gamesLabel); buildConstraints(gbc, 1, 11, 1, 1, 100, 100); gbc.anchor = GridBagConstraints.WEST; gbc.fill = GridBagConstraints.HORIZONTAL; layout.setConstraints(gamesField, gbc); serverPanel.add(gamesField); gamesField.setText("10"); // Allows the server to enter their port; label and textbox portLabel1 = new JLabel("Port"); buildConstraints(gbc, 0, 12, 1, 1, 100, 100); gbc.anchor = GridBagConstraints.WEST; gbc.fill = GridBagConstraints.NONE; layout.setConstraints(portLabel1, gbc); serverPanel.add(portLabel1); buildConstraints(gbc, 1, 12, 1, 1, 100, 100); gbc.anchor = GridBagConstraints.WEST; gbc.fill = GridBagConstraints.HORIZONTAL; layout.setConstraints(port1, gbc); serverPanel.add(port1); port1.setText("4444"); port1.addKeyListener(this); // The button which will initiate the game initiateGame = new JButton("Start Game");

buildConstraints(gbc, 0, 13, 4, 1, 100, 100); gbc.anchor = GridBagConstraints.CENTER; gbc.fill = GridBagConstraints.NONE; layout.setConstraints(initiateGame, gbc); serverPanel.add(initiateGame); initiateGame.addActionListener(this); return serverPanel; } /** * Lays out the client panel, which allows users to join a game. * * @return - a JPanel with the appropriate layout. */ private JPanel getClientPanel() { JPanel clientPanel = new JPanel(); GridBagLayout layout = new GridBagLayout(); GridBagConstraints gbc = new GridBagConstraints(); clientPanel.setLayout(layout); // The Join a Game label at the top right of the screen joinLabel = new JLabel("Client Screen - used to join a game"); buildConstraints(gbc, 0, 0, 4, 1, 100, 100); gbc.anchor = GridBagConstraints.CENTER; gbc.fill = GridBagConstraints.NONE; layout.setConstraints(joinLabel, gbc); clientPanel.add(joinLabel); // The user enters the IP address and port for the specific game IPLabel = new JLabel("IP address"); buildConstraints(gbc, 0, 2, 2, 1, 100, 100); gbc.anchor = GridBagConstraints.WEST; gbc.fill = GridBagConstraints.NONE; layout.setConstraints(IPLabel, gbc); clientPanel.add(IPLabel); portLabel2 = new JLabel("Port"); buildConstraints(gbc, 0, 3, 2, 1, 100, 100); gbc.anchor = GridBagConstraints.WEST; gbc.fill = GridBagConstraints.NONE; layout.setConstraints(portLabel2, gbc); clientPanel.add(portLabel2); buildConstraints(gbc, 2, 2, 2, 1, 100, 100); gbc.anchor = GridBagConstraints.WEST; gbc.fill = GridBagConstraints.HORIZONTAL; layout.setConstraints(IP, gbc); clientPanel.add(IP); buildConstraints(gbc, 2, 3, 1, 1, 100, 100); gbc.anchor = GridBagConstraints.WEST; gbc.fill = GridBagConstraints.HORIZONTAL; layout.setConstraints(port2, gbc);


138

clientPanel.add(port2); port2.setText("4444"); port2.addKeyListener(this); // The user chooses a specific player and enters a name ButtonGroup bg = new ButtonGroup(); for (int i = 0; i < playerLetter.length; i++) { playerLetter[i] = new JRadioButton("Player " + (i + 2) + "

(Team " + (i % 2 == 0 ? "B" : "A") + ")"); bg.add(playerLetter[i]); playerLetter[i].addActionListener(this); buildConstraints(gbc, 0, 6 + i, 2, 1, 100, 100); gbc.anchor = GridBagConstraints.CENTER; layout.setConstraints(playerLetter[i], gbc); clientPanel.add(playerLetter[i], gbc); playerNameRight[i] = new JTextField("", 30); playerNameRight[i].setEditable(false); buildConstraints(gbc, 2, 6 + i, 2, 1, 100, 100); gbc.anchor = GridBagConstraints.WEST; gbc.fill = GridBagConstraints.HORIZONTAL; layout.setConstraints(playerNameRight[i], gbc); clientPanel.add(playerNameRight[i]); playerNameRight[i].addKeyListener(this); } // The button to join a game join = new JButton("Join Game"); buildConstraints(gbc, 2, 13, 1, 1, 100, 100); gbc.anchor = GridBagConstraints.CENTER; gbc.fill = GridBagConstraints.NONE; layout.setConstraints(join, gbc); clientPanel.add(join); join.addActionListener(this); return clientPanel; } /** * Checks to see if the user is already playing a game before starting a new * one. Gives them the option to leave the current game and start a new one. * */ private void isAlreadyPlaying() { if (User.isPlaying()) { int result = JOptionPane .showConfirmDialog( null, "You can only play 1 game at a time, are you sure you want to exit your current game?", "Caution: cannot play more than 1 game at once",

JOptionPane.YES_NO_OPTION); if (result == JOptionPane.YES_OPTION) { User.setPlaying(false); if (s != null) { s.exitGame(); } if (c != null) { c.exitGame(); } } } } /** * Displays the frame. * */ public void launchFrame() { this.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE); this.setVisible(true); } /** * ActionPerformed, in this case when a radio button is pressed it signifies * a player being selected therefore the appropriate text is set. Also, when * a button is pushed it means a user is trying to start a game, so the * appropriate action is taken. * * @param evt - * the event that caused this function to be called. */ public void actionPerformed(ActionEvent evt) { if (evt.getSource() == help) { new InformationScreen(InformationScreen.HELP_MAIN_SCREEN) .launchFrame(); } if (evt.getSource() == logo) { new InformationScreen(InformationScreen.PRODUCT_INFORMATION) .launchFrame(); } // A user trying to create a game, if one is not already in progress // initiates it if (evt.getSource() == initiateGame) { try { isAlreadyPlaying(); if (!User.isPlaying()) { boolean[] human = new boolean[] { playerType[0][1].isSelected(), playerType[1][1].isSelected(), playerType[2][1].isSelected(), playerType[3][1].isSelected() }; String[] playerNames = new String[] {


139

playerNameLeft[0].getText().substring(0, Math.min(playerNameLeft[0].getText() .length(), 10)), playerNameLeft[1].getText().substring(0, Math.min(playerNameLeft[1].getText() .length(), 10)), playerNameLeft[2].getText().substring(0, Math.min(playerNameLeft[2].getText() .length(), 10)), playerNameLeft[3].getText().substring(0, Math.min(playerNameLeft[3].getText() .length(), 10)) }; int[] skillLevels = new int[] { difficultyLevel[0].getSelectedIndex() - 2, difficultyLevel[1].getSelectedIndex() - 2, difficultyLevel[2].getSelectedIndex() - 2, difficultyLevel[3].getSelectedIndex() - 2 }; int numberPoints = Integer.parseInt

(pointsField.getText().trim()); int numberGames = Integer.parseInt(

gamesField.getText().trim()); if (numberPoints < 0) {

throw new NumberFormatException("For input string " + numberPoints);

} if (numberGames < 1) {

throw new NumberFormatException("For input string " + numberGames);

} s = new Server(Integer.parseInt(port1.getText()

.trim()), human, playerNames, skillLevels, numberPoints, numberGames);

s.start(); } } catch (Exception e) { User.setPlaying(false); JOptionPane.showMessageDialog(null, e.getMessage(), "Error Connecting", JOptionPane.

ERROR_MESSAGE); } } // A user trying to join a game, if one is not already in progress // attempts to join it if (evt.getSource() == join) { try { isAlreadyPlaying(); if (!User.isPlaying()) {

int playerNumber = 0; String pName = ""; for (int i = 0; i < playerLetter.length; i++) { if (playerLetter[i].isSelected()) { playerNumber = i + 2; pName = playerNameRight[i].

getText().substring(0, Math.min(playerNameRight[i]. getText().

length(), 10)); } } if (playerNumber != 0) { c = new Client(IP.getText(),

Integer.parseInt(port2. getText()), playerNumber, pName);

c.start(); } } } catch (Exception e) { User.setPlaying(false); JOptionPane.showMessageDialog(null, e.getMessage(), "Error Connecting",

JOptionPane.ERROR_MESSAGE); } } // If a radio button was pushed update the player's names accordingly for (int i = 0; i < playerLetter.length; i++) { if (evt.getSource() == playerLetter[i]) { for (int j = 0; j < playerNameRight.length; j++) { playerNameRight[j].setText(""); playerNameRight[j].setEditable(false); } playerNameRight[i].setEditable(true); playerNameRight[i].setText("Player " + (i + 2)); } } for (int i = 1; i < playerType.length; i++) { if (evt.getSource() == playerType[i][1]) { playerNameLeft[i].setText(""); playerNameLeft[i].setEditable(false); } if (evt.getSource() == playerType[i][0]) { playerNameLeft[i].setEditable(true); playerNameLeft[i].setText("Player " + (i + 1)); } } } /** * Puts a limit on the number of characters in each text box. */


140

public void keyTyped(KeyEvent evt) { for (JTextField textField : playerNameLeft) {

if (textField == evt.getSource() && textField.getText().length() > 10) {

textField.setText(textField.getText().substring(0, 10));

} } for (JTextField textField : playerNameRight) {

if (textField == evt.getSource() && textField.getText().length() > 10) {

textField.setText(textField.getText().substring(0, 10));

} } if (port1 == evt.getSource() && port1.getText().length() > 5) { port1.setText(port1.getText().substring(0, 5)); } if (port2 == evt.getSource() && port2.getText().length() > 5) { port2.setText(port2.getText().substring(0, 5)); } } public void keyPressed(KeyEvent evt) {} public void keyReleased(KeyEvent evt) {} /** * main function - should not take in any args Loads all the imahes into * memory and then runs the program. * * @param args */ public static void main(String[] args) { Board.initialise(); Train.initialise(); Background loading = new Background(); loading.launchFrame(); loading.playOpeningSequence(); loading.dispose(); MainScreen ms = new MainScreen(); ms.launchFrame(); } } /** * ExitWindow - qwuits the system when the above frame closes. * * @author Richard Walklate * @date 03/05/2007 * @version 1.0

*/ class ExitWindow extends WindowAdapter { /** * When the closes exit the system * * @param e - * the window that caused the function to be called. */ public void windowClosing(WindowEvent e) { System.exit(0); }

}


141

E.2. Server package networking; import java.io.*; import java.net.*; import javax.swing.JOptionPane; import ai.Algorithm; import board.*; import data.*; /** * The Server class controls the actions the server can take when playing a game * of dominos. These actions are the same as the client's, when interacting with * the user, however, a lot of extra behind the scenes work occurs. The server * connects to all the clients. The server also has to distribute all moves to * each client. Communication with the computer players is also handled in this * class. The server communicates with the appropriate computer players, * updating them of moves made and requesting whent they should make moves. * * @author Richard Walklate * @date 03/05/2007 * @version 1.0 * */ public class Server extends User { /* * Connects to the client. */ private ServerSocket serverSocket; /* * When a connection is made, handles the communication with the client. */ private WaitForClientConnections clientConns; /* * Whether the players are humans or not (true represents human). */ private boolean[] human; /* * the names of the players. */ private String[] playerNames; /* * The skill levels of the computer players. */ private final int[] skillLevels;

/* * The numbers of the players which are humans. */ private int[] playerNumbers; /* * The numbers of the players which are computers. */ private int[] computerNumbers; /* * The number of points needed to win a game. */ private final int NO_POINTS; /* * The number of games to play. */ private final int NO_GAMES; /* * The Background object used in the class. */ private Background background; /* * Whose turn it is. */ private int playerGo; /** * Creates a new Server object with the global variables initialised. * * @param port * @param human * @param playerNames * @param skillLevels * @param noPoints * @param noGames * @throws ConnectionException */ public Server(final int port, final boolean[] human, final String[] playerNames, final int[] skillLevels,

final int noPoints, final int noGames) throws ConnectionException {

playing = true; background = null; NO_POINTS = noPoints; NO_GAMES = noGames; playerGo = 1; this.human = human; playerName = playerNames[0]; this.playerNames = playerNames;


142

this.skillLevels = skillLevels; clientConns = new WaitForClientConnections(new Waiting()); clientConns.setHuman(human); if (clientConns.getClientSockets().length != 0) { try { serverSocket = new ServerSocket(port); serverSocket.setSoTimeout(2000); } catch (BindException e) { throw new ConnectionException(

"Failed to create a server socket: " + e.getMessage());

} catch (java.io.IOException ioe) { throw new ConnectionException("IO Exception " + ioe); } } } /** * Runs the program. Called when the thread is started. Listens for the * clients to join the game, then plays the game. */ public void run() { try { if (clientConns.getClientSockets().length != 0) { listen(); new IgnoreOtherConnections().start(); } playGame(); } catch (ConnectionException ce) { if (playing) {

JOptionPane.showMessageDialog(null, ce, "Connection Error", JOptionPane.ERROR_MESSAGE);

} } finally { exitGame(); playing = false; } } /** * Loops while listening for new connections. When a client makes a new * connection a new thread starts to deal with the client. * * @throws ConnectionException */ private void listen() throws ConnectionException { while (clientConns.waitingMoreConnections()) { try { try {

new ServerConnection(serverSocket.accept(), clientConns).start();

} catch (SocketTimeoutException ste) { }

} catch (IOException e) { throw new ConnectionException(

"IO Exception while accepting connection " + e);

} } } /** * Plays the game of dominos. Loops over each round until the match is over. * Asks the server if they wish to play a new match, until they say no, or * until someone leaves the game the loop continues. * * @throws ConnectionException */ private void playGame() throws ConnectionException { clientConns.disposeWaiting(); clientConns.sortClientSockets(); ClientSocket[] cs = clientConns.getClientSockets(); int humanCounter = 0; for (int i = 1; i < human.length; i++) { if (human[i]) { playerNames[i] = cs[humanCounter++].getPlayerName(); } } playerNumbers = new int[humanCounter]; computerNumbers = new int[3 - humanCounter]; humanCounter = 0; int computerCounter = 0; for (int i = 1; i < human.length; i++) { if (human[i]) { playerNumbers[humanCounter++] = i + 1; } if (!human[i]) { computerNumbers[computerCounter++] = i + 1; } } boolean gameOver = false; ScoreBoard.clearGameScores(); while (playing) { background = null; for (int i = 0; i < NO_GAMES; i++) { while (!gameOver) {

gameOver = playRound(cs, i == NO_GAMES - 1 ? true : false);

} gameOver = false; } } try { Thread.sleep(1000); exitGame(); } catch (Exception e) {


143

} } /** * Plays each round against the opponent listening to user input and * updating the clients and computer players about the moves. * * @param cs - * the sockets for the client. * @param finalGame - * true if it is the final game in the match. * @return true if the game is over and false otherwise. * @throws ConnectionException */ private boolean playRound(ClientSocket[] cs, final boolean finalGame) throws ConnectionException { int[][] dominoNos = ManageDominos.getDominos(4); Board.initialise(); Train.initialise(); // In the first round the first player to move is the one with the // double 6 if (background == null) { playerGo = ManageDominos.getPlayerDouble6(dominoNos) + 1; } // Informs the clients whose turn it is, the player's names and their // dominos try { for (int i = 0; i < playerNumbers.length; i++) { ObjectOutputStream oos = cs[i].getOutputStream(); oos.writeObject(playerNames); oos.writeObject(dominoNos[playerNumbers[i] - 1]); oos.writeObject(playerGo); } } catch (java.io.IOException ioe) { throw new ConnectionException("" + ioe); } Algorithm[] computer = new Algorithm[computerNumbers.length]; // Initialises the computer players for (int i = 0; i < computerNumbers.length; i++) { Background temp = new Background(playerNames,

dominoNos[computerNumbers[i] - 1], computerNumbers[i]);

computer[i] = Algorithm.getAlgorithm( skillLevels[computerNumbers[i] - 1], temp, dominoNos[computerNumbers[i] - 1],

computerNumbers[i]); }

// If this is not the first round of the match transfer the previous // information across if (background != null) { MessageLog message = background.getMessageLog(); background.dispose(); background = new Background(this, playerNames, dominoNos[0],

1, message); background.launchFrame(); if (!ScoreBoard.isEmpty()) { new ScoreBoard().launchFrame(); } } // This is the first round, hence set up new the new Background else { background = new Background(this, playerNames, dominoNos[0],

1, new MessageLog()); background.launchFrame(); } try { boolean roundOver = false; boolean noMoves = false; int numberKnocks = 0; LayedDomino layedDomino = null; int counter = -1; String playerName = ""; while (!roundOver) { background.setPlayerGo(playerGo);

// The server's turn, so wait for user input then // distribute the

// move if (playerGo == 1) { background.setTurn(true); waitForDomino(); layedDomino = background.getLastLayed(); roundOver = background.getRoundOver(); counter = -1; playerName = this.playerName; } else { int playerArrayNumber = getPosition(playerGo,

playerNumbers); // Client's turn so wait for the client to play

// then distribute the move if (playerArrayNumber != -1) { ObjectInputStream ois =

cs[playerArrayNumber] .getInputStream(); String clientName = ois.readObject()

.toString(); layedDomino = (LayedDomino)


144

ois.readObject(); roundOver = ((Boolean)

ois.readObject()). booleanValue();

counter = getPosition(playerGo, playerNumbers);

playerName = clientName; } int computerArrayNumber = getPosition(playerGo, computerNumbers); // Computer's turn so ask the algorithm to

// move, then distribute the move if (computerArrayNumber != -1) { try {

Thread.sleep(SetSpeed. currentValue * 100);

} catch (InterruptedException e) { } layedDomino = computer

[computerArrayNumber].layDomino(); roundOver = computer [computerArrayNumber].roundOver();

counter = -1; playerName = playerNames[playerGo - 1]; } if (layedDomino != null) {

background.addNewDomino(layedDomino, playerGo);

} background.setPlayerName(playerName, playerGo); } // Update the MessageLog if (layedDomino == null) { background.getMessageLog().updateData(

playerNames[playerGo - 1] + " knocked", ScoreBoard.getRoundNumber());

numberKnocks++; } else { background.getMessageLog().updateData(

playerNames[playerGo - 1] + " laid " + layedDomino.toBracketString(), ScoreBoard.getRoundNumber());

numberKnocks = 0; } // If four knocks are in a row, then the round is over if (numberKnocks >= 4) { roundOver = true; noMoves = true;

} // Distribute the moves to the others distributeDomino(layedDomino, counter, playerName,

roundOver); for (Algorithm eachComputer : computer) { eachComputer.dominoLaid(layedDomino, playerGo); } playerGo = (playerGo % 4) + 1; } int[] scores = getScores(cs, computer); playerGo = (playerGo - 1); if (playerGo == 0) playerGo = 4; // Update the scores // Draw scores[4] = 0; scores[5] = 0; Object message = "Round over; draw"; // Team A wins int winningTeam = 0; if (!noMoves && playerGo % 2 == 1) { scores[4] = scores[1] + scores[3]; winningTeam = 1; } if (noMoves && scores[0] + scores[2] < scores[1] + scores[3])

{ scores[4] = scores[1] + scores[3] - scores[0] –

scores[2]; winningTeam = 1; } // Team B wins if (!noMoves && playerGo % 2 == 0) { scores[5] = scores[0] + scores[2]; winningTeam = -1; } if (noMoves && scores[1] + scores[3] < scores[0] + scores[2]) { scores[5] = scores[0] + scores[2] - scores[1]

scores[3]; winningTeam = -1; } if (winningTeam == 1) { message = "Round over; won by Team A"; } if (winningTeam == -1) { message = "Round over; won by Team B"; } background.getMessageLog().updateData(message,

ScoreBoard.getRoundNumber());


145

ScoreBoard.addScore(scores); boolean gameOver = ScoreBoard.isGameOver(NO_POINTS); // Inform others whether the game is over for (int i = 0; i < playerNumbers.length; i++) { ObjectOutputStream oos = cs[i].getOutputStream(); oos.writeObject(scores); oos.writeObject(gameOver); } if (gameOver) { new ScoreBoard().launchFrame(); background.nextGame(winningTeam); ScoreBoard.clearScores(); if (finalGame) { background.matchOver(); } for (int i = 0; i < playerNumbers.length; i++) { ObjectOutputStream oos =

cs[i].getOutputStream(); oos.writeObject(playing); } } if (!gameOver) { background.nextRound(winningTeam); } return gameOver; } catch (IOException e) { throw new ConnectionException("Someone may have left the

game"); } catch (ClassNotFoundException e) { throw new ConnectionException("Someone may have left the

game"); } } /** * Distribute the move to the other human players. * * @param lastLayed - * the domino laid. * @param counter - * the player not to distribute it to (the player who laid the * domino). * @param playerName - * the name of the player who laid the domino. * @param roundOver - * whether the round is over. * @throws IOException */ private void distributeDomino(final LayedDomino lastLayed, final int counter, final String playerName, final boolean

roundOver)

throws IOException { ClientSocket[] cs = clientConns.getClientSockets(); for (int i = 0; i < cs.length; i++) { ObjectOutputStream oos = cs[i].getOutputStream(); if (i != counter) { oos.writeObject(playerName); oos.writeObject(lastLayed); } oos.writeObject(roundOver); } } /** * Returns the index of a number in an array. * * @param number * @param array */ private int getPosition(final int number, final int[] array) { for (int i = 0; i < array.length; i++) { if (array[i] == number) return i; } return -1; } /** * Sets up the scores for each player at the end of a round. Requests the * number of dots remaining for each player at the end of the round and * calculates the scores. * * @param cs - * the socket connections to each client. * @param computer - * the computer players involved in the game. * @return the scores of the game in an int array. * @throws IOException * @throws ClassNotFoundException */ private int[] getScores(final ClientSocket[] cs, Algorithm[] computer) throws IOException, ClassNotFoundException { int[] scores = new int[6]; for (int i = 1; i < scores.length + 1; i++) { if (i == 1) { scores[i - 1] = background.getScores(); } int playerArrayNumber = getPosition(i, playerNumbers); if (playerArrayNumber != -1) { ObjectOutputStream oos = cs[playerArrayNumber] .getOutputStream(); oos.writeObject("REQUEST_SCORE"); ObjectInputStream ois = cs[playerArrayNumber]

.getInputStream();


146

scores[i - 1] = ((Integer) ois.readObject()). intValue();

} int computerArrayNumber = getPosition(i, computerNumbers); if (computerArrayNumber != -1) { scores[i - 1] = computer[computerArrayNumber].

getScores(); } } return scores; } /** * If the game is over for some reason then the sockets with the clients are * closed. */ public void exitGame() { for (ClientSocket css : clientConns.getClientSockets()) { if (css != null) { css.closeSocket(); } } if (serverSocket != null && !serverSocket.isClosed()) { try { serverSocket.close(); } catch (IOException e) { } } } /** * While the game is in progress no-one else should be able to connect to * the server. This code will reject all other connections. * * @author Richard Walklate * @date 03/05/2007 * @version 1.0 * */ private class IgnoreOtherConnections extends Thread { /** * The thread listens for all other connections and immediately

* rejects them. This thread begins when the game begins. */ public void run() { while (playing) { try { new ServerConnection(serverSocket.accept(),

clientConns).start(); } catch (SocketTimeoutException ste) { } catch (IOException e) { }

} } }

}


147

E.3. CheckLayedDomino package board; import java.util.ArrayList; /** * Checks to see if a domino can be laid at a certain location on the board. * * @author Richard Walklate * @date 03/05/2007 * @version 1.0 * */ public class CheckLayedDomino { /* * The board being used. */ private Board board; /* * When seeing if a domino can be laid occasionally the A and B values are * swapped. Because they cannot be swapped immediately, as this alters some * results, they need to be swapped at the end. This boolean value keeps * track of whether they need to be swapped. */ private boolean toSwap; /* * If the train becomes joined the round is over and this value becomes * true. */ private boolean roundOver; /** * Constructor sets the appropriate parameters. * * @param board - * the board being used. */ public CheckLayedDomino(final Board board) { this.board = board; toSwap = false; roundOver = false; } /** * Adjusts the position where the mouse has been clicked. This is because * the mouse does not point to the top left hand corner of the domino. * * @param dom

* @param x * @param y * @return - the LayedDomino in the appropriate place. */ public LayedDomino adjustGridDomino(final Domino dom, int x, int y) { int subForVertical = (dom.o == 'v' ? BoardLayout.BOARD_GRID_UNIT :

0); int subForHorizontal = (dom.o == 'h' ? BoardLayout.BOARD_GRID_UNIT :

0); int top = BoardLayout.TOP_DOMINO + subForVertical; int left = BoardLayout.LEFT_DOMINO + subForHorizontal; int arrayX = (x - left) / BoardLayout.BOARD_GRID_UNIT; int arrayY = (y - top) / BoardLayout.BOARD_GRID_UNIT; return getDomino(dom, arrayX, arrayY); } /** * Tests to see if the domino can be laid in the stated location. * * @param dom - * the domino * @param arrayX - * the left most position of the domino. * @param arrayY - * the top most position of the domino. * @return - the LayedDomino in the appropriate location, otherwise null if * the domino cannot be laid. */ public LayedDomino getDomino(final Domino dom, final int arrayX, final int arrayY) { LayedDomino currentDom = new LayedDomino(); currentDom.A = dom.A; currentDom.B = dom.B; currentDom.o = dom.o; currentDom.locXA = arrayX; currentDom.locYA = arrayY; boolean doubleDom = (dom.A == dom.B) ? true : false; boolean horizDom = (dom.o == 'h') ? true : false; if (horizDom) { currentDom.locXB = arrayX + 2; currentDom.locYB = arrayY; currentDom.o = 'h'; } if (!horizDom) { currentDom.locXB = arrayX; currentDom.locYB = arrayY + 2; currentDom.o = 'v';


148

} // If it is the first item in the train, not many checks have to be

// made if (Train.getFirstItem() == null) { currentDom.trainPosition = BoardLayout.DOMINO_START_TRAIN; currentDom.top = arrayY; currentDom.left = arrayX; currentDom.activeSide = BoardLayout.DOMINO_BOTH; if (doubleDom) { currentDom.implementDouble = true; } return currentDom; } // If there is some overlap return null. if (!board.checkForOverlap(currentDom.o, arrayX, arrayY)) { return null; } // If there are inappropriate surrounding dominos, or no correct

// dominos near it return null int res = checkSurroundingDoms(currentDom, arrayX, arrayY,

doubleDom); if (res == BoardLayout.DOMINO_INVALID || res == BoardLayout.DOMINO_UNKNOWN) { return null; } // If the train is linked the round is over if (res == BoardLayout.DOMINO_BOTH) { roundOver = true; } currentDom.left = arrayX; currentDom.top = arrayY; currentDom.activeSide = res; // Sets the position in the train if (currentDom.activeSide == BoardLayout.DOMINO_FIRST) { currentDom.trainPosition = BoardLayout.DOMINO_START_TRAIN; } else { currentDom.trainPosition = BoardLayout.

DOMINO_DONT_START_TRAIN; } return currentDom; } /** * Check the surrounding dominos to see if it is ok to lay the domino. A * value res is used to keep track of whether it is appropriate to lay the * domino. When checking the result is multiplied with res; * - DOMINO_INVALID * (0) - the domino is next to something incorrect, therefore res will be

* multiplied with 0. res will also not change as anything multiplied with 0 * = 0.

* - DOMINO_UNKNOWN (1) - the domino has not been placed next to anything * so far. Therefore this will not change the results. If the final value of * res is 1, then this is not allowed. * - DOMINO_FIRST (2) - the domino is at the start of the train. * - DOMINO_LAST (3) - the domino is at the end of the train. * - DOMINO_BOTH (6) - the domino is at both the start and end of the train. * 6 = 2 * 3. So both the start and end values did match. * * @param currentDom - * the domino to lay. * @param arrayX - * its left most position. * @param arrayY - * its top most position. * @param doubleDom - * if the domino is a double. * @return an integer value saying whether the domino can be laid and if so, * where within the train. */ private int checkSurroundingDoms(LayedDomino currentDom, final int arrayX, final int arrayY, final boolean doubleDom) { toSwap = false; int res = BoardLayout.DOMINO_UNKNOWN; // Check each side of the domino // Vertical domino if (currentDom.o == 'v') { // Top res *= checkSide(currentDom.cloneLayedDomino(), arrayX, arrayY

- 1, true, true, 1); // Top left res *= checkSide(currentDom.cloneLayedDomino(), arrayX - 1,

arrayY, true, false, 3); // Bottom left res *= checkSide(currentDom.cloneLayedDomino(), arrayX - 1, arrayY + 2, false, false, 2); // Top right res *= checkSide(currentDom.cloneLayedDomino(), arrayX + 2,

arrayY, true, false, 3); // Bottom right res *= checkSide(currentDom.cloneLayedDomino(), arrayX + 2, arrayY + 2, false, false, 2); // Bottom res *= checkSide(currentDom.cloneLayedDomino(), arrayX, arrayY

+ 4, false, true, 1); if (doubleDom) { if (res == BoardLayout.DOMINO_UNKNOWN) { currentDom.implementDouble = true; } // Middle left


149

res *= checkSide(currentDom.cloneLayedDomino(), arrayX - 1, arrayY + 1, true, false, 6);

// Middle right res *= checkSide(currentDom.cloneLayedDomino(), arrayX

+ 2, arrayY + 1, true, false, 6); } } // Horizontal domino if (currentDom.o == 'h') { // Left res *= checkSide(currentDom.cloneLayedDomino(), arrayX - 1,

arrayY, true, false, 1); // Top left res *= checkSide(currentDom.cloneLayedDomino(), arrayX, arrayY

- 1, true, true, 3); // Top right res *= checkSide(currentDom.cloneLayedDomino(), arrayX + 2, arrayY - 1, false, true, 2); // Bottom left res *= checkSide(currentDom.cloneLayedDomino(), arrayX, arrayY

+ 2, true, true, 3); // Bottom right res *= checkSide(currentDom.cloneLayedDomino(), arrayX + 2, arrayY + 2, false, true, 2); // Right res *= checkSide(currentDom.cloneLayedDomino(), arrayX + 4,

arrayY, false, false, 1); if (doubleDom) { if (res == BoardLayout.DOMINO_UNKNOWN) { currentDom.implementDouble = true; } // Top middle res *= checkSide(currentDom.cloneLayedDomino(), arrayX

+ 1, arrayY - 1, true, true, 6); // Bottom middle res *= checkSide(currentDom.cloneLayedDomino(), arrayX

+ 1, arrayY + 2, true, true, 6); } } if (toSwap) { currentDom.swapAB(); } return res; } /** * Checks the side of the domino to see if it is ok to on the board. * * @param currentDom - * the domino to lay. * @param arrayX - * the column of the board to check.

* @param arrayY - * the row of the board to check. * @param a - * whether A (true) or B (false) is being checked. * @param incX - * whether to increment arrayX or arrayY. * @param strictness - * how strict to be when checking one side against another domino * (be less strict with doubles). * @return an integer value depending on whether this side of the domino * causes a conflict. */ private int checkSide(final LayedDomino currentDom, final int arrayX, final int arrayY, final boolean a, final boolean incX, final int strictness) { if (arrayX < 0 || arrayY < 0) return BoardLayout.DOMINO_UNKNOWN; int newArrayX = arrayX + (incX ? 1 : 0); int newArrayY = arrayY + (incX ? 0 : 1); // Check to see if the side is on the board if (newArrayX >= BoardLayout.BOARD_GRID_WIDTH || newArrayY >= BoardLayout.BOARD_GRID_HEIGHT) return BoardLayout.DOMINO_UNKNOWN; // Check to see if the side is next to nothing if (board.get(arrayY, arrayX) == 0 && board.get(newArrayY, newArrayX) == 0) return BoardLayout.DOMINO_UNKNOWN; // Check to see if half the side is next to something if (board.get(arrayY, arrayX) != 0 && board.get(newArrayY, newArrayX) == 0) return (strictness % 2 == 0 ? BoardLayout.DOMINO_UNKNOWN : BoardLayout.DOMINO_INVALID); if (board.get(arrayY, arrayX) == 0 && board.get(newArrayY, newArrayX) != 0) return (strictness % 3 == 0 ? 1 : 0); // Check to see if the side is next to 2 different dominos or sides int ptr = board.getPtrValue(arrayX, arrayY); int ptr2 = board.getPtrValue(newArrayX, newArrayY); if (ptr != ptr2) { return BoardLayout.DOMINO_INVALID; } int number = a ? currentDom.A : currentDom.B; // If the domino is next to the first domino if (ptr == board.getFirstDom()) { LayedDomino first = Train.getFirstItem().getFirstNode() .cloneLayedDomino(); if (strictness != 1) { if (first.o == currentDom.o) {


150

return BoardLayout.DOMINO_INVALID; } } if (number == first.A) { if (!a) { currentDom.swapAB(); } else { toSwap = true; } if (checkCorrect(currentDom, first)) { currentDom.swapAB(); return BoardLayout.DOMINO_FIRST; } } return BoardLayout.DOMINO_INVALID; } // If the domino is next to the last domino if (ptr == board.getLastDom()) { LayedDomino last = Train.getFirstItem().getLastNode() .cloneLayedDomino(); if (strictness != 1) { if (last.o == currentDom.o) { return BoardLayout.DOMINO_INVALID; } } if (number == last.B) { if (!a) { toSwap = true; currentDom.swapAB(); } last.swapAB(); if (checkCorrect(currentDom, last)) { return BoardLayout.DOMINO_LAST; } } return BoardLayout.DOMINO_INVALID; } // It is not next to the first or last, therefore it is invalid return BoardLayout.DOMINO_INVALID; } /** * Check to see if the dominos joined onto the correct side. * * @param newDom - * the domino to lay. * @param checkDom - * the first or last domino. * @return true if everything is correct, false otherwise. */ private boolean checkCorrect(final LayedDomino newDom,

final LayedDomino checkDom) { if (newDom.o == checkDom.o) return true; if (!checkDom.implementDouble) { if (!newDom.implementDouble && (checkDom.locXA == newDom.locXA ||

checkDom.locYA == newDom.locYA)) { return true; } if (newDom.implementDouble && (Math.abs(checkDom.locYA - newDom.locYA) ==

1 || Math.abs(checkDom.locXA - newDom.locXA) == 1)) {

return true; } } if (checkDom.implementDouble) { if (Math.abs(newDom.locXA - checkDom.locXA) == 1 || Math.abs(newDom.locYA - checkDom.locYA) ==

1) { return true; } } return false; } /** * For a domino loops over the grid getting all the correct locations to lay * the domino. * * @param domino - * the domino to lay. * @return an ArrayList of places where the domino could be laid. */ public ArrayList<LayedDomino> getLayOptions(final Domino domino) { ArrayList<LayedDomino> layOptions = new ArrayList<LayedDomino>(); int verticalLoss = domino.o == 'v' ? 4 : 2; int horizontalLoss = domino.o == 'h' ? 4 : 2; for (int i = 0; i <= BoardLayout.BOARD_GRID_HEIGHT - verticalLoss;

i++) { for (int j = 0; j <= BoardLayout.BOARD_GRID_WIDTH –

horizontalLoss; j++) { LayedDomino layedDomino = getDomino(domino, j, i); if (layedDomino != null) { layOptions.add(layedDomino); } } } return layOptions; } /** * From one domino gets all the locations it can be laid, for all 4 of its


151

* rotations. * * @param dominos - * the domino to lay * @return an ArrayList of all possible locations the domino can be laid. */ public ArrayList<LayedDomino> getLayableDomino(final Domino dominos) { ArrayList<LayedDomino> layOptions = new ArrayList<LayedDomino>(); Domino domino = dominos.clones(); domino.o = 'h'; layOptions.addAll(getLayOptions(domino)); domino.o = 'v'; layOptions.addAll(getLayOptions(domino)); domino.swapAB(); domino.o = 'h'; layOptions.addAll(getLayOptions(domino)); domino.o = 'v'; layOptions.addAll(getLayOptions(domino)); return layOptions; } /** * For an ArrayList of dominos returns all the possible locations all the * dominos can be laid if they are at any orientation. * * @param dominos - * an ArrayList of dominos. * @return - an ArrayList of all the locations the dominos can be laid. */ public ArrayList<LayedDomino> getLayableDomino( final ArrayList<Domino> dominos) { ArrayList<LayedDomino> layOptions = new ArrayList<LayedDomino>(); for (int i = 0; i < dominos.size(); i++) { layOptions.addAll(getLayableDomino(dominos.get(i))); } return layOptions; } /** * Returns true if the round is over, false otherwise. */ public boolean isRoundOver() { return roundOver; }

}


152

E.4. Algorithm package ai; import java.util.*; import board.*; /** * The Algorithm class is a super class of all the algorithms. This class * contains the common functions that all the algorithms must implement, for * example laying a domino and being updated about a domino being laid. This * also contains common functions about the probabilities of players owning * particular dominos. * * @author Richard Walklate * @date 03/05/2007 * @version 1.0 * */ public abstract class Algorithm { /* * The integer values of the 6 different skill levels. */ public static final int VERY_EASY = 0; public static final int EASY = 1; public static final int MEDIUM = 2; public static final int HARD = 3; public static final int VERY_HARD = 4; public static final int MASTER = 5; /* * The background class used by the algorithm, to help with laying the * dominos. */ protected Background background; /* * The dominos owned by the computer player. */ protected ArrayList<Domino> dominos; /* * HashMaps contain probability players owns a domino. The probabilities can * be calculated in different ways. */

protected HashMap<Integer, Double>[] dominoDistribution; /* * The dominos definitely owned by a player. */ protected ArrayList<Integer>[] dominoOwn; /* * The dominos definitely not owned by a player. */ protected ArrayList<Integer>[] dominoNotOwn; /* * The number of dominos remaining for each opponent. */ protected int[] numberDominosLeft; /* * True if the probabilities are not being updated, false otherwise. */ protected boolean distributionFlag; /* * The number of the player. */ private int playerNo; /* * The number of moves that have been made. */ private int numberTurns; protected boolean roundOver; /** * The constructor initialises each of the global variables with the * appropriate values. * * @param background * @param playerNo */ @SuppressWarnings("unchecked") public Algorithm(final Background background, final int playerNo) { this.background = background; this.playerNo = playerNo; dominos = background.getDominos(); dominoDistribution = new HashMap[4]; dominoNotOwn = new ArrayList[4]; dominoOwn = new ArrayList[4]; numberDominosLeft = new int[] { 7, 7, 7, 7 }; numberTurns = 0; roundOver = false; }


153

/** * Lay a domino. * * @return the domino to lay. */ public abstract LayedDomino layDomino(); /** * Return the ordering class for the algorithm. */ public abstract OrderDominos getOrderDominos(); /** * Inform the algorithm that a domino has been laid. * * @param domino - * the domino that has been laid. * @param playerNo - * the player who laid the domino. */ public abstract void dominoLaid(final LayedDomino domino, final int

playerNo); /** * In the grumpy algorithms, the weighting of how much to attack the left * player by. * * @param increaseLeft - * double value of how much to attack left by; 1 means no * preference, less than 1 attacks right more, more than 1 * attacks left more. */ public void setIncreaseLeft(final double increaseLeft) { } /** * Returns a domino with the position being at the center of the board. This * allows for the game to go on for longer, as the dominos are not squashed * against the side. * * @param domino - * the domino to lay. * @return a LayedDomino in the correct location. */ protected LayedDomino getCentrePosition(final Domino domino) { LayedDomino layableDoms = new LayedDomino(); layableDoms.A = domino.A; layableDoms.B = domino.B; layableDoms.o = 'v'; layableDoms.locXA = 20; layableDoms.locYA = 15; layableDoms.locXB = layableDoms.locXA;

layableDoms.locYB = layableDoms.locYA + 2; layableDoms.top = layableDoms.locYA; layableDoms.left = layableDoms.locXA; layableDoms.trainPosition = BoardLayout.DOMINO_START_TRAIN; layableDoms.activeSide = BoardLayout.DOMINO_BOTH; if (layableDoms.A == layableDoms.B) { layableDoms.implementDouble = true; } return layableDoms; } /** * Given an ordering of dominos, returns the best option. This is based upon * what dominos can be laid. * * @param orderDominos - * the class that orders the dominos. * @return a LayedDomino in a correct location based upon the ordering in * the class pased in. If no domino can be laid null is returned. */ protected LayedDomino getLayOption(final OrderDominos orderDominos) { // Wait for the ordering to finish while (!orderDominos.isReadyFlag()) { try { Thread.sleep(20); } catch (InterruptedException e) { } } // If the domino is the first in the train, lay it in the center, as

// any domino can be laid if (Train.getFirstItem() == null) { LayedDomino layableDoms = getCentrePosition(dominos .get(orderDominos.getDominoOrder()[0])); dominos.remove(orderDominos.getDominoOrder()[0]); return layableDoms; } // If the domino is not the first in the train, choose the highest

// one in the list and lay it wherever possible for (int dominoOrder : orderDominos.getDominoOrder()) { ArrayList<LayedDomino> layableDominos = background .getLayableDomino(dominos.get(dominoOrder)); if (layableDominos.size() > 0) { LayedDomino layableDom = layableDominos.get(0); if (layableDom != null) { dominos.remove(dominoOrder); if (layableDom.activeSide == BoardLayout.

DOMINO_BOTH) { roundOver = true; } return layableDom;


154

} } } return null; } /** * Similar to the getLayOption(Domino ) function except this function takes * orientation into consideration, as there is a difference between laying * domino [A, B] than laying domino [B, A] depending upon whether A or B * joins onto the train. * * @param orderDominos - * the class which orders the dominos. * @return a LayedDomino object in a correct location, or null if no domino * can be laid. */ protected LayedDomino getLayOptionOrientation( final OrderDominos orderDominos) { // Wait for the ordering function to finish while (!orderDominos.isReadyFlag()) { try { Thread.sleep(20); } catch (InterruptedException e) { } } // If the domino is the first item in the train lay it in the central // position if (Train.getFirstItem() == null) { LayedDomino layableDoms = getCentrePosition(dominos .get(orderDominos.getDominoOrder()[0] %

dominos.size())); dominos.remove(orderDominos.getDominoOrder()[0] %

dominos.size()); return layableDoms; } // If the domino is not the first item in the train find the most // appropriate location to lay it for (int dominoOrder : orderDominos.getDominoOrder()) { boolean aHidden = dominoOrder < dominos.size(); int adjustedDominoOrder = dominoOrder % dominos.size(); ArrayList<LayedDomino> layableDominos = background .getLayableDomino(dominos.get(adjustedDominoOrder)); for (LayedDomino layableDom : layableDominos) { if ((dominos.get(adjustedDominoOrder).A ==

layableDom.A && ((aHidden && !layableDom.trainPosition) || (!aHidden && layableDom.trainPosition)))

|| (dominos.get(adjustedDominoOrder).A == layableDom.B

&& ((aHidden && layableDom.trainPosition) || (!aHidden && !layableDom.trainPosition)))) {

dominos.remove(adjustedDominoOrder); if (layableDom.activeSide ==

BoardLayout.DOMINO_BOTH) { roundOver = true; } return layableDom; } } } return null; } /** * If an opponent has laid a domino deduct one from the number of dominos * they own. * * @param playerNo */ protected void updateDistributionLay(final int playerNo) { numberDominosLeft[playerNo - 1]--; } /** * When a move has been made increase the total number of turns. */ protected void updateNumberTurns() { numberTurns++; } /** * Get the total number of rotations (4 moves) that have occurred. * * @return numberTurns / 4, add 1 because the first rotation should be 1 not * 0. */ protected int getRotationNumber() { return (numberTurns / 4) + 1; } /** * Updates the ArrayList of definitely owned and not owned dominos. There * are two ways that a domino can be added to the definitely owned list. The * first is if players X, Y and Z definitely do not own the domino, then it * must be owned by player W. The second way is if player W owns n dominos, * player W definitely does not own m dominos, there are d dominos in total, * if n = d - m, then player W must own all these dominos. These dominos are * added to player W's own list and also added to all other players' not own * list. */ protected void updateDefinites() {


155

// If 3 players definitely do not own a domino, the other player must // own it for (int i = 0; i < dominoNotOwn.length; i++) { for (Integer notOwn : dominoNotOwn[i]) { int notOwnCounter = 0; int playerNotToOwn = 0; for (int j = 0; j < dominoNotOwn.length; j++) { // This is already in someone's own list, so do

// not add it again if (dominoOwn[j].contains(notOwn)) { notOwnCounter = 0; break; } if (dominoNotOwn[j].contains(notOwn)) { notOwnCounter++; } else { playerNotToOwn = j; } } if (notOwnCounter == 3) { dominoOwn[playerNotToOwn].add(notOwn); dominoDistribution[playerNotToOwn].put(notOwn,

1.0); } } } // If a player can only own n dominos and they own n dominos then

// they must own all of these dominos for (int i = 0; i < dominoNotOwn.length; i++) { if (dominoDistribution[i].size() - dominoNotOwn[i].size() ==

numberDominosLeft[i]) { for (Integer eachIntDomino : dominoDistribution[i].

keySet()) { if (!dominoNotOwn[i].contains(eachIntDomino) &&

!dominoOwn[i].contains(eachIntDomino)) { for (int j = 0; j < dominoOwn.length;

j++) { if (j == i) { dominoOwn[j].

add(eachIntDomino); dominoDistribution[j]. put(eachIntDomino, 1.0);

} else if (!dominoNotOwn[j]. contains(eachIntDomino)) {

dominoNotOwn[j]. add(eachIntDomino);

dominoDistribution[j]. put(eachIntDomino, 0.0);

} }

} } } } } /** * Initiate the probabilities HashMaps so that all dominos being owned have * probability 0. Alter the probabilities based upon the dominos owned by * the player. Update the own and not own lists. * * @param ownedDominos - * the dominos owned by the player. */ protected void initiateDistribution(final int[] ownedDominos) { dominoNotOwn[playerNo - 1] = new ArrayList<Integer>(); dominoOwn[playerNo - 1] = new ArrayList<Integer>(); dominoDistribution[playerNo - 1] = new HashMap<Integer, Double>(28); for (int i = 0; i < 28; i++) { dominoDistribution[playerNo - 1].put(i, 0.0); dominoNotOwn[playerNo - 1].add(i); } for (int ownedDomino : ownedDominos) { dominoOwn[playerNo - 1].add(ownedDomino); dominoNotOwn[playerNo - 1].remove((Integer) ownedDomino); dominoDistribution[playerNo - 1].put(ownedDomino, 1.0); } for (int i = 0; i < dominoNotOwn.length; i++) { if (i != playerNo - 1) { dominoNotOwn[i] = new ArrayList<Integer>(); dominoOwn[i] = new ArrayList<Integer>(); dominoDistribution[i] = new HashMap<Integer,

Double>(28); for (int ownedDomino : ownedDominos) { dominoNotOwn[i].add(ownedDomino); } for (int j = 0; j < 28; j++) { dominoDistribution[i].put(j, 0.0); } } } } /** * Returns true if the round is over and false otherwise. */ public boolean roundOver() { return ((dominos.size() == 0 ? true : false) || roundOver); }


156

/** * Returns the score of the player. * * @return the total number of dots owned by the player. */ public int getScores() { return background.getScores(); } /** * Returns the distribution flag, this says whether the algorithm has * finished executing. */ protected boolean isDistributionFlag() { return distributionFlag; } /** * Returns the probabilities that a player owns a certain domino. * * @return an array of HashMaps of the probabilities. */ protected HashMap<Integer, Double>[] getDominoDistribution() { return dominoDistribution; } /** * Returns the player number. */ protected int getPlayerNo() { return playerNo; } /** * Returns the number of dominos left for each opponent. */ protected int[] getNumberDominosLeft() { return numberDominosLeft; } /** * Given a skill level, a background, dominos and a player number creates * the appropriate skill level algorithm. * * @param intAlgorithm - * the skill level of the algorithm. * @param background - * a Background class, containing the player names, player number * and dominos owned. * @param intDominos - * the dominos owned by the player. * @param playerNo -

* the number of the player. * @return an instance of the appropriate algorithm. */ public static final Algorithm getAlgorithm(final int intAlgorithm, final Background background, final int[] intDominos, final int playerNo) { switch (intAlgorithm) { case VERY_EASY: return new FriendlyIIAlgorithm(background, intDominos,

playerNo); case EASY: return new TrivialAlgorithm(background, playerNo); case MEDIUM: return new ConservativeAlgorithm(background, playerNo); case HARD: return new FriendlyLCAlgorithm(background, intDominos,

playerNo); case VERY_HARD: return new GrumpyIIAlgorithm(background, intDominos, playerNo, GrumpyIIAlgorithm.ATTACK_BOTH, 1.1); case MASTER: return new MergeDGCAlgorithm(background, intDominos, playerNo, DominoSimulator.GRUMPYII_BOTH2); } // Default choice return new ConservativeAlgorithm(background, playerNo); }

}


157

E.5. MergeDGCAlgorithm package ai; import java.util.HashMap; import board.*; /** * This algorithm merges a grumpy algorithm, a diverse algorithm and a * conservative algorithm. The merging of the diverse and conservative * algorithms occur using similar standards as the MergeDC algorithm. The grumpy * algorithm's value increases when more information about the game is * discovered and the opponents are more likely to win. * * The following algorithm is used; * * PA = 1 - (DA / (DA + DB)) * * P1 = 1 - (D1 / (D1 + D2)) * * I = ln(R + 1) / ln(29) * * Vi = D * Di * ((PA + P1) / 2) + Ci * (1 - PA) + G * Gi * (((1 - PA) + I) / 2) * * Where; * * DA / DB is the number of dominos owned by team A or team B respectively * * D1 / D2 is the number of dominos owned by the current player, or their team * mate respectively * * R is the number of rotations * * PA is the probability of team A winning rather than team B * * P1 is the probability of player 1 winning rather than player 2 (their team * mate) * * I is the amount of information * * Di is the value assigned to domino i by the Diversity algorithm * * Ci is the value assigned to domino i by the Conservative algorithm * * D is the scale factor to increase the Diversity algorithm's value by * * G is the scale factor to increase the Grumpy algorithm's value by * * Vi is the value assigned to the domino * * @author Richard Walklate * @date 03/05/2007

* @version 1.0 * */ public class MergeDGCAlgorithm extends Algorithm { private static final double DIVERSITY_BETTER = 3.0; private static final double GRUMPY_BETTER = 3.3; private MergeDGCOrder orderDominos; private HashMap<Integer, Algorithm> algorithms; private int grumpyAlgorithm; public MergeDGCAlgorithm(final Background background, final int[] intDominos, final int playerNo, final int grumpyAlgorithm) { super(background, playerNo); algorithms = new HashMap<Integer, Algorithm>(); algorithms.put(DominoSimulator.CONSERVATIVE, new

ConservativeAlgorithm(background, playerNo)); algorithms.put(DominoSimulator.DIVERSITYII, new DiversityIIAlgorithm( background, playerNo)); switch (grumpyAlgorithm) { case DominoSimulator.GRUMPYII_BOTH2: algorithms.put(grumpyAlgorithm, new

GrumpyIIAlgorithm(background, intDominos, playerNo, GrumpyIIAlgorithm.ATTACK_BOTH, 1.1)); break; case DominoSimulator.GRUMPY_BOTH: algorithms.put(grumpyAlgorithm, new

GrumpyAlgorithm(background, intDominos, playerNo, GrumpyAlgorithm.ATTACK_BOTH, 1.0));

break; } this.grumpyAlgorithm = grumpyAlgorithm; orderDominos = new MergeDGCOrder(); } @Override public void dominoLaid(LayedDomino domino, int playerNo) { if (domino != null) { updateDistributionLay(playerNo); } updateNumberTurns(); algorithms.get(grumpyAlgorithm).dominoLaid(domino, playerNo); } @Override public LayedDomino layDomino() { algorithms.get(DominoSimulator.CONSERVATIVE).getOrderDominos().run();


158

algorithms.get(DominoSimulator.DIVERSITYII).getOrderDominos().run(); algorithms.get(grumpyAlgorithm).getOrderDominos().run(); orderDominos.run(); LayedDomino option = getLayOptionOrientation(orderDominos); return option; } private class MergeDGCOrder extends OrderDominos { private void quicksort(double[] values) { quicksort(values, 0, values.length - 1); } private void quicksort(double[] a, int left, int right) { if (right <= left) return; int i = partition(a, left, right); quicksort(a, left, i - 1); quicksort(a, i + 1, right); } private int partition(double[] a, int left, int right) { int i = left - 1; int j = right; while (true) { while (a[++i] > a[right]) ; while (a[right] > a[--j]) if (j == left) break; if (i >= j) break; exch(a, i, j); } exch(a, i, right); return i; } private void exch(double[] a, int x, int y) { double swap = a[x]; a[x] = a[y]; a[y] = swap; int swapInt = dominoOrder[x]; dominoOrder[x] = dominoOrder[y]; dominoOrder[y] = swapInt; } protected void orderDominos() { double teamProbability =

getTeamProbability(getNumberDominosLeft(), getPlayerNo()); double selfProbability =

getSelfProbability(getNumberDominosLeft(),

getPlayerNo()); double gameStatus = getGameStatus(getRotationNumber()); double averageTeamSelf = (teamProbability + selfProbability) /

2.0; double averageGSTeamLoss = ((1.0 - teamProbability) +

gameStatus) / 2.0; double[] values = new double[dominos.size() * 2]; double[][] otherValues = new double[algorithms.size()][dominos .size() * 2]; for (int i = 0; i < algorithms.get(DominoSimulator.

CONSERVATIVE).getOrderDominos().getValue().length; i++) {

otherValues[0][i] = algorithms .get(DominoSimulator.CONSERVATIVE).getOrderDominos() .getValue()[i]; otherValues[0][i + dominos.size()] =

otherValues[0][i]; } otherValues[1] = algorithms.get(DominoSimulator.DIVERSITYII) .getOrderDominos().getValue(); otherValues[2] = algorithms.get(grumpyAlgorithm).

getOrderDominos().getValue(); for (int i = 0; i < values.length; i++) { values[i] = otherValues[0][i] * (1 - teamProbability); values[i] += otherValues[1][i] * averageTeamSelf * DIVERSITY_BETTER; values[i] += otherValues[2][i] * averageGSTeamLoss * GRUMPY_BETTER; } quicksort(values); } private boolean isReady() { for (Algorithm algs : algorithms.values()) { if (!algs.getOrderDominos().isReadyFlag()) { return false; } } return true; } public void run() { readyFlag = false; while (!isReady()) { try { Thread.sleep(20); } catch (InterruptedException e) { } } resetDominoOrder(dominos.size() * 2); orderDominos(); readyFlag = true; }


159

} @Override public OrderDominos getOrderDominos() { return orderDominos; }

}


160

F HELP SCREENS

The help screens used within the product are displayed in this section. The help screens have been copied and pasted into the document, therefore the layout may differ slightly to the screens viewed in the product.

F.1. Main Screen Help

Main Screen Help

1. How to play a game involving only computer players 2. How to play a game involving human players a. Initiating a game (the server side) b. Joining a game (the client side) 3. Common errors a. You can only play 1 game at a time, are you sure you want to exit your current game? b. For input string: "word" c. Failed to create a server socket: Address already in use: JVM_Bind

1. How to play a game involving only computer players

The instructions below describe a way of initialising a game involving only computer players. Figure 1 shows an example of this;

1. Make sure the Initiate Game tab is selected. 2. Make sure all 3 of the computer player buttons are selected. 3. The third player is your team mate, the second and fourth players are in the opposing

team. 4. Select difficulty levels for the computer players. If a difficulty level is not set then

the computer shall play as a Medium difficulty level. 5. If you wish; enter names for the players. 6. Enter the number of points for a team to win a game. 7. Enter the number of games you wish to play. 8. The Port option can be ignored 9. Click the Initiate Game button at the bottom of the screen.


161

10. If all is well you should see a Dominos board like the one shown in figure 2. If an error is displayed see the error handling section.

Figure 1. Initialising a game involving computer players.

Figure 2. The dominos game.

Back To Top


162

2. How to play a game involving human players

When playing a game which involves other humans, one player must be a 'server', the other players must all be 'clients'. The role of the server is to initialise the game. The clients then join the game. Whilst playing, the server and client are considered equal. Before playing the game decide who shall be a server and then follow the appropriate instructions below.

Back To Top

2a. Initiating a game (the server side)

The instructions below describe a way of initialising a game involving two human players. Figure 3 shows an example of this:

1. Make sure the Initiate Game tab is selected. 2. Select the appropriate buttons depending upon how many people are playing and how many computer players are playing. The first

and third players are on one team, the second and fourth players are on the opposing team. Figure 3 shows the server playing with a human against a team consisting of a computer and a human.

3. Select the difficulty level of the computer players. If a difficulty level is not selected then the computer's difficulty level is set to Medium.

4. If you wish; enter names for yourself and any computer players. 5. Enter the number of points for a team to win a game. 6. Enter the number of games you wish to play. 7. Click the Inititate Game button at the bottom of the screen. You should see a Window which says Waiting... and telling you the

status of the other players. An example of this window is displayed in figure 4. 8. Tell the other clients your IP address. If you are connecting with someone on the same network the IP address can be found by going

to the Start menu in Windows, going to Run, typing cmd and pressing OK. This will bring up a black box. Type ipconfig and press return. The IP address should be displayed. If you are connecting to someone on a different network the IP address can be found at http://whatismyip.com. Tell the other clients what port you are on which is displayed in the box on the screen. Your IP address should be a 4 numbers between 0 and 255 separated by a '.'. Your port should be a number between 1024 and 65535, its default value is 4444.

9. If an error is displayed see the error handling section.


163

Figure 3. Initialising a game with human players.

Figure 4. Waiting for clients to join.

Back To Top

2b. Joining a game (the client side)

The instructions below describe a way of joining a game. Figure 6 shows an example of this:


164

1. Select the Join Game tab. 2. Wait for the server to initiate the game as detailed in section 2a. 3. Ask the server for their IP address and port number. Enter this information in the

appropriate boxes. 4. Select the appropriate button depending upon which player you are and, if you wish,

enter a name. 5. Click the Join Game button. If all is successful you should either see a dominos

board (like the one displayed in figure 7), or a Waiting... screen (displayed in figure 5) informing you of the current progress of who has joined the game.

6. If an error is displayed see the error handling section.

Figure 5. One client has joined, one client is yet to join.


165

Figure 6. Joining a game as player 3.

Figure 7. The dominos game.

Back To Top

Common Errors

The following shows a list of common errors and hopefully potential solutions, that can occur when trying to set up the game.

Back To Top


166

3a. You can only play 1 game at a time, are you sure you want to exit your current game?

You are only allowed to play one game at once. Therefore if you try to start a new game the old one will become end. The way to play more than 1 game at once is to load up another copy of the application.

Back To Top

3b. For input string: "word”

You have most likely entered an incorrect value into the Points to Win Game, Number of Games or Port entry boxes. The word represents the incorrect word that you have entered. Remember, these boxes must only contain decimal numbers.

Back To Top

3a. Failed to create a server socket: Address already in use: JVM_Bind

This is most likely due to a port not being closed. This has a simple solution. If you are a server try entering a different port in the Port box (eg: 4445). If you are playing with other humans remember to tell them about this change. This is shown in figure 8.


167

Figure 8. The port has been changed to 4445.

Back To Top


168

F.2. About Dominos

Domino Rules

1. Game Set Up 2. Rounds 3. Laying Dominos

1. Game Set Up

• Dominos is played with 4 people, 2 teams of 2. The players are situated around a table so that each player faces their team mate. • The domino board is a rectangular grid, players can only lay dominos within that grid. • Each domino is made up of 2 parts. Each part contains a certain number of spots (from 0 to 6 inclusively). All combinations of dominos are available (28 in total).

A domino is twice as long as it is wide. • A dominos game consists of a number of rounds. After each round points are won by teams. The game ends when a total number of points (normally 100) are won

by a team.

Back To Top

2. Rounds

• At the start of each round the dominos are shuffled, and then distributed evenly to each player. Shuffling can be done by placing each domino face down and mixing up the dominos. One player can then deal the dominos to each player until there are no more remaining. The main points here are that the dominos are distributed randomly and each player can only see their own dominos.

• Each player then arranges their dominos so they can see them. Normally by placing them on their side so the back faces towards the other players. • A start player identified. This is the person with the double-6 domino in the first round. In other rounds it is the person who laid the final domino in the previous

round. • In the round the order of play goes in a circular clockwise fashion. The dominos laid form a train where a player can add a domino to either the start or to the end

of the train. On a player’s turn, if they can, they must add a domino to the train. • There are many ways of laying a domino onto the end of a train which are described in the laying dominos section. Only if a player is unable to lay, then they

‘knock’ which means pass the go onto the next player.


169

• If someone runs out of dominos then the round is over. The team containing the player who ran out of dominos is the winner. The losing team counts the total number of spots they have on their remaining dominos (their dominos that have not been laid). This score is added to the winning team’s score.

• If there are 4 knocks in a row, implying no-one can move then the round is over. Both teams count the number of dots they have on their remaining dominos, the face up dominos. The winning team is the team with the fewest dots. The winning team gains the difference in the number of dots remaining. In the case of a draw no-one wins any points and the round is replayed (except the start player may alter accordingly).

• If someone manages to lay a domino which makes the chain cyclic (they lay a domino which joins both ends of the train), then that team wins the round. The losing team counts the number of dots they have left and that value is added to the winning team’s score. This situation is known as fish.

Back To Top

3. Laying Dominos

1. A domino can be laid either horizontally or vertically. The same rules apply in either case only the orientation changes. Over the next few points laying a vertical domino shall be assumed.

2. A domino can be placed above/below another vertical domino. 3. The orientation of the domino can be changed. This is done by either placing a vertical to the right/left of a horizontal domino, or placing it just above or below

either end of a horizontal or vertical domino. 4. When laying double dominos (dominos with the same number of spots in both segments) the rules are slightly different. A double domino can be placed vertically

to the left/right of a horizontal domino. The domino can be placed so that its vertical middle aligns with the vertical middle of the laid domino (see the diagrams below to get a better understanding of this). If this is done then the domino is said to implement double. If a double domino is laid on the first move then it also implements double.

5. When laying a domino next to a domino that implements double rule 3 is no longer valid. However, now a vertical domino can be laid just below, or above the centre of the horizontally laid domino.

6. No domino can be laid if it overlaps, or is adjacent to any other domino. All dominos must remain on the board. 7. The train can become cyclic; if a domino is laid which connects the first and last dominos then this is known as a fish.

The above 7 rules may seem confusing and are tricky to explain, so the following diagrams give examples of the rules (the pink outlines show where the domino can be laid):


170

Figure 1. Example of rule 2.

Figure 1 shows an example of rule 2. A vertical domino can be placed below another. Figure 2 shows an example of rule 3 being applied to laying a horizontal domino. If the domino was rotated by 180? then it could be placed to the left of the [0, 6] domino.


Figure 3. Example of rules 3 and 4.

Figure 3 shows an example of rules 3 and 4. There are 5 potential areas to lay the domino. 4 of the positions are due to rule 3 and are the same as the above right diagram. The one new position is because the domino [0, 0] can be laid to the right of [0, 6]. The centre of the domino [0, 0] can align with the centre of domino [0, 6], resulting in figure 4. The [0, 0] domino is said to implement double in this case.



171


Figure 5 shows an example of rule 2 when laying next to a domino that implements double. This is no different to normal.

Figure 6 shows an example of rule 5 and how it is different to rule 3. This is because there is a new place that the domino can be laid, if it is being laid next to a domino that implements double. The domino [0, 2] can only be laid in 1 place now as shown in the image.





172


These images all show examples of rule 6. The red outlines show where dominos can not be laid. Figure 7 shows how dominos cannot overlap as domino [1, 5] cannot overlap with domino [0, 6], therefore it cannot be placed beneath [1, 2]. Figure 8 shows that although domino [1, 5] will not overlap with any dominos if it is placed beneath [1, 3], it will be adjacent to domino [4, 6]. This means it cannot be placed beneath [1, 3]. Figure 9 shows that the dominos must remain on the board. As domino [0, 5] is near the edge, the options are limited for domino [4, 5] as it cannot be placed to the left of [0, 5].


Figure 10 shows an example of rule 7. It displays the two places in which the domino [0, 2] can be placed. The top left one shows how the train can become linked. Figure 11 shows the result of this.

Figure 11. Example of rule 7; fish.

Back To Top


173

F.3. Help Dominos Game

How to use the Interface

This help screen gives an overview of using the interface. For the specific rules of playing dominos see the about dominos section.

1. The basics of using the system 2. Changing the configurations of the game.


174

1. The basics of using the system

Figure 1. The important features of the dominos board.

1. The dominos you currently own. To select a domino left click the one you want, then move the mouse over the board. Alternatively, hold ALT and press i to select your ith domino (so ALT+2 will select domino [1, 3] in figure 1).

2. The domino you are currently holding. To rotate the domino either right click, or hold shift and left click, or rotate the mouse wheel, or press ALT+R. To lay a domino on the board left click in the appropriate place.

3. The orange rectangles show where the domino you are holding can be laid. 4. The train of dominos. Dominos can only be added to the start and end of the train. 5. The green area is the board where the dominos are laid.


175

6. The knock buttons. When you are unable to lay a domino on your turn, click one of these buttons. 7. The name of the player who's turn it is. You may only lay dominos on your turn. 8. The highlighted area of the board illustrates whos turn it is. 9. The player at the top of the screen is your team mate. The green (the colour may vary depending upon the position) dominos shows how many dominos they have

left. 10. The players on the left and right sides of the screen are your opponents. The blue and yellow (the colours may vary depending upon positions) dominos shows

how many dominos they have left. 11. Basic instructions of how to pick up, rotate and lay the dominos. 12. The menu bar allowing you to change certain configurations about the game. These configuations are listed in section 3; Changing the configurations of the game.

Back To Top

2. Changing the configurations of the game.

Menu Item Sub-Menu Item Definition

File (ALT+F) Exit Game Quits the current game

Options (ALT+T)

Message Log (ALT+M) Displays the message log which dynamically displays a record of previous moves.

Knock (ALT+K) Knocks, implying that you ae unable to move on your turn.

Change Name (ALT+N) Allows you to change your name. The change will take effect on other player's screens after your next move.

Display Options (ALT+O)

If this option is selected you will see orange rectangles showing you where you can lay your next domino. Deselect this option if you do not wish to see these rectangles.

Colour Dominos (ALT+C)

If this option is selected it colours each players' dominos depending upon their position. This can give a better indication as to which player who has laid each domino.

View Scores (ALT+S)

View the current scores of the game. The score screen contains 2 tabs:

• The first tab is for the scores of the current game, it contains 7 columns; o Column 1 shows the round number. o Columns 2-5 show how many dots each player finished the round with. o Columns 6-7 shows each team's current score.

• The second tab shows the overall scores in the match. It shows the current scores in games and the final scores in each


176

game.

Change Speed (ALT+P) This option will alter the time it takes for each computer player to lay their domino to the nearest second. The default time is 1 second.

Help (ALT+H) About Dominos (ALT+A)

Informs the reader about the rules of dominos.

Dominos Game Help (ALT+D)

The current screen. Gives the reader an insight into how to use the system.

Information (ALT+I) Information about the product.

Back To Top


177

F.4. Product Information

Product Information

Dominos Application


178

Project Name Applying Suitable AI Techniques to a Game of Dominos

Created By Richard Walklate

Project Supervisor Professor Nicoli Vorobjov

Date Created October 2006 - May 2007

Version Number 1.0


179

BIBLIOGRAPHY 1. Armanino, D., C., 1998. A Little About the History of Dominoes. Available from

http://www.worlddomino.com/history.htm. [Accessed on 17 March 2007]. 2. Tidwell, K., 2000. Dominoes. Available from

http://www.gamecabinet.com/rules/DominoIntro.html. [Accessed on 17 March 2007]. 3. Masters, J., 1997. The Online Guide to Traditional Games. Available from

http://www.tradgames.org.uk/games/Dominoes.htm. [Accessed on 17 March 2007]. 4. SoYouWanna, 2007. SoYouWanna Learn To Play Mah-Jong. Available from

http://www.soyouwanna.com/site/syws/mahjong/mahjong3.html. [Accessed on 17 March 2007].

5. McGowan, M., 2002. Fact Families!. Available from http://www.mrsmcgowan.com/math/factfamilies.htm. [Accessed on 17 March 2007].

6. Reuters, 2006. Millions of Dominoes Fall. Available at http://today.reuters.com/tv/videoChannel.aspx?storyId=d3d5306c7ac6ceafd8d3b73e95602d33bafda935. [Accessed on 17 March 2007].

7. Tidwell, K., 2000. Domino Games. Available from http://www.gamecabinet.com/rules/DominoGames.html. [Accessed on 17 March 2007].

8. Masters Games, 1999. Rules for Dominoes. Available from http://www.mastersgames.com/rules/dominoes-rules.htm. [Accessed on 17 March 2007].

9. AngelFire, 2004. Dominoes 42 Texas Style Events and Tournament Winners. Available from http://www.angelfire.com/tx5/dom42texasstyleclub/2.html. [Accessed on 17 March 2007].

10. Domino-Games, 2007. Domino Clubs, Organizations, & Events. Available from http://www.domino-games.com/domino-clubs.html. [Accessed on 17 March 2007].

11. PageManager, 2007. World Championship Domino Tournament. Available from http://www.worlddomino.com/. [Accessed on 17 March 2007].

12. Tidwell, J., 2005. Designing Interfaces. O’Reilly. 13. Noyes, J., Baber, C., 1999. User-Centred Design of Systems. Kent: Gray Publishing. 14. Faulkner, C., 1998. The Essence of Human-Computer Interaction. Herfordshire: Prentice

Hall Europe. 15. UPA Minnesota, 2001. User Interface Design. Available from

http://www.upamn.org/news/2001/hfi_ui_design_aug_01.shtml [Accessed 5 December 2006].

16. Marcus, A., Gould, E., 2000. Cultural Dimensions and Global Web User-Interface Design: What? So What? Now What? Available from http://www.amanda.com/resources/hfweb2000/hfweb00.marcus.html [Accessed 5 December 2006].

17. Harbour, J., S., 2004. Game Programming All In One. 2nd ed. Stacy L. Hiquet. 18. McCain, R., A., 2004. Game Theory. Ohio, USA. Swlearning. 19. Friedman, D., 1998. Hard Problems: Game Theory, Strategic Behaviour, and Oligopoly.

South-Western Publishing Company. Available from http://www.daviddfriedman.com/Academic/Price_Theory/PThy_Chapter_11/PThy_Chapter_11.html [Accessed 5 December 2006].

20. Michie, D., 1988. Artificial Intelligence. A Knowledge-Based Approach. PWS Kent. Kent, UK.

21. Copeland, J., 1994. Artificial Intelligence. A Philosophical Introduction. Blackwell Publishers. Oxford, UK.

22. Campbell, M., 1999. Knowledge Discovery In Deep Blue. New York, USA. ACM Press. Available from http://delivery.acm.org/10.1145/320000/319396/p65-campbell.pdf?key1=319396&key2=6862593611&coll=GUIDE&dl=GUIDE&CFID=4872292&CFTOKEN=63362556 [Accessed 5 December 2006].

23. Levy, D., N., L., 1987. Computer Games I/II. New York, USA. Springer-Verlag. 24. Horizon, AI., 2005. Introduction to the Problems of Go AI Programming. Available from

http://www.aihorizon.com/essays/goai/intro.htm [Accessed 5 December 2006].


180

25. Steele, G., 2006. The Psychology of Poker. Available from http://www.professional-poker.com/strategy/generic/psychology-poker.htm [Accessed 5 December 2006].

26. Bochan, T., Top 10 Poker Tips to Make You a Better Player & Improve Your Poker Game. Available from http://poker.about.com/od/strategyadvice/tp/tipspokerskill.htm [Accessed 5 December 2006].

27. Wooldridge, M., 2002. An Introduction to MultiAgent Systems. John Wiley and Sons. 28. Padget, J., De Vos, M., Caulfield, T., Intelligent Agents : CM30174. Available from

http://moodle.bath.ac.uk/moodle5/course/view.php?id=400 [Accessed 5 December 2006]. 29. Checkers.WS, Dominoes Online. Available from

http://www.checkers.ws/board_games/dominoes_game/dominoes_online.htm [Accessed 14 March 2007].

30. Aleksei Taranov, 2005, Domino Ace 1.0. Available from http://www.altarsoft.com/domino_ace.shtml [Accessed 14 March 2007].

31. Big Fish Games, 2007, Ultimate Dominos. Available from http://www.bigfishgames.com/mac/ultimatedominoes/index.html [Accessed 14 March 2007].

32. Arthur Crump, 2006, Shark Dominoes. Available from http://www.soft32.com/download_1603.html [Accessed 14 March 2007].

33. Ian Sommerville, 2001, Software Engineering. Edition 6. Essex: Pearson Education Limited.

Documents

Applying Suitable Artifical Intelligence Techniques to a ...mdv/courses/CM30082/projects.bho/2006-7/... · Applying Suitable Artificial Intelligence Techniques to a Game of Dominos