OpenLobby: A Non-Dedicated Game Server
Firstname A. Lastname1, Firstname B. Lastname2, and Firstname C. Lastname1
1
First affiliation, City and postcode, Country
2
Second affiliation, City and postcode, Country
Email: first.author@hostname1.org; second.author@hostname2.org; third.author@hostname3.org
Abstract— Online Multiplayer is one of the most desirable
feature in modern games. However, developing online
multiplayer feature may require cost and skill which is not
common in small and early game developers. Our objective is to
develop a server that openly available to be used by other
developers. Any games that follows the provided application
progrmaming interface may use the server for matchmaking and
basic user's data management. For testing purpose, we
developed two different games that uses the server as their
multiplayer server.
Index Terms—Numerical Programming, Precision Error, Java
Programming, BigDecimal, Performance Computing,
I. INTRODUCTION
A. Background
Modern video games industry is flooded with games
with online multiplayer capability. It is one for the
commonly required feature by user since it is capable in
lengthening the lifespan of a game.
However, developing an online multiplayer feature in a
game is not a trivia task. It requires a specific skills and
tools to develop the feature. While large game developers
already have enough resources to develop this feature,
(network programmer, game/database server), small
game developers might not be able to have these
privileges. Common game engines such as Unity and
Unreal has also provide a higher level API to decrease the
complexity in developing a multiplayer feature. However,
this feature still requires networking programming skill
and developed specifically to a certain game engine.
In this paper, we propose a solution that able to help
small developers to add an online multiplayer feature in
their product. Our solution consists of 3 part: game
server, API documentation, and game samples. The game
server provides a process to find a set of compatible
players based on some certain criteria (usually called a
matchmaking) and basic user's data management. The
API documentation provides a thorough information
regarding how to communicate properly to our server.
We also provide two game as samples that use our server
that can be used as a reference for other game developers.
Manuscript received Month Day, 2016; revised Month Day, 2016.
This work was supported by the Foundation Name under Grant No.
XXXXXX.
Corresponding author email: author@hostname.org.
doi:10.12720/jcm.v.n.p-p
Our objective is to decrease the required skill and
resource to develop an online multiplayer games. While
we are concern with the usability of our solution, our
current observation does not focus on performance issue.
B. Related Works
In his work, Cowlishaw [11] shows how decimal
representation using binary floating point may cause a
correctness issue. One of the example given is the
problem of calculating a 5% sales tax on a $0.70
telephone call. Using manual calculation, we can easily
figure out that total cost would be 0.735. However, a
double precision binary floating point calculation would
give us 0.7349999999999999 (which could be rounded to
$0.74).
Researches on binary floating point mostly fall into
two categories: correctness and performance. Erle et. al.
offers a hardware specification that may increase the
performance of floating point based calculation while
maintaining its precision [2]. The paper proposed a
hardware that support decimal floating point calculation
natively which eliminate the need to convert the decimal
into binary format. Beauchamp et. al. proposed three
architectural modifications on field programmable gate
arrays (FPGA) that may increase the efficiency of
floating point operations.
Researches focusing on precision have also been done
previously. Joldes et. al. introduces arithmetic algorithms
using floating points expansion that offers a better
precision. The work offers improvement in performing
normalization, division, and square root [7]. Similar work
has also been done by Muller et. al. that focus their
research in multiplication operation algorithm using
floating-point expansions [6]. Ruibo-Gonzalez et. al.
offers Precimonious [4], a program that able to assists
developers to tune the precision of floating points
program. It allows developers to define the desired
precision and set floating point variables to satisfy the
constraints. It also allows developers to increase the
performance of the program by allowing the use of less
precise floating point variables. Later on, Rubio-
Gonzalez proposed a method to automate precision
analysis of a floating point operand [5] called Blame
Analysis. This method, combined with his previous work
Precimonious, allows programmer to have an automated
precision data and control on an applications code. Hull
et al. proposed an architecture design for coprocessor that
able to perform variable precision floating point
arithmetic. Ho et. al. created a similar program that
allows developer to perform floating point precision
tuning efficiently [7]. A research from NASA by Goodloe
et. al. focus on verifying the correctness of numerical
program [10]. Chiang et. al. developed a heuristic search
algorithm called Binary Guided Random Testing [11].
The program evaluates floating point routines and find
the input that maximize the error. By using the evaluation
results, programmer can allocate resources to a certain
routine that requires more precision. MAKE MORE
RELATED WORK, LIBS OF JAVA FOR SCIENTIFIC
II. SERVER ARCHITECTURE
The overall architecture of our server is as follow
The server contains 3 important items; web server,
database, and daemon. The web server is responsible to
receive user's request and send the appropriate response.
The communication is done via HTTP request. The
database is responsible in keeping the data. The format of
the data kept in the database will be defined in the later
section. To perform matchmaking, we create a daemon
program and scheduled the program to perform a
matchmaking process every 10 seconds. The details of
the matchmaking algorithm will be detailed on the later
section.
A. Web Server
The web server is responsible in receiving and
processing request from client and sending the
appropriate response to client. Currently, our server is
able to process basic functions of a game server.
The first basic function of the server is to register a
new player who would like to join a multiplayer game
session. When a client is requesting to join a multiplayer
game, it send a request to join to the server. The server is
then kept the basic information related to the request such
as request arrival time and client's IP address.
The second basic function is to inform the client
whether the client has been joined to a multiplayer
session. Our system follows a pull-notification method to
perform this function; clients send a request to get the
update from the server.
The third function is to update the player's information
related to the game such as score, win/lose, rank, etc.
This information is sent after a multiplayer session has
completed.
B. Database Architecture
In designing the database server, we have to consider
the various requirement of games that may connect to our
server. Different games have different requirements and
criteria to create an ideal session. Most games, if not all,
rely on player's rank and experience to define an ideal set
of players. Some games use additional player's properties
such as region, latency, and preference.
To provide the different requirements of games, we
have to develop a flexible concept to store player's
properties. We can not define one player's property as a
single column since each game may require different
properties. We came up with a simple solution to store
various properties; a text based values delimited with a
specific unusable character. Hence, we only need a single
column to store all properties defined by the game.
The figure below shows the overall architecture of our
database design.
FIGURE DATABASE
The database consists of 4 table: game, player, queue,
and session. Table game contains information regarding
registered games. The properties field contains a
delimited text that lists the properties of the game and its
default value. Similar to properties, the
matchmaking_algo is also contains a delimited text that
defines the algorithm to find a suitable player based on
their properties. Figure XX below shows the structure of
the text in properties and matchmaking_algo fields.
FIGURE PROPERTIES MATCHMAKING
The definition of the of these values will be defined in
the later section when we discuss the matchmaking
process.
Table queue holds all players that queueing during the
matchmaking process. Table session is responsible in
keeping sessions' data. Due to our architecture that use
P2P multiplayer, each session has a player that act as a
host.
C. Matchmaking Process
The matchmaking process is responsible in grouping
idle player in the queue. The main challenge in our
matchmaking system is each game has its own properties
to define an ideal group of players. The goal of the
algorithm is to assign players to different groups in a way
that maximizes the player in each group and satisfies the
property values based on the game definition.
As previously stated, the properties are kept as text
value. Additionally, we also kept the time the player start
queueing and overall score. The overall design of the
matchmaking process is shown in diagram below.
The matchmaking process starts by selecting player
with the longest waiting time. The system will then pick
another set of players (based on the number required by
the game to start a session) prioritizing players with
longer waiting time.
III. IMPLEMENTATION
In this section, we will go through the implementation
of the architecture previously described.
A. Web Server
The web server is built using PHP. It uses HTTP
protocol to communicate with the clients.
B. Communication Protocol
The current web servers allow 5 functions as listed
below:
1. enqueue: this function is called when a user wants
to be listed as queueing in a game queue.
2. get_status: this function is called by user to check
its queue status. The server is then return the user's
status whether its waiting, found, or canceled.
3. get_session_info: this function is called by user to
find information regarding the session it is in. The
information sent contains the host IP address,
session_id.
4. session_started: this function is called by the host
right after a session is started.
5. update_result: this function is called by the host
after a session is over. Its function is to update the
session data which is used to update the user's
data.
6. remove_queue: this function is called when a user
wants to be removed from a queue.
IV. TESTING
To test whether the server can successfully work, we
built two different games. The first game is a question-
and-answer math games that allows two players to
compete with each other. The priority of the
matchmaking process for this game is to find 2 players
with similar experience and skill. These variables can be
determined by using the amount of game has been played
and the win/lose ratio during those games. Since the
gameplay does not require a real time performance, we
do not use delay and player's location for consideration.
The screenshot of the game
The second game is a top down shooter that allows
multiple players to play in a session. Players will be split
into two groups and each group will try to beat the other
group by getting more points. Unlike the previous one,
this game requires a more complex matchmaking system
since it allows eight players to play in a multiplayer
session. The matchmaking requirement is similar to the
previous game.
APPENDIX A APPENDIX TITLE
Appendixes, if needed, is numbered by A, B, C... Use
two spaces before APPENDIX TITLE.
ACKNOWLEDGMENT
The authors wish to thank A, B, C. This work was
supported in part by a grant from XYZ.
REFERENCES
(Periodical style)
[1] S. Chen, B. Mulgrew, and P. M. Grant, “A clustering
technique for digital communications channel equalization
using radial basis function networks,” IEEE Trans. on
Neural Networks, vol. 4, pp. 570-578, July 1993.
[2] J. U. Duncombe, “Infrared navigation—Part I: An
assessment of feasibility,” IEEE Trans. Electron Devices,
vol. ED-11, pp. 34-39, Jan. 1959.
[3] C. Y. Lin, M. Wu, J. A. Bloom, I. J. Cox, and M. Miller,
“Rotation, scale, and translation resilient public
watermarking for images,” IEEE Trans. Image Process.,
vol. 10, no. 5, pp. 767-782, May 2001.
(Book style)
[4] A. Cichocki and R. Unbehaven, Neural Networks for
Optimization and Signal Processing, 1st ed. Chichester,
U.K.: Wiley, 1993, ch. 2, pp. 45-47.
[5] W.-K. Chen, Linear Networks and Systems, Belmont, CA:
Wadsworth, 1993, pp. 123-135.
[6] H. Poor, An Introduction to Signal Detection and
Estimation; New York: Springer-Verlag, 1985, ch. 4.
(Book style with paper title and editor)
[7] R. A. Scholtz, “The Spread Spectrum Concept,” in
Multiple Access, N. Abramson, Ed. Piscataway, NJ: IEEE
Press, 1993, ch. 3, pp. 121-123.
[8] G. O. Young, “Synthetic structure of industrial plastics,” in
Plastics, 2nd ed. vol. 3, J. Peters, Ed. New York: McGraw-
Hill, 1964, pp. 15-64.
(Published Conference Proceedings style)
[9] S. P. Bingulac, “On the compatibility of adaptive
controllers,” in Proc. 4th Annu. Allerton Conf. Circuits and
Systems Theory, New York, 1994, pp. 8-16.
[10] W. D. Doyle, “Magnetization reversal in films with
biaxial anisotropy,” in Proc. 1987 INTERMAG Conf.,
1987, pp. 2.2-1-2.2-6.
(Presented Conference Paper style)
[11] G. W. Juette and L. E. Zeffanella, “Radio noise currents n
short sections on bundle conductors,” presented at the
IEEE Summer Power Meeting, Dallas, TX, June 22-27,
1990.
(Thesis or Dissertation style)
[12] J. Williams, “Narrow-band analyzer,” Ph.D. dissertation,
Dept. Elect. Eng., Harvard Univ., Cambridge, MA, 1993.
[13] N. Kawasaki, “Parametric study of thermal and chemical
nonequilibrium nozzle flow,” M.S. thesis, Dept. Electron.
Eng., Osaka Univ., Osaka, Japan, 1993.
(Patent style)
[14] J. P. Wilkinson, “Nonlinear resonant circuit devices,”
U.S. Patent 3 624 12, July 16, 1990.
(Standards style)
[15] Letter Symbols for Quantities, ANSI Standard Y10.5-
1968.
(Handbook style)
[16] Transmission Systems for Communications, 3rd ed.,
Western Electric Co., Winston-Salem, NC, 1985, pp. 44-
60.
[17] Motorola Semiconductor Data Manual, Motorola
Semiconductor Products Inc., Phoenix, AZ, 1989.
(Journal Online Sources style)
[18] R. J. Vidmar. (August 1992). On the use of atmospheric
plasmas as electromagnetic reflectors. IEEE Trans.