Ryzom

==================
News from the devs
==================

As promised, here is a first step in lifting the lid; this article's
goal is to provide some insight on current short and mid-term plans for
Ryzom - ie. the months to come. The intent is not to provide accurate
dates, but to let you know what's in our minds right now and where Ryzom
is going.

The report is in two parts. First, I review some of the key
modifications we made to the production's processes since the release,
as the experience earned in the meantime has a great influence on the
current orientation. Second, I detail what's currently in the pipes, as
well as the associated patch processes - which will help you to
visualize how the described content will be introduced.

I] Since the release

You noticed it : some of our previous patches went fine, but some of
them weren't as polished as we would have liked them to be. There were
various reasons for that, but mainly it was due to two causes :

• A fast-paced patch cycle
• A limited testing capability

After the release, the features-coding rate was high, because we knew
that there was a lot of expectations here; the main rule back then was
to integrate changes into the live version as quickly as possible -
usually every week. We also had 24 hours a day shifts, to be extremely
reactive to issues. It was successful, since it really speeded things up
at first.

But it resulted in a very limited testing time with a modest testing
capability. This is no surprise that Nevrax is no Sony or Vivendi (and
it will never be!) : we had to earn the money before spending it. So
there was a small set of testers in-house (only three people at that
time!), which were permanently under a heavy load.

On the long term, the side-effect was that the quality of the code base
declined. Due to lack of time and testing, lots of small issues were
introduced and not properly cleaned. It's annoying in-game, when you
can't properly use a feature, but it's also increasingly delaying the
work of the devs, since they have to cope with bugs' side effects when
they are developping new code.

Solutions were gradually introduced to remedy to the problem :

• The number of in-house testers was increased. From three at the
  beginning, they are now eight. It's still greatly insufficient, but it
  improved the situation.
• The release-cycle rate has been decreased. There is now a different
  and longer testing process for major patches which introduce new content
  or major changes (new chapters, extra rites, etc.) compared to minor
  patches which fix punctual problems (lags, client crashes, etc.). When
  everything works fine, a minor patch only requires three days of
  in-house testing, whereas major patches are now tested for two to three
  weeks. We should start to see the repercussions of this with the next
  major patch, since the new process has only been introduced within the
  last few weeks. We are confident that it should greatly help to get
  smoother patches in the future - even if there is no such thing as a
  perfect patch.
• The Advanced Test Server (ATS) was opened in a rather unconventional
  manner, with alpha versions of patches being opened up for public
  testing. There has been a lot of useful feedback coming from the players
  hunting bugs in there, which certainly improved the situation. But that
  still wasn't enough. The time that the patches spent up on the ATS
  before going live didn't allow much time for serious digging, and issues
  that were signalled by the ATS players were often considered to be
  important but not sufficient to merit delaying the patch by a week (a
  week being the typical time for a fix and re-test cycle). To make
  testing on the ATS more productive, and as a consequence to the previous
  point, the major patchs candidates will be applied to the ATS for
  significantly longer periods ranging from 2 weeks up, depending on the
  patch content.

II] Now

In this section, I will present what is currently in our pipes. To help
you to understand how this will affect the short and mid-term future of
Ryzom, the first step will be to explain how our process for
development, testing and release functions.

A] Process for new content patches

Once the development work for a new patch is finished, the code gets a
new version number and is passed to the testing team. After a standard
test cycle in the in-house testing team (which takes a few days), if no
major issue has been found, the patch is applied to the ATS. The patch
then goes into a second, deeper in-house testing cycle while it is
tested simultaneously on the ATS. Issues are fixed by the development
team when they are reported, and when all tests (in-house and on the
ATS) are positive, the patch is announced and applied to the live
servers.

B] Encyclopedia and rites

As the encyclopedia was released, we intended to follow with the first
new rites patch within two weeks and to maintain a sustained rate after
that. We currently have some 450 encyclopedia texts that have been
written and are awaiting release into the game, with their associated
rites. However, the initial encyclopedia patch did not go as smoothly as
planned and we decided that the following rites were going to require
more in house testing than originally planned before being released. As
a result we currently have a backlog in test awaiting release. The
current situation is this :

• On the live servers (it is to say - in game right now) : 8
  rites (accomplishing a rite gives access to the associated encyclopedia
  text). There are also the 'ritual tasks' required for about 40 more of
  the next sets of rites due for release.
• On the ATS : 5 new escort rites have been in test for a little
  while, and 4 additionnal rites have just been patched in. They are
  included in the next major patch which, according to the new process, is
  now in test and should be released within in 2-3 weeks if no major
  issues are discovered in the meantime.
• Being tested in-house : 73 more rites. These will not all come out
  at once, but will be released in batches, first onto the ATS and then
  into the following major patches. We are planning to space major patches
  out by 2-3 weeks each, though this time will be increased if issues are
  discovered late in testing.

Also, a few user interface improvements are being prepared; for example,
you will be able to know which prerequisites you lack to start
accomplishing a mission by right-clicking on highlighted encyclopedia
items.

C] Clean-up

This is the current AAA priority. Two weeks ago, tasks were reassigned
so that 80% of the code team could concentrate on cleaning code and
fixing problems from the bug & suggestion database. This includes lots
of small points that affect the gameplay or the useability of the game.
This is going to remain the main focus of the code team for some time as
the number of issues that have piled up since launch is reasonably
large.

Next week, I will post details on what is being addressed.

D] Outposts

You have already heard a lot about it, so I didn't wanted to just drop a
few lines on this subject that would just repeat what has already been
said in the past. So there will be an article published next week that
will detail the high level specifications (remember? I promised there
would be such a review for important features to be introduced in the
game - the outposts will be the first one!).

But that won't restrain me from giving you some timeline indications
(again, beware! That's far from being *real* dates, as development time
and debugging time can vary according to the issues being reported. See
A] for details) :

• in 2-3 weeks, the first outpost features will enter an
  internal test phase.
• if testing goes well, 2-3 weeks later, the first version will be
  introduced on the ATS.
• Then will begin the lenghty process of the finalization of the
  outposts, before they can go live. The features will go through internal
  testing and be added to the ATS progressively, while we work with the
  ATS players on balancing. At this point, the success of the ATS will
  play a major role in determining schedules.

E] Events

This is still part of our main focus, as they help moving the story of
Atys. Different teams of event managers are dedicated to the
organization of global and shard based events.

During the last month there has been an ongoing improvement of the
events. They already became richer, broader and last longer.
Nevertheless we aren't yet at the stage we want to reach, however a key
step is about to be finished : on the 7th of March the event managers
from the different support companies will visit Nevrax in Paris to get
the first set of tools developed especially for the events and their
improvement. After the necessary training period where they will
familiarise themselves to their new tools, which will help to increase
the number of events in-game as well as their quality.

Also future events will have a stronger focus on the background story
and life on Atys, including religious customs, politics death and
rebirth, along with the Kami and Karavan conflict.

F] User interface design improvements

There is a small team dedicated to improving the user interface right
now. They're pretty much at the auditing and stage right now, so I will
let you know when there will be more concrete things to talk about. In
the meantime, if you have remarks and improvement suggestions, they will
be happily welcomed.



That's for the start. If you have any comments or questions about all
that, do not hesitate to post in your respective per-community forums.
It will help to prepare the first set of answers, which will be posted
next week.

--
Xavier.