A System for Collaboration and Competition
in Sudoku Puzzles
Gary Breavington
BSc Computing (Industry)
Session 2005/2006
The candidate confirms that the work submitted is their own and the appropriate credit has been given
where reference has been made to the work of others.
I understand that failure to attribute material which is obtained from another source may be considered
as plagiarism.
(Signature of student)
Summary
Sudoku is a puzzle game that has enjoyed a great deal of popularity over the last year and a half.
By its nature, however, it is a very difficult game for more than one person to play at any one time.
The aim of this project was to develop a prototype system and protocol that allow users to participate
simultaneously on the same Sudoku puzzle using networked computing devices. The system was also
to allow for competitive play.
The project investigated numerous technologies and architectures that could be used to help the
building of the system. The system was then designed and implemented using the Agile Unified Process
[28]. Finally, the system was evaluated with user testing to see if the system helped improve performance
of multiple participants solving a single Sudoku puzzle.
i
Acknowledgements
I would like to thank my project supervisor, Nick Efford for all his help, feedback, time, patience
and assistance in this project. Thanks also to my project assessor, Haiko Muller for his feedback on the
mid-project report and at the progress meeting.
Thanks to all in the School of Computing support and the individuals on News who have helped answer my questions, both in this project as well during my time at University. Special thanks to Graham
Hardman for setting up machines to test the system on. Thanks also to Trevor Dodds who offered me
advice about how to tackle this project and warnings of some of the pitfalls to avoid. Thanks to those
who gave up their time to be a part of the testing; it was truly appreciated.
Thanks to all my friends and family who have supported me in my time at University and finally,
thanks to Sarah for putting up with all my complaining.
ii
Contents
1 Project Background
1
1.1
What is Sudoku? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
1.2
The problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
1.3
Proposed solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
1.4
Current solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
1.5
Minimum requirements and possible extensions . . . . . . . . . . . . . . . . . . . . .
5
2 Background Reading
2.1
6
Network considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
2.1.1
Network architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
2.1.2
Network protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
Game state consistency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
2.2.1
3 dimensions of consistency . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
2.2.2
Consistency-throughput trade off . . . . . . . . . . . . . . . . . . . . . . . . .
9
2.2.3
Mobile networking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
2.3
Development platforms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
2.4
Potential technologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12
2.4.1
Jini . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12
2.4.2
JXTA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
2.4.3
JADE-LEAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
2.2
3 Design Methodology
15
3.1
Choosing a development methodology . . . . . . . . . . . . . . . . . . . . . . . . . .
15
3.2
Waterfall process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
iii
3.3
3.4
Agile methodologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
3.3.1
Unified process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
3.3.2
Rational unified process . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
3.3.3
Agile unified process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18
Chosen methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18
4 Design and Implementation
4.1
4.2
4.3
20
Inception iteration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
4.1.1
Project scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
4.1.2
Project risks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22
4.1.3
Project feasibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
Elaboration iteration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
4.2.1
Socket channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
4.2.2
JXTA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
4.2.3
Software prototype . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
4.2.4
System architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
28
4.2.5
Game lobby . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
29
4.2.6
Protocol design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
30
4.2.7
Server implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
31
4.2.8
Sudoku generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
33
Construction iteration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
34
4.3.1
Game logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
35
4.3.2
Text user interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
36
4.3.3
Graphical user interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
36
4.3.4
Interface updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
39
5 Evaluation
40
5.1
Technical testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
40
5.2
User evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
41
5.2.1
Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
41
5.2.2
Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
43
5.2.3
Results analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
43
iv
5.2.4
Observations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
44
Development methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
46
5.3.1
Schedule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
47
5.4
Other systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
47
5.5
Minimum requirements and extensions . . . . . . . . . . . . . . . . . . . . . . . . . .
48
5.6
Further extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
49
5.3
Bibliography
51
A Personal Reflection
56
B Glossary of Sudoku Terms
58
C System Protocol
59
v
Chapter 1
Project Background
1.1 What is Sudoku?
Sudoku is a logic game originating from Japan involving numbers in a grid of 9 squares by 9 squares.
The numbers one to nine appear just once in every row, column and box of 3 by 3 squares. To begin
with, the grid is empty except for a few ‘given numbers’ left by the puzzle setter to give enough clues
about which numbers go in the remaining blank squares; the player then sets about filling in the empty
squares. Appendix B contains a glossary of words relating to Sudoku puzzles and defines their usage
throughout this project.
Sudoku has caught the public’s imagination within the last twelve to eighteen months. Most daily
newspapers now feature at least one Sudoku challenge amongst their puzzle pages. Unlike more traditional puzzles such as crosswords, they require only logic to solve which perhaps explains part of their
appeal. Mepham [41] explains the rules as well as some of the logic that can be applied to solve a
Sudoku puzzle.
1
Figure 1.1: An example of a Sudoku puzzle
1.2 The problem
An important distinction from crosswords is that Sudoku puzzles are not easy to collaborate on. With a
crossword, a clue may be read out to an audience and all can offer suggestions. The letters of the answer
to the clue that are already placed are also easy to relay.
A Sudoku puzzle is fundamentally different. Every blank square has a number of techniques that could
lead to its answer which can be derived from studying the position of other numbers already placed on
the grid. Relaying this information is like the crossword example, if not impossible, difficult enough to
be pointless, both for the person with the puzzle and the person wishing to help. The only real solution
is for the puzzle to be in view of all participants.
This limits how many people can take part in solving a puzzle and does not necessarily remove confusion; only one person can have the puzzle and a pen in their possession at one time and if someone else
spots an answer, indicating where it can go verbally can be difficult. For example, ‘An eight goes in the
bottom left’ could mean the three by three square in the bottom left of the grid, or the bottom left of the
three by three box that the pen is closest to.
2
Another method to indicate an answer to a square is pointing at it - which can still confuse, especially
if the squares are small. The pen and puzzle may also be passed to another player - which increases the
difficulty of viewing the grid. These problems all lend some degree of awkwardness for participants and
must be overcome to solve the puzzle. A solution where users have their own copy of the grid they can
look at and add to would represent a significant improvement on these methods.
1.3 Proposed solution
A system that allows users to collaborate on the same puzzle across a network would have many advantages. Each user would have their own copy of the grid and their own interface to add any numbers
they find, without interrupting other participants. Any squares filled in on one player’s puzzle would be
replicated on other players’ puzzles.
Such a system should be easily modified so that people can then compete on a puzzle - this would
add a whole new element to the game. As before, each user has their own version of the grid and
their own interface; however, when a user finds a square’s answer and enters it into their grid, other
participants are informed only that an opponent has filled a square. The crucial difference from the
collaborative mode is that they are not given the answer, only notification that another player has filled
a square. Players would compete to complete the grid before the other participants.
There is also the possibility to extend this system to mobile devices such as PDAs and mobile phones.
Both types of device offer a range of connectivity options and Sudoku is not an elaborate (therefore
not difficult) game to represent on resource-constrained devices. Such a system would provide novel
functionality not present in existing systems, despite the proliferation of Sudoku programs for mobile
phones.
1.4 Current solutions
Software already exists that allows Sudoku to be played on computing devices. Many are very similar;
some have distinctive features to set themselves apart but few allow for collaboration or competition on
a puzzle.
3
GSudoku [5] allows turn-based attempts at solving a puzzle i.e. player one plays until he enters a
number; play then passes to player two who plays until he finds a number; play then passes back to
player one and so the game continues. There is also a turn-based speed challenge - one player plays
until the grid is solved and then the second person attempts to beat that time.
Both these multi-player modes take place at the same computer and are rather awkward methods of
playing multi-player Sudoku. In the co-operative mode, players may just as well have one person with
the mouse and keyboard filling in the squares, regardless of whose turn it is. Play over a network would
allow both users to manipulate the puzzle in real time, independent from the other player. With a competitive mode over a network, players could manipulate their own versions of the puzzle simultaneously,
rather than having to wait for the other player to finish.
Sudoku Fun [16] calls itself “The online Sudoku speed challenge.” Upon arrival at the site, visitors
are presented with a Sudoku puzzle along with a start time and how long the game has been running.
Visitors are invited to solve the puzzle and submit their name - they are assigned a time for completion
and are added to a score board. Once seven people have submitted a completed (and correct) grid, a new
puzzle is set.
Once again, this is a somewhat awkward implementation of multi-player functionality. Users have
no feedback as to when a new puzzle begins, so they could be left solving a puzzle that is already old.
If a user arrives and the game displayed already started some time ago, there is little incentive in joining
the game as others already have a head start. With no way of knowing when the next game starts, the
user is left to press the refresh button of the web browser until a new puzzle is presented. Finally, Sudoku Fun offers only competitive play - no option of collaborating is offered.
In December 2005, Go! Sudoku [6] was released for the Sony PlayStation Portable (PSP), a Sudoku
game for the handheld device. One of its most notable features is multi-player Sudoku on multiple
PSP consoles, over a wireless LAN. Three multi-player modes are on offer, including competitive and
collaborative modes.
Though a very sophisticated solution to the problem, Go! Sudoku requires each participant to have
4
their own PSP console and their own copy of the game. These are significant costs, approaching £200
per participant. Even if someone already owns the console, the game could cost up to £35; still a significant amount. This is all in addition to the fact that the type of system being suggested does not need
hardware as sophisticated as the PSP. More and more of the mobile phones in today’s market have the
requisite hardware to power a portable version of Sudoku. This is hardware that people already have, so
justifying high expenditure for multi-player Sudoku is unlikely and unnecessary.
1.5 Minimum requirements and possible extensions
The minimum requirements for this project are:
• A communications protocol to support multi-player Sudoku
• A system that allows two players to collaborate across a network to solve a Sudoku puzzle
• Support in the system for competitive play
• Support in the system for team-based play
Possible extensions are:
• Extend the system so that it can be used on mobile devices
• Implement support for different types of connectivity on mobile devices
• Implement automatic setting and solution of puzzles
5
Chapter 2
Background Reading
2.1 Network considerations
As the system will be operating over a network, consideration must be given to network issues such as
topography and protocols, as the choices in these areas will affect all aspects of system design.
2.1.1
Network architecture
Within a client-server network model, a process on a client machine makes a request to a process on
a server which in turn provides a response [52]. What the request and response contain is up to the
application developer - for example, it could be information about an event in a game or the contents of
a web page (i.e. HTTP). Within this architecture, it is possible for two separate clients to communicate
- a process on one machine could send a message to the server which would then relay the message to
other clients.
An alternative architecture is peer-to-peer whereby clients talk directly with each other rather than
through a server [39]. A client within such a system is called a ‘peer’. The details of how the network is used is again decided by the application developer and varies from program type to program
type. For example, a file-sharing application may send out a request for a file that propagates through6
out the network until the file is found. A network game using peer-to-peer however would need to send
information directly from the sender to the other players in the game [51].
Of the two architectures, peer-to-peer is the more difficult to implement as it has design and implementation issues that can prove difficult to manage [39]. Peers need to know how to locate and contact
other peers without a central point of communication such as a server. In the client-server model, the
server is contacted and communicates to other clients on a client’s behalf; how many people are interested in that information and their location on the network is not important to the client - the server
manages these details.
Despite the extra management, peer-to-peer architectures offer more flexibility. If a server stops responding or is not accessible (as may be the case with a mobile device where connectivity may not
always be guaranteed), communication between clients is no longer possible. In a peer-to-peer architecture, failure of one node does not compromise the network.
2.1.2
Network protocols
The network that data are transferred across is not the only consideration, how the data are transferred is
also important. The Transmission Control Protocol (TCP) and the User Datagram Protocol (UDP) are
transport-level protocols for the transmission of data. TCP is a connection-oriented service that provides
reliable byte-stream data transfer and is “considerably more complex” [40] than UDP. This complexity
adds error checking, guaranteed and in-order delivery of data meaning a more reliable transfer method
but one that has more overhead and is therefore slower.
UDP guarantees none of the things that TCP does and only offers a ’best effort’ service - packets may
arrive in a different order to which they were sent or may not arrive at all. Because of the lack of headers
that TCP has, the overhead of using UDP is smaller which means that although more unreliable, UDP
is faster. In situations where packets being dropped or arriving out of order is preferable to late delivery,
UDP is the better choice.
7
2.2 Game state consistency
Network architecture and choice of protocol have particular implications for gaming applications or
applications where consistency of a shared environment is of great importance. Consider an implementation of a Sudoku system whereby a user fills in a cell with a number which is then sent over the
network to inform other players of the move. Along the way, the packet is lost in some way and, in this
implementation, is not retransmitted. Play continues normally and successfully after this incident until
all cells are known.
At least, they are all known in one instance of the game: the instance that filled in the cell that did
not reach the other players. All other participants still have one square left empty. Depending on implementation, they may be able to fill that square in themselves or they may be denied access to change it.
In this latter instance, it means that the other players are unable to finish the game. This is an instance
of just one packet being lost - over an unreliable connection, packet loss could be much greater. This
could leave each player’s view of the game highly inconsistent with other players’ views of the grid.
2.2.1
3 dimensions of consistency
Vaghi et al. [54] focus on collaborative virtual environments, much more graphically sophisticated than
the system proposed here. It identifies 3 dimensions of consistency in a virtual environment: presentation (the level of consistency between the different views of the environment), physics (consistency
of behaviour of the environments and its objects) and interaction (consistency between user actions
and the objects they act upon in the environment). Usually, “one of the dimensions of consistency is
. . . promoted at the expense of the other two.” [54]
Of the three, presentational consistency concerns this project the most - a consistent view of the puzzle
between participants is most important. Physics consistency does not relate to this project at all whilst
interaction consistency does hold some importance; if a user interacts with a square, they are going to
expect that square to react (change its value). If the state of the game is handled somewhere centrally to
help enforce presentational consistency, this may impact on interaction consistency [54]. For example,
over a wide enough network, there may be a signficant delay between the user entering a value for a
square and that value being rejected, causing confusion for the player.
8
There are multiple approaches to resolving such issues. The first is that, if speed is not important to
an application, TCP can be used to guarantee that packets containing information about the game state
actually arrive; if they do not, they will be retransmitted as part of the TCP protocol. As long as an
application-level protocol is designed appropriately, the game should not enter an inconsistent state on
any machine.
Other solutions include using a client-server architecture. This acknowledges that the state is going
to become inconsistent on the clients playing the game, so the ‘real’ state of the game is kept on a
server. Updates to the game state can be relayed in a number of ways; for example, updates could be
confirmed to the original sender by the server and relayed to other players. Another way could involve
periodic synchronisation between server and client to ensure consistency of the grid between players.
This latter solution is not suited to a networked Sudoku system. Between synchronisations, a client’s
view of the grid may deviate from the real state determined by the server. When synchronisation occurs, and the client’s view of the grid is updated to the real state, this may make changes to the grid
in a number of squares. As the player is unable to focus on multiple squares at a time, the state of
the grid in several places may change suddenly; the user will be aware changes have occured but be
unaware where they have occured. Such a solution is better suited to systems where changes between
the unsynchronised and synchronised state can be made gradually.
2.2.2
Consistency-throughput trade off
Applications with an environment shared across multiple clients also face the consistency-throughput
trade off. Singhal and Zyda [51] explain this as meaning an application can have:
“. . . a dynamic world in which information changes frequently or. . . a consistent world in which all
hosts maintain identical information.”
This means that there must be a balance between what can change in an environment and the consistency of the environment between clients - the more dynamic the environment, the less consistency
there is. This is especially relevant in applications that need to transmit a lot of data to keep the envi-
9
ronment consistent. In a Sudoku system, this is unlikely to be an issue. In the collaborative mode of the
system, all that is likely to change is the value of a cell - it may be added, changed or removed - so a
highly-dynamic environment is not necessary.
2.2.3
Mobile networking
The choices to be made about the network for a desktop application are not always consistent with the
choices for a mobile application. If the system was only for the desktop, a client-server architecture
would likely be the most sensible choice. In such a system, consistency would not be difficult to maintain. Design and implementation of the proposed system here, however, should at least consider the
possibility of running on a mobile device. Peer-to-peer is more likely to be the correct choice here even with the difficulty that implementing such a system entails.
In a mobile environment, an ad-hoc network of peers may form without being able to contact a central server. In this case, having a central server maintaining the game state may not be possible. A
way of maintaining a consistent state between peers (i.e. acknowledgement of received messages and
retransmission of unacknowledged messages) or the establishment of a peer to act as a server (that holds
the ‘real’ game state) are possible ways to deal with this.
2.3 Development platforms
The idea for multi-player Sudoku extends well to mobile computing devices. Puzzles are popular in
spaces where attention can be spared and there is time to pass i.e. a train journey. In these sorts of situations, traditional forms of Sudoku (such as a newspaper or a book) may not be available but a mobile
device might be. Having a version of the system for such devices would be welcome in situations such
as these. Furthermore, with connectivity methods such as Bluetooth available, an ad-hoc network with
nearby devices could be formed to provide multi-player gameplay in a wireless environment.
From a business perspective, content for the mobile market is growing in popularity. The Wireless
Business Forecast [25] looks at predictions of how much this area is set to grow - by 2010, ‘data services’ (of which, games are a subset) may represent $47 billion worth of business to the mobile market.
Mintel [24] provide a further breakdown of the UK market for mobile downloads, claiming that in 2004,
10
the market for mobile games made £60 million and predicts this to more than double in value in 2005
to £150 million. Combining the popularity of Sudoku with the burgeoning mobile games market could
certainly be a financially sound idea.
If the system is to be extended to mobile platforms, the choice of development platform requires more
thought. There are many choices for implementation on a standard PC, but in resource constrained
mobile devices, the choice becomes a lot more limited. Specific coding for different platforms should
be minimised or eliminated if possible, which is where development platforms and frameworks such as
.Net [13] and Java [9] can aid development of multiplatform systems.
B’Far [31] describes the .Net Compact Framework (NCF) [12], a development framework from Microsoft for mobile devices. Rather than writing code for specific pieces of hardware, the code is written for a runtime environment. The code is then compiled for execution on the runtime environment;
whether the host machine is a PDA or a smart phone, as long as the .Net runtime is available for that
device, the program will run. NCF is only available for devices that run a Microsoft operating system.
Java Micro Edition (JME) [8] works somewhat similarly in that code is written to run on a Java Virtual
Machine (JVM) rather than specific hardware. Unlike Microsoft’s solution, this is not tied to a particular operating system, so code written to run on a JME JVM will run on any mobile device with an
implementation of that JVM available for it.
This is similar to Java Standard Edition; however, JME should not be viewed simply as Java Standard Edition (JSE) for mobile devices. It is a subset of what is included with JSE and has much more
limited functionality than its Desktop counterpart. To operate on resource limited devices, a number of
features are trimmed from the JVM. B’Far [31] lists absent or reduced features from JME as including
floating point arithmetic, exception handling and automatic garbage collection.
This means that a program written for use with Java on the Desktop (i.e. JSE) will at least need recompilation to run on a mobile device with Java Micro Edition. It is possible that some code will even
need to be rewritten.
11
The .Net Compact Framework is very similar - it is a subset of the .Net Framework much like JME
is a subset of JSE. This means that some of the more resource intensive features are not available on
mobile devices. In a comparison of the two frameworks, Janecek and Hlavacs [35] states the main differences between the two to be the supported hardware: applications written in JME are more portable,
but because of closer ties with the local operating system, NCF has better support for native methods.
The current mobile phone market favours Java’s offering. Yuan [56] states that JME enabled phones
dominate the market with a combined 80% market share. There are far fewer models of mobile phone
running a Windows operating system and those that do are still capable of hosting a JME JVM.
2.4 Potential technologies
There are a number of technologies that could aid in the implementation of the system for this project,
specifically relating to the networking aspects of the game.
2.4.1
Jini
The Jini specification is aimed at providing “a simple infrastructure for providing services in a network”
[29]. The architecture is service-based - if a device needs a service, it can connect to a Jini network
(a federation) and make a request for the service it needs. A look-up service provides the location of
available instances of this service that the device can then use.
Jini is interesting for a number of reasons. Because of its use of Remote Method Invocation (RMI)
and remote objects, a device using a Jini service needs to know very little about the implementation
of the service it uses. The code behind the service could be completely rewritten and as long as the
interface did not change, the client could act on and use that service in exactly the same way. Jini also
features a distributed event system that allows for discovery of services when they become available if
they are not available immediately [53].
Because of the layers of abstraction in a Jini network, Jini may sound like a good match for a flexible system such as the one proposed here - it is a technology that is designed with the dynamic nature of
the network in mind. It seems particularly well suited to providing a network infrastructure across both
12
desktop and mobile devices. Unfortunately, there are some limiting factors on its use.
Firstly, “Jini and J2ME on the same device is not widely available” [31]. This is partly because of
the limitations of the JME JVM - Jini requires RMI which is not available on JME and Sun currently
have no plans to implement Jini for JME [22]. Clever workarounds have been found. Hashman and
Knudsen [33] note that the Jini specification only requires RMI-like behaviour but not necessarily a full
implementation of RMI. Their JMatos software claims to offer Jini network technology for JME devices
for a small licensing fee. There is also the Jini Surrogate Architecture whereby a surrogate host “[acts]
on behalf [of a] device that is not Jini technology-enabled” [19].
The second problem with Jini is that its spontaneous nature of forming a network only really works
locally. Upon connecting to a network, a Jini device broadcasts its presence hoping to find a Jini network within its proximity. Due to the nature of this communication, this broadcast is not likely to get
very far - routers will not let the message propagate much further than a LAN. It is possible to enable Jini
to work over the Internet by specifying device locations; but this limits Jini’s spontaneous networking.
2.4.2
JXTA
JXTA (Juxtapose) is a set of protocols that allow for communication between different types of device in
a peer-to-peer manner. The three main aims of the JXTA project are interoperability (between networks
by using a common set of protocols), platform independence and ubiquity i.e. any type of device should
be able to connect via an implementation of the protocols [32].
The JXTA protocols define the basic operations that are needed to assemble peers and communicate
between them in a peer-to-peer fashion. Though most networks of this type share some common traits,
the implementation and application of a peer-to-peer network can vary a great deal. Therefore, applications can use as many or as few of the protocols as needed to implement the necessary features of the
type of network that an application requires.
Reference implementations for the JXTA protocols are available so developers can implement them
if required but ready-made implementations are available to use. Because of the open source nature of
the project, there are actually several implementations, tailored to specific application types, platforms,
13
programming languages and so on. JXME [10] is one such project that extends JXTA to mobile devices
running JME.
2.4.3
JADE-LEAP
The aim of the Java Agent Development (JADE) framework is to aid in the development of applications
involving multiple agents [7]. Originally, JADE was intended for systems running JSE and its requirements were much too demanding for mobile platforms. The Lightweight Extensible Agent Platform
was developed to provide a JADE runtime environment suitable for JME [11]. Eventually, the LEAP
libraries were integrated fully into the JADE project.
The idea behind JADE-LEAP is that there is a common API between different types of host (such
as mobile devices or desktop machines) [31]. A container for each host type implements the API specifically for that type of device. Agents that make use of the API can move from host to host without
having to worry about the new host’s capabilities.
From initial research, it seemed as if the JADE-LEAP API could be used for the networking of both
desktop and mobile versions of this project. Its use in a mobile environment, however, is limited.
Because of the constrained resources on mobile platforms, there is a dependence on “. . . static and
resource-rich infrastructure . . . ,” without which “. . . A mobile device is unable to effectively communicate with other mobile devices” [46]. The reliance on such an infrastructure means that JADE-LEAP
will not suitable for creating ad-hoc networks, nor for developing code that works on both the desktop
and mobile devices.
14
Chapter 3
Design Methodology
3.1 Choosing a development methodology
Software development methodologies guide the workflow of a software engineering project. There are
many such methodologies, each setting out principles and practices to be adopted in their vision of what
a software lifecycle should entail.
3.2 Waterfall process
When people think of structured methodologies with a set number of stages and a strict progression
through them, the Waterfall process is likely to be one of the first methodologies that comes to mind.
Though Royce [48] is often cited as its origin, this is in fact incorrect; though he describes aspects of the
Waterfall-like methodologies (though never actually uses the term ‘Waterfall’), the author explains why
such models are flawed and offers suggestions for improvement. These suggestions have gone largely
unnoticed and people think of the methodology as a rigid, inflexible development process. Weisert [55]
views the ’Waterfall’ name as a “straw-man term” used to describe a methodology that “. . . no competent methodology expert ever favored.”
15
Royce [48] explains how in an ideal Waterfall process, a phase’s interaction with other phases should be
limited to the phases immediately before and after it. The reality, however, is that the interaction usually
reaches further than this, leading to a point late in the process where substantial changes in much earlier
phases is required: “In effect, the development process has returned to the origin,” [48] meaning work
has to start again from the beginning of the process.
3.3 Agile methodologies
Such rigid approaches are in contrast to ’iterative’ and ’agile’ development processes. The idea behind
these methodologies is that the construction of a system is broken down into iterations, the outputs from
which are built upon in the subsequent iteration.
The building of the system tends to start earlier and a system with limited functionality is usually one
of the outputs from an iteration. This has two benefits - firstly, it provides a proof of concept of initial
designs and highlights potential problems that designing and implementing such a system may pose.
Secondly, each system produced by an iteration can be presented to the end user to find out more about
the problem domain (i.e. requirements capture) and to see how well the current design and implementation fits with what the user actually wants.
Agile, iterative methodologies were more suited to this type of project than the more structured models. Research into the network aspects of the system required early implementation to understand how
possible solutions could work; Early versions of the system provide the opportunity to research these
solutions. The results from the findings then influenced the design in subsequent iterations.
There were also a number of features that could have been added to the system depending on the time
available. In a development model where all the design takes place up front, it can be difficult to judge
how long things are going to take. If things go wrong, features that have been designed have to be
dropped and design work goes to waste; conversely, if progress moves ahead of schedule, the design
may not be able to accommodate the adding of extra features.
16
3.3.1
Unified process
The Unified Process uses the Unified Modelling Language (UML) to create a user-focussed methodology. Si Alhir [26] describes it as: “a use-case-driven, architecture-centric, iterative and incremental
development process framework.” It features four iterations of development: inception (framing the
project within a viable business context), elaboration (arriving at a viable system design that meets the
requirements), construction (the building of the system) and transition (finalising the product, testing it
and then rolling the system out to the users).
The elaboration and construction iterations can be broken down further into sub-iterations. This aids the
requirements gathering, design and building of the system by decomposing the functionality required of
systems built in these iterations into manageable sub-iterations. The UP also encourages the tackling of
risk as early as possible. If a team attacks the riskiest parts of a project first, it is known early if those
risks can be overcome; if not, there is less loss in cancelling (or seriously reworking) a project than if
this realisation comes late in the project lifecycle, after many resources have already been expended.
3.3.2
Rational unified process
If the Unified Process provides a framework for developing software, the Rational Unified Process
(RUP) provides the details of how to execute a project under such a methodology [26]. It is a commercial product, a methodology along with a set of tools provided by Rational Software (a part of IBM) to
help build software according to their version of the UP. It is intended for companies with large software
projects and places a strong emphasis on the business aspects of a project, particularly in the inception
iteration.
Kroll [38] emphasises the key principles of the RUP such as: “Accommodate change early in the project”
(as changing requirements are more easily accommodated in the early stages of the project lifecycle)
and “Stay focused on executable software” (as software is usually the end result of a project, it is a
good way to gauge progress). Though the RUP specifies a highly defined process, “the RUP should be
considered a smorgasboard from which you choose the dishes that fit your needs.”
17
3.3.3
Agile unified process
The Agile Unified Process (AUP) is quite closely related to the UP. As people have been applying the
UP and its variants in their projects, people have come to be using it in ways that, although tailored to
a particular project, are not necessarily agile. For example, the process would be adapted to a project
at the start but then followed rigorously throughout the project [27], rather than adapted throughout, as
and when the project required.
What the AUP tries to do is apply agility throughout the project lifecycle. It also tries to reduce complexity in design and development. For example, it suggests creation of “models and documents which
are just barely good enough” [28], at points just before they are needed. This way, decisions made about
the system benefit because of increased knowledge of the requirements, and development is not bogged
down with making and documenting decisions that are not yet relevant. The AUP also places much less
emphasis on business modelling than the RUP. That is not to say it discards these things - for example,
estimating cost, schedule and project feasibility are all part of the inception iteration - but it reduces
these activities to a level suitable for a smaller project.
3.4 Chosen methodology
The AUP was chosen as the methodology for this project. Of the methodologies considered, it felt like
the most natural fit. Research that involved implementation was necessary; re-using the results of that
research seemed like an excellent way of answering technology and design questions at the same time
as working on an actual system. Therefore, a linear model like the Waterfall was not a good candidate.
Though the RUP encourages its users to select the parts of the process most needed for a particular
project, it was considered unsuitable for two main reasons. Firstly, the problem was not heavily rooted
in the business domain so using a methodology that focuses heavily on that part of development was
not deemed sensible. Secondly, though an agile and adaptable process, it is still heavyweight compared
to other available processes. Hirsch [34] describes how one company adapted RUP to be more agile
for smaller projects but defines a small project in that context as having “3 to 5 developers and 6 to 9
months duration.” With a similar development period but a fraction of the developers, it was thought
that even a lightweight version of RUP would not have been suitable.
18
Many of the requirements disciplines of the RUP are combined into one ‘Model’ discipline in the AUP,
reducing work unnecessary for a smaller project. The AUP makes the point that this discipline “doesn’t
dominate the process“ [28], therefore modelling activities are light throughout the project lifecycle. This
allows for a greater focus on implementing a system earlier in the process, rather than excessive modelling and documentation.
This has three main benefits: firstly, early implementation helps inform the design. Secondly, as there
is only one developer, modelling and documentation is not as important as it is for teams of developers.
Keeping these activities to a minimum means the time can be spent elsewhere. Finally, there are a number of ambitious possible extensions to the project that could be added if time allows. If there is time to
implement some of these, the modelling can be done when that decision is made rather than doing the
modelling in advance.
There was one change made to the process however - the transition iteration was not used. The focus of
this iteration is to deliver the system into the environment it will be used in [28]; and as the system was
intended as a prototype and as there was no environment to deliver it into, applying a transition iteration
in the project was not necessary.
19
Chapter 4
Design and Implementation
4.1 Inception iteration
The AUP Product version 1.0 [28] defines the major activities of each iteration of the AUP and breaks
them down into work to be done by discipline. The main activities of the inception iteration are:
• Define the project scope (with high level architectural and user modelling)
• Estimate cost and schedule (develop a high level schedule)
• Define risks (which should be documented in a controlled manner)
• Determine project feasibility (via prototyping)
• Prepare the project environment
(N.B. Some parts of the activities and workflows are not applicable to this project - e.g. obtaining
stakeholder funding, estimating cost).
4.1.1
Project scope
The project scope in terms of the highest level features of the system were defined by the minimum
requirements. These were expanded upon and formalised with UML diagrams. First, a use case diagram
20
captured the high level activities of a user of a system that meets the minimum requirements; this is
shown in Figure 4.1.
Figure 4.1: High level Use Case diagram
A high level diagram of the architecture was also drawn up in a deployment diagram. This is shown
in Figure 4.2; clients connect to the server and then to each other.
Figure 4.2: High level Deployment diagram
Though the Use Case diagram captures part of what the user requires of the system, more detailed
diagrams were developed later to capture the requirements in more depth. Similarly, it was understood
that the deployment diagram was likely to change as the requirements of the system became better
understood and the software and architecture design evolved into the system to be developed.
21
4.1.2
Project risks
Trying to identify the risks of the project was somewhat more difficult. There was a more general problem at this stage of deciding what to focus on - specifically, if the minimum requirements were to be
exceeded, should the risks involved with possible extensions hold up progress towards the minimum
requirements? It was important to avoid getting bogged down in meeting these risks early if it meant
the minimum requirements went unmet because too much ambition was shown to start with.
The solution used was to consider the meeting of the minimum requirements as the most important
aspect of the development period. That is not to say that considerations relating to design and implementation of project enhancements went unconsidered; however, if there was an aspect of extending the
project that could have caused delay that endangered the meeting of the minimum requirements, it was
put off until a later iteration.
With this in mind, the main risk of this project was the underlying network communication and the
choice of technology that it was built on: sockets or JXTA. It was decided to research and make this
decision in the elaboration iteration. The possibility of multi-platform development was another large
risk as system design needed to be flexible enough to accommodate a version for portable devices.
Such a version was not part of the minimum requirements. Early prototyping to see how such a system
for mobile devices could work was counter-productive to the development of a version satisfying the
minimum requirements. A compromise was achieved. The system was generalised into three layers
shown in Figure 4.3:
Figure 4.3: The layers of the design
The thinking behind this was that it would be possible to specify interfaces to the different parts of
the system; any of these components could later be replaced by another component that performed the
same function, even if the underlying implementation was completely different.
22
Such a design is versatile enough to allow one part of the system to change without affecting the rest of
the system. This was useful for both the possibility of trying out different network technologies as well
as possible extension of the system to other devices. The idea was that the layers that needed changing
for the system to work on a different platform could be re-implemented without making changes to the
other layers.
4.1.3
Project feasibility
After the initial consideration of risks was the question of project feasibility. The indications from the
research up until this point indicated that the project was feasible. Even so, a small prototype was made
to show that sockets could be used to implement a simple system with basic functionality, as well as an
exercise to see how socket programming in Java worked.
Figure 4.4: A simple system to prove the network architecture
An overview of this system can be seen in Figure 4.4. In this small system, clients connect to a
server where a ClientHandler deals with the connection. Clients can then initiate connections to
each other. The prototype was crude and did not function anywhere near to what was required of the
final system, but it showed that such a solution was possible.
Java was selected as the development platform and the Eclipse [3] Java Integrated Development Environment as the environment. As discussed in Chapter 2, there is little to distinguish between Java and
.Net Compact Framework in the features they offer for multi-platform development in a project such as
this.
Java was chosen because of available resources. No mobile phones with the .Net Compact Framework were available and although emulators of phones were available, running a built system on a real
23
phone was considered to be a benefit; however a Nokia Series 60 mobile phone with JME was available,
as were other similarly equipped phones. Finally, Nokia [14] offer a wealth of resources for development on their mobile phone platforms, from Software Development Kits to documentation across all
levels and across many different areas - including Bluetooth. It was the availability of these resources
that reinforced the decision to use Java.
4.2 Elaboration iteration
The most important task in the Elaboration iteration is: “to prove the architecture for the system to be
developed... and the best way to do that is to build a end-to-end, working skeleton of the system called
an ‘architectural prototype’.” [28]
In relation to this project, this meant implementing a networking solution suitable for the final system. It did not need to be the network code that the deliverable used; however it needed to at least
strongly resemble what was used for the construction iteration. A decision was needed about what
network technology to use. The choice here was between socket streams, socket channels and JXTA.
4.2.1
Socket channels
Socket channels are part of the New I/O packages introduced into Java to, amongst other things, provide “An API for scalable I/O operations on both files and sockets, in the form of either asynchronous
requests or polling” [47].
This is in contrast to the more traditional socket streams whereby a thread that sends and receives
input on a socket will “block” (do nothing) until it receives input. In this model, each client connected
to a server would need a thread and its own set of data streams to handle the connection.
With socket channels, however, one thread can manage multiple channels. The thread in charge of
I/O for a set of connections checks whether input is waiting to be read into or sent out of a channel,
“somewhat like being directly driven by hardware interrupts from the network controller” [44].
Though channels do offer efficiency advantages, they bring additional complexity to a system’s im-
24
plementation and the benefits are largely for systems that handle a vast number of connections. Pitt [44]
states the channels approach “scales much better when the number N of simultaneously open channels
is large, say in the hundreds of thousands.” Beloglavec et al. [30] conclude that in fact the most efficient
solution may actually rely on a mixture of both sockets and channels depending on the system being
developed and that system’s aims.
After researching socket channels, it was decided that if JXTA was also ruled out, socket streams would
be the choice for the network. The ability to scale up to thousands of connections was considered superfluous for a prototype system. The additional complexity also introduced more risk that could have
jeopardised the completion of the project.
4.2.2
JXTA
JXTA was technically one of the most interesting solutions considered. A peer-to-peer networking system would have offered a sophisticated solution, difficult to obtain if coded from the ground up. There
was the added advantage of a version of JXTA exists for mobile devices, called JXME. This offered a
possibility of easy extendibility to mobile phones.
JXME has some crucial limitations however. If the system were ported to mobile devices, Bluetooth
connectivity would be the preferred method of connection. However, JXME requires access to a JXTA
proxy making “an ad-hoc usage of JXME impossible” [36]. Work began on incorporating Bluetooth
connectivity into JXME in 2003 - however the status page for that sub-project lists two entries in 2003
and no further updates since then [20].
Work has taken place outside of the JXME project to produce a solution, the most advanced of which
is the Jadabs JXME BT [21]. From looking at the product’s documentation however, getting it working
required too great an effort than the time for this project allowed.
JXTA still remained a possibility for non-portable versions. The JXTA v2.3.x: Java Programmer’s
Guide [23] presents a series of tutorials illustrating the different features available with the JXTA framework.
25
A JXTA client that wishes to collaborate in some way with other clients must first join the Net Peer
Group. Networking between clients can be done at this level but usually it is advisable to look for a peer
group that offers the functionality or services required by a peer; if such a group does not exist, one can
be created. Group policies such as membership, security and service access can be tailored to meet the
specific requirements of an application.
Communication between clients is abstracted into putting messages into and receiving messages from
pipes. A pipe may be unicast and send messages to only one other pipe; alternatively, a pipe may propagate a message to more than one pipe. Such features make passing messages to other clients much
simpler.
Advertisements in JXTA are XML documents that represent a resource in the JXTA network - a resource could be, amongst other things, a pipe, a peer or a peer group. Peers use these documents to
locate the services they require and then interact with the service accordingly.
A possible system using JXTA would involve a peer that looked for a Sudoku game peer group; if
no such group existed, it would create one. Peers could negotiate within the peer group to begin a new
game, organise a new peer group for that game to take place in and then play the game within that peer
group.
Despite all this promise, JXTA posed a danger to the project deadline. It appeared that using JXTA
for the network required a lot of experimentation and work to produce a satisfactory solution. Though
powerful, the research indicated that constructing a sensible JXTA solution was not a trivial task; the
quality of tutorials and documentation did not help and there is quite a share of complexity in the JXTA
framework that made it even more daunting.
While the abstraction of the network would have helped deal with the complexities of implementing
a peer-to-peer system, JXTA appeared too elaborate for what the project required and too difficult to
implement in the time that the schedule allowed. Therefore, the decision to use socket streams was
made.
26
4.2.3
Software prototype
With the decision made about what to use for the networking, coding of a basic system for the elaboration iteration began. In iterative development, a basic system can be built with features being added as
iterations progress. The best starting point in this case was establishing the basic connectivity functions
that a client required, i.e. establish a connection to a server, find other players for a game and perform
the necessary network operations to start a new game amongst the players.
To help aid coding, the user’s expected behaviour when attempting to play a game was modelled as
an activity diagram, shown in Figure 4.5. From this diagram, enough of a system was developed to see
how such a solution may work. It is important to note however, that this exercise was to help inform
decisions about a system design rather than replacing the design of the component with just performing
the implementation.
Figure 4.5: Activity diagram showing possible system behaviour
27
4.2.4
System architecture
Using the original proof of concept from the inception iteration as a base, a framework more suited
to the final system was partly implemented. The original system relied on synchronous behaviour at
both the client and server; a message had to be received before a reply could be sent. This behaviour
is acceptable for a server - although not every message from a client necessitates a response, a simple
acknowledgement can be sent (and subsequently ignored by the client).
Due to the nature of a multi-player game, a client needs asynchronous communication. If a player
on another client makes a move, it needs to be sent to other participants in that game. Because of the
blocking nature of sockets in a single threaded solution, the server (or client if peer-to-peer is used)
would be unable to send a move to other clients and would have to wait until a receiving client sent
something to the server before it could pass on the move.
It could take a while for this to happen - if the player does not make a move, there may be no contact with the server/another client for minutes at a time. An update request from a client could be sent if
no contact had been initiated after a specified interval but this could lead to disparities between the game
state on different clients for periods of up to that interval. The length of time the games are unsynchronized could be reduced by reducing the period of this time interval - this, however, increases network
traffic. With a peer-to-peer network and enough players, this could flood the network and consume
resources to a point where performance of the system as a whole is impaired.
The first proof of concept system attempted a limited peer-to-peer set up whereby clients discovered
each other on a server and then connected to one another to communicate directly. Initially, the plan
was to keep this behaviour in the second version of the networking system. The decision was made to
go with a client-server architecture however, for a number of reasons.
First of all, JXTA provides a “firewall-friendly” means of connecting peers. As JXTA had been discounted however, it could not be assumed that players are going to be on networks that allow connections on arbitrary ports. Secondly, a game within a peer-to-peer network faces a host of problems
relating to game consistency and communication between peers. These problems are easier to manage in a server-client architecture and only the machine running the server needs to accept and manage
28
connections from clients.
4.2.5
Game lobby
One of the design issues in this iteration was how players would set up, locate and join games. As the
project only required a prototype system, handling these issues did not have to be particularly sophisticated. For example, a machine could be assigned to act as a server and set up a game; the address of
the server could be passed to the clients at runtime and once they were connected, they could play the
game.
One of the first tasks when coding the networking was to get messages from one client to another.
The content of the message was not initially important, just that clients could send messages to each
other, as once this is done, the actual messages to be sent by the system can come later.
This inspired the idea of a ‘lobby’ system - a place where players could meet, exchange messages
(i.e. chat), set up new games, see a list of existing games and join a game that needs players. Game
information was to be held on the server, so information could be aggregated and sent to clients when
requested and chat messages could be easily propagated by the server to other client connections.
This functionality represents a significant extension to the minimum requirements as well as providing a far more sophisticated and user friendly environment for the user. A simple system could have
required users to set up a host themselves and know in advance who they were playing with. The lobby,
however, means that this is not needed and players can meet other people looking to play Sudoku as
well. Though it added some complication to the system, the benefits outweighed any added difficulty.
The biggest impact on the design was that connections now had a lifecycle on the server. Whereas
in a basic system, a client connection would be a participant in a game, there now needed to be different
behaviours depending on a connection’s state. For example, a client that has registered as a participant
in one game should not be able to join or start a new game as a client can only be in one game at a time.
This lifecycle is represented by 3 ‘states’ that a connection goes through. When the client connects,
they are initially in the game lobby state. In this state, a client can send and receive messages to the
29
lobby, create a new game or join a game that is waiting for additional players. Once a player joins or
creates a game, they are in the game waiting state; they are unable to start or join games but they can
still receive messages from other players.
Finally, once there are enough players and the game begins, the connection is in the game state; still
unable to join and create new games and now only able to receive messages from other players in the
game (i.e. moves other players have made). Each connection to the server has a variable that tracks that
connection’s state that is used to determine what that connection is and is not allowed to do.
4.2.6
Protocol design
As the system now enabled client communication, attention turned to the application protocol. HTTP
[18], FTP [45] and SMTP [37] all specify methods of replying to a client with a three digit informational code, sometimes followed by informational text. As Klensin [37] explains, “Replies to SMTP
commands serve to ensure the synchronization of requests and actions... The number is for use by automata to determine what state to enter next; the text is for the human user.”
Amongst these protocols, the first digit usually gives a high level indication of whether the command
sent was a success or failure. For example a code with a 1 as the first digit is a “Positive preliminary
reply” in FTP [45] and a code beginning with a ‘4’ in HTTP indicates a client error [18]. If more information about the response is needed, the second digit should provide the general class of response [37].
The first two digits together with the third make up a specific code that provides a unique informational
message about the command that was sent.
A three digit code with a defined hierarchy such as the ones in the protocols discussed above provided a suitable approach for the protocol to be developed for this system. Messages could be grouped
into a handful of general types and then broken down into subsections with appropriate codes. This
method provides structure but also extendibility - if a new code needs to be added, it can be added to
an appropriate group of codes if one exists, or a new group can be created if the existing ones are not
suitable. If a group grows too large, it is probably an indication that the group can be broken into a
number of smaller groups.
30
To begin assigning the codes to be used, it was necessary to flesh out which messages will need to
be sent by clients and the server. The initial Use Case diagrams provided the necessary insight into the
messages that would be sent and they were added to a brainstorm. Fairly quickly, common areas began
to emerge amongst the messages with a number of options on how to divide them up. The following
hierarchy was established:
• 1xy: General informational messages relating to connectivity to the server
• 2xy: Game set up messages i.e. messages relating to setting up a new game
• 3xy: In game messages i.e. moves from other players
Initially, error messages were subsets of these commands. However, it was decided to move error
messages to their own set of codes, beginning with a 4. A full list of the commands in the final system
protocol can be found in Appendix C.
It would have been possible to use objects for the transfer of messages. Strings were chosen as information passed over the network could be easily represented in text; objects would have introduced
additional overhead and would need to be serialised to be sent over a network. As B’Far [31] notes, Java
Mobile Edition does not offer serialisation so using objects was not an option if the system was ever to
be ported to the JME platform.
4.2.7
Server implementation
As a client-server architecture had been chosen, the server needed to handle each client over the lifetime
of its connection and act appropriately for each one depending on whether it represented a user in the
lobby or a user playing a game.
To enable clients to connect to a server, a ServerSocket waits for connections on a given port.
Once a client connects, a new Socket object is created representing the new connection. As the server
needed to accept multiple connections, a new thread was necessary to handle messages sent to and received from each client.
In the system built, this is handled by a ServerNetworkHandler object for each new socket. Each
31
of these objects runs on its own thread, accepting and sending messages whilst the ServerSocket
continues listening for and accepting new connections. The ServerNetworkHandler objects are
kept in a ClientConnections class and stored in a HashMap. This allows objects to be stored
in a map and indexed in the map by a key; in this case, the object was a ServerNetworkHandler
object and the key was an Integer derived from the number of connections on the server at the time
a client connects. Each object in the HashMap must have a unique key, allowing each connection to be
uniquely identified on the server. This identifier was important for client-server communication, as well
as the game information kept on the server.
Because of the decision to use a client-sever model, a game being played now needed have to be represented on the server in some way. Moving the entire game logic to the server did not seem sensible
as it was possible this could compromise the performance of the server and as a result, communication
between clients.
The Game class represents a Sudoku game on the server. This class holds the basic information that
the server needs to know about a game - the type of game, the game state, the number of players and
the ServerNetworkHandler objects of the clients in the game. Like the ClientConnections
class, the participants are stored in a HashMap (with two in a competitive game, one for each team).
When a client wants to initiate a new game, it passes the parameters for that game to the server game type, number of players and the puzzle the game will use. The server uses these to create a new
Game object. The connection number of the client starting the game is used as that game’s identifier
and as a key in a HashMap. This HashMap is held within a class called GameList and keeps track
of all the games currently on the server. This is shown in Figure 4.6.
When a client wishes to know what games are available to join, the GameList returns a list of the
games waiting for players. As clients join a game, they are added to a HashMap in the Game object;
once there are enough players, each of the clients in the game is notified and sent the puzzle to initiate
the game on the client.
Once the game begins, the main role of the Game object is to relay messages between clients. If the
32
game is a co-operative one, this simply means sending a move on to all the clients in the Game object’s
HashMap. In a competitive game, this is slightly different; instead, a message containing the move is
sent to all the clients in the same HashMap as the client sending the move (the client’s ‘team’), and a
message saying to the clients in the other HashMap to inform them that their competitors have filled a
square.
Figure 4.6: Server class diagram
4.2.8
Sudoku generation
This project’s requirements have deliberately not included generation of puzzles as this is a field that
already has many good solutions available. SourceForge [15] hosts a number of Sudoku projects that
are capable of producing puzzles, as well as having licenses that permit re-use of their code. Coding a
Sudoku generator is not a trivial task and projects (and their licenses) offer a quick way of getting such
functionality.
Of all the Sudoku projects, only a handful are coded in Java and some are quite obscure in how they
work due to a lack of commenting and documentation. After trialling a few and perusing their source
code, FreeSudoku [4] was chosen to provide the Sudoku generation functionality. Though partly written in Spanish, it was fairly easy to interpret what the code was doing and after extracting some of the
classes and adapting their behaviour slightly, puzzles could be generated easily and in a suitable format
(a text-based representation of the puzzle).
The deliverables defined by the AUP for the elaboration iteration had now been met. The technical
33
risks had been identified and met head on - the system prototype was built and validated the architecture
(albeit a different architecture from what was originally envisioned). The models had been fleshed out,
though probably not as much as they could have been by this stage; this is acceptable within the AUP,
however there is a feeling that more should have been formalised in design documents and/or diagrams.
This left a lot of design work for the start of the next iteration.
The major technical risk had been met - the network architecture. Other areas, such as the GUI, still
needed substantial work but the network was vital to understand and get working.
A request was put into the School of Computing Support team to ask for permission to run a server
listening on port 49200 on two of the School machines. This request was granted and security measures
were put into place by the support team to allow connections to these machines from the School’s Linux
subnet.
4.3 Construction iteration
The AUP [28] lists many activities in the construction iteration but, like previous iterations, not all were
applicable to this project. The activities of interest were:
• Flesh out use cases and other diagrams as necessary to design and then implement each requirement
• Build continuously
• Evolve the user interface
• Test the software
The construction iteration began with a review of the network architecture as it was felt there were
improvements to be made. The message parsing on both the client and server side were refactored into
separate classes. In the previous version, parsing of messages was done in the network handler code.
Though this worked and could have been kept for the final version, moving it to its own class had a
number of advantages, such as code that is easier to read and maintain. It also helped separate the components of the system more cleanly.
34
The actual classes that parsed messages sub-classed a newly implemented CommunicationHandler
class. This way, classes in need of parsing and construction of messages could specify a
CommunicationHandler variable and assign it an instance of a sub-class for specific parsing. For
example, the ServerNetworkHandler class originally had methods to parse messages received
from a client. Instead, it was given a CommunicationHandler variable that, in the
ServerNetworkHandler’s constructor, was assigned a ServerCommunicationHandler object which is used to process messages (and construct messages to send to clients).
With this newer architecture, changing the protocol or program behaviour in response to received messages means implementing a new class that inherits from CommunicationHandler and assigning
an instance of this new class to the CommunicationHandler variable in the
ServerNetworkHandler class instead. This makes the architecture more easily extended for other
protocols and behaviour than the previous system.
Once these changes were implemented, the network infrastructure was complete, and implementation
moved onto the game and game logic i.e. the representation of the puzzle in the program. This was
tied in with the development of the game with the user interface. As the game needed to represent a
puzzle, viewing the puzzle was necessary; likewise, the game needed to handle changes to squares (and
checking these changes required a view of either the square or the puzzle) so developing solutions for
both was the best way to proceed.
4.3.1
Game logic
Development proceeded to implementation of a text-based interface alongside the game logic. This
would provide a safety net in case the graphical interface could not be implemented in time for the
progress meeting. It also offered a chance to practice the graphical interface implementation; design
and implementation issues would be highlighted in the development of the text interface and then dealt
with or avoided as appropriate when implementing the graphical interface.
Design of the game logic was kept simple. The Sudoku puzzle was implemented as a class called
Grid which had a collection of Square objects. In the previous iteration, a Sudoku generator was
35
found [4] which was adapted so that puzzles were generated in a space separated string format - this
made the puzzle easy to parse and transfer into the Grid and Square objects.
This was all held together with a SudokuGame class, representing the link between the user interface
and the network. When a player makes a move in the game, it is the responsibility of the SudokuGame
object to update the game state and then, if the move is allowed, send the move to the server to be sent
to other players. Similarly, if a client receives a move from the server, it needs to update the relevant
square and notify the user interface which can take appropriate action (i.e. redraw the grid).
4.3.2
Text user interface
This was a relatively simple interface to implement as its main purpose was to accept user input and
then pass on the information to the game logic layer. However, a mechanism was needed in the user
interface to handle updates from the server. Though the actual grid was updated in the game layer, the
change made needed to be conveyed to the user (i.e by redrawing the grid).
The solution was to implement a method in the text user interface class called update that takes
the position of the square that has changed and its new value as arguments. This way, the user interface
can be notified when and where a change has occurred and act accordingly. In the text interface, it simply redraws the grid. This is not quite the behaviour we would like as, if the user is entering something
when an update is received, the grid will be printed whether they have finished entering their input or not.
A solution to this quirk was possible but it was unnecessary. Though the behaviour was likely to frustrate
users, the text-based interface was only intended as an temporary interface to test the implementation of
the game logic and demonstrate the system at the progress meeting. A graphical user interface would
not face the same problem, so solving it in the text interface was not a priority.
4.3.3
Graphical user interface
The development of the graphical user interface came in two parts - the lobby interface and the game
interface. Each part was implemented in its own class to enable clean separation of code with a third
class to control which interface was displayed and to control the transition between the two.
36
The lobby interface was split into the lobby-chat area (an area where the current chat is displayed, with
a text field so users can send their own messages) and the new game/join game buttons. A screenshot of
the lobby can be seen in Figure 4.7.
Figure 4.7: Screenshot of the lobby
Clicking the new game button brings up a new window where a user can select how many players
are on a team, the type of game (co-operative or competitive) and the difficulty level of the puzzle. These
options are presented in such a way so that only valid options can be chosen. For example, the choice
of difficulty ranges from zero to four so a drop down menu with the choices is presented rather than a
text field where a user may enter invalid input. The Start New Game window can be seen in Figure 4.8.
Figure 4.8: Screenshot of the Start New Game dialogue
Once a user has set the parameters for a new game, they can create it - the details are sent to the
server and a new game is created there, details of which are sent to other clients looking to join a game.
On the client that set up the new game, the start game and join game buttons can no longer be pressed
- the server would not allow them to start a new game or join another but deactivating the button reinforces that the player has to wait for their game to start. The user can still send and receive messages
from the lobby whilst waiting for others to join the game.
The method for joining a game is similar. Upon clicking the join game button, a list of games waiting for players is retrieved from the server and presented in a selectable list. This window can be seen
37
in Figure 4.9 The user selects the game they wish to join and clicks the join button. Once again, the
game buttons in the main window deactivate though players can still chat in the lobby. This continues
with players joining a game until there are enough players (as specified by the person who set up the
game) at which point, the main lobby window on each of the participants machines closes and the game
interface is displayed in its place, displaying the puzzle set for the participants.
Figure 4.9: Screenshot of the Join Game dialogue
The main component of the game interface is a grid of text fields, each one representing a square of
the puzzle. The squares given at the start of the puzzle are not editable and numbers put into squares that
are editable by the user are displayed in a different colour from the given squares. This enables players
to easily identify which squares have been given and which ones are to be filled in by the players. A
screenshot can be seen in Figure 4.10.
Figure 4.10: Screenshot of the Game window
38
4.3.4
Interface updates
As with the text interface, an update method was used to inform the graphical interface that a change
had occurred to a square. In the graphical interface, updates can occur without disturbing user input.
With both types of interface, updates to the grid are not the only thing that a client could receive as
occasionally, information such as messages from other users or a list of available games is sent. The
way that this information is presented depends on the type of information it is; the update method, however, is only able to handle updates to the grid.
Two approaches to solving this problem were considered. Firstly, each category of information could
have a relevant method in a user interface that defines how the interface should handle that type of
received information. For example, an interface could have a receiveMessage method to deal
specifically with messages received from other players.
The other way of handling this is to prefix strings at the game logic level. This prefix acts as an identifier
for the type of message that follows. This could then be examined by the user interface which could
then make a decision about what to do with the information in the rest of the string.
The latter method was chosen as it was felt to be more flexible and slightly easier to implement. The
first technique required methods to be implemented in the user interfaces and specific method calls from
within the game logic level. If any of these needed changeing or a new one added, it required changes
across a number of classes. With the prefix technique, only one method of the interface class would be
called and adding new message categories message was as simple as adding an if statement.
The downside is that it arguably breaks the separability of the design that was being aimed for. Ideally, the user interface should not need to work out what type of message has been sent as this should
be done at the game level after a message is received. The prefix method was used despite this - it was
thought that it would offer quicker development, easier debugging and a change to the other method of
receiving messages could be made at a later date.
39
Chapter 5
Evaluation
5.1 Technical testing
Testing was performed throughout the implementation of the system. Most coding involves some testing
as the code is written but as the system here became more sophisticated, more sophisticated testing was
required. This was especially true around the development of two key parts in the system - the state of
connections and the definition of the protocol.
With the introduction of the state of a connection, there were clearly defined things that a connection could and could not do depending on its state. Testing this was a matter of going through these
different states and making sure the connection was able to do what it was supposed to and not do what
it was not supposed to. For example, a connection that has joined a game that has not started yet should
not be able to join another game but should be able to send messages to the lobby.
Similarly with the protocol, a code sent to a client should only have so many replies that can get sent
back. A reply depends on things such as the state of the connection and the state of certain objects on
the server, so testing to make sure that the correct responses are obtained in the right circumstances is
important.
40
Testing these took place as they were coded which uncovered numerous bugs that were then fixed.
As implementation took place incrementally, a feature was added, tested until it behaved correctly and
then work proceeded onto the next feature. The plan was to implement these tests in an automatic fashion to build a test suite that could be run periodically to make sure that new code had not broken any of
the old functionality. Unfortunately, there was not enough time to do this.
Because of the way the system was built from the network up, the networking components should
be pretty robust. Running some tests with the GUI uncovered some problems - all the games on a
server are not shown in the Join Game window if there is more than one game for example. In competitive games, sometimes a game broadcasts moves to both teams. However, these are GUI and Server
problems respectively and are not to do with the underlying network code.
5.2 User evaluation
The focus of the user testing needed to address whether the system produced actually solved the original
problem. This meant involving users to discover whether the system improved collaboration on Sudoku
puzzles.
5.2.1
Methodology
In [49] and [50], Ruddle et al. describe experiments that investigate how users interact with virtual environments, as well ideas as to how that interaction may be improved. The experiments involve observing
users to see how they perform when doing certain tasks and then adjusting certain parameters to see
how they affect performance.
Though the system developed here is not a graphical virtual environment as in the above experiments,
there are parallels that can be drawn in terms of evaluation. The aim of this system was to improve
collaborative performances on Sudoku puzzles. To evaluate how successful the system is at this, observation of collaboration without the system can be compared with collaboration using the system; if
when using the system, the performance is better then the system can be considered a success.
41
This was the method used to evaluate this project. Volunteers were grouped into pairs and given a
Sudoku puzzle on a sheet of paper, a single pen and 8 minutes to fill in as many blank squares on the
puzzle as the time allowed. Then the pair members were given adjacent PCs running the system built
here and given another 8 minutes to solve a different Sudoku puzzle. The reason for the PCs being
adjacent is to see how communication changes, even though the players are still in close proximity to
each other. Throughout both experiments, observations of how the pair were performing were made.
Before the first puzzle, the volunteers were asked how good they considered themselves to be at Sudoku and if they played, how they played (for example in a newspaper, in a book, online). They were
also asked if they played with other people and if so, how (for example, simultaneously, one person
at a time). After each puzzle, the participants were asked how they thought they had performed, what
problems they encountered (if any) and if they felt they were restricted in anyway. This brief discussion
was to see how they felt about the different ways of solving Sudoku collaboratively and to see if they
actually perceived there to be a problem in the first place.
There were a range of respondents to the request for volunteers and a range of experience and ‘skill’ levels in solving Sudoku puzzles. The pairs were arranged to provide a mixture of pair abilities - some pairs
had members of a similar (self-perceived) skill level, whereas others were a little more mis-matched.
This was to see if differing levels of ability would be affected in different ways. For example, in a
mis-matched pair, the player of higher ability may have been able to better communicate with the other
pair member when the puzzle was on paper, helping the weaker member learn how puzzles are solved.
Similarly, some respondents knew other respondents and pairs were formed to see if this would affect results. A pair where members knew each other may have been more communicative when solving
a puzzle and as a result solved more or fewer squares. Maybe the built system would lead to less
communication as players were on different (although adjacent) computers which could in turn affect
performance.
The main points investigated by the evaluation were differences in performance between a Sudoku
puzzle solved on paper and a Sudoku puzzle solved on the system. The results would show whether
42
or not the system was an improvement over the traditional pen and paper method. Ability levels were
varied and some pairs knew each other whereas some did not - this was to see if the system helped (or
hindered) some groups more than others.
In all, five pairs took part in the experiments. This may seem a low number but Nielsen and Landauer [43] conclude that between 3.8 and 4.2 users provide the most cost-effective testing for a small
project. Nielsen [42] later goes on to say 5 users is all you need to test with to find most usability
problems. Though the testing is not looking directly for usability problems, the purpose of the testing
is to identify the usability of the system as a whole and to see whether it improves a pair’s performance
over traditional methods of solving Sudoku puzzles collaboratively.
5.2.2
Results
Table 5.1 shows the results from the experiments. Each pair member’s self-perceived skill was mapped
to either ‘Beginner’ if the member did not have much experience with solving Sudoku puzzles (people
with no experience whatsoever were not part of the study), ‘Intermediate’ if they had some experience
and confidence but not much and ‘Advanced’ if the user considered themselves to have a fair amount of
experience and confidence with Sudoku puzzles.
Skill level
Squares filled on paper
Squares filled on system
Member 1
Member 2
Member 1
Member 2
Total
Member 1
Member 2
Total
Group 1
Advanced
Beginner
12
8
20
6
3
9
Group 2
Advanced
Advanced
10
6
16
26
22
48
Group 3
Beginner
Beginner
2
4
6
4
7
11
Group 4
Advanced
Intermediate
16
11
27
21
18
39
Group 5
Beginner
Intermediate
5
10
15
3
13
16
Table 5.1: Results of users playing Sudoku on paper and on the system
5.2.3
Results analysis
Four of the five groups showed improvements when using the system compared to a shared puzzle on
paper and a pen. The first group commented that the puzzle on the system seemed harder than the one
43
on paper, so this may partly explain the discrepancy.
The improvement in performance varies in relation to skill level as shown in Figure 5.1. Beginners
see no performance increase; in fact, the number of squares they provide on the puzzle actually decreases when playing on the system. This could be due to less communication between players when
using the system or the lack of a shared space to solve the puzzle in - the weaker player no longer has
the visual cues or feedback from the stronger player who simply gets on with solving the puzzle.
Figure 5.1: Variance in performance at different skill levels
Stronger players, however, see a marked improvement. On average, intermediate players filled in
five extra squares on the system than on the paper and advanced players increased their performance
by 7.75 squares. This would suggest that simply having their own version of the puzzle to work on
improves a non-beginners performance.
Because of this, it comes as no real surprise that the system helps pairs of non-beginners the most.
Of the groups that saw improvements when using the system, groups with beginners saw very little
improvement whereas those without saw the biggest performance increases.
5.2.4
Observations
The biggest difference between solving a puzzle on paper and solving a puzzle using the system was the
level of communication. When sharing a puzzle on paper, pairs communicated in many different ways
44
and for many different reasons. Some of the reasons observed included: thinking aloud to indicate lines
of thought to the other player; explanation of recent moves; pointing out mistakes; or explaining some
of the logic rules that can be used to work out answers to squares.
When using the system, communication between group members in all pairs was reduced; in most
cases, drastically so. Volunteers had mixed reactions about this - most preferred that there was no communication as they could ‘just get on with it’ rather than have to communicate or coordinate with the
other group member. One group commented that they liked using the system as it allowed each group
member to keep their own train of thought.
The groups that continued to communicate when on the system experienced more difficulty than those
that did not. Without a common puzzle space (that the paper provides) it became harder to describe
what squares were being talked about; this is one of the problems that the system set out to solve! One
participant said they preferred the pen and paper method because of the easier communication.
Solving the puzzle on paper was more sociable than expected and the groups that knew eachother beforehand were generally more communicative in both attempts at solving the puzzles. Despite this,
most participants claimed not to mind the reduced communication and the results indicated it did not
dent performance enough to outweigh the performance gains.
There was sufficient evidence from the observations to reinforce the view that sharing one copy of
the puzzle on paper and a pen is problematic. Most groups typically had one member with the pen who
filled in the squares with the other member pointing out squares they had worked out. All groups experienced confusion in their communications at some point whether it was because it was unclear which
square was being pointed at or because of misunderstood explanations.
One of the groups highlighted another problem previously unconsidered with the pen and paper method.
In this pairing, there was one member who proved to be very controlling of putting answers into squares.
Even when asked by the other group member to make the puzzle more visible, he continued to obscure
the view. There were also times when the other group member would offer answers that went ignored.
45
The system helps level the playing field in situations like these. As each player has their own interface to the puzzle it means that players do not get shut out from helping to solve it by a more dominant
member. As a result, the group member who was kept out from the puzzle on paper performed better
when using the system.
To summarise, the experiments did highlight a multitude of problems with pairs solving Sudoku puzzles
with just one copy of the puzzle on paper and a single pen. The results show that the system did improve
performance but improvements were limited to those who were moderately skilled at Sudoku and higher
- beginners saw no improvement. The difference in the level of verbal communication between the two
experiments in most cases was vast, though most participants claimed not to mind this. In conclusion,
it would appear that the system goes a long way in solving the original problem.
5.3 Development methodology
Using the Agile Unified Process (AUP) for development considered successful, especially because it
encouraged development to begin early. This allowed code written as technology and design research
to form the base of a system. It also meant that work on a solution began as soon as possible; progress
was easily gauged against how far the system implemented the required functionality in the minimum
requirements.
As an agile, iterative process, the AUP allowed development in the early stages to focus on the important functionality and deliverables first and then adding other features in later iterations. This meant
that time was not wasted trying to get advanced features working early on that would not have been
implemented in the time available anyway. This saved the project from over-ambition many times.
One of the AUP’s aims is to encourage agility throughout development. This was definitely one of
the biggest advantages of the process as the focus was on developing a system rather than completing
unnecessary diagrams and modelling. In a self-enclosed project such as this one, excessive requirements
and design modelling is not needed and it was the only methodology that seemed to recognise that it was
unnecessary for a project of this size. Large projects, with large teams and long project lifetimes need
proper requirements gathering and design to be captured in documents and artefacts that other processes
46
advise. This was not such a project and the choice of a more flexible methodology was certainly the
correct one.
If there is anything negative to say about the AUP, it is that it would take a disciplined set of individuals (or very well-managed) to apply it in a team. The concepts of doing ‘just enough’ and ‘applying
agility throughout’ could lead to under-developed requirements capture and quickly built systems that
have to be constantly reworked to meet missed requirements.
5.3.1
Schedule
The schedule for this project changed a lot and, seemingly, always for the worse. On reflection however,
it was not as bad as it may have seemed.
Part of the perception that the plan was always running late is that at the end of each iteration in the
AUP, the plan needs to be updated and revised. At the end of all 3 iterations, work was behind schedule
and once a plan falls behind schedule, it is very difficult to catch up. The reasons for the lateness each
time was that the amount of work had been underestimated and had moved slower than anticipated. It is
very hard to accurately predict how long things are going to take, especially when so much of the work
is new material.
Ultimately, it is the response that counts. Compromises and changes were made; for example the original plan was to present a GUI version of the system at the progress meeting but this had to be the text
interface instead. As a result, despite the schedules falling behind, no deadlines were missed. Looking
back at the mid-project report, work on the design and implementation was finished not too far behind
what was originally planned. The evaluation took place two weeks after originally intended. Overall,
work took place far more in parallel than the original plan scheduled. This, and that there was so much
time allocated for the write helped to keep things on track.
5.4 Other systems
At the research stage of the project, the only existing solution that allowed multiple players was Go!
Sudoku, a game that required expensive hardware to play. Since then, the situation has changed and
47
there are a few such systems available.
Sudoku Live [1] offers a sophisticated Sudoku system capable of co-operative and competitive play.
As well as offering visual flair, it also boasts features such as built in chat to allow communication with
other players. A professional looking solution, Sudoku Live comes at a price of $19.95 and is released
under a closed source license. Therefore any changes or additions to the system must be made by the
system’s author.
Synthetic Sudoku [17] is a freely available Sudoku game that allows for competitive play. The license
is also closed source, so like Sudoku Live, changes and additions to the software must be made by the
software authors. Though competitive play is supported, this system lacks co-operative play. Nor is
there a lobby, meaning players must know how to set up or join games before they can play.
Sudoku Sniper [2] is a mobile version of Sudoku written for the .Net Compact Framework that allows for multi-player games over Bluetooth. Only a competitive mode is available, which offers a twist
to the competitive mode developed for the system in this project. Players compete on the same grid and
can see the answers to squares their opponents have filled in. For each square a player fills in, they are
awarded a point and once the grid is full, the player with the most points wins.
That a number of projects offering multi-player Sudoku have appeared since the start of this project
is testament to the strength of the idea. Though all offer professional, well-rounded solutions, each has
its own weaknesses. Most lack a lobby system to allow games to be started and joined as easily as the
system developed here, two of them require payment to obtain and none of the systems mentioned here
are open-source.
5.5 Minimum requirements and extensions
The system needs to be evaluated against the minimum requirements. When measured in this way, the
project is a success; a protocol was developed for networked Sudoku which was then implemented in a
system to allow for collaborative and competitive modes of play, for teams of two or more players.
48
Of the possible extensions listed at the start of the project, only automatic setting of puzzles was
achieved. The solution to the puzzle was also generated so it could be argued this extension was also
met but the system as it is does not solve arbitrary puzzles. Then again, no such interface in the system
exists to enter such puzzles and in retrospect, the extension seems out of place for a project with such
specific functionality as this one.
There were other extensions implemented that were outside those listed at the start of the project. The
lobby system where users can chat and arrange games before launching a puzzle is the most obvious
and biggest enhancement to the project. Though other systems have emerged that allow multi-player
Sudoku, most do not have lobby systems to meet other players and find games waiting for other players
to join. Having the pre-game lobby makes starting or joining games easier, especially for those unfamiliar with networking.
Finally, the system has been designed to enable components to be easily extended or changed in the
future. This flexible design opens up a lot of possibilities for further development and investigation.
5.6 Further extensions
The system developed for this project has many possible future extensions, some of which may be possible as future final year projects.
One of the design goals was to produce a system where individual parts could change without affecting
the rest of the system. Possible extensions could involve changing some of these components to test this
design. There are network technologies that could replace the sockets used in this system to enhance the
network connectivity. This system could be extended as an exercise in assessment of these technologies,
some of which were discussed in this report such as JXTA and Jini.
One of the possible extensions was to port the game to mobile devices. It was originally hoped this
would be possible but it proved to be a significant undertaking. Connectivity on mobile devices is certainly an interesting area and this system should provide enough of a base to investigate the possibilities.
49
Other, less drastic changes involve the game components. An obvious extension is to add further game
modes and different ways of playing Sudoku with other people. The system could also be used as a base
for collaborative versions of other games, for example a collaborative crossword. Again, this would test
how reusable the components of the system are.
Finally, the system was built as a prototype and therefore the user interface is unpolished. The users who
tested the system offered their thoughts on how the system could be improved. Some suggestions were
about adding functionality to help solving of the puzzle - for example, selectable levels of assistance to
indicate when an incorrect number has been entered, or showing when all of one of the digits have been
entered into the grid. Others were about improving communication in the game or giving better indications of what the other player is doing. Examples include: showing which square other players currently
have highlighted; making squares that have just been filled in more obvious; and having some sort of
chat function. All of these could be investigated to see if they improve performance in collaborative
games any further.
50
Bibliography
[1] Dead Pixel - Live Games. Available from: http://www.deadpixelgames.com/ Last accessed:
30/04/06.
[2] DKM Software. Available from: http://www.dkmsoftware.com/ Last accessed: 30/04/06.
[3] Eclipse.org Home Page. Available from: http://www.eclipse.org/ Last accessed: 30/04/06.
[4] Free Sudoku Home Page.
Available from: http://freesudoku.sourceforge.net/ Last accessed:
30/04/06.
[5] G-Sudoku. Available from:
http://www.yzonesoft.com/gsudoku/gsudoku.html Last accessed: 30/04/06.
[6] Go! Sudoku. Available from: http://www.go-sudoku.com/ Last accessed: 30/04/06.
[7] JADE FAQ. Available from: http://jade.cselt.it/community-index.htm Last accessed: 18/04/06.
[8] Java Platform, Micro Edition (Java ME). Available from: http://java.sun.com/javame Last accessed: 01/05/06.
[9] Java Technology Home Page. Available from: http://java.sun.com/ Last accessed: 01/05/06.
[10] JXME Project Home Page. Available from: http://jxme.jxta.org Last accessed: 30/04/06.
[11] LEAP User Guide. Available from:
http://mia.ece.uic.edu/ papers/MediaBot/jade/doc/LEAPUserGuide.pdf
Last accessed: 01/05/06.
[12] Microsoft .Net Compact Framework. Available from: http://msdn.microsoft.com/mobility/netcf/
Last accessed: 01/05/06.
51
[13] Microsoft .Net Homepage.
Available from: http://www.microsoft.com/net/ Last accessed:
01/05/06.
[14] Nokia Developer Resources. Available from: http://www.forum.nokia.com/main.html Last accessed: 30/04/06.
[15] SourceForge.net Home Page. Available from: http://sourceforge.net/ Last accessed: 30/04/06.
[16] Sudoku Fun. Available from: http://www.sudokufun.com/ Last accessed: 30/04/06.
[17] Synthetic Sudoku Home Page. Available from: http://www.syntheticsudoku.co.uk/ Last accessed:
30/04/06.
[18] RFC 2616: Hypertext Transfer Protocol – HTTP/1.1, 1999.
[19] The Jini Technology Surrogate Architecture Overview, 2001.
http://surrogate.jini.org/overview.pdf Last accessed: 30/04/06.
[20] Bluetooth JXME Status Page, 2003. Available from:
http://bluetooth-jxme.jxta.org/docs/status.html Last accessed: 30/04/06.
[21] Jadabs-JXME-BT, 2004. Available from:
http://jadabs.berlios.de/jadabs-cldc/multiproject/jxme-bt-j2me/index.html
Last accessed: 30/04/06.
[22] Jini Technology for Dynamic Networking, 2005. Available from:
http://java.sun.com/developer/community/chat/JavaLive/2005/jl0111.html
Last accessed: 30/04/06.
[23] JXTA v2.3.x: Java Programmer’s Guide, 2005. Available from:
http://www.jxta.org/docs/JxtaProgGuide v2.3.pdf Last accessed: 30/04/06.
[24] Mobile Downloads - UK, August 2005. Market Intelligence Essentials (Mintel Reports).
[25] From Deck to Direct: As The Data Channel Turns. Wireless Business Forecast, 14(6), 2006.
[26] S. Si Alhir. Understanding the Unified Process (UP). Methods & Tools, 10(1):2–18, 2002.
[27] S. Si Alhir. The Agile Unified Process (AUP), 2005. Available from:
http://home.comcast.net/ salhir/TheAgileUnifiedProcess.PDF Last accessed 30/04/06.
52
[28] S. Ambler. The Agile Unified Process v1.0, 2005. Available from:
http://www.ambysoft.com/downloads/AgileUP.ZIP Last accessed: 30/04/06.
[29] K. Arnold, B. O’Sullivan, R.W. Scheifler, J. Waldo, and A. Wollrath. The Jini Specification.
Addison-Wesley, 2001.
[30] Simon Beloglavec, Marjan Heričko, Matjaž B. Jurič, and Ivan Rozman. Analysis of the limitations
of multiple client handling in a java server environment. SIGPLAN Not., 40(4):20–28, 2005.
[31] R. B’Far. Mobile Computing Principles: Designing and Developing Mobile Applications with
UML and XML. Cambridge University Press, 2005.
[32] L. Gong. Project JXTA: A Technology Overview, 2002. Available from:
http://www.jxta.org/project/www/docs/jxtaview 01nov02.pdf Last accessed: 30/04/06.
[33] S. Hashman and S. Knudsen. The Application of Jini Technology to Enhance the Delivery of
Mobile Services, 2001. Available from:
http://www.microjava.com/articles/PsiNapticMIDs.pdf Last accessed: 30/04/06.
[34] Michael Hirsch. Making RUP agile. In OOPSLA ’02: OOPSLA 2002 Practitioners Reports, pages
1–ff, New York, NY, USA, 2002. ACM Press.
[35] Andreas Janecek and Helmut Hlavacs. Programming interactive real-time games over wlan for
pocket pcs with j2me and .net cf. In NetGames ’05: Proceedings of 4th ACM SIGCOMM workshop
on Network and system support for games, pages 1–8, New York, NY, USA, 2005. ACM Press.
[36] D. Käppeli. JXTA Over Bluetooth. PhD thesis, Swiss Federal Institute of Technology Zurich,
2003.
[37] J. Klensin. RFC 2821: Simple Mail Transfer Protocol, 2001.
[38] P. Kroll. The Spirit of the RUP, December 2001. The Rational Edge.
[39] J. Kurose and K. Ross. Computer Networking: A Top-Down Approach Featuring the Internet.
Addison-Wesley, 3rd edition, 2005.
[40] A. Leon-Garcia and I. Widjaja. Communication Networks: Fundamental Concepts and Key Architectures. McGraw Hill, 2nd edition, 2004.
53
[41] M. Mepham. Solving Sudoku. Available from:
http://www.sudoku.org.uk/PDF/Solving Sudoku.pdf Last accessed: 30/04/06.
[42] Jakob Nielsen.
Why You Only Need to Test With 5 Users, 2000.
Available from:
http://www.useit.com/alertbox/20000319.html
Last accessed: 30/04/06.
[43] Jakob Nielsen and Thomas K. Landauer. A mathematical model of the finding of usability
problems. In Proceedings of ACM INTERCHI’93 Conference, pages 206–213, Amsterdam, The
Netherlands, 1993.
[44] E. Pitt. Fundamental Networking in Java. Springer, 2006.
[45] J. Postel and J. K. Reynolds. RFC 959: File Transfer Protocol, 1985.
[46] Olga Ratsimor, Dipanjan Chakraborty, Anupam Joshi, Timothy Finin, and Yelena Yesha. Service
discovery in agent-based pervasive computing environments. Mob. Netw. Appl., 9(6):679–692,
2004.
[47] M. Reinhold. Java Specification Request 51: New I/O APIs for the Java Platform, 2000. Available
from: http://www.jcp.org/en/jsr/detail?id=51 Last accessed: 30/04/06.
[48] W.W. Royce. Managing the development of large software systems: concepts and techniques.
1970 WESCON technical papers volume 14, Western electronic show and convention, 14:8 pp. –,
1970.
[49] R.A. Ruddle. The effect of trails on first-time and subsequent navigation in a virtual environment.
IEEE Virtual Reality 2005 (IEEE Cat. No.05CH37649), pages 115 – 22, 2005.
[50] R.A. Ruddle and D.M. Jones. Movement in cluttered virtual environments. Presence (USA),
10(5):511 – 24, 10 2001.
[51] S. Singhal and M. Zyda. Networked Virtual Environments: Design and Implementation. Addison
Wesley, 1999.
[52] A.S. Tanenbaum. Computer Networks. Prentice Hall, 3rd edition, 2001.
[53] A.S. Tanenbaum and M. van Steen. Distributed Systems: Principles and Paradigms. Prentice Hall,
2002.
54
[54] Ivan Vaghi, Chris Greenhalgh, and Steve Benford. Coping with inconsistency due to network
delays in collaborative virtual environments. In VRST ’99: Proceedings of the ACM symposium
on Virtual reality software and technology, pages 42–49, New York, NY, USA, 1999. ACM Press.
[55] Conrad Weisert. There’s no such thing as the Waterfall Approach! (and there never was), 2003.
Available from: http://www.idinews.com/waterfall.html Last accessed: 30/04/06.
[56] M. Yuan. Challenges and Opportunities in Mobile Games, 2004.
http://www-128.ibm.com/developerworks/wireless/library/wi-austingameconf.html
Last accessed: 01/05/06.
55
Appendix A
Personal Reflection
I was on placement before my final year and something that surprised me about the other placement
students that I met throughout the year was how early some of them started their final year projects. It
varied from university to university; but some required work to be done over the summer before returning for the final year. Having now completed the project, I can certainly see the benefit of starting things
so early.
Originally, I had an ambitious vision for my project. Though 400 hours of work sounds like a lot,
it goes quickly so my advice to anyone wishing to use their project for something ambitious would be
to start early. Your project will not be assigned until later so there is a risk you will not be able to do it,
but speak with someone who can help minimise this risk. Reading and experimenting with things such
as JXTA before returning to university may have meant I could have shown more ambition at the design
and implementation stage.
I confess to being slightly dissatisfied with the end result of my project and I have a few thoughts
on this. Partly I believe this happened because when designing and implementing the system, I made
many ‘safe’ choices. I believe this was the right thing to do as it meant I met deadlines and these choices
probably saved me from my own ambition. In that respect, I do not regret making these decisions.
56
There is the nagging doubt however that making these safe choices dulled the project in some ways.
Instead of getting to try out a lot of new and exciting things as I had originally envisioned, I settled for
something I knew would work, with the possibility of trying something more adventurous later. Through
no real fault of my own, these possibilities were always slim and making these choices probably meant
the difference between a working system that fully met the requirements and one that met a few and did
not fully work. But it is another argument for starting early if possible.
It may sound like I am unhappy with my project but this is certainly not the case. I believe it is possible
to get too close to your project and forget what you have achieved. This realisation came when explaining to a friend that the socket programming that underpins the system was not complicated. As someone
who had not done any socket programming however, to them it did not sound trivial. At the start of this
project, I probably would have felt the same.
Simply, I have learnt a massive amount and been able to get experience in fields I had not tried before: socket programming, multi-threaded code, Java Swing. Even the things that I read about but did
not use have contributed massively to my knowledge and that is incredibly rewarding.
Some advice for students who are yet to start their final year project. Firstly, do not underestimate
the write-up - it takes up a massive amount of time and I wish I’d started mine earlier. Write early and
write often and that way the deadlines are not so hard on you. Try and hand in quality work at the midproject report and draft chapter stages; between them, you should be able to get high-quality feedback
on 20-30 pages of your report.
Finally, there are many variables in a final year project: the problem, the approach to solving it, the
type of project, the student, the supervisor and many more. At points, either when looking at past
projects or talking with friends you will notice differences in what you are doing which may cause
alarm for some people. But do not worry. You can look to others to see how to approach aspects of
the project but at some point you have to accept that what you are doing is unique and that you have to
make your project your own. Look at others for guidance but ultimately, you have to do your project in
the most appropriate way you think possible. Accepting this can make your life somewhat easier.
57
Appendix B
Glossary of Sudoku Terms
Square - The smallest component of a Sudoku Puzzle. A square holds a single number
Box - A box is a 3 by 3 collection of squares
Grid - The grid is the entire puzzle, a 9 by 9 collection of squares
Column - A single column of squares in the grid (the length of which is 9)
Row - A single row of squares in the grid (the length of which is 9)
Given - A square in the puzzle that is filled in at the start of the game; hence the answer is “given”
58
Appendix C
System Protocol
The following is a table containing all the codes in the protocol that the developed system uses. Entried
under ‘Code’ indicate the code sent, entries under ‘Sender’ indicates whether the client, server or both
can send the code, ‘Carries data?’ indicates whether any data follows the code and ‘Meaning’ explains
what the code represents.
Code
Sender
Carries data?
Meaning
110
Client
N
Client’s initial message on connecting to the server
111
Server
N
Server’s response to code 110
120
Client
Y
A message to be broadcast to other players in the lobby
121
Server
N
Message received by server (see code 120) and being sent to other
players in the lobby
122
Server
Y
Message from another player received from the server - message
follows in data
190
Client
N
Client is disconnecting
191
Server
N
Server disconnecting
Table C.1: Informational/Lobby messages
59
Code
Sender
Carries data?
Meaning
210
Client
N
Request for a list of games
211
Server
Y
List of games currently available on the server and information
about them. Format: gameID,gameType,numberOfPlayers
220
Client
Y
Request to start a new game.
Game details follow in data
in the format of a comma separated list:
numberOfPlay-
ers,gameType,puzzle
221
Client
Y
Puzzle answer (follows in data)
230
Client
Y
Request to join a game. Game ID number follows in data
231
Server
N
Accepted into game, waiting for other players
232
Server
N
Puzzle answer was set
Table C.2: Game set up messages
Code
Sender
Carries data?
300
Client
Y
Meaning
Game move follows in data. Format: XYZ where X is the row, Y
is the column and Z is the value
301
Server
Y
Move from server follows in data, see code 300 for format
302
Server
N
Opponents have filled a square (competitive mode only)
310
Client
Y
Players’ solution to the grid follows in data
310
Server
Y
Game’s puzzle follows in data (implicit suggestion the game has
started)
321
Server
Y
Game over, game over string from server follows in data
Table C.3: In game messages
60
Code
Sender
Carries data?
Meaning
410
Server
N
Client sent unrecognised command to server
411
Server
N
Client tried to broadcast a message whilst in a game
420
Server
N
Error setting up the game
421
Server
N
Client registered in a game and tried to start a new one
422
Server
N
Client tried to start game with invalid number of players
423
Server
N
Client registered in a game and tried to join another
424
Server
N
Invalid game ID specified when trying to join a game
425
Server
N
Error setting up game
426
Server
N
Error joining game
427
Server
N
Error setting puzzle answer
430
Server
N
Invalid in-game command sent
431
Server
N
Client can not send a move, is not a participant of a game
Table C.4: Error messages
61