1. Introduction
The Saga of Ryzom is
a persistent massively-multiplayer online game (MMORPG) released in
September 2004 throughout Europe and North America, localised in 3
languages so far. It has been developed by Nevrax since 2000, and was
taken over by Gameforge
in late 2006.
The Nevrax team
built Ryzom from scratch, starting with the Nevrax
Library (NeL), made
available as free software under the General Public License (GPL). On
top of NeL, a server technology was created to handle an immersive
virtual world. This article focuses on the network techniques
developed to display a smooth scene of moving entities, the dynamic
properties of which are propagated to all connected end-user clients
having an avatar in the same virtual area.
I would like to
thank Daniel Miller, CTO of Nevrax and Gameforge France, for his
enlightening contributions and reviews of this article.
Purpose of the Works
Our client software
had to display an animated 3D scene figuring moving and animated
entities. Players would have direct control over their avatars, as
point & click control (the alternative usually found in 2D or ¾
perspective games, even sometimes in 3D games) was considered not
immersive enough. While the role-playing genre usually does not
require fast input from the players, like in first person shooters
(where the first player to shoot, will be the one who survives) or in
sport games (where synchronization is very important for collective
actions), movements had to be consistent & smooth.
We wanted
visible micro-teleportations, or position jolts, to be less frequent
than in other MMOGs, in which, at least at the time when the Ryzom
project started, entities often seemed to go back in time or jump
forward. Another important feature was to allow the characters to
move in a seamless environment, without loading time between
predetermined small geographical zones, during which the player would
be idle.
In the present
article, which explains the techniques we tried and which ones were
eventually chosen, a visual property refers to any dynamic
state or attribute of a player or non-player entity that must be
known by client software to render it, such as position &
heading, 3D model identifier, clothes set, current animation, etc. We
assume the client software has local access to some static data such
as 3D models, textures and animations. In most of the document we
will focus on the propagation of position, because the continuous
nature of position paths makes greatly noticeable when smooth
propagation is not achieved.
Challenges
In an online game,
especially a massively multiplayer one, the bandwidth constraints
prevents from trivially sending every position change to all players.
At the planned time of Ryzom launch, 56k modems still were widespread
among players, ADSL was still in its infancy. Our MMORPG had to work
nominally on a 56k or even 14k connection.
Besides, in an
online game, cheating utterly destroys the game experience of the
victims (the players put at a disadvantage) and must be prevented.
From the ever-popular adage “Don’t trust the client”, even more
present as Nevrax’s founders’ intention was to release the Ryzom
client under a free software license, it was quickly clear that the
client would be a display and input device, while all game logic
would have to be on the server.
Handling dynamic game information on
the server side would prevent the appearance of player-made radars,
for instance. Then, after excluding a peer-to-peer network solution,
the bandwidth constraints did not only originate from the low
bandwidth available in consumers’ homes, but also in the server
farms that we would have to rent.
MMORPG playing
experience was known to come with lag,
an unpleasant noticeable delay between an action and its viewing,
often visible as a stopped animation or animation jerk. This lag
phenomenon had to be minimized by design. It usually originated
either from an inadequate information propagation system under tight
bandwidth constraints and latency-prone networks such as the
Internet, or from delay in CPU-processing by the server.
Our work then had to focus
on studying the known techniques of visual property propagation, and
possibly creating better ones. The CPU performance of the software
was also critical, to avoid time-consuming peaks.