Franc¸ois Deli
Aalborg University
Fredrik Bajers Vej 5, 9100 Aalborg, Denmark
Esteban Zim
e Libre de Bruxelles
avenue F.D. Roosevelt 50, 1050 Brussels, Belgium
On-line role playing, multi-player game, web services, communication models, community acceptance.
Star Wars Combine is a game involving thousands of players in a virtual world. Each player impersonates a
character that continues evolving even when the player is not connected. Players have formed groups, called
factions, that are self-organized. The more members a faction has, the more complicated to manage it becomes.
The goal of this work is to create an infrastructure to allow faction management tools to automatically update
their data with the information maintained on the game server. The web services technology is chosen for the
various advantages it offers. While this technology is already widely accepted in the business world, its use
in a game context is totally new. It seems that web services have gained their place in the game world and
will continue to be developed. Hopefully, this experiment will convince other game designers to adapt their
platforms in a similar manner.
Web services are widely used by several companies to
maximize their e-commerce products. In view of all
the advantages that such services offer, we wondered
whether they could also be usefully integrated into
Massively Multi-Player On-line Role-Playing Games,
briefly MMORPGs. We tried to apply them to a well-
known MMORPG called Star Wars Combine
, briefly
SWC. The experience revealed soon to be fully suc-
cessful, as we will explain in this paper.
SWC is defined by its main developers as follows :
“The Star Wars Combine is a free mas-
sively multi-player on-line role-playing simula-
tion game, based on the Star Wars universe, de-
veloped by amateurs during their spare time.
Through its simulation aspects, SWC introduces
and develops the concept of factions. Factions are
groups of players who are given in-game tools to or-
ganize and manage themselves. The faction leaders
have access to various data concerning their factions:
membership statistics, reports, inventory status, maps,
etc. With time, a growing need emerged for the fac-
tions to be able to retrieve information in a usable for-
mat and to import it in their own application.
The project consisted in trying to develop a client-
server architecture using web services technology. By
invoking remote methods, factions would be able to
perform various actions without using the game inter-
face anymore, but by using their own application in-
stead. Among the system specifications, the commu-
nication system to be created would have to be easy
for both server and client programmers to implement,
while offering security features to allow users to au-
thenticate themselves and retrieve the data in relation
to their characters’ access levels.
This paper is organized as follows. Section 2
briefly presents the SWC game concepts and its cur-
rent architecture. Section 3 defines our objectives and
explains why the web services technology was chosen
to set up a new communication infrastructure. Sec-
tion 4 presents the implementation design. Section 5
discusses security mechanisms such as the authentica-
tion and the authorization processes. Section 6 shows
how the web services were perceived by the commu-
nity, as illustrated by some usage statistics. Section
7 concludes with an evaluation of the work and per-
spectives for future developments.
Deliège F. and Zimányi E. (2006).
In Proceedings of WEBIST 2006 - Second International Conference on Web Information Systems and Technologies - Internet Technology / Web
Interface and Applications, pages 441-446
DOI: 10.5220/0001254204410446
As already mentioned in the introduction, SWC is a
MMORPG based on the Star Wars universe, devel-
oped by amateurs during their spare time. It offers
one of the best Star Wars universe simulation with its
own various game mechanisms related to the physics,
economics, politics or engineering in the universe.
As in any role-playing game, the character is one
of the most important game concepts. Any player
joining the game is invited to create his own charac-
ter with various specific skills that he will be able to
enhance throughout the game. In most MMORPGs
when a player disconnects, his character is saved in
the game database and his avatar disappears from the
game. When the player returns, his character reap-
pears somewhere in the game universe. SWC has
adopted a different approach: once a player has cre-
ated a character, his character remains in the game
universe until it gets killed. This is referred as char-
acters persistence.
Factions are another main concept of SWC, as
shown in Figure 1. Factions are groups of players
who are organizing and managing themselves. SWC
proposes a complete system allowing any player to
create his own faction whenever he wishes. He will,
however, have to fulfill a few in-game conditions such
as a determined capital, in-game cash, or in-game as-
sets as well as out-of-game conditions such as the cre-
ation of a web site. Upon foundation of a new faction,
the player may again decide in which area his faction
will work and develop, e.g., a faction may specialize
in bounty hunting, mining, trading, or any other ac-
tivities. In order to manage themselves, factions can
use tools made available to them through the game
interface. Those tools are very useful and offer vari-
ous ways to manage the faction, but the possibilities
to export the data remain limited. While exporting
data does not seem very useful for small factions, it
is a very attractive feature for most of the medium to
large scale factions, that have most of the time devel-
oped a dynamic web site as well their own application
and tools.
Figure 1: SWC main concepts.
Today, SWC counts more than 2000 active players,
all interacting with the game engine through a web-
based game interface. This Graphical User Interface,
briefly GUI, is the only existing way to interact with
the game engine.
The purpose of creating a web services infrastruc-
ture is to allow communications between heteroge-
neous machines and the game engine. In large fac-
tions, groups of players tend to develop their own
tools to improve their management capacities and en-
large their game experience. Web services would al-
low those tools to be automatically updated with fresh
data. The three specific objectives of this work are
therefore the following:
1. To develop a web services architecture for the game
server already in place. By invoking remote meth-
ods, factions will be able to perform various actions
without using the game interface anymore, but by
using their own application instead. Among the
system specifications, the communication system
to be created will have to be easy for both server
and client programmers to implement, while offer-
ing security features to allow users to authenticate
themselves and retrieve the data in relation to their
character access levels.
2. To integrate the web service infrastructure into the
already deployed game server with respect of both
server security and game rules.
3. To demonstrate the technology usability and mea-
sure its acceptance among the whole community.
The decision of using web services technologies to
enable remote faction management was made for the
following reasons:
Faction communication has clearly a distributed
computing nature: parts of the solution exist in
multiple network endpoints.
The solution has to be built and run by various orga-
nizations involving different administration teams.
The data need to be available to more than just the
core application that generates and maintains them.
Most of the transactions should become automated
and therefore extensive use of machine-to-machine
communication is preferable.
The solution needs to be flexible to respond to the
various changes that future developments could re-
quire from any partner.
While web services have been adopted by major
companies such as Google or Amazon, it does not
seem that any game has already truly made the step
of widely using them. Most existing games using
web services as part of their core features are very
basic ones such as Tic-Tac-Toe games. Other games
are using web services: for example, YaYa LLC
developed a platform using web services capabilities
that allow software designers to create games captur-
ing data on a player’s preferences, e.g., for car mod-
els. This information is then delivered to a Customer
Relationship Management system, e.g., the car man-
The SWC technology is an on-line browser-based
game model. The server runs the simulation logic
and generates web pages to interface with the players.
The whole game is therefore centralized in one loca-
tion and no information is transmitted to third parties’
web sites. The primary purpose of the SWC web ser-
vices is to enable client interaction with the simula-
tion server. Two models of communication exist.
(a) Direct trust
(b) Indirect trust
Figure 2: Trust models.
The direct trust relationship model, Figure 2(a) en-
ables third parties’ applications to directly connect
to the central application and perform actions or up-
dates. The GUI becomes one of the many applications
that connect to the server and permits user interaction.
In the indirect trust relationship model, Figure 2(b),
third parties’ clients are enable to interact with each
other directly and to develop their own client server
architecture that allows client applications to directly
interact with the game server.
Figure 3: SWC layers web services.
Figure 3 shows how the web services infrastruc-
ture components (remote objects and remote methods
interface, web services logic and management inter-
face) will be integrated into the already existing pro-
duction server. Web services represent an alternative
to the classical web interface used to interact with the
game server. They lay between the client and the li-
braries, next to the web interface. A new set of rules,
proper to web services, are created to handle web
services access. These authorization rules are com-
pletely independent from the “In-Game” rules that be-
long to the simulation.
The authentication and authorization mechanisms are
not independent from each other. The partners which
are involved in the authorization process need to have
their identity verified by the authentication process.
The SWC security requirements are as follows:
The administrators need to be able to control which
faction has access to a particular web service.
The game requires a user authentication to perform
character actions.
Factions can not be trusted and should not handle
critical user information such as user password.
A web site can be used by multiple factions.
A faction can be using multiple web sites.
5.1 Authentication
The web service authentication and authorization pro-
cesses are composed of three following steps pictured
in Figure 4:
1. User authentication and creation of a authenti-
cation contract: When a user wants to authenti-
cate to use web services features offered on a web
site, the web site redirects him to a SWC authenti-
cation page. The authentication page uses the id of
the client to warn the user that the specified client
is trying to authenticate him and displays a login
form (Step 1a). Once successfully authenticated,
Figure 4: Authentication process overview.
the SWC server generates a contract. The contract
includes information such as the user identification
number, the client identification number and the
contract validity duration. Then, the server redi-
rects the user to the web site. It uses the user’s
browser to communicate to the client a contract
identification string. If the client is not registered
as a web interface, the authentication page simply
displays the identification string (Step 1b).
2. Client authentication and generation of a secu-
rity token: In order to work, SWC web services
require security tokens, briefly sToken. The sTo-
ken must be provided for each web services call by
the client. A sToken is an object abstraction of a
few security information such as the contract iden-
tification string or the query number. In order to
obtain a valid sToken, the client has to request one
from the SWC server using a web service (Step 2).
3. Accessing web services using a sToken: Using
the sToken received in Step 2, the client can try to
access web services. The client simply has to pro-
vide the sToken in every web service call it makes.
All communications are encrypted using SSL, this
prevents third parties to access the exchanged in-
formations (Step 3).
5.2 Authorization
The SWC web services are grouped in the following
three categories:
Public web services: These web services do not
require any kind of authentication. Their purpose is
advertisement. They are really easy to implement
but do not offer many functionalities. They can be
used to obtain server time, time conversion and the
list of all visible systems in the galaxy or estimate
time of arrival for a given travel.
Client-restricted web services: These web ser-
vices require only client authentication. They
have more functionalities than public web ser-
vices: clients can download the whole galactic
map, browse the character profiles or connect to the
galactic news system.
User-restricted web services: These web services
require both client and user authentication. Players
can download their character information, list the
faction members, connect to their personal inven-
tory or retrieve their faction assets.
The authorization process has two main objec-
tives: allowing administrators to introduce restric-
tions aimed at preventing abuses (via so-called admin-
istrator rules) as well as allowing users to introduce
restrictions aimed at protecting their privacy (via so-
called user rules).
The administrators can introduce restrictions via
rules of the following types:
User rules: Such rules have the finest granularity.
They allow the administrator to authorize or deny
web service access to a particular character using a
specified client. A user-type rule requires that user
authentication is used in order to apply.
Factions rules: Such rules have a lower granularity
as they manage all the members of a faction at the
same time. They are only effective if no user rule
was found and if user authentication is used.
Clients rules: Client rules have a lower priority
and granularity than the two previous ones. They
manage all connections made by anyone trying to
access particular web services with a given client.
Default rules: Default rules have the lowest prior-
ity and granularity of of all. They allow the admin-
istrator to set up a default behavior when accessing
a web service.
Additional rules have to be set up by the user.
These rules ensure that the user has deliberately al-
lowed a client to access a web service using its ac-
Figure 5: Authorization rules for WS requiring client au-
Figure 5 represents the different steps the autho-
rization goes through before access is granted or de-
nied to a particular client. In case of user authenti-
cation, the user needs to authorize the client to use
the web services. The authorization process uses four
filters to get to a decision as illustrated in Figure 6.
Figure 6: Authorization rules for WS requiring user authen-
Although this system allows a very fine control of
what can be done or not, it got some negative feed-
back. The user authorization steps were seen as too
complicated, as many users were not aware of which
web services are involved in most transactions. As an
improvement, users proposed the creation of a pack-
age concept. Packages are sets of web services that
are working in the same semantic domain. For ex-
ample, an inventory package was created to group all
the web services related to the various assets owned
by a faction. For each package, a description is avail-
able. Furthermore, for each web service in a package,
a user friendly description is provided.
One major objective of this project is to observe how
the SWC community responds to the creation of the
web services infrastructure. Measuring community
acceptance of new features, such as the web services
proposed in this paper, in a massively multi-player on-
line role-player game is a difficult task. The measure-
ment includes many elements, which need to be ana-
lyzed by various specialists such as psychologists, so-
ciologists, game experts, etc. However, the following
indicators predict a good future for a wider adoption
of web services in the MMORPGs context:
The large number of clients developed or being de-
veloped over a very short period of time.
The numerous complaints about the imperfections
in the pilot web services architecture proposed.
The huge number of requests coming from the de-
velopers for new web services features.
The high number of utilizations revealed via the
statistics tool.
The initiative taken by some developers to create a
wiki web site dedicated to document the web ser-
vices component and share their code.
The great speed at which bugs have been identified.
So far, twenty two clients went through the regis-
tration process successfully. The Galactic Empire is
one of the largest faction in the game and provides all
its members with a single and user-friendly web page
containing all the galactic news.
The CenterPoint Space Station, another large fac-
tion, is using web services to keep its inventories up
to date. Once a player has performed authentication
through the web services mechanism, he has access to
all his character’s belongings and he can also obtain a
list of his faction’s assets, provided he has the required
privileges. Furthermore, the CenterPoint Space Sta-
tion has created a dynamic map to locate its assets in
the galaxy. Assets are marked with dots on the map.
When moving the mouse to one of these dots, the user
can obtain various information about the assets placed
One of the main activities of the Galactic Corpora-
tion consists of an on-line auction web site for objects
in the galaxy. It is concerned with many security is-
sues, in particular the verification of its user accounts.
Not surprisingly, the Galactic Corporation has mainly
been using account verification web services.
Every time a client is successfully authenticated
and authorized to use a web service, a record con-
taining its clientID, the userID, the time and the web
services requested is stored on the database. All these
data are then used for statistics purposes. Figure 7
shows the web services use from 16 June to 8 August
2005. The huge amount of calls made by the Galac-
tic Empire in order to access the news system should
be noticed. Security measures have to be taken to
avoid massive resources consumption by a minority
of clients. An automated limitation tool will need to
be put in place so as to avoid abuses or unfortunate
Today, SWC web services have reached the stage of
direct trust relationship defined in Section 4. The
large number of clients developed in a very short time
has demonstrated the usability of the technology. The
current release of the SWC web services component
allows clients to retrieve information about invento-
ries, characters, galaxy map, galactic news and time
as structured data easily integrable in any other appli-
While building the web services server application
and proving its usability and usefulness was quite
an achievement, the community acceptance objective
was not forgotten. We think this objective was also
reached, as demonstrated by the comments received
from users.
As for the future of the web services component,
Figure 7: SWC web services usage.
we strongly believe that it can easily be expanded to
include new features. As the infrastructure is now in
place, this would not take up much time. On the other
hand, it would be very useful to set up a developer
working group to insure that the new features are in
line with the game rules.
Concerning the development of the next version
that would allow to reach the indirect trust relation-
ship stage, we, however, recommend to pay great at-
tention to the following aspects:
the important amount of time which will be needed
to set up the necessary public key infrastructure;
the client technical limitations, as most clients will
not be allowed to install the cryptographic libraries
required; and
the high level skills that will be requested from the
developers, in particular on the client side.
For these reasons, we do not recommend that the
current web services component be upgraded in the
short time. SWC is already a pioneer with regard to
web services: no other game is yet using such a tech-
nology. We think it would be wise to wait for more
feedback from the community before investing more
time in web services.
We would like to thank Jehan Snyers d’Attenhoven
for imagining the SWC and without whom this pas-
sionating work wouldn’t have been possible, and also
all the SWC developers for their devoted work and
Daconta, M. C., Obrst, L. J., and Smith, K. T. (2003). The
Semantic Web: A Guide to the Future of XML, Web
Services, and Knowledge Management. Wiley.
Endrei, M., Ang, J., Arsanjani, A., Chua, S., Comte, P.,
Krogdahl, P., Luo, M., and Newling, T. (2004). Pat-
terns: Service-Oriented Architecture and Web Ser-
vices. IBM Redbooks.
Fuller, J., Egervari, K., Fuecks, H., Waters, B., Stephens, J.,
and Solin, D. (2003). Professional PHP Web Services.
Graham, S., Davis, D., Simeonov, S., Daniels, G., Britten-
ham, P., Nakamura, Y., Fremantle, P., dieter Konig,
and Zentner, C. (2005). Building Web Services with
Java, Making sense of XML, SOAP WSDL, and UDDI.
Sams Publishing.
IGDA Online Games SIG (2004). Web and Download-
able Games White Paper. http://www.igda.org/online/
IGDA WebDL Whitepaper 2004.pdf.
Iverson, W. and O’Reilly, T. (2004). Web Services in Action:
Integrating with the eBay Marketplace. O’Reilly.
OASIS (2005). Security Services (SAML) TC.
http://www.oasis-open.org/committees/tc home.
php?wg abbrev=security.
Rosenberg, J. and Remy, D. (2004). Securing Web Ser-
vices with WS-Security: Demystifying WS-Security,
WS-Policy, SAML, XML Signature, and XML Encryp-
tion. Sams Publishing.
Sarang, P., Browne, C., Ayala, D., and Chopra, V. (2003).
Professional Open Source Web Services. Wrox.
Snyers d’Attenhoven, J. (2003). SW Combine Strate-
gic Overview. http://www.swcombine.com/
documentation/pdf/SWC-SO-v1 0.pdf.