Middle East Technical University: Massively Multiplayer Online Role Playing Game Project Virtual Turkey

Middle East Technical University
Ceng 491
Software Requirements Specifications
Massively Multiplayer Online Role Playing Game Project
Virtual Turkey
MECAC
Cinar Kilcioglu
Mert Degirmenci
Umit Cavus Buyuksahin
December 5, 2010
Contents
1 Introduction 1
1.1 Problem Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.3 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.4 User and Literature Survey . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.5 Definitions and Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.6 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.7 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2 Overall Description 4
2.1 Product Perspective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2 Product Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2.1 User Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2.2 Administrator Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . 8
3 Specific Requirements 10
3.1 Interface Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.1.1 User Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.1.2 Hardware Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.1.3 Software Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.1.4 Communications Interfaces . . . . . . . . . . . . . . . . . . . . . . . . 11
3.2 Functional Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.2.1 Sign-Up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.2.2 Play . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.2.3 Update . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.2.4 Manage Accounts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.2.5 Monitor Network Traffic . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.2.6 Manage NPCs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.3 Non-Functional Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.3.1 Performance Requirements . . . . . . . . . . . . . . . . . . . . . . . . 16
3.3.2 Design Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4 Data Model and Description 17

4.1 Data Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.1.1 Data Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.1.2 Relationships . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.1.3 Complete Data Model . . . . . . . . . . . . . . . . . . . . . . . . . . 23
5 Behavioral Model and Description 23

5.1 Description for Software Behavior . . . . . . . . . . . . . . . . . . . . . . . . 23
5.2 State Transition Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
6 Planning 26
6.1 Team Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
6.2 Estimation (Basic Schedule) . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
6.3 Process Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
7 Conclusion 28
List of Figures
1 Virtual Turkey . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2 Sample Quest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3 General View of the System . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4 Client Software Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5 Server Software Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
6 Sign-Up Use Case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
7 Play Case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
8 Sign-Up Use Case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
9 Manage Accounts Use Case . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
10 Sign-Up Use Case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
11 Manage NPCs Use Case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
12 The Complete Data Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
13 Quest Data Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
14 NPC Data Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
15 Character Data Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
16 Vehicle Data Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
17 Account Data Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
18 Treasure Data Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
19 Entity Relationship Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
20 State Transition Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
21 Game Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
22 The Spiral Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
23 Gantt Chart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
1 Introduction
This document contains the software requirements for “Virtual Turkey” which is a massively
multiplayer online role playing game (MMORPG). The approach used in this specification
is adapted from IEEE recommended practices [1]. This document also abides the standards
presented [2]. MECAC, the project group, assumes full responsibility of the requirements
presented in this document.
1.1 Problem Definition

Turkey has variety of places with cultural inheritance to visit. In order to bolster touristic
interest in Turkey, we will develop an online multiplayer game which will provide culture
enthusiasts around the world the opportunity to preview sightseeing places in Turkey. To
meet the requirements of an MMORPG, the game being developed is expected to support
thousands of players concurrently. The project will later be published under GNU license
when it reaches the maturity of other well-known open source MMORPGs.
1.2 Purpose
This software requirements specification intends to provide complete description of all re-
quirements of “Virtual Turkey”. The requirements suggested in this document will serve as
a guideline throughout the development process of this project. The end-product will be
tested against the requirements to ensure the quality of the software produced.
1.3 Scope
This document addresses the functionality, external interfaces, performance, attributes, and
design constraints of the MMORPG to be developed. However, the requirements presented
in this document does not impose any design or implementation details.
1.4 User and Literature Survey

There are some open-source MMORPG projects currently available. Most popular and well-
known open-source project is WorldForge[3] .
The WorldForge project aims to produce an open source framework for MMORPG. The
intent of the project is to create a widely used development framework and set of libraries
by motivating interested developers.
Software Requirements Specifications for Virtual Turkey 1

Besides WorldForge, there are many MMORPGs that can be played free of charge online
such as Allegiance[4] . It provides a mix of real-time strategy and player piloted space combat
gameplay. Initially developed by Microsoft Research, the game was later released under a
shared source license in 2004[5] and is now maintained and developed by volunteers[6] .
Despite numerous open-source and free games released, a commercial MMORPG is still
dominating the market. In April 2008, World of Warcraft (WOW) was estimated to hold
62% of the MMORPG subscription market[7] . Although this ratio may have slightly changed
during the last two years, WOW is still the most popular MMORPG.
As mentioned in the problem definition, potential users of “Virtual Turkey” are the people
interested in Turkey’s monuments, and the culture enthusiasts.
1.5 Definitions and Abbreviations

CPU Central Processing Unit
DoS Denial of Service
GNU GNU is not Unix
GPU Graphics Processing Unit
GUI Graphical User Interface
IP Internet Protocol
MMORPG Massively Multiplayer Online Role-Playing Game
MPI Message Passing Interface
NPC Non-Player Character
RPM Revolutions per minute
RSA Rivest, Shamir and Adleman
SRS Software Requirements Specifications
1.6 References
[1] IEEE, IEEE Std 830-1998 IEEE Recommended Practice for Software Requirements Spec-
ifications. IEEE Computer Society.
[2] CSS.06 - Yazılım Gereksinimleri Belirtimi Standardı. Rev.7.0
[3] http://worldforge.org/ Retrieved Oct. 28, 2010.

Figure 1: Virtual Turkey
[4] http://en.wikipedia.org/wiki/Allegiance (computer game) Retrieved Nov. 2, 2010.
[5] http://www.microsoft.com/games/allegiance/home.htm, Microsoft Research Allegiance

Source Code. MSR. 2004. Retrieved Nov. 2, 2010.
[6] http://au.gamespot.com/pc/sim/allegiance/news.html?sid=6087574, Colayco, Bob (2004-

02-06). Microsoft pledges Allegiance to its fanbase. Gamespot. Retrieved Nov. 2, 2010.
[7] http://www.mmogchart.com/Chart7.html MMOG Subscriptions Market Share April 2008.

mmogchart.com, Bruce Sterling Woodcock. 2008-04-01. Nov. 4, Retrieved 2010.
1.7 Overview
The report contains seven sections. First section introduces the project “Virtual Turkey”.
In the second section, the game is explained with a high-level perspective. The details of the
project is started to be given in section 3. This section explains the software requirements to
a degree that enables designers to design this system, and testers to test it. Domain for the
software and behavioral model is described in section 4 and 5, respectively. Finally, planning
of the project is presented and the report is concluded.

2 Overall Description
2.1 Product Perspective
The MMORPG project, Virtual Turkey,
mainly serves the purpose of introducing the
worth seeing monuments all around Turkey.
The map of Virtual Turkey with missions is
given in Figure1. The player will be travel-
ing the country in order to collect coins and
the gold scattered over some secret places, as
it can be seen from Figure 2. While visiting
and learning about the invaluable historical
places of Turkey to carry out the quests, the
player will have more chance to gain trea-
sure; however, the treasure has to be hidden
due to non-transportable nature of it, which
makes the game more mysterious and rivet-
ing. Each player is planned to have several
attributes to make the game-play more real-
istic. Player needs these attributes in order
to use the quest system, the player-class sys-
tem and the trade system. For instance, a
player might need an item in order to com-
plete a quest, or a gold to trade.
Virtual Turkey is an independent and to-
tally self-contained system. The major parts
of the system are clients and the server. Figure 2: Sample Quest
Components of the server are NPCs, physics
engine, network and database which holds
the client information. Clients also have physics engine, game loop and the communica-
tion layer. Clients and the server will communicate periodically to initiate and progress the
MMORPG. Block diagram, showing the major components, is shown in Figure 3.

Figure 3: General View of the System
2.2 Product Functions

Actors of the main functions in the system are the user and the administrator. Users has
access to the clients software, and the administrator has access to the server software.
User has three main use cases in the client software, which are shown in Figure 4.
Figure 4: Client Software Use Cases

Administrator has three main use cases in the server software, as shown in Figure 5.
Figure 5: Server Software Use Cases
Below, each use case is explained in detail.
2.2.1 User Use Cases
Use Case: Sign-Up
Figure 6: Sign-Up Use Case
Diagram:
Brief Description: This use case describes how the user interacts with the client
software to create an account on the server database.
Initial step-by-step description:
1. User runs the client component of MMORPG.

2. User clicks the “Sign-up” button.
3. User fills the form for user-id, password, and e-mail.
4. If the user-id does not exist in server database the user account is created.

Use Case: Play
Figure 7: Play Case
Diagram:
Brief Description: This use case describes how user logs-in to the system, plays the
game and logs-out.

2. User clicks Log-in button.
3. User fills the form for user-id and password.
4. If the server authenticates the user-id and password, the user proceeds to the next
step.
5. User clicks “join-game” button, and plays the MMORPG.
6. User clicks log-out button and disconnects from the server.
Use Case: Update
Diagram:

Brief Description: This use case explains how the user updates his account infor-
mation.
Initial Step-By-Step Description:

2. User clicks “Log-in” button.
3. If the user id authenticated, he clicks the “update” button.
4. User updates his information such as username, password, e-mail address.
5. User clicks “log-out” button and disconnects from the server.
2.2.2 Administrator Use Cases
Use Case: Manage Accounts
Figure 9: Manage Accounts Use Case
Diagram:
Brief Description: This use case describes how administrator manages accounts of
users.
1. Administrator logs in to the server computer.

2. Administrator clicks “Accounts” button in server GUI.
3. GUI shows the accounts in tabular form with associated actions.
4. Administrator updates accounts and clicks “commit” button.
5. Administrator logs out from the server computer.

Use Case: Monitor Network Traffic
Diagram:
Brief Description: This use case explains how the administrator monitors the net-
work traffic.

2. Administrator clicks “Monitor” button in the server GUI.
3. GUI shows number of online players, network overhead on the server, and the commu-
nication delays in clients.
4. Administrator views the status of network traffic.
Use Case: Manage NPCs
Figure 11: Manage NPCs Use Case
Diagram:
Brief Description: This use case explains how the administrator manages non-
playing characters.


2. Administrator clicks “Manage NPCs” button in the server GUI.
3. GUI shows non-playing characters and their status in a tabular form.
4. Administrator updates NPCs and clicks “commit” button.
3 Specific Requirements
This section describes all the software requirements to a level of detail sufficient to enable
designers to design and testers to test a system which satisfies this specification.
3.1 Interface Requirements

3.1.1 User Interfaces
There are two user interfaces of “Virtual Turkey”. These are the client interface for the
players and the administrator interface for managing the MMORPG. Following sections
describe the logical characteristics of each interface.
Client User Interface: Clients will interact with the system by means of a personal
computer. After deployment of the client software to users personal computer, the user will
be able to connect the persistent world of “Virtual Turkey” and interact with other clients.
The users of the game will also be able to sign-up through the client software.
Administrator Interface: The administrator user interface will enable interaction be-
tween the administrator of the game and the software. The graphical user interface will
allow the administrator to monitor the network traffic, online players, malfunctions within
the game logic and the client software.
3.1.2 Hardware Interfaces
The client and the server components of the software has different hardware interfaces.
Following paragraphs describe the hardware interfaces for the two components.

Client Hardware Interface: The client component of MMORPG will rely on CPU and
GPU to leverage the computational demand of networking, physics engine, and graphics of
the game. The CPU will belong to x86 family of instruction set architectures. The target
client software is intended to operate on 64-bit processor with 32-bit backward compatibility.
For optimal experience for players, client software will try to offload the graphics and physics
calculation to GPU whenever possible. Client software will also require Ethernet card to
communicate with the server.
Server Hardware Interface: The server-side software will be interfacing with an x86
processor to leverage network and database tasks. For the clients to have seamless experience
with MMORPG the software should interface at-least 15000 RPM disk drive and internet
connection speed of 100 Mbit/second or more.
3.1.3 Software Interfaces
Both the client and the server component of MMORPG will be an application for Windows
NT family of operating systems. As both components will be developed with C# program-
ming language, Microsoft’s .NET 4.0 software framework will be needed. XNA 4.0 runtime
libraries will be used for client-side graphics computation. The physics engine of client will
be leveraged by JigLibx which is specifically designed for XNA. For network communication,
the client and the server software will depend on LidGren library.
3.1.4 Communications Interfaces
The interaction between server and client will be maintained on TCP channel. All other
communications will be carried out on shared memory. The components within the server
will use MPI to communicate over shared memory.
3.2 Functional Requirements

Each major function along with data flow and requirements of it will be presented in this
section.

3.2.1 Sign-Up
Description: This function of the system specifies how user signs-up to MMORPG.
Basic Data Flow:

2. User clicks “Sign-up” button.
4. The user account is created.
Alternative Data Flow 1:

4. The user id exists in the database. Server denies the clients request.
5. The GUI shows an error message asking for user to select different user-id.
6. The sign-up user interface goes back to (3).

4. Password length is less than 6 characters. Server denies clients request.
5. The GUI shows an error message asking for user to select longer password.
6. The sign-up user interface goes back to (3).
Functional requirements:
1. REQ-1: Server should not accept the same user-id twice when signing-up users.
2. REQ-2: Server should not accept the passwords shorter than 6 characters when signing-
up users.

3.2.2 Play
Description: This function specifies the process of user logging-in, playing the game, and
the signing out process. It does not however, specify any content within the game logic, nor
does it specify the graphics within the game.
Basic Data Flow:

4. Server authenticates the user-id and password, and the user proceeds to next step.

4. Server does not authenticate the user-id and password entered.
5. The log-in user interface goes back to (3).

4. Server authenticates the user-id and password, and the user proceeds to next step.
6. User loses its network connection while playing MMORPG.
7. Server logs out the user from the game, and saves-off its state.
1. REQ-3: Server should check the user-id and password entered by the user.
2. REQ-4: Server should log-out the user automatically which has disconnected from the
network.

3.2.3 Update
Description: This function explains how the user updates his/her account information.
Basic Data Flow:

4. Server authenticates the user, and the user clicks the “update” button.
5. User updates his/her information such as username, password, e-mail address, and the
server accepts the request.
6. User clicks log-out button and disconnects from server.

3. User fills it user-id and password form.
4. Server does not authenticates the user, and the log-in screen goes back to (3).

4. Server authenticates the user, and the user clicks the “update” button.
5. User updates his/her information, and clicks the “update” button.
6. Server does not accept the request, showing the user the reason.
1. REQ-5: Server should check the new user-id entered by the user in case it already
exists.
2. REQ-6: Server should check the new password in case it is shorter than 6 characters.
3. REQ-7: Server should check the new e-mail to verify that its a valid e-mail address.

3.2.4 Manage Accounts
Description: This function describes how administrator manages accounts of the users.
Basic Data Flow:

2. Administrator clicks “Accounts” button in server GUI.
3. GUI shows the accounts in tabular form with associated actions.

2. Administrator clicks “Accounts” button in the server GUI.
3. GUI shows the accounts in a tabular form with associated actions.
5. Server rejects the changes explaining the administrator the error occurred.
6. The GUI goes back to (2).
1. REQ-8: Server GUI should not accept two changes at a time to prevent malicious
action of the administrator.
3.2.5 Monitor Network Traffic
Description: This function of the server software specifies how the administrator interacts
with the system to monitor the network traffic.
Basic Data Flow:

2. Administrator clicks “Monitor” button in server GUI.
3. GUI shows number of online players, network overhead on the server, and the commu-
nication delays in clients.
4. Administrator views the status of the network traffic.

1. REQ-9: Server GUI should show the number of online players in the monitor panel.
2. REQ-10: Server GUI should show the communication delays for each user currently
logged into the system.
3.2.6 Manage NPCs
Description: This function specifies how the administrator manages non-player charac-
ters.
Basic Data Flow:

2. Administrator clicks “Manage NPC” button in server GUI.
3. GUI shows non-player characters and their status in a tabular form.
4. Administrator updates NPCs and clicks “commit” button.
1. REQ-11: Server GUI should enable administrator to add/remove non-player character

to the game.
2. REQ-12: Server GUI should enable administrator to change the status or the location
of a non-player character.
3.3 Non-Functional Requirements

3.3.1 Performance Requirements
In order for “Virtual Turkey” to be massively multiplayer, the server should support 1000
users concurrently. The delay of communication between server and the user should not
exceed 0.1 second. The database transaction should not consume more than 10
In order for the MMORPG to be maintainable, the GUI of the server component should
be robust for the administrator to update information or monitor the network traffic. The
administrator should be able to log-on to the server within 5 seconds even when the server
supports a thousand players online. When the administrator clicks “Manage Accounts” or
“Manage NPCs” buttons, the GUI should show the requested information within 10 seconds
and commit the changes within a minute. Monitoring network traffic should not increase
the overhead on server-side as such information can directly be computed on-the-fly. When

the administrator clicks monitor network traffic, the GUI on the server component should
show the current traffic summary within 10 seconds.
3.3.2 Design Constraints
Security: The communication between the server and the client component of MMORPG
should be encrypted with RSA algorithm. Server should also check the cheating case with
offloading major physics calculations to server-side. In order to prevent abuse of the server
component, software on the server of MMORPG should block the recurring requests from
the same IP address. Server should log common proxy addresses as well to check if the client
is performing DoS attack.
Software System Attributes:
1. Maintainability: The modification of the source code should be disabled. The exten-
sions should be applicable directly without modification to the back end. The patching
service should be regarded as a different component in case extensions would be of-
floaded to a different server.
2. Portability: Both the client and the server component of the software should be
portable. The target hardware platform for client component is unknown. Only re-
quirement for the client software to be deployed is the operating system that belongs to
Windows NT family. The server side of MMORPG should be independent of specific
hardware or software configuration.
3. Scalability: Most important software system attribute of “Virtual Turkey” is its scala-
bility. Deploying additional servers and dividing the persistent world should not require
additional extension on the client software.
4 Data Model and Description

4.1 Data Description
The complete data model is given in Figure 12. The focus of the model is on Character
and NPC data objects. Account, Vehicle, and Treasure data objects are associated with
Character object. NPC object, on the other hand stores the information about the trade
items of it. Non-playing characters has no associated vehicles or accounts as it can be
observed from the figure. Following sections describes all the data objects and their major
attributes in more detail.

Figure 12: The Complete Data Model

4.1.1 Data Objects
In this section a brief description of each data object is given. For each data object, function
and semantics associated with it are summarized. This section also describes major attributes
of data objects.
Figure 13: Quest Data Object
Quest This data object represents quest given by non-player characters. Database needs
to store the identifier of the quest which is only major attribute of it.
id: The unique identifier of the quest data object.
Figure 14: NPC Data Object
NPC The NPC data object - as its name suggests - represents a single non-player character
in “Virtual Turkey” MMORPG. Besides its unique identifier, it has three major attributes
namely position, owner, and type.
id: The unique identifier of the NPC data object.

owner: The owner character of the NPC data object.

Figure 15: Character Data Object
Character This data object represents the character of the user associated with the ac-
count. The user character may have associated Vehicle or Treasure data objects.
name: The unique identifier of the Character data object.

account: References corresponding Account data object.
last played: The time that the character last played “Virtual Turkey”.
created on: The time that the character has been created.
position: The location of the character in the persistent world of MMORPG.
quests completed: The quests that the character has completed successfully.
quests in progress: The quests that the character has attempted to complete.
is online: The boolean attribute showing whether the character is connected to per-
sistent world or not.
vehicle: The current vehicle of the character that references a Vehicle data object.
Figure 16: Vehicle Data Object

Vehicle This data object represents the vehicle in “Virtual Turkey”. Only characters can
use the vehicles in the MMORPG to transport their character between different locations of
the persistent world. Each vehicle can be associated with only one character.
id: The unique identifier of the Vehicle data object.

character: References the corresponding character object that owns the vehicle.
position: The current location of the Vehicle in the persistent world of MMORPG.
Figure 17: Account Data Object
Account This data object stores the account information of players. The account data
object does not store the character information. However, it references a character data
object. This approach enables players to have multiple characters in MMORPG.
e-mail: The email address of the account owner.

password: The password of the account owner.
name: The nick name chosen by the account owner.
address: The address of the account owner. This attribute is optional.
last signed on: The last date when the account holder has logged-in.
created on: The date when the account was created.
online: Boolean attribute showing if the account owner is connected.
confirmation code: The confirmation code for account owner.
confirmed: Boolean attribute showing whether the account was confirmed or not.

Figure 18: Treasure Data Object
Treasure This data object represents the treasure items that the characters poses. The
treasure data objects have associated value and position in the virtual world. This data
objects are intended to be traded for items by characters.
id: The unique identifier of the treasure data object.

value: Value of the treasure data object.
position: The location of the treasure data object in the persistent world of MMORPG.
4.1.2 Relationships
This section describes the relationship between the data objects described in the previous
section.
NPC - Quest: Each NPC may be associated with one or more quests. Those quests
are to be completed by characters. However, a quest may not be associated with multiple
NPCs.
NPC - Item: Each non-playing character may own one or more items. However, an
item can not be owned by multiple non-playing characters. NPCs are able to trade the items
with playing characters.
Character - Item: Each character may own one or more items. However, an item can
not be owned by multiple characters. Characters can trade the items and treasures with
other characters or NPCs.
Character - NPC: Each non-playing character is owned by only one character. An
NPC without an owner or a character without an NPC can exist.
Character - Vehicle: Each character can only own one vehicle in the MMORPG. A
vehicle can not be associated with multiple characters.
Character - Account: Each character can be associated with at most one account.
However an account owner may own multiple characters.

Character - Treasure: A character may collect zero or more treasure, however a
treasure can only be owned by a single character.
4.1.3 Complete Data Model
This section describes a complete data model merging data object descriptions with rela-
tionships explained in previous sections. Figure 19 shows the entity relationship diagram of
the data model which provides a conceptual representation of data. Major data objects are
NPC, quest, item, treasure, character, account, and vehicle. The relationships between data
objects provide both semantical and relational information.
Figure 19: Entity Relationship Diagram
5 Behavioral Model and Description

5.1 Description for Software Behavior
The game has two main parts, clients and server. The relationship between these two parts
is accomplished by package transferring between each part’s own communication layer.
Game loop, which belongs to clients component, interacts with NPC part of the server
component and during the interaction, information is passed to NPC through communication

layers. Information can be gain gold, next position of character, vehicles etc. It also initiates
the game to start.
Database inside the server component stores the information such as account information
of the users, last position of the players, and their attributes. It also has a connection with
server physics engine, which enables the physical system of the game.
5.2 State Transition Diagram
Figure 20: State Transition Diagram

Figure 21: Game Architecture

6 Planning
6.1 Team Structure
“Virtual Turkey” Project Team does not have any team leader that directs the project. The
power of the team comes from the motto “Individually, we are one drop. Together, we are
an ocean”. Each member of the team puts all of his effort to the project.
The team has weekly meetings with Assoc. Prof. Veysi Isler, who is the advisor of the
project, at MODSIMMER. The team also meets with Research Assistant Umit Rusen Aktas
to discuss about the progress of the project. Members of the team study the topics that
have been determined before with fully participation every Tuesday and Thursday.
6.2 Estimation (Basic Schedule)

The plan is to prepare the detailed design report and prototype demo till the end of the
semester. Second semester mainly will be based on configuration management, system design
development, and system testing.
The detailed schedule of the project is given in Figure 23.
6.3 Process Model

The spiral model is used as a software development process, which combines elements of
both design and prototyping-in-stages. The project team benefits from the spiral model’s
ability to combine top-down and bottom-up concepts.1 The spiral model used in the project
is given in Figure 22.
Figure 22: The Spiral Model
1
http://en.wikipedia.org/wiki/Spiral model

Figure 23: Gantt Chart

7 Conclusion
This analysis report shows software team’s approach to MMORPG problem. User interaction
with the system is defined in addition to project constraints. Market research presented in
this document covers popular open-source MMORPGs. Scheduling and timeline have also
been specified in this document. This specification will hopefully constitute the basis for
design, development, and testing of the project.

Middle East Technical University: Massively Multiplayer Online Role Playing Game Project Virtual Turkey

Uploaded by

Copyright:

Available Formats

Middle East Technical University: Massively Multiplayer Online Role Playing Game Project Virtual Turkey

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Middle East Technical University: Massively Multiplayer Online Role Playing Game Project Virtual Turkey

Uploaded by

Copyright:

Available Formats

Middle East Technical University

4 Data Model and Description 17

5 Behavioral Model and Description 23

1.1 Problem Definition

1.4 User and Literature Survey

Software Requirements Specifications for Virtual Turkey 1

1.5 Definitions and Abbreviations

[2] CSS.06 - Yazılım Gereksinimleri Belirtimi Standardı. Rev.7.0

[3] http://worldforge.org/ Retrieved Oct. 28, 2010.

Software Requirements Specifications for Virtual Turkey 2

[4] http://en.wikipedia.org/wiki/Allegiance (computer game) Retrieved Nov. 2, 2010.

[5] http://www.microsoft.com/games/allegiance/home.htm, Microsoft Research Allegiance

[6] http://au.gamespot.com/pc/sim/allegiance/news.html?sid=6087574, Colayco, Bob (2004-

[7] http://www.mmogchart.com/Chart7.html MMOG Subscriptions Market Share April 2008.

Software Requirements Specifications for Virtual Turkey 3

Software Requirements Specifications for Virtual Turkey 4

2.2 Product Functions

Figure 4: Client Software Use Cases

Software Requirements Specifications for Virtual Turkey 5

Figure 5: Server Software Use Cases

Below, each use case is explained in detail.

2.2.1 User Use Cases

Use Case: Sign-Up

Figure 6: Sign-Up Use Case

Initial step-by-step description:

1. User runs the client component of MMORPG.

Software Requirements Specifications for Virtual Turkey 6

Figure 7: Play Case

Initial step-by-step description:

1. User runs the client component of MMORPG.

Use Case: Update

Figure 8: Sign-Up Use Case

Software Requirements Specifications for Virtual Turkey 7

Initial Step-By-Step Description:

1. User runs the client component of MMORPG.

2.2.2 Administrator Use Cases

Use Case: Manage Accounts

Figure 9: Manage Accounts Use Case

Initial step-by-step description:

1. Administrator logs in to the server computer.

Software Requirements Specifications for Virtual Turkey 8

Figure 10: Sign-Up Use Case

Initial step-by-step description:

1. Administrator logs in to the server computer.

Use Case: Manage NPCs

Figure 11: Manage NPCs Use Case

Software Requirements Specifications for Virtual Turkey 9

1. Administrator logs in to the server computer.

3.1 Interface Requirements

3.1.2 Hardware Interfaces

Software Requirements Specifications for Virtual Turkey 10

3.1.3 Software Interfaces

3.1.4 Communications Interfaces

3.2 Functional Requirements

Software Requirements Specifications for Virtual Turkey 11

Basic Data Flow:

1. User runs the client component of MMORPG.

Alternative Data Flow 1: