University of Manchester
School of Computer Science
Project Report 2015
Turn-Based Online Games
Author: Rui Jorge Clara Teixeira
University ID: 8501263
Supervisor: Dr Rizos Sakellariou
Word Count: 8798
Abstract
Turn-Based Online Games
Author: Rui Jorge Clara Teixeira
This report presents the development of a server-side game framework. This framework is targeted at turn-based online games. It sets itself apart from existing solutions for being highly
customizable. The approach was to develop the framework and to apply it by building two
games: a chess game and a poker game. Applying the framework allowed to improve it incrementally through the project. The framework is customizable in different ways and it is built to
support a wide range of turn-based online games. The project also involved the development
of a web application to help developers manage the flexibility of the framework.
The most important points to take from this report is why it is considered a success and how it
became a success. To explain these points, the report follows a logical structure, starting with
the research stage which serves as the base for the project. This is followed by the requirements
gathering results defining features users are offered in different parts of the project. Then, the
design, the implementation and the testing of the software is presented. Finally this there is a
reflection on the plan, approach, testing and use of the project.
All in all, building a framework allowed a better understanding of distributed systems without
being constrained by the specifics of a game. Furthermore building different systems with
various different technologies was an invaluable learning experience.
Supervisor: Dr Rizos Sakellariou
Acknowledgements
I would like to thank Dr Rizos Sakellariou for guiding me, pushing me to do
better throughout the project and supporting me in trying new technologies and
approaches. I would also like to thank Dr Richard Neville for his feedback which
brought a fresh perspective.
1
Contents
1
2
3
4
Introduction
1.1 Project Overview . . . . . . . . .
1.2 Existing Solutions . . . . . . . . .
1.2.1 Marauroa . . . . . . . . .
1.2.2 SmartFoxServer . . . . .
1.2.3 Photon Turnbased . . . .
1.3 Proposed Solution and Motivations
1.4 Aims and Milestones . . . . . . .
1.5 Report Structure . . . . . . . . . .
Background
2.1 Overview . . . . . . . . .
2.2 Turn-Based Online Games
2.3 Client-Server Architecture
2.4 Software Frameworks . . .
2.5 Summary . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Requirements
3.1 Overview . . . . . . . . . . . . . . .
3.2 Stakeholder Analysis . . . . . . . . .
3.3 Features List . . . . . . . . . . . . . .
3.4 Requirements . . . . . . . . . . . . .
3.4.1 Functional Requirements . . .
3.4.2 Non-Functional Requirements
3.5 Context Diagram . . . . . . . . . . .
3.6 Use Cases . . . . . . . . . . . . . . .
3.7 Summary . . . . . . . . . . . . . . .
Design
4.1 Overview . . . . . . . . . . .
4.2 Overall Project Design . . . .
4.3 Framework . . . . . . . . . .
4.3.1 Research & Decisions
4.3.2 Modularity . . . . . .
4.3.3 Software Design . . .
4.4 Customizer . . . . . . . . . .
4.5 Chess Game . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
2
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
7
7
7
7
8
8
8
8
9
.
.
.
.
.
10
10
10
11
11
11
.
.
.
.
.
.
.
.
.
12
12
12
13
14
15
16
17
17
18
.
.
.
.
.
.
.
.
19
19
19
19
20
21
22
27
27
4.6
4.7
5
6
7
8
Poker Game . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Implementation
5.1 Overview . . . . . . . . . . . . . . . . . .
5.2 Overall Implementation . . . . . . . . . . .
5.3 Framework . . . . . . . . . . . . . . . . .
5.3.1 Software Engineering Methodology
5.3.2 Prototypes . . . . . . . . . . . . .
5.3.3 Implementation Technologies . . .
5.3.4 Algorithmics . . . . . . . . . . . .
5.4 Customizer . . . . . . . . . . . . . . . . .
5.4.1 Software Engineering Methodology
5.4.2 Implementation Technologies . . .
5.4.3 Database . . . . . . . . . . . . . .
5.5 Chess Game . . . . . . . . . . . . . . . . .
5.5.1 Software Engineering Methodology
5.5.2 Implementation Technologies . . .
5.6 Poker Game . . . . . . . . . . . . . . . . .
5.6.1 Software Engineering Methodology
5.6.2 Implementation Technologies . . .
5.7 Summary . . . . . . . . . . . . . . . . . .
Testing
6.1 Overview .
6.2 Framework
6.3 Customizer
6.4 Games . . .
6.5 Summary .
.
.
.
.
.
.
.
.
.
.
Results and Analysis
7.1 Overview . . .
7.2 Framework . .
7.3 Customizer . .
7.4 Chess Game . .
7.5 Poker Game . .
7.6 Summary . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Reflection
8.1 Overview . . . . . . . . . . . . . . . . . . .
8.2 Testing Evaluation . . . . . . . . . . . . . .
8.3 Approach Evaluation . . . . . . . . . . . . .
8.4 Project Planning and Management Evaluation
8.5 Overall Effect . . . . . . . . . . . . . . . . .
8.5.1 Challenges . . . . . . . . . . . . . .
8.5.2 Successes . . . . . . . . . . . . . . .
8.6 Possible Improvements . . . . . . . . . . . .
8.7 Summary . . . . . . . . . . . . . . . . . . .
3
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
29
29
29
29
30
30
30
31
32
32
32
32
33
33
33
33
33
33
34
.
.
.
.
.
35
35
35
35
36
36
.
.
.
.
.
.
37
37
37
38
38
39
39
.
.
.
.
.
.
.
.
.
40
40
40
40
41
41
41
41
41
42
9
Conclusion
43
9.1 Project Future . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
9.2 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Bibliography
44
Glossary
46
A User Interfaces
A.1 Customizer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.2 Chess Game . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.3 Poker Game . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
47
47
49
51
B Framework Use Case Descriptions
54
C Requirements Gathering
56
C.1 Customizer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
C.2 Chess Game . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
C.3 Poker Game . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
D Initial Plans
D.1 Initial Plan of the Framework . .
D.2 Initial Plan of the Games . . . .
D.3 Initial Design of the Framework
D.4 Initial Design of the Chess Game
.
.
.
.
.
.
.
.
.
.
.
.
4
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
64
64
64
65
65
List of Figures
3.1
3.2
3.3
Stakeholder Power/Interest Grid . . . . . . . . . . . . . . . . . . . . . . . . . 12
Context Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Framework’s Use Case Diagram . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.1
4.2
4.3
4.4
Example of adding a Listener Module .
Framework’s Hierarchical Task Analysis
Framework’s Class Diagram . . . . . .
Framework’s Sequence Diagram . . . .
5.1
Customizer’s Entity-Relationship Diagram . . . . . . . . . . . . . . . . . . . . 32
A.1
A.2
A.3
A.4
A.5
A.6
A.7
A.8
A.9
Customizer’s User Interface . . .
Framework’s Getting Started Page
Chess Game’s Login Screen . . .
Chess Game’s Lobby Screen . . .
Chess Game’s Game Screen . . .
Poker Game’s Login Screen . . .
Poker Game’s Register Screen . .
Poker Game’s Lobby Screen . . .
Poker Game’s Game Screen . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
22
23
25
26
47
48
49
49
50
51
51
52
53
C.1 Customizer’s Use Case Diagram . . . . . . . . . . . . . . . . . . . . . . . . . 58
C.2 Chess Game’s Use Case Diagram . . . . . . . . . . . . . . . . . . . . . . . . . 59
C.3 Poker Game’s Use Case Diagram . . . . . . . . . . . . . . . . . . . . . . . . . 63
D.1 Framework’s Initial Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
D.2 Chess Game’s Initial Design . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
5
List of Tables
3.1
3.2
3.3
Framework’s Features list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Framework’s Functional Requirements . . . . . . . . . . . . . . . . . . . . . . 15
Non-Functional Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.1
Class Responsibility-Collaborators Cards . . . . . . . . . . . . . . . . . . . . 24
B.1
B.2
B.3
B.4
Develop Server Use Case Description . .
Start Server Use Case Description . . . .
Handle Connection Use Case Description
New Message Use Case Description . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
54
54
55
55
C.1
C.2
C.3
C.4
C.5
C.6
C.7
C.8
C.9
Customizer’s Features list . . . . . . . . . . .
Customizer’s Functional Requirements . . . .
Customizer’s Non-Functional Requirements .
Chess Game’s Features list . . . . . . . . . .
Chess Game’s Functional Requirements . . .
Chess Game’s Non-Functional Requirements
Poker Game’s Features list . . . . . . . . . .
Poker Game’s Functional Requirements . . .
Poker Game’s Non-Functional Requirements
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
56
57
57
59
60
60
61
62
62
6
.
.
.
.
Chapter 1
Introduction
1.1
Project Overview
This project involved designing and implementing a server-side framework for development
of turn-based online games. The framework was required to provide support for the user to
develop a complete system from networking to game logic.
Most of the functionality was implemented in the form of modules which can be combined
to produce various types of game servers. The modularity of the framework was one of the
main focus points during the project. A web application was also created to help users configure
these modules.
In order to prove the flexibility of this platform a part of the project was dedicated to the
development of two distinct games: a chess game and a poker game. These were designed to
be different in terms of logic, their infrastructures and their support features.
1.2
Existing Solutions
According to the latest study by Gartner the game industry was worth $93bn in 2013 and this
number is expected to grow to $111bn in 2015 [1]. With such a large industry it is not possible
to list all the existing solutions.
The following are the most notorious solutions of frameworks that can be used to build
turn-based online games. Understanding existing solutions helped find gaps in their features
and formulate a solution that differentiates itself from these.
1.2.1
Marauroa
Marauroa is a Java server-side framework for the development of multiplayer games. It supports Java and Python code extensions to game logic. Persistent storage is available through
MySQL databases. Communication with clients is established through a TCP oriented protocol [2].
Providing all the infrastructure to the user is a useful feature. However, this feature also
limits the possibilities of the user changing the lower level details of the server.
7
1.2.2
SmartFoxServer
It is a complete Software Development Kit (SDK) for the development of multiplayer games.
It provides not only a complete toolset to build the server-side architecture but also client APIs
for several languages [3].
The fact that this is a closed sourced solution makes it hard to extend the functionality and
limits the clients to the languages currently supported by their API. In order to create clients
in an unsupported language the developer would have to reverse engineer their communication
protocol.
1.2.3
Photon Turnbased
This is the only solution presented that is more focused on the development of turn-based
online games even though it later evolved to support all types of online games. The SDK
provided gives the user full control over low level details such as the communication protocol
and message format.
The drawback of this system is that it is built to be ran on their own cloud platform. Despite
offering an access to a variety of external services, the user has to be bound to their infrastructure [4].
1.3
Proposed Solution and Motivations
The proposed framework that was developed during this project sets itself apart from existing
solutions for being highly flexible. The system was built to have a core system with all the
networking facilities and basic game logic. The user should be able to build any type of turnbased only game using this as a base.
In order to provide more features apart from low level infrastructure the core was designed
to allow full customization. This can be done both by changing its inner working and by adding
modules with different functionality. A web application was created in order to help with these
modular customizations.
In addition to the server-side flexibility the framework was also built to be language agnostic
on the client-side. By default it uses a communication protocol with standardized technologies
and formats which further contributes to this flexibility.
1.4
Aims and Milestones
The final goal of this project was to produce a polished framework that could be used outside
the scope of this project. In order to achieve this an iterative Agile-like approach was taken.
This approach consisted of applying the framework to the development of two game servers in
order to receive immediate feedback on the design.
Building two different games also helped validate another aim of the framework. It helped
prove that using the same base it was possible to obtain different systems.
8
In order to reach these aims the most important milestones were:
1. Design and develop an initial prototype of the framework
2. Design and develop the chess game using the prototype
3. Improve the framework based on the experience of building the game
4. Improve the chess game taking advantage of changes to the framework
5. Design and develop the poker game using the latest version of the framework
In addition to these aims there were also personal aims. Two of the most important were
improving knowledge on distributed systems and learning new programming languages.
1.5
Report Structure
This report starts by giving Background information that was essential when designing the
framework and to support all the decisions made throughout the development. Then an analysis of Requirements is made that includes the requirements, stakeholder analysis, and use case
descriptions. Design and Implementation cover all the steps taken to go from the initial requirements to the final product. In the Results section the final product is shown. In order to validate
the results this report includes the Testing results as well as an Analysis of Results. Finally a
balance of the whole process is made in the Reflection chapter.
9
Chapter 2
Background
2.1
Overview
This chapter starts by describing turn-based games highlighting what characteristics need to
be taken into account when implementing them as online games. After this it describes clientserver architectures and gives some focus to the chosen architecture. Finally there is a brief
analysis of what a development framework should offer to the user.
2.2
Turn-Based Online Games
The definition of a turn-based game is broad and for some games it can be hard to define if it
falls under this category or under real-time games [5]. In order to provide basic game logic it
was important to define what turn-based means in the scope of the project.
The definition chosen is more related to classic board and card games and establishes the
following basic logic. Each player has a turn to play. In each turn the game state doesn’t
change unless in exceptional circumstances until the player who holds the turn makes a move.
A sequence of turns that covers all players in the game once is called a round. Between turns
and rounds as well as at the start and end of the game the state can be changed based on extra
logic not triggered by the players.
When implementing this as an online game the turns system means the server rarely has
to deal with valid concurrent actions from the clients. However, it is possible that players still
send actions even when its not their turn and this needs to be dealt with gracefully. Moreover
special circumstances, such as a player leaving or entering, will affect the game state regardless
of whose turn it is. This requires preventive measures in order to avoid that these special
circumstances cause actions that leave the game in an inconsistent state.
10
2.3
Client-Server Architecture
A client-server architecture is a centralized distributed system in which a single machine, the
server, provides services to several machines, the clients [6]. This definition is broad and there
are several variations of this architectures which can be used to develop online turn-based
games.
An exemplary approach is the server is used to connected clients but then the actual game
happens in a peer-to-peer manner with the clients hosting the game and the server only intervening in case of conflict. This reduces the load on the server but brings security and synchronization problems.
Another approach, the one taken in this project, is hosting the game on the server and using
the clients as simple thin clients that send and receive changes to the state of the game. This
provides full control over the games at the expense of higher load on the server.
2.4
Software Frameworks
Software Frameworks are used as libraries to assist in the development of applications. However, frameworks distinguish themselves from regular libraries for extendability and adaptability to user needs rather than just being a collection of functions [7]. Frameworks are complex
structures that associate their functionality with abstractions. The users need to implement
these abstractions in order to take advantage of the framework’s functionality. Once the user
provides the implementation the framework does all the work of calling the correct functions
and working through the correct flow of control [8].
Building a framework requires a balance between what is abstract and needs to be implemented and what should be provided. This is to achieve the aim of allowing the user to have
full customization power without having to change the code from the framework.
2.5
Summary
The framework discussed in this report is a combination of all these concepts. It should encompass all the basic logic of an turn-based online game as well as all the infrastructure needed for
a client-server architecture. All of this while still maintaining the high level of customization
that makes it a framework.
11
Chapter 3
Requirements
3.1
Overview
This chapter describes the process of planning this project. It starts by showing the stakeholder
analysis. Then it goes over the features of the system by importance. After this the functional
and non-functional requirements are listed and prioritized. Finally there is use case and context
analysis along with their respective diagrams. The full results of requirements gathering for the
games and the customizer can be found in Appendix C.
3.2
Stakeholder Analysis
Listing and categorizing the stakeholders of a project is a very important step before outlining
the requirements. Stakeholders were separated into their level of interest and power over the
project. This information is invaluable in order to understand what needs would have to be met
and whose support was going to be more relevant to complete the project. [9].
In Figure 3.1 we can see the stakeholder grid which resulted of this analysis. The student
who is in charge of the project, the supervisor, and the second marker had both high influence
and high interest in it. Most of the discussions about the project happened within this group
and the project needed to satisfy all the requirements of these stakeholders.
Figure 3.1: Stakeholder Power/Interest Grid
12
Developers that were already working or looking to work with turn-based online games
had a high interest in the project. However, within the scope of the project they didn’t have any
influence. This could be changed if the project went into beta testing to get feedback from the
users.
Other developers did not have power for the same reason. Also because they would not be
looking at this kind of systems they were not considered interested. Nevertheless they should
be monitored as the impact of the framework could potentially take some of these into a group
of more interest.
3.3
Features List
The features listed in Table 3.1 are a combination of the initial features along with others that
were added during progress reviews done periodically throughout the project. The features
were categorized in terms of priority.
The highest priority features are the ones that must be implemented in order to have a
working final product. These include all the infrastructure to get a server running as well as the
customizable parts since they are what sets the framework apart.
The second second highest priority features should be in the system but they would not stop
it from being usable. An example is making an option available for the user to use encrypted
connection. The framework would still work with insecure connection but this was considered
an important option the user should have.
The lowest priority features could add extra value to the product but do not affect the core
quality. These kind of features, such as user manuals, help the framework have a more professional look and feel to the user. During planning these features were considered add-ons which
could be left out if there was not enough time to complete them.
13
Feature
Complete Server
Infrastructure
Client Agnostic
Messaging
Protocol
Basic Extendable
Player Logic
Basic Extendable
Game Logic
Text
Configurable
Customizable
with Modules
Secure
Connection
User Manual
Description
The core framework on its own must implement a fully
working server which can be ran “out-of-the-box”.
The framework must implement a default basic message exchanging protocol between the server and the client. This
protocol needs to allow the clients to be written in any language.
The server must have the basic player management logic
which can be extended by the developer.
The server must have the basic logic for turn-based games
which can be extended by the developer.
The server must be configurable by changing a settings file
that is packed with the framework containing the default
values required to get the system working.
The server must allow extensions through modules. This is
an essential feature of the framework as this is what sets it
apart.
User should be able to configure the server to establish connections secured by SSL. Secure connections are not critical
but it is an important feature of the framework.
Frameworks require a lot of documentation. Apart from
javadoc the framework could be packed with a user manual in order to have a more professional feel. However, this
is not important for the quality of the system itself.
Priority
Must
Must
Must
Must
Must
Must
Should
Could
Table 3.1: Framework’s Features list
3.4
Requirements
The requirements gathering was done taking into consideration the features planned for the
project as well as input from the most relevant stakeholders. Each requirement was attributed
a priority level which defines the order of implementation. Lower priority requirements should
be left on hold until higher priority ones are completed. Furthermore for each requirement a
risk level was determined to represent the proportions of the damage caused by not meeting the
requirement. Risk also encompasses the amount of development effort involved in completing
the requirement.
14
3.4.1
Functional Requirements
Functional requirements refer to the range of capabilities the framework needs to provide to
the developer. Table 3.2 contains the complete list.
Name
Multithreading
Abstract Logic
Messaging
Protocol
Modular
Extendability
Text
Configuration
Optional Secure
Connection
Log System
Description
Priority
(1-7)
The framework must run on top of a multithreaded architec- 7
ture using a Thread Pool. This is essential as the rest of the
system is built on top of this.
Both the player and the game logic need to be abstractions 6
for the developer to implement his own system. This is what
makes the system a framework.
A default messaging protocol which involves network trans- 5
port protocol and the message format must be implemented
in order to have client-server communication. Without this
it is not possible to build any game with the framework.
Through the use of modules the functionality of the frame- 4
work should be extendable. This is the requirement that
sets the framework apart. It is essential for the goal of the
project but not to have a functional basic framework.
The framework on start should read a settings file and store 3
all configurations to make them available throughout the
system. This contributes for an even more extensible framework but it’s not essential for the scope of the project or for
the success of the framework.
The user should be able to configure the client-server con- 2
nection to use SSL. This does not affect the quality of the
infrastructure but it adds to the configurability of the system.
The framework should log all relevant information in order 1
to help the user debug problems. Even though this is not
important for the infrastructure of the system it is essential
for a polished final product.
Table 3.2: Framework’s Functional Requirements
15
Risk
(1-3)
3
3
3
2
2
1
2
3.4.2
Non-Functional Requirements
The non-functional requirements shown in Table 3.3 characterize the qualities of the framework
and how it should operate to the developer and to the end user.
Name
High Availability
Sensible
Messaging
Protocol
Flexibility
Easy to use
Extensive
Documentation
Description
Priority
(1-7)
The infrastructure of the server created with the framework 7
should always be available and stable.
The structure of the messages exchanged should be human 6
readable while being easy to process by the software. This
is part of the early stages of development but it’s not essential for the purpose of the project since an inefficient protocol will still result in a working system.
Throughout the entire system from the core to the modules 5
of the framework the user must have flexibility to add, remove and change functionality. This is not important to get
a working system but it is essential for the project’s goal.
The framework should be create a natural workflow to the 4
developer and be easy to understand and use. Even though
the system can still have high quality as an infrastructures
in order to be a good framework it needs to be user friendly.
A framework user is usually going to have a good grasp of 3
the framework’s inner workings in addition to the information on its external interfaces. For this the code needs to
be well documented and additional manuals should be provided.
Table 3.3: Non-Functional Requirements
16
Risk
(1-3)
2
1
3
2
1
3.5
Context Diagram
In order to determine the interfaces between the system and all the actors in this environment
a context diagram can be used [10]. Figure 3.2 shows the context diagram drawn for the
framework. The Customizer web application only makes changes to the framework by adding
modules and changing settings. The developer extends the framework to make his own game
and relies on the information and errors displayed by the system. Finally once the user develops
the client it interacts with the server using network connection and a JSON message protocol.
Figure 3.2: Framework’s Context Diagram
3.6
Use Cases
The Context Diagram does not provide a view of how the actors interact with the different
parts of the system. Figure 3.3 shows the Use Case Diagram for the system. This was derived
by combining information of the Context Diagram with the Requirements. It shows how the
developer interacts with the framework in order to implement it in an initial stage. Then he
monitors the status of the system when deployed. The client establishes a connection to the
server and then exchanges messages using the same connection.
Within the system all parts need to report relevant information and errors in order to keep
the developer informed.
17
Figure 3.3: Framework’s Use Case Diagram
3.7
Summary
This chapter showed that most of the requirements focus on making a highly customizable
system. Moreover the system needs to balance the functionality which should be core to the
framework and what can be part of further customization. This had a huge impact on the
following stages as it will be shown in the next chapters.
18
Chapter 4
Design
4.1
Overview
This chapter presents the process of defining the architecture of the Framework, Customizer
and the two games. For each of these it describes the most relevant research and the decisions
made based on that research. It then describes the actual design based on the path set out by
the research stage. Details and screenshots of the user interfaces can be found in Appendix ??.
Appendix D shows the initial plans and designs for the project and can provide a better understanding of the way the project evolved.
4.2
Overall Project Design
The initial design of the framework was based purely on theoretical research on online multiplayer game design. This initial prototype was used and improved with the development of
the chess game. The resulting design, that was already similar to the final system, was then
used to develop the Poker Game and, once again, applying it influenced its own design. The
framework’s design was also restricted by the fact that it had to be automatically customized
by the web application. This influence that all parts of the project have on each other is clear
throughout this chapter.
Research was a constant need throughout the development of the project and it would not
be feasible to list all topics researched. These topics are accompanied by the decisions they
influenced. The research described for each part of the project had more concrete implications
into the design and implementation of the system than the one in the Background chapter.
4.3
Framework
The final design aimed at having all the basic functionality that a developer needs to deploy a
server while allowing full customization. Applying the framework made it easier to understand
what requirements the developer might have and in some cases lead to the complete redesign
of certain parts. Frameworks have an indirect target public which is composed of the end users
of the game it is used to build. In order to provide flexibility for this crowd too it was important
to make the framework in such a way that the client is platform agnostic.
19
4.3.1
Research & Decisions
For the framework the research covered three major topics. The first was Networking, which
involved every aspect of the infrastructure required to start exchanging messages between client
and server. Second was Threading, which covered how it should be done and how it influences
the rest of the design. Finally Dependency Injection was an important pattern researched to
make the framework customizable.
Networking
The main topics of research within networking were the network transport protocol used to
establish client-server communication and the format of the messages exchanged in the communication.
In turn-based online games all information exchanged between server and clients is important. This means packets cannot be lost, risking the integrity of the messages. Therefore User
Datagram Protocol (UDP), which does not ensure packet arrival [11], was ruled out. Moreover
packet rate in a turn-based game is going to be low compared to real-time action games even if
the game includes features such as chat. The memory cost of the Stream Control Transmission
Protocol’s (SCTP) redundancy system for higher throughput is unnecessary [12]. This made
the protocol unsuitable for this task. The final choice was Transmission Control Protocol (TCP)
because it keeps packet order and recovers lost packets maintaining the integrity of the data at
the cost of speed. This delay is a trade-off that can easily be accepted in this type of game.
For the messaging format XML [13] and JSON [14] were the two formats considered since
they are the most commonly used on the web. Since these are standard formats they allow the
client to be language agnostic. The decision had to weigh the power of XML in terms of complex data structures against the light syntax of JSON that makes it better for bandwidth [15].
For this kind of game the need for complex objects was not foreseen and therefore JSON was
selected. However, in order to offer the flexibility that characterizes the framework the messaging API, the JSON API, will be accessed through a wrapper class. If XML, or another protocol,
is needed then the user will simply change how the wrapper class works.
Threading
The server is required to have multiple connections open. However, in turn-based online games
these connections can be idle during a long time. Multithreading allows an optimal use of
resources by blocking idle threads and providing CPU time to active ones [16].
In order to remove the overhead of creating threads on each connection the server will have
a Thread Pool. The threads will be then taken from the Pool when a new connection is opened
and put back when they are done. Having a fixed size pool will also protect the server from
spawning too many threads and end up with a starvation problem [17].
Using multithreading means that the resources of the program are shared among the threads.
This had a huge impact in the way the rest of the system was designed. All objects shared across
threads had to include thread-safe access in order to avoid the concurrent processes leaving data
in an inconsistent state.
20
Dependency Injection
Dependency Injection is a pattern that was researched for the way it allows a code to be extended. In this pattern the functionality is written using abstractions of classes. This functionality can be used with any implementation of those classes being passed to it[18]. This is was
used to develop the framework allowing the user to inject their own implementations of the
classes. See Dependency injection example in Listing 4.1.
The initial plan was to use a library to help implement this pattern but with some further
thought it became clear the pattern could easily be implemented without it. This also removed
the need for an extra library dependency whilst it did not affect functionality.
p u b l i c c l a s s Example {
private Abstraction abstraction ;
p u b l i c Example ( A b s t r a c t i o n u s e T h i s I m p l e m e n t a t i o n ) {
abstraction = useThisImplementation ;
}
public void PerformAction ( ) {
abstraction . action ();
}
}
Listing 4.1: Dependency Injection Example
4.3.2
Modularity
In order to make the framework customizable one of the design focuses was on architecting the
system such that it can be extended by modules without making it dependent on them. This
means that the framework should still be fully usable even if stripped off of all modules. The
framework supports two different types of modules each described below.
Standalone modules are classes that make a certain functionality available to the whole
system. An example is a database wrapper that would make available a set of methods to
access the server’s database.
Listener modules implement functionality that is triggered by messages from the client. By
default the developer needs to implement the abstract class Player in order to implement his
own set of custom actions between client and server. These modules extend Player and each
one has already coded common actions that the users would have to code by themselves.
Figure 4.1 shows a simplified version of how the Listener Modules system works with a
login module. When the module is added the developer does not have to implement any related
logic except if he wants to make changes to its functionality. As the user will extend the module
he still has access to everything it does, such as the method loginSuccessful.
21
Figure 4.1: Example of adding a Listener Module
4.3.3
Software Design
During the design process of the framework it was important to conciliate the requirements
gathered with the constraints created during the research stage. This section will cover Software
Patterns applied to the framework. Furthermore it shows the HTA, CRC, Class and Sequence
diagrams that were created as part of the design process.
Software Patterns
In order to achieve the required customizability it was necessary to apply the Inversion of
Control (IoC) pattern. When classes are instantiated they receive the implementations of their
dependencies rather than looking and instantiating these dependencies themselves [19]. This
brings other benefits such as testability because the class can receive a dummy implementation
to create a more controlled testing environment. In the framework IoC is achieved by using
Dependency Injection described in the research section.
It was also taken into consideration the fact that the server has to be available most of the
time. However, the clients should not be blocked waiting for reply in case the server becomes
unresponsive for a period of time. For this reason an asynchronous message passing design is
the base of the system [20].
HTA
An Hierarchical Task Analysis (HTA) was used in order to split the process of deploying a
server using the framework into steps the user needs to follow [21]. This analysis allowed an
optimization of the design to match the workflow that is most appropriate to guide the user
through these steps.
22
Figure 4.2: Framework’s Hierarchical Task Analysis
Figure 4.2 shows the final HTA diagram produced for the framework. The three main
steps the user needs to take are customizing the framework, implementing all the game and
player logic and finally running the server. Within the customization step there are different
types of customizations possible even if the user chooses not to use any customization at all.
Also in order to get the server running the developer needs to inject the logic created in the
implementation step.
23
CRC
Class Responsibility-Collaborators Cards were used to define the tasks each class has to perform alongside the classes it interacts with. The resulting CRC cards are shown in Table 4.1.
TurboNGServer
Responsibility
Collaborators
ServerSettings
Responsibility
Collaborators
- Instantiated by
user.
- Gets injected the
player implementation.
- Read settings
from file.
- Make settings
available to whole
system.
- TurboNGSocketFactory
- ConnectionHandler
- ServerSettings
- PlayerFactory
TurboNGSocketFactory
Responsibility
Collaborators
- Read socket settings.
- Instantiate correct
socket.
- TurboNGServer
- TurboNGSocketFactory
PlayerFactory
Responsibility
Collaborators
- TurboNGServer
- ServerSettings
- Instantiate player
implementation
- TurboNGServer
ConnectionHandler
Responsibility
Collaborators
PlayerLobby
Responsibility
Collaborators
- Instantiates players on new connection.
- Manages pool of
threads
- Receives and
Validates
client
actions.
- Sends valid actions to client.
Responsibility
- TurboNGServer
- PlayerFactory
- Player
- PlayerLobby
Player
Collaborators
- Executes actions
from client.
- Sends actions to
the game its in.
PlayersManager
Responsibility
Collaborators
- Holds online
players
- Wraps players in
thread-safe implementation
- Player
- Game
Game
Collaborators
Responsibility
- Basic game turnbased logic.
- Send actions
to client through
player.
- PlayerLobby
- PlayersManager
- Game
- Action
Responsibility
- ConnectionHandler
- Player
- Action
- Player
- Action
Action
Collaborators
- Represent messages exchanged
between client and
server
- PlayerLobby
- Player
- Game
Table 4.1: Class Responsibility-Collaborators Cards
The top four classes are in charge of the setup of the server when it is started. ConnectionHandler and PlayerLobby deal with message exchanging and validation. Player and Game are
abstractions of the logic and need to be implemented by the user. These are the only classes
the user needs to implement in order to get the server running. Action is the message format
wrapper that by default uses JSON messages.
24
Class Diagram
A Class Diagram was used to complement the information from the CRC. This diagram made
it possible to visualize the relationships between classes in order to help in the implementation
stage and to find mistakes in the design in early stages.
Figure 4.3 shows the final class diagram of the framework. This diagram shows how the system will be structured once the developer implements Game and Player with the logic needed
to run the desired game.
Figure 4.3: Framework’s Class Diagram
25
Sequence Diagram
A Sequence Diagrams represents the flow of control of a system for required scenarios. The
diagram in Figure 4.4 shows the system behavior from the point it is started to responding
to messages from the client. The developer runs the TurboNGServer class that triggers all
the setup sequences. The ConnectionHandler waits for connections from the client and on
connection spawns a PlayerLobby to hold the connection to the client open. Then the client
exchanges messages with the PlayerLobby which validates them and sends them to Player to
be executed.
Figure 4.4: Framework’s Sequence Diagram
26
4.4
Customizer
The Customizer is a web application used to help developers create their own customized version of the framework. The tool is a web application that is used to visually choose the modules
that are going to be bundled with the framework as well as the text configurations that should
be included in the settings file.
When designing this system one of the main concerns was to design it in such a way that it
could be extended. This should happen not only by adding possible configurations within the
existing types but also by adding other types of configurations. The design needed to include a
way to easily add configurations without having to change any code.
For this a Model-View-Controller (MVC) pattern was chosen as the best option because it
allows a clear separation of concerns [22]. The Models define the different configurations and
their dependency relationships. These are located in permanent storage and are not hard-coded
into the application. The Controller dynamically loads the configurations, interprets and binds
them in such a way that the View can display them in a logical way for the user. The Controller
also processes the finalized version of the configurations in order to package the framework
only with the required functionality.
4.5
Chess Game
The Chess Game was developed to be a game with no permanent storage. Each time the user
logs in he picks a unique username and the sessions last only as long as the user remains online.
Users should be able to exchange messages with any player that is online and challenge them.
The design of the game was split into server, which is mostly based on the framework and a
thin client, which is built to run on low specifications machines. The design of the server-side
was mostly based on the framework’s own architecture. Nevertheless it was necessary to build
modules in order to customize the framework for this game.
Server-Side
There were three listener modules created. First was a password-less login module and then a
public and a private messages exchanging system. Another module developed was an invite by
username module that allows users to invite any user that is online by username look-up.
The server was also configured to only accept secured connections. This was used for
extensive testing on the SSL connection option which is part of the framework.
Client-Side
The client was built to be a thin client, which only receives short messages with updates to the
state of the interface. Despite this simplicity the design is made to have a clear separation of
concerns.
A networking class connects to the server and is in charge of sending and receiving messages while validating their format. ChessGame and Player classes hold the current state of
the game. Finally there are the User Interface classes, one for each of the three screens that
are available to the user: login, lobby and game screens. These are in charge of displaying the
current state of the game and processing inputs.
27
4.6
Poker Game
The Poker Game was designed to be a more complex game than the chess game in terms of
keeping information in permanent storage even after the user logs out. The user has a permanent
account, which uses a combination of username and password as credentials. When the user
authenticates he gets access to information on the number of games played and won, and the
current amount of coins owned. Players do not have access to all the players but only to the
ones in their friend lists. They can also view information on these users even if they are offline.
The poker game was also highly based on the framework and therefore there is not a lot
of the design to be noted aside from the modules. However, it is important to point out that a
design supporting permanent storage of data requires certain constraints to avoid losing information.
Server-Side
The server had to store the information of each user and therefore it required a database. A
database wrapper module was created in order to abstract out the database API used. Furthermore another standalone module was created that provided a basic deck of cards as well as the
most common actions performed on it.
The login system was provided by a listener module that uses the database wrapper to
provide authentication with username and password. Moreover the list of friends of the user
is maintained by a different module that also uses the database modules. These dependencies
had to be considered when developing these modules because they needed to give the user
descriptive messages in case of dependency errors.
Client-Side
The design of the client of the Poker Game is split into different controller classes each in
charge of managing its own UI screen. There are four different UI screens and each is responsible for displaying the information and processing input from the user. The UI screens are
login, register, lobby and game.
All the classes share a networking class which is in charge of sending and receiving messages to and from the server while distributing them to the correct controllers. This allows each
class to handle the messages from the server that belong to it instead of having a single class
that executes all the messages.
4.7
Summary
The framework put together various areas of computer science. The design of the system was
the most important stage of the project. It allowed a much easier implementation stage which
is covered in the next chapter.
28
Chapter 5
Implementation
5.1
Overview
This chapter represents the realization of the plan produced by the requirements gathering
and the design stages into a working system. It covers implementation details such as the
Methodology used to approach the development and the Technologies used. It will also give
some details on Algorithmics and other constructs used during development.
5.2
Overall Implementation
The framework, and its modules, influenced and were influenced by the development of the
games. Having a well structured plan of implementation helped ensuring the framework fully
benefited from this approach. This meant that any part of the games which did not allow
to assess the framework was deprioritized. This applied mostly to complex game logic and
graphical user interfaces.
The ultimate goal was to develop the framework to be as functional and polished as possible. The resulting system should be robust and validated enough to be released as a beta version
even if this stage is out of the scope of the project.
5.3
Framework
In order to achieve a framework that was highly validated in terms of robustness and features
available the development of this system was on going throughout the whole project. This
meant keeping the framework open to changes during all the stages even when the focus had
steered to the games.
29
5.3.1
Software Engineering Methodology
The Software Engineering (SE) methodology used in developing the framework was Agile.
The strategy followed was to produce working prototypes in a short period of time. Early
feedback was possible by applying these prototypes to develop the games. Further feedback
was provided by weekly meetings with the project supervisor. The changes that resulted from
these feedbacks were validated right after being implemented when the new version of the
framework was applied. This created a cyclical approach typical of Agile development that
helped continuously test and validate the framework [23].
5.3.2
Prototypes
Since the framework was always open to changes it was common to apply minor improvements
and bug fixes. It is not relevant to refer all these changes. Instead there are three major prototypes worth noting as they characterized the evolution of the framework and marked the pace
of development of the games.
The first prototype implemented an initial version of the core of the framework. At this
point modules were not supported. This version was used to start developing the Chess Game.
While developing the game the modules idea came along. This would turn some of the functionality already built into generic modules to be applied in any other game. This kickstarted
the development of the next version.
The second prototype was designed to be extendable by modules. The core framework was
also improved with the feedback from the previous version. The new framework was then reapplied to the chess game. This meant creating all the modules needed for it and changing the
existing system to work with the new features. Once this version was working smoothly with
the chess game it was applied to the Poker Game.
The third prototype and last was the one present in both games during the demonstration of
results to the supervisor and second marker of the project. This is the result of all the changes
made during the development of the poker game and the ones made during the final testing of
the framework on both games.
5.3.3
Implementation Technologies
The framework was built using Java. This was decided taking into consideration different
characteristics of the language. Java has in its core competencies the ability to deal with networking and scalability of applications which made it very suitable to build a good core for
the framework. Furthermore being object oriented allowed to easily implement certain aspects
of the framework such as its extendability and the separation of concerns that allows it to be
customizable. Lastly being platform independent was also important in order to follow the
framework’s main requirement: giving full freedom to the user.
30
5.3.4
Algorithmics
The most notable algorithmics developed was the Listener Modules system. When approaching
this problem the following list of constraints was put together.
• The number of modules in use must be unlimited
• The modules must be able to process specific client messages and report back when
messages received cannot be processed.
• The modules must have control over the player and the game the player is in.
The solution found was to make all the modules extend Player and implement the executeAction(clientAction) method which is called whenever a new message arrives for the Player. In
Listing 5.1 an example of a listener module is shown. The module processes all actions of type
“demo”.
p u b l i c a b s t r a c t c l a s s DemoModule e x t e n d s P l a y e r {
@Override
public boolean e x e c u t e A c t i o n ( Action a c t i o n ) {
/ / [ . . . ] Omitting action validation for r e a d a b i l i t y
i f ( a c t i o n . g e t V a l u e O f ( ” a c t i o n t y p e ” ) . e q u a l s ( ” demo ” ) ) {
/∗
P r o c e s s and e x e c u t e a c t i o n
∗/
r e t u r n t r u e ; / / T r u e means t h e module e x e c u t e d t h e a c t i o n
}
r e t u r n f a l s e ; / / F a l s e means t h e module can ’ t e x e c u t e t h e a c t i o n
}
}
Listing 5.1: Example of a Listener Module
This approach allows the modules to be developed individually. When they have to be
applied together the first one extends Player, the second one is changed to extend the first and
so on. The implementation of Player by the developer will extend the last module.
As the module is the player it will have full control over it and can extend it with methods
and variables the developer can also use.
31
5.4
Customizer
The Customizer has two different interfaces. One for the developer to customize and download the framework and the other to manage the back-end in which the existing modules are
configured.
5.4.1
Software Engineering Methodology
The methodology used in developing the customizer was close to a waterfall approach. This
is because most of the logic the system needed to implement had already been defined when
developing the framework customizability system. In turn this meant that the customizer’s
goal was to automatize a process that was already well defined. After planning the schema of
the database and designing the user interfaces it was implemented in one go. Some bug fixes
happened after the main implementation stage but not substantial enough to consider them
other iterations.
5.4.2
Implementation Technologies
The web application was built using Ruby on Rails. This was decided as the system had to
provide static web pages with documentation and graphical customizing system. In addition it
needed to provide a RESTful API to request customizations of the framework. Having these
two elements separated means that the API can be used by more than the interface provided.
Other developers can create their own system such as framework updating systems. Rails also
uses the MVC approach that had been defined in the Design chapter.
Moreover this platform handles database creation and management easily if given the correct constraints. It also automatically associates the schema with models.
5.4.3
Database
Figure 5.1 shows the Entity-Relationship diagram for the database schema. Configuration Entries represent every possible configuration that can be added to the framework. These are
grouped within Main Configurations that represent the areas being configured by the entries.
An example is the Main Configuration Login that includes all types of login available and each
of these is a configuration entry.
Figure 5.1: Customizer’s Entity-Relationship Diagram
32
5.5
Chess Game
The Chess Game client was developed to run on low specifications devices such as the Raspberry Pi. This impacted the UI design. It also influenced the definition of the complete message
protocol so that it would not require too many resources to be parsed.
5.5.1
Software Engineering Methodology
This game was the one that was more intimately connected to the development of the framework. The approach chosen was divided in two distinct phases. In the first phase an initial
version was planned and implemented in order to produce a prototype fully based on the framework. The second stage was adapting the game iteratively as the framework was changed. This
contributed to the ongoing feedback referred earlier. In spite of these changes the actual features of the game were kept the same even if implemented differently.
5.5.2
Implementation Technologies
The client was developed using Python because it’s the language of choice to develop for the
Raspberry Pi. The GUI was developed using Tkinter. This choice was due to the fact that it
belongs to the default libraries of the language. It also weighed on the decision the fact that
it uses the native components of the system it is used in. This allows even lower need for
computation resources.
5.6
Poker Game
The poker game is an iOS game specifically targeting the iPad platform due to the larger screen.
5.6.1
Software Engineering Methodology
The development of this game was the last task planned for the project. With the changes to
the framework and the addition of the Customizer the time to complete this task was short
when compared to the time available for the Chess Game. An Agile approach was taken here
in which the system was quickly developed until it reached a working state and then it was
improved iteratively as much as time allowed.
5.6.2
Implementation Technologies
The iOS platform requires the use of Objective-C or Swift programming language to run native
applications. Native development allows better perform and is supported by Apple’s IDE which
contributes for lower development time. The chosen language was Swift for being more recent
and also having a simpler syntax. It also weighed in this decision the fact that working with the
language for the first time would be a major learning experience.
Although Swift has support for JSON messages the language is still in early stages and
the access controls in JSON objects are not very functional. In order to solve this problem an
external library, SwiftyJSON, was used to help parse, access and modify the JSON messages.
33
5.7
Summary
The implementation benefited from a strong design phase that supported a lot designs. In
addition to this the implementation process benefited from the incremental approach taken.
This stage was also important because it demonstrated all the capabilities of the framework.
34
Chapter 6
Testing
6.1
Overview
This chapter goes over the testing process of each part of the system. It includes the number
and type of tests.
6.2
Framework
The testing of the framework can be divided into three categories.
The first is composed of the unit tests done to the core of the framework. Aside from the
regular testing during development there were a total of 51 test cases part of formal testing.
The second category includes the development of the two games. This is not a formal
method but applying the framework is one of the best ways to find problems with the framework
and validate its design and implementation.
The last category is the testing of the modules. Standalone modules were tested using unit
testing. Between the two standalone modules a total of 30 test cases were done as part of the
formal testing. The Listener Modules had to be tested both with unit tests as well as their
integration with the framework. The total number of test cases for these five modules was 58.
6.3
Customizer
The customizer API was unit tested and special attention was given to the methods involved in
putting the customized framework pieces together. It was also tested using an HTTP command
line client in order to make sure no malicious requests are processed.
The actual web page of the customizer was extensively tested because it was used several
times as the framework was changed to bundle the customizations for the games. Moreover in
order to formally test the interface a total of 30 UI tests were made.
35
6.4
Games
The server-side infrastructure of the games was already well validated for being heavily based
on the framework’s core as well as its modules. The main tests done to the server of the games
were integration tests. For the Chess Game the total number of formal test cases were 61 and
for the Poker Game 57. These test cases were applied by using the client applications built for
each of the games, which allowed them to be tested simultaneously.
Even though the clients were built to be thin clients there was some validation and constraints to inputs on this side. In order to make sure that these cases would also be dealt with
by the server for each of the games all the test cases were repeated using a telnet terminal.
6.5
Summary
The formal unit testing made to the framework was not thorough which was due to time constraints. However, building the games also contributed to make sure the main product of this
project was correctly and thoroughly validated. In the customizer the focus of the testing was
more on the UI than on the API.
36
Chapter 7
Results and Analysis
7.1
Overview
This chapter presents the final result of each of the parts as well as the analysis of these results.
Complete walkthroughs of the final user interfaces can be found in Appendix A, as referred to
earlier.
7.2
Framework
The final version of the framework has all the high and medium priority features that were
planned for it. Moreover it also complies with all the requirements that were listed. Listing 7.1 shows the code needed to instantiate a server that uses the framework and injecting the
implementation of Player to start the it.
p u b l i c c l a s s DemoServer {
p u b l i c s t a t i c v o i d main ( S t r i n g [ ] a r g s ) {
TurboNGServer s e r v e r = new TurboNGServer ( p a t h −t o −s e t t i n g s −f i l e ,
s s l −k e y s t o r e −p a s s w o r d ) ;
s e r v e r . s t a r t ( new I P l a y e r F a c t o r y ( ) {
@Override
public Player i n s t a n t i a t e P l a y e r ( ) {
r e t u r n new DemoPlayer ( ) ;
}
});
}
}
Listing 7.1: An example of how the server is instantiated and started.
37
One of the features required was having a user manual to support the user when using the
framework. However, this was not completed and even though it is not essential for the quality
of the software the system cannot be considered ready to be released.
Another drawback the framework has is the fact that the modules depend on the use of
JSON as the format of the messages exchanged. Even though the core of the framework is
built to support any format that can be interfaced with using the created wrappers if the user
chooses to use modules this will be constrained.
Nevertheless the framework was successfully applied to the two games and it implemented
successfully the design that was created.
7.3
Customizer
The Customizer was designed to be integrated in the framework’s website along with its presentation and the documentation. The website was created even though only the customizer
page was completed. The final design shows the user all the configurations available grouped
in Listener Modules, Standalone Modules and Text Configurations categories. Each type of
configuration gets the type of input that better fits it.
The graphical interface is dynamically adaptable making it easy to add possible configurations. It acts as a thin client relying fully on the API to provide all the correct information and
generate the correct customization.
The resulting interface is very similar to what was designed initially. It is a clean and simple
design but modern and provides an intuitive interaction. The only downside to point out is that
the inputs were not styled and do not conform with the rest of the page’s design. Overall it has
a polished look and it can be considered a success.
7.4
Chess Game
The Chess Game was completed in what comes to applying the framework. However, the
game logic was cut down since it was not relevant for the scope of the project. The game is
fully working but certain advanced logic such as the prediction of check and checkmate were
not implemented.
The UI developed does not have a very modern look due to the use of the Tkinter library.
This same library also created certain problems for not being oriented to game interfaces. Looking back at this choice a more game development oriented library could have helped the development process at a small performance cost. Nevertheless, in terms of style, it is an interface
that was well implemented given the limitations of the library.
The fact that the advanced game logic was not implemented is not seen as a failure. The
initial plan was always to have a cut-down version of the game and only add to it in case time
allowed it.
38
7.5
Poker Game
The development of the interface of the Poker Game had to take into consideration the fact that
it was aimed at being used on a tablet. This is reflected in the controls being on the sides of
the screen to be accessible by the thumbs. The controls were also far from the bottom as the
on-screen keyboard could cover them when toggled on.
Another important point to mention is the ability to go back to the lobby screen when in a
game which was something that was not possible in the Chess Game. It carried extra concerns
such as the fact that the user should not be able to, in any circumstance, use the lobby to join a
second game.
Allowing things such as going back to lobby when in game required that the full state of the
game be transmitted to the client every time there is a change. The tests did not show performance problems and in turn-based games a certain amount of delay is acceptable. Nevertheless
this choice was a risk for the increased load on the client. A better approach could have been
separating situations in which only the changes to the game need to be sent and when the entire
game state is needed.
The interface was done using all the native components and therefore complies with the
design standards for this type of applications. However, from a design point of view the lobby
screen could have a more clean and organized look.
7.6
Summary
Overall the development of the framework, the customizer and the games was a success. All
the necessary features were implemented and the final versions are polished and to professional
standards. Nevertheless there is some gap for improvements.
39
Chapter 8
Reflection
8.1
Overview
This chapter is a reflection on the entire project. It includes an evaluation of the approach and
validation as well the project management. It ends with a reflection on challenges and successes
faced throughout the process.
8.2
Testing Evaluation
The testing of the framework was thorough as it combined unit testing with the integration
testing done by applying it to the games. Moreover each of the modules was tested individually,
which further supports the validation of the system.
The main focus of the Customizer was the UI that was needed to create customizations. The
API that was also part of the Customizer was not as thoroughly tested due to time constraints.
It was also important to make sure that given the right inputs the correct framework is always
produced. What this means is that using the web interface it will use the API in the right way
and this has been well tested. Using the API directly on the other hand is not guaranteed to
work for all inputs.
8.3
Approach Evaluation
Developing a framework by applying it to the games was the desired approach since the beginning of the project. This approach helped achieve more than improving the framework based
on experience. The two games built are different in logic and platform and this helped validate
the flexibility of the framework.
The downside of this approach was the time spent working on the Chess Game. As it was
decided that both games had to be working on the same version of the framework the game had
to be constantly updated. So, when major changes happened to the framework major changes
had to happen to the game’s server, delaying even more the rest of the project.
40
8.4
Project Planning and Management Evaluation
Throughout the project the main plan did not change radically apart from when it was decided
that the framework should be customizable. This meant both the Framework and the ongoing
Chess Game had to be restructured. Furthermore a Customizer web application had to be
implemented and that would change the timeline too.
Nevertheless by sticking to priorities and keeping track of on-going tasks using taskboards
it was possible to stick to the plan. Considering the project was very rarely more than a week
behind the schedule and was ready on schedule it is right to say project management was a
success.
8.5
Overall Effect
A project of this magnitude covering such a wide range of topics and technologies brings a
huge learning opportunity in addition to a few obstacles.
8.5.1
Challenges
One of the major challenges was the testing and debugging process of the framework and the
games as distributed systems. The fact that the server is a multithreaded system and that the
client is connected through a potentially unreliable framework made the causes of certain problems hard to track. Mechanisms such as log systems, unit testing and network monitoring were
essential to mitigate this problem. Nevertheless it was present throughout the entire development.
Another challenge was learning new languages as part of the project. Ruby on Rails and
Swift were learned from scratch and the development of GUIs in Python was also a new challenge. This was weighed when planning the project. For each of them there was enough time
to grasp the languages. However, not having a complete control over a language can sometimes
lead to bad coding.
8.5.2
Successes
It was not clear from the beginning of the project how the flexibility of the framework was going
to be achieved. The modular system created was a success and helped achieve a flexibility that
would not be possible if the system had been approached as a single unit.
8.6
Possible Improvements
As it has been referred before the wrapper for the message exchange format was not well designed and when developing the modules they ended becoming dependent of the JSON format.
The first technical improvement that would be made if more time was available would be restructuring this part of the framework to allow for easier implementation.
The second technical improvement has to do with the feature that was not completed, the
user manual. The framework has a lot of methods available and a specific workflow that optimizes its use. In order to release the framework it would be necessary to have thorough
documentation and guides.
41
From the point of project management the testing of the framework and the other systems
could have been more extensive. Not only in terms of the number of tests but also add different
types of testing that can find different problems. One example was the lack of performance
testing that is essential when developing a server.
8.7
Summary
The approach taken to the project and the project planning involved in carrying out this approach proved successful. Learning new programming languages was a challenge because of
the time it required. It was also a success since all the parts of the project were completed using
the chosen technologies.
42
Chapter 9
Conclusion
9.1
Project Future
The framework was designed and implemented taking into consideration that it could be improved if time allowed. Even though its current version is not considered a final release it is
very close to a Beta version. It was important throughout the project to build a product which
can be used outside the scope of the project. This was achieved.
9.2
Conclusion
The features required for the Framework, the games and the Customizer were completed. All
the requirements were met even if some of the low priority ones were not fully finished due to
time constraints. Nevertheless these were already planned as add-ons and being able to work
on them shows how successful time management was.
Applying the framework to the games created the possibility of being both a developer and
a user of the system being built. This contributed to different perspectives on the development
of the project as whole.
This project was above all an opportunity to learn and apply a wide range of concepts
and technologies. This goal was achieved. Building a framework was a chance to develop
an abstract distributed system capable of handling different structures. In addition to this several programming languages, frameworks and libraries were used in the various parts of the
project, which was an important learning experience. Finally it is worth noting the fact that the
framework has potential to be improved and used in the future and that’s also a success.
43
Bibliography
[1] Gartner. Press release - gartner says worldwide video game market to total $93 billion in
2013. http://www.gartner.com/newsroom/id/2614915, 2013.
[2] Marauroa Team. What is marauroa? https://stendhalgame.org/wiki/What_is_
Marauroa, 2011.
[3] SmartFoxServer Team.
Smartfoxserver - platform overview.
smartfoxserver.com/overview/platform.
http://www.
[4] Exit Games. Turnbased - features. https://www.exitgames.com/en/Turnbased.
[5] Soren Johnson Gamasutra. Analysis: Turn-based versus real-time. http://www.
gamasutra.com/php-bin/news_index.php?story=25920, November 2009.
[6] Encyclopaedia Britannica. Definition of client-server architecture. http://www.
britannica.com/EBchecked/topic/1366374/client-server-architecture,
2013.
[7] Mike Baker.
What is a software framework?
and why should
you
like
’em?
http://info.cimetrix.com/blog/bid/22339/
What-is-a-Software-Framework-And-why-should-you-like-em, October 2009.
[8] Mike Taylor The Pragmatic Bookshelf. Tangled up in tools. https://pragprog.com/
magazines/2010-04/tangled-up-in-tools.
[9] Mind Tools Team. Stakeholder analysis - winnning support for your project. http:
//www.mindtools.com/pages/article/newPPM_07.htm.
[10] Karl
Wiegers.
Defining
project
scope:
Context
and
use
case
diagrams.
http://www.jamasoftware.com/blog/
defining-project-scope-context-use-case-diagrams/, February 2014.
[11] Diffen Team. Tcp vs udp. http://www.diffen.com/difference/TCP_vs_UDP.
[12] Rajesh Rajamani University of Wisconsin. Sctp vs tcp [presentation]. pages.cs.wisc.
edu/˜raj/sctp/presentation.ppt.
[13] O’Reilly Team. A technical introduction to xml. http://www.xml.com/pub/a/98/10/
guide0.html.
[14] JSON Team. Introducing json. json.org.
44
[15] Angel Vladov. Json vs xml. http://avladov.com/post/82316325208/json-vs-xml,
April 2014.
[16] Jakob Jenkov. Java concurrency - multithreading benefits. http://tutorials.jenkov.
com/java-concurrency/benefits.html.
[17] Jakob Jenkov. Java concurrency - thread pools. http://tutorials.jenkov.com/
java-concurrency/thread-pools.html.
[18] James Shore. Depedency injection demystified. http://www.jamesshore.com/Blog/
Dependency-Injection-Demystified.html, March 2006.
[19] Martin Fowler. Inversion of control containers and the dependency injection pattern.
http://www.martinfowler.com/articles/injection.html, January 2004.
[20] Ray Toal Loyola Marymount University. Message padding. http://cs.lmu.edu/˜ray/
notes/messagepassing/, February 2014.
[21] Peter Hornsby UX Matters. Hierarquical task analysis. http://www.uxmatters.com/
mt/archives/2010/02/hierarchical-task-analysis.php, February 2010.
[22] Chrome Developer Team. Mvc architecture. https://developer.chrome.com/apps/
app_frameworks.
[23] Kelly Watters All about Agile. What is agile? (10 key principles of agile). http://www.
allaboutagile.com/what-is-agile-10-key-principles/, February 2007.
45
Glossary
Term
Turn-Based Game
Game Turn
Description
The game is split into turns and sequential turns form rounds.
A turn is when the game is stopped waiting for a specific player to make
a move.
Game Round
A sequence of game turns that covers all the players in the game once.
Real-Time Game
The game is open for all players involved to affect its state at any time.
It involves a better responsiveness and lower delays than a Turn-based
game.
Game Logic
Set of rules that are specific to a game which includes how turns are
sequenced and validation of moves.
Sofware Library
Collection of resources that can be used by developers when programming. These can include pre-written code, documentation, configuration data, templates, and more.
Software Framework
A library with functionalities associated with abstractions. The user
provides aditional code to implement the abstractions and take advantage of the functions.
Real-Time Game
The game is open for all players involved to affect its state at any time.
It involves a better responsiveness and lower delays than a Turn-based
game.
SCTP
Stream Control Transmission Protocol is a message-oriented protocol.
Its major strength is the multi-streaming system that allows it to have
multiple connections open simultaneosly between two nodes.
Thread Pool
Collection of spawned but inactive threads. It removes the overhead
of spawning threads every time one is needed by an initial overhead
instantiating the entire pool.
Inversion Of Control (IoC) Software Design Pattern in which flow of control is provided to a program by a reusable and abstract library.
Dependency Injection
Software Design Pattern that implements IoC by implementing logic
using abstract classes. This logic is accessed by providing implementations of the these abstractions.
REST
Representational State Transfer is Software Architecture Style which
consists of a standard for scalable web services. It defines a set of HTTP
methods and responses.
Glossary
46
Appendix A
User Interfaces
A.1
Customizer
There were two main areas that needed focus when developing the UI. The first was organizing
the configurations such that the layout is intuitive for the user and can easily be expanded
dynamically as more configurations are added to the database. The second was making sure
the user could easily understand the dependencies of each configuration.
Figure A.1: Customizer’s User Interface
47
As it is shown in Figure A.1 the first concern was addressed by separating configurations
by their type. Within each type they were organized inside a table-like format. This created an
easy to navigate interface that can be extended by adding rows to the table.
The second issue was tackled by creating a sidebar that provides information on the overall
selection got the system. It also provides a list of dependency errors. These errors are raised
when a module is selected and the modules it depends on have not been selected.
In addition to the customizer one of the goals of this website was to have the documentation.
Time did not allow the development of extensive documentation but a “Getting Started” page
was created. Figure A.2 shows this page.
Figure A.2: Framework’s Getting Started Page
48
A.2
Chess Game
The UI was designed to be simple in order to run smoothly on machines with low specifications.
The Chess Game starts with a login screen, in Figure A.3 with a single input for the username.
Figure A.3: Chess Game’s Login Screen
Once the user is logged in he goes to a lobby screen, in Figure A.4. Here the user sees all
the online users and has access to a public chat.
Figure A.4: Chess Game’s Lobby Screen
49
When the user invites or is invited to a game and the invite is accepted both players are
taken to the game screen. This screen is shown in Figure A.5. The players share a private chat
and the game board. At the bottom there are messages from the server.
Figure A.5: Chess Game’s Game Screen
50
A.3
Poker Game
The Poker Game starts with a login screen as shown in Figure A.6, from which the user can
easily go to the register screen that is shown in Figure A.7.
Figure A.6: Poker Game’s Login Screen
Figure A.7: Poker Game’s Register Screen
51
After login the user is taken to the lobby screen as shown in Figure A.8. Here the user has
access to his friend’s information even if they are offline. Furthermore the user can access on
going games as well as creating new ones.
Figure A.8: Poker Game’s Lobby Screen
52
After the user joins a game he is moved to the game screen, in Figure A.9, that has the
poker table. This has a limit of four players, one on each corner. The blank space left in the
interface had the purpose of being used to fit a chat window that was not created due to time
constraints. Game controls are placed at the top corner to allow for easy access when using a
tablet.
Figure A.9: Poker Game’s Game Screen
53
Appendix B
Framework Use Case Descriptions
Name
Description
Actors
Triggers
Main Course
Alternative Courses
Develop Server
The developer implements the game logic
Game Developer
None - Developer Decides
1. Create implementation of Game
2. Create implementation of Player
3. Configure settings file
4. Instantiate TurboNGServer
None
Table B.1: Develop Server Use Case Description
Name
Description
Actors
Triggers
Main Course
Alternative Courses
Start Server
The server is started and it performs all setup operations
Game Developer
Developer calls start method on server
1. Instantiate socket based on text settings
2. Instantiate pool of threads
3. Start ConnectionHandler
4. Display success info
1. If socket cannot be instantiated: stop execution and display error
2. If pool cannot be instantiated: stop execution and display
error
Table B.2: Start Server Use Case Description
54
Name
Description
Actors
Triggers
Main Course
Alternative Courses
Handle Connection
Setup a connection with the client
Client
New connection from client
1. Fetch thread from the pool
2. Instantiate a PlayerLobby with the thread
3. Pass socket to client to PlayerLobby
1. If there are no threads available: wait
Table B.3: Handle Connection Use Case Description
Name
Description
Actors
Triggers
Main Course
Alternative Courses
New Message
Handle a message from a connected client
Client
New message from client
1. Validate message format
2. Pass message for player to execute
4. Player executes action
3. Get reply from player
4. Send reply message to client
1. If invalid message: send error to client
3. If no reply from player: no reply sent
Table B.4: New Message Use Case Description
55
Appendix C
Requirements Gathering
C.1
Customizer
Feature
Customization
Generate
Customizations
Dependency
Management
Configuration
Description
Documentation
Description
The user must be able to choose which modules to add and
do text configurations. This is the main feature of the customizer.
When the user requests the generation of a valid configuration the system must put together only the needed files
and make them available for download. This is essential to
allow users to download their customizations.
The user should be able to see dependencies of the configurations as he chooses them and system shouldn’t allow
unresolved dependencies. The customizer will still be able
to do its job without this but it would allow the generation
of broken customizations.
Each configuration could have a short description to support
users doing their customizations. This is not essential but it
provides a more professional looking interface.
The web application could have a documentation page with
the user manuals of the framework. This is not relevant
for the scope of the project but it would give the project as
whole a more polished feel.
Table C.1: Customizer’s Features list
56
Priority
Must
Must
Should
Could
Could
Name
Dynamic
Interface
Automatic
Generation
Dependency
Detection
Documentation
Page
Description
Priority
(1-4)
The configurations are loaded from a database and the in- 4
terface adapts itself to the number and type of module. The
interface could be made static and configurations manually
added but dynamic interface is a useful feature.
The system should be able to combine the request from 3
the user with information from the database and generate
a valid framework customization. This is essential for the
Customizer do do its job.
The system should be able to automatically determine un- 2
resolved dependencies and report them to the user. Without
this the user can generate customizations but it would allow
the generation of broken systems.
The customizer should have a documentation page in which 1
the user can access the framework’s manuals. This is not
important for the scope of the project.
Risk
(1-3)
3
3
2
1
Table C.2: Customizer’s Functional Requirements
Name
Sensible
Database Schema
Intuitive
Description
Priority
(1-2)
All the information about configurations is stored in a 2
database and loaded dynamically. It is important that the
schema used is sensible enough to allow extendability and
to be read into an organized UI.
The user should be able to easily understand what is being 1
changed and also visualize what dependencies need to be
resolved. Being intuitive doesn’t affect the functionality of
the system but it’s important for usability.
Table C.3: Customizer’s Non-Functional Requirements
57
Risk
(1-3)
2
1
Figure C.1: Customizer’s Use Case Diagram
58
C.2
Chess Game
Feature
Login
Invite Any Player
Messaging
Cut-down Logic
Description
User must be able to login using only a username. This
username is released once the user leaves the game. Being
able to login into the game is essential.
User must be able see and invite any online player. Without
this users cannot start games so this is essential.
Users should be able to broadcast messages to all players or
send private messages to specific players. The game would
still work without this but it is important to demonstrate the
capabilities of the framework
Users be able to play a cut-down version of the game. It includes the logic for all the pieces but it won’t contain certain
advanced features.
Table C.4: Chess Game’s Features list
Figure C.2: Chess Game’s Use Case Diagram
59
Priority
Must
Must
Should
Should
Name
Description
Passwordless
Login
Invite By
Username
Public Chat
Private Chat
Chess
Logic
Game
Priority
(1-5)
User must be able to choose any username that is not being 5
used at the same time to login to the game. Logging in is
essential to use the game.
Users must be able to invite any online player by the user- 4
name. Inviting players is the only way to get to games and
that’s why it is essential.
Users should be able to send public chat message broadcast 3
to all online players. This is not an essential feature for
basic turn-based games.
Users should be able to send private messages to other on- 2
line players. This is not an essential feature for basic turnbased games.
The game should contain basic chess game logic. The users 1
should be able to play a full game even if not all features are
available. Without this logic the capabilities of the framework as a server can be demonstrated but not as a game
server.
Risk
(1-3)
3
3
2
2
2
Table C.5: Chess Game’s Functional Requirements
Name
Description
User
Friendly
Game Interface
Low
tions
Specifica-
Priority
(1-2)
The game interface should make it easy for the user to move 2
pieces, determine which pieces were moved and understand
whose turn is it currently
The client made for this game should run on low specifica- 1
tions devices. This is not essential for the project but it’s
one of the features chosen.
Table C.6: Chess Game’s Non-Functional Requirements
60
Risk
(1-3)
1
1
C.3
Poker Game
Feature
Register & Login
Join Any Table
Friends System
Cut-down Poker
Logic
Description
The user must register using a username and password and
can login using this combination at any time. No other user
can use the same username. A login system is essential for
the player to use the game and it demonstrates the permanent storage capabilities of the framework.
Users can join any ongoing game as long as there is space
in that game. Joining games is fundamental for the user to
play.
The user should be able to keep a list of other players that
he can get information about even if they are not online at
the same time. This is not a necessary feature but it further demonstrates the permanent storage capabilities of the
framework.
Even though not all advanced moves are available the users
should be able to play full games.
Table C.7: Poker Game’s Features list
61
Priority
Must
Must
Should
Should
Name
Description
Permanent &
Data Storage
Username &
Password
Login
Store Friends
Poker
Logic
Game
Priority
(1-4)
The system must store information about the user such 4
as the username and password and the number of games
played and won. Without this feature the login system can’t
be implemented.
The system must implement a login system that uses a user- 3
name and password pair for registering and logging in. This
is essential for the user to enter the game and start playing.
The system should store along with the players info a list of 2
players the user wants to have closer contact with. This is
important to demonstrate how the modules can interact.
The system should provide a full basic game of poker. Ad- 1
ditional advanced plays can be added if time allows.
Risk
(1-3)
3
3
2
2
Table C.8: Poker Game’s Functional Requirements
Name
Consistency
Tablet Friendly
Description
Priority
(1-2)
The permanent storage interfaces must be designed in such 2
a way that it guarantees the consistency of the database.
This is an essential feature for the database module wrapper and a point to take into consideration when using it.
The UI should be designed so that it is easy to use on a tablet 1
using a touch screen. This is an important requirement of
an iPad application.
Table C.9: Poker Game’s Non-Functional Requirements
62
Risk
(1-3)
3
2
Figure C.3: Poker Game’s Use Case Diagram
63
Appendix D
Initial Plans
D.1
Initial Plan of the Framework
The following list of features was put together as part of the initial plan that had to be submitted
during the first week of the project.
The Client:
• A thin client API that deals with all the network communication interfaces and provides
the basic logic of a turn based game client.
The Server:
• Server API for network communications with the clients and other servers
• Clock synchronization for timed games like Fast Chess
• Security mechanism including message integrity checking and authentication.
• Scalability utilities like load balancing
D.2
Initial Plan of the Games
The initial plan was to design two games with similar features in different platforms. This plan
evolved as the framework became more flexible and the need to demonstrate this required the
games to have different features. The following list is the set of features planned initially for
both games.
• Simple 2D User Interface
• Log in screen
• Lobby - After logging in users will have a lobby where they can check the current statistics of other players, chat with other online players and initiate games.
• Game Board/Game Table - When the game starts the user is taken to the game board for
chess and game table for poker and a chat window will be available for him to chat with
the opponent.
64
D.3
Initial Design of the Framework
Figure D.1 shows the initial design of the framework. At this point the framework still incorporated some of the features that later became modules.
Figure D.1: Framework’s Initial Design
D.4
Initial Design of the Chess Game
Figure D.2 shows the initial design of the Chess Game. At this point the responsibility of processing all message was on a single class. In addition one UI class was in charge of displaying
game screens and receiving user inputs.
Figure D.2: Chess Game’s Initial Design
65