Seamless and Transparent Integration of Content and
Engine Update in online/connected Videogames
Thomas Bousquet
Edouard Kieffer
{tbousquet,ekieffer}@gatech.edu
1. Motivations
Videogames have become a prominent media over the years, becoming in 2007 the second major
source of entertainment. The last evolution of the media as a whole are multiplayer online games
and solo connected games. The former brings several hundreds of thousand players together in the
same world while the latter gives connected value to solitary experiences.
In terms of development cycle, this shift in use created new opportunities but also spawned a lot of
challenges: the developers could now react to users' feedback in matters of hours or days but they
also had the responsibility of handling hundreds of thousand if not millions of users at once.
Three major applications appeared in this domain in the past two years:
● World of Warcraft by Blizzard is the most popular massively online role playing game, it
gathers millions of players 24/7, most of them shaping the universe of the game on a daily
basis.
● Steam, an online distribution service by Valve which automatically delivers updates or
additional content for a large library of online and offline games. It is considered the best of
its kind as it also integrates a social network and advanced system such as matchmaking and
achievements.
● Sam & Max, a digital distributed game series which witnesses a new episode every month
over a period of six months.
These various applications highlight three advantages of connected games : uninterrupted service,
user impacted worlds and shortest, highly dynamic development cycles of incremental game. On
the whole it helps create new kind of games, brought to the end user in new fashions.
The main challenge behind these opportunities is to deliver new content ( both in terms of software
and of assets) in a way that is both tolerable to the user but also noticeable, as new content usually
means new gameplay possibilities. The current paradigm is to check for new content at startup (or
in the case of Steam, at regular interval of times), retrieve it on the client machine and apply it when
the game restarts.
When it comes to art assets integration, some game such as 'Guild Wars' adopts a more elegant
approach : the game world being separated in zones, it downloads & updates the content when
entering a new zone. The other tour de force of Guild War is to be able to maintain all the art
content in one 1.5Go file that is never decompressed.
However, updating the software is still a stop-and-go operation and integrating art assets lack
imagination thus this project offers to explore three different domain of improvement :
● transparent software update delivery and applications through dynamic coding
● intelligent integration of new content within the game logic (application to one or several
genres)
2. Related Work
1. Content delivery
1. Solid State Networks Announces at GDC the First Commercial-Class Content Delivery
Solutions
Based
on
the
BitTorrent
Protocol
http://findarticles.com/p/articles/mi_pwwi/is_200603/ai_n16111129
2. GDC 2008: Akamai Unveils Unique Games on the Edge Portal : work on scalable,
adaptable solution in content delivery http://pc.ign.com/articles/853/853401p1.html
2. Dynamic Coding
1. Java
1. Java Dynamic Proxies: One Step from Aspect-oriented Programming
Learn how to implement application concerns such as logging and remote error
handling across classes using dynamic proxies.
2. Add dynamic Java code to your application - Java World
This article shows you how to make code dynamic, as such, some of your source
code will be deployed, instead of compiled binary code. Any changes to the source
code will cause it to be recompiled and the class to be reloaded. Your application
will then run on the new class, and users will see the change immediately. This
article covers not only runtime source compilation and class reloading, but also a
design that separates the dynamic code from its caller. The caller holds a static
reference to the dynamic code, and no matter how the dynamic code reloads at
runtime, the caller can always access the up-to-date class without updating the
reference. In this way, dynamic code changes are transparent to the client.
3. Java Class Loading: The Basics
Gain flexibility in assembling and extending your application with the Java class
loader architecture.
4. Dynamic Class Loading in the Java Virtual Machine - Liang, Bracha
(ResearchIndex)
Class loaders are a powerful mechanism for dynamically loading software
components on the Java platform. They are unusual in supporting all of the
following features laziness, type safe linkage, user defined extensibility, and multiple
communicating namespaces. We present the notion of class loaders
3. C++ :
1. A Library for Explicit Dynamic Code Generation and Optimisation in C++ (2003) : a
library that was conceived to dynamically compare the performance of different
implementation
of
parallel
paradigm
on
terascale
machine
http://citeseer.ist.psu.edu/679099.html
2. Dynamic C++ Classes A lightweight mechanism to update code in a running
program : IBM sponsored research of an easy, fexible way to make existing C++ code
dynamic http://citeseer.ist.psu.edu/266962.html
4. Integration of new/dynamic content
1. Advertisement Integration that fits the player : research and application that also look for
intelligent
integration
of
new
content
in
the
game
universe
http://games.ign.com/articles/636/636324p1.html
2. Guild Wars Technologies Interview : http://pc.ign.com/articles/534/534454p1.html
3. Proposed Work
System Overview
From what has been described above, we plan to develop a back-end capable of storing both content
and compiled code and sending it to a remote client. We will also develop a simple front-end to
ease administration. The other main part of the project will be a "dynamic client" template. The
client should be able to update the code of the application without requiring a restart, and ideally
without getting in the way of the user. On top of this template, we plan to develop a sample
application demonstrating the benefit of our dynamic code approach. Depending on time
constraints, we will be considering anything between a single player, tile-based exploration game to
a simple multi player, 3D virtual world. In all cases, this sample application will obviously allow
for the game engine to be dynamically updated and content of the game to be dynamically streamed
and/or updated. We will also work on making content delivery seamless for the user by making it
part of the storytelling.
Functionalities
The back-end will provide the following functionalities:
●
Storage of different versions of several compiled modules of the code (eg: graphics engine,
physics engine, etc.)
●
Sending of the version designed as "current" of each module to the clients
●
Storage of content packages
●
Streaming of packages for which a client has a valid authorization, and dynamic updating at
the client of those packages to the most recent version
The front-end will ease administration of the back-end by providing the following functions:
●
Displays a list of all versions of an application module and allow the user to designate one
as the current version
●
Upload of a compiled module to the server
●
Upload of content resources to the server
●
Definition of relations between the content resources (eg: define a "flowers" package
containing 3D model for a rose, a tulip etc.)
●
Manage users and their authorizations for different content resources
Lastly, the dynamic client template will implement the following functionalities:
●
Hot-swapping of some part of the application with a more recent one
●
Access to a local resource storage area
●
An API enabling communication with the server, manual content requests, etc.
Software Used
To develop the application, we will be using either Java or C++. We are currently conducting a
research and doing a first Proof of Concept (PoC) implementation for each language and will then
choose which technology to base the rest of our development process accordingly.
Architecture
4. Plan of Action
Date
February 22nd
Milestone
●
●
February 29th
●
●
March 8th
●
●
March 15th
●
●
●
March 22nd
●
●
March 29th
●
●
April 7th
●
●
●
April 14th
April 21st
Gathered and read bibliography
PoC implementations on their way
Both PoC should be done
Set our choice for either C++ or Java
Have the basic set of functionalities for the back-end ready
Implement matching front-end screens
Get a basic client template to connect with the server
Have a simple application run dynamic code and update content
Basic API feature set
Most features for the back-end ready
Matching front-end screens
Improved client template code
Resume API development
Security model for content authorization management devised
Implementation in back-end, front-end and API
Features' freeze
●
Back-end/front-end/API stabilized and debugged
Sample application half done
●
Sample application ready for the show!
●
5. Evaluation Methodology
1 – overhead of dynamic code : comparing similar demo coded in statically and dynamically.
Criteria : lowest framerate and framerate consistency.
2 – content delivery : time between availability of the changes on sever and the time it is present on
the client station. (criteria might change depending on the protocol used)
3 - content integration : test on several individuals what kind of update they noticed, the way they
noticed it.
4 - Evolution of performance (load time, framerate) after several update.