Editor's Note: This article had previously been posted on the official Ryzom website. It is however, reposted here for context as we continue this series and soon begin posting these diaries as a limited time exclusive on MMORPG.com.

---

Before I begin, I'm going to talk vocabulary for a moment. It's really, really hard to find good names to use in design work. When you find a word that you like for something and you start to use it, you invariably find that some large part of your audience use the same word for something else. As a result, I'm going to start by laying down a couple of terms that I'll use throughout this article and continue to use in the future.

The first term is COMPONENT. We're using this term to describe a large, grouped piece of a scenario a player might build, such as a group of NPCs with a boss/leader or a bandit camp. We previously used the term 'feature', which still figures on the screenshots that I've included here. Unfortunately, 'feature' just leads to far too much confusion :(

The second term is PIONEER. We use PIONEER to describe players who create or run scenarios. We all think that this is a great term for an extension like ours, that is stepping off the normal trodden path.

As development started on R², the team laid down a few basic design guidelines. Thinking through the way that the tools are likely to be used, we decided that we need a simple interface. It needs to be accessible to absolutely anybody who plays Ryzom. Beyond this, we need to provide depth for players who are more familiar with programming concepts and who want as much freedom as they can have. We need to provide support for sharing of scenarios and the possibility for the more technical players to create and distribute 'modules' usable by anyone. All of this led us to two concepts:

• In-Game Integration: First of all, we decided that all the tools needed to be integrated directly into the game. Players of Ryzom are familiar with the game environment and interfaces and it is clear that there's nothing like 'seeing' what you're manipulating from the player's perspective to get a true sense for the result that it's going to give. An 'admin' interface that is displayed on the screen allows you to change modes backwards and forwards between 'editing' and 'testing' in order to get a feel for what you're doing.

• Component System: The second concept, that our design guidelines led us to, is concerned with the way that scenarios are put together. R² scenarios are composed of building blocks called 'components'. The basic idea is that 'components' represent complete game components such as a living fauna system, a bandit camp or a Kitin nest. The component system allows us to place and manipulate relatively rich and complex game systems in our scenarios without requiring us to understand how they're put together.

Each component type is defined by a script file on the player's machine. This means that it will be possible for anyone with a good grasp of the concepts of scripting to develop their own components and to distribute these for use by others.

The R² tools provide a friendly and flexible system for managing groups of NPCs and wandering monsters. One can drag and drop characters of different types from the 'palette' window into the scene, placing them with simple mouse clicks. They can each have their own behaviour or simply be linked to another 'leader' character to form a group, in which case it's the leader who defines the behaviour for the whole group.

Ryzom being a massively multiplayer game, everything important happens on the game servers. This means that the scenarios that one creates are generated and stored on the server and that to edit, test or run a scenario, one needs to be connected. There are certain advantages to this, including the ease with which one can pass backwards and forwards between 'editing' and 'testing' modes. The interfaces over the screen change and the characters come to life or revert to their initial positions.

It is worth knowing that while a scenario is running 'live' it can not be edited. A certain number of operations such as changing NPC texts can be performed via the animation interfaces, but these are more limited than they are with the editing interfaces.

The design for R² is heavily focused on sharing and providing the means for the community of Pioneers to exchange their work. As a result, the component definition scripts used in scenarios are automatically copied up to the server and bound to the scenarios in which they have been used. When one edits an existing scenario, the appropriate component definition scripts are automatically installed. This makes it possible to share both independent component definitions and complete scenarios with their complete set of associated components. A future article will cover this in more detail.