Revision as of 11:59, 28 July 2015

Translation requested, please.

MISSIONS - WORKFLOW

Le guide suivant concerne l'écriture de toutes les missions à venir pour le jeu Ryzom encadrées et validées par l'équipe Level Design.

TERMINOLOGIE

Note aux utilisateurs de ce manuel :

Les mots en GRAS de la liste ci-dessous sont volontairement écrits dans un langage qui doit rester commun pour tous, ils ne doivent pas être traduits. Ceci afin de permettre ensuite à l'équipe des programmeurs ARK de travailler plus facilement et rapidement.

• MISSION : 3 types possibles:
  • MISSION permanente (PM)
  • MISSION unique (UM)
  • MISSION unique récurrente (RM)
• PJ : Le personnage du joueur.
• NPC : Un personnage non jouable.

Chacun est libre d'inventer un nom, tant qu'il est conforme à la Lore. Mais l'usage du générateur de noms Ryzom est recommandé. (http://atys.wiki.ryzom.com/RyzomNameGenerator)

• MISSION_GIVER : Le NPC délivrant la MISSION au PJ.
• STEP: une étape dans la MISSION.
• GAMEPLAY: la mécanique et les actions dans le jeu.
• ROLEPLAY: L'intégration des actions du PJ dans l'histoire.
• LEVEL-DESIGNER: l'auteur(e) des MISSIONs et rites.
• LEVEL-DESIGN: L'ensemble des LEVEL-DESIGNERs.
• GAME-DESIGN: Le processus de création et mise au point des règles et éléments constitutifs de Ryzom.*
• DB: Base de données où peuvent être enregistrées des informations propres à la MISSION en vue de l'utilisation dans cette MISSION ou d'une réutilisation ultérieur.

QU'EST-CE QU'UNE MISSION SUR RYZOM ?

Une MISSION est une tâche effectuée par un PJ au profit d'une faction (peuple, puissance, tribu...). C'est un challenge individuel si le PJ est seul ou un challenge collectif si plusieurs PJ accomplissent simultanément la même MISSION prise auprès du MISSION_GIVER. Même si elle est accomplie en équipe, une MISSION repose toujours sur un mécanisme personnel et individuel. Ainsi par exemple, la récompense sera toujours donnée individuellement au PJ accomplissant l'objectif. Une MISSION repose sur un ou plusieurs objectifs GAMEPLAY simples, clairement définis par le personnage MISSION_GIVER et autant que possible "ORIGINAUX", par une histoire ou un récit ROLEPLAY clair et intéressant et par une récompense adaptée. Les MISSIONs peuvent être de plusieurs types, définis par leur récit.

MISSION PERMANENTE

• Les MISSIONs permanentes sont réalisables à tout moment, par tous les PJ qui le souhaitent, à moins qu'une condition personnelle ne les en empêche : renommée, rite de citoyenneté... Elles sont "re faisables" à volonté.
• CONTRAINTES :

Le récit d'une MISSION permanente doit se reposer sur une trame scénaristique et sur des enjeux permettant la reproductibilité presque infinie de la MISSION. Ainsi, le LEVEL-DESIGNER se doit d'avoir toujours à l'esprit, lors de l'écriture d'une MISSION permanente, la cohérence dans les objectifs et les dialogues, afin qu'il soit réaliste et crédible que des centaines de PJ l'accomplissent. Ainsi, le LEVEL-DESIGNER se doit d'avoir toujours à l'esprit, lors de l'écriture d'une MISSION permanente, la cohérence dans les objectifs et les dialogues, afin qu'il soit réaliste et crédible que des centaines de PJ l'accomplissent.

• CONTRE-EXEMPLES
  • Un forgeron demande à tous les PJ d'aller sauver sa fille retenue prisonnière par un groupe de bandits et de rapporter comme preuve la tête du chef de ces derniers. Cet exemple implique une prisonnière refusant de quitter son lieu de captivité et une pile de têtes s'élevant derrière ledit forgeron...
  • "Retrouver et escorter toujours le même NPC." Le pauvre doit avoir des problèmes de mémoire pour toujours se perdre.
  • Remplir sans cesse un tonneau." Sans une raison valable ou une autre MISSION vidant ledit tonneau en parallèle, c’est à éviter.

Ces idées de MISSIONs sont à proscrire pour raison impérieuse de cohérence.

• EXEMPLE :
  • "Le responsable Fyros de l'approvisionnement en eau a besoin que des PJ volontaires ramènent de l'eau pour les Cités Impériales. les PJ doivent prendre des amphores, aller en Aeden Aqueous et revenir avec de l'eau... et peuvent refaire la mission instantanément." (synopsis de la MISSION "La route de l'eau" FYR-PM-050-Routedeleau)

• Les MISSIONs Uniques ne sont réalisables que durant une période donnée (exemple : saison particulière ou moment de la journée, ou bien cumul des deux) ou en quantité limitée du fait de la cohérence vis-à-vis du récit.
• EXEMPLE :
  • S'il y a un nombre limité d'éléments accessibles, une fois tous récoltés plus rien ne sera disponible pour les autres joueurs, à l'exemple des matières suprêmes). Cette quantité ou cette temporalité doivent être globales, c'est à dire à l'échelle du serveur de jeu, et non pas liée à un seul PJ. Le LEVEL-DESIGNER veillera toutefois à ne pas donner le sentiment erroné au joueur d'un PJ que lui seul est missionné pour cette MISSION (à moins bien sûr que la MISSION ne soit disponible qu'en quantité 1 ).

• EXEMPLES
  • MISSION Unique:
    • Un groupe de Kitins sévit dans la région de Thesos. Le responsable de l'armée de la cité propose une récompense pour tout PJ apportant la preuve de la destruction du groupe d'éclaireurs Kipestas (dards du grand Éclaireur Kipesta). Un seul PJ sera donc récompensé (celui ayant le "dard du grand Éclaireur Kipesta"). A lui de partager la récompense avec ceux qu'il souhaite remercier). Une fois le groupe de kitins tué, la MISSION disparaît.
    • "9 Najabs gooifiés menacent la sécurité des colporteurs et des foreurs et l'équilibre de toute la région. Les autorités de Jen-Laï offrent une récompense pour la mort de chacun d'entre eux, à la condition de rapporter leur crête comme preuve de leur destruction." La MISSION ne sera réalisable que 9 fois, une fois par "Crête de Najabs gooïfié" rapportés (un seul élément par Najab gooïfié tué). Une fois les 9 Najabs Gooïfiés tués ("Crêtes de Najabs Gooïfiés" rapportés ou non, la MISSION disparaît.
  • L'aspect temporaire d'une MISSION Unique peut sembler déséquilibrer le rapport "temps investi dans le développement" par rapport au "contenu ajouté en jeu", mais il convient de garder à l'esprit qu'une même structure peut être conservée, copiée et légèrement modifiée (principalement sur les dialogues, les items demandés, la récompense reçue ou les zones concernées) pour ajouter très rapidement un nouveau contenu Unique.

• • MISSION Unique Récurrente.
    • Certaines MISSIONs Uniques peuvent être amenées à réapparaître plusieurs fois, régulièrement ou non. On parlera alors de MISSIONs Uniques Récurrentes.
    • Les MISSIONs Uniques Récurrentes répondent aux mêmes règles que les MISSIONs Uniques (tout en prenant en compte dans les dialogues de la récurrence de l'évènement.)
    • Le parfumeur de Dyron a besoin au début de chaque printemps de sacs de fleurs : il ne lui faut QUE 12 sacs chaque printemps, qui doivent être apportés au parfumeur. La quantité de sacs est donc limitée : une fois les 12 sacs pris, la mission est fermée jusqu'au printemps suivant." (synopsis de la MISSION "Les fleurs de Savaniel" FYR-RM-100-Savaniel) Si plus de 12 PJ prennent cette mission, seuls les 12 premiers à la rendre au NPC la valideront. Pour les suivants, le NPC leur refusera la livraison. ("Trop tard, j'ai mes 12 sacs pour cette année.")

ÉCRIRE UNE MISSION

L'intérêt d'une MISSION repose sur une double exigence :

• Des objectifs "originaux" et intéressants d'une part,
• Un récit, une "bonne" histoire travaillée et cohérente d'autre part.

Les MISSIONs reposent généralement sur des objectifs simples et moins "longs" que ceux des rites et sur un récit plus clair et court.

Une MISSION ne doit pas être un long tunnel scénaristique et GAMEPLAY.

GAMEPLAY

Une MISSION doit présenter des objectifs GAMEPLAY clairs, intéressants et dans la mesure du possible, "originaux". L'ensemble d'une MISSION doit être réalisable dans un temps relativement court (attente de conditions de durée, de saison, de météo favorables non comprises) par rapport à un rite, et ne pas enchaîner de trop nombreux objectifs en cascade.

Pour cela, les boucles de GAME-DESIGN devront être combinées de façon à obtenir des challenges sortant de l'ordinaire du jeu.

Le LEVEL-DESIGNER veillera ainsi à assembler les actions de base du GAMEPLAY du jeu pour offrir une expérience différente des activités normales des PJ sur Ryzom.

Les objectifs pourront amener les joueurs à découvrir des facettes habituellement méconnues ou délaissées, qu'il s'agisse de lieux, de créatures ou NPC à contacter ou à tuer, des matières premières ou des éléments à trouver, ou encore des éléments d'artisanat à fabriquer.

Contrairement aux rites, des MISSIONs reprenant des éléments plus connus et maîtrisés du GAMEPLAY sont également possibles : les MISSIONs constituent le "quotidien" des homins, et réinventer de nouvelles mécaniques de GAMEPLAY n'est pas obligatoire (sans pour autant tomber dans une trop grande évidence et platitude).

Une MISSION (quel que soit son type) se doit d'être courte, elle ne doit pas être découpée en de multiples épreuves. Un jeu de dialogues d'introduction, permettant de prendre connaissance du récit et des objectifs de la MISSION, et permettant d'accepter ou de refuser celle-ci sera toujours présent.

La progression au long d'une MISSION repose sur un découpage en étape appelées STEPs.

Ces STEP's peuvent utiliser des données puisées dans les informations du PJ mais aussi utiliser une DB dédiée à la MISSION et dans le même temps, gérer la mise à jour de l'objectif en cours dans le "Journal des Missions" (raccourci J en jeu).

Grâce à la reconnaissance de cette STEP (propre à chaque PJ), chacun des NPC et objets réactifs concernés par la MISSION redirigera le PJ vers le dialogue correspondant à son état d'avancement dans la MISSION. (OBJET REACTIF : élément du décor sur lequel le PJ peut intervenir, tels une caisse, une plante, un panneau d'information, un téléporteur...)

EXEMPLE de STEPs :

• A la STEP 0 de la MISSION, Aquilegus renseigne sur l'objectif de la MISSION "Les fleurs de Savaniel" et propose d'accepter ou refuser. S'il accepte la MISSION, le PJ atteint la STEP 1. A un PJ ayant atteint la STEP 1, Aquilegus donne davantage de consignes et enjoint le PJ à prendre des sacs de fleurs puis fait passer le PJ a la STEP 2. L'objet "tas de sacs" ne proposera rien aux PJs n'ayant atteint que les STEP 0 et 1, mais permettra aux PJ ayant atteint la STEP 2 de prendre un sac de fleurs.

EXEMPLE d'utilisation d'une DB :

• Une MISSION A demande à un PJ de réaliser une activité pour un NPC. Chaque fois que le PJ valide cette mission, le script ARK note dans une DB centralisée que la MISSION A a été faite par ce PJ.
• Une MISSION B nécessite pour être réalisée que le PJ ait au moins une fois réalisé la MISSION A. Le script ARK va donc vérifier dans la DB, avant de proposer au PJ quoi que ce soit, que ce dernier a déjà bien réalisé la MISSION A.

LE RÉCIT

L'histoire racontée par une MISSION est présentée par le NPC central de la MISSION (nommé techniquement MISSION_GIVER), récit dans lequel celui-ci inclut les PJ à qui il demande de l'aide. Une MISSION constitue toujours une aide apportée par un PJ auprès d'un NPC, et à travers lui à une faction (peuple, puissance, tribu). Lors d'une MISSION, le PJ accomplit donc une tâche auprès d'une faction, rendant service à un NPC et à sa faction et sera récompensé par le NPC et reconnu par la faction pour son aide. Le récit d'une MISSION est donc opposé à celui d'un rite ou les PJ doivent prouver leurs capacité(s) et valeur(s) par une série d'épreuves.

Si elle est une MISSION Permanente ou si elle présente un nombre d'occurrences supérieur à 1, une MISSION doit logiquement s'adresser à des dizaines ou des centaines de PJ venant l'accomplir : ainsi une MISSION Permanente ou MISSION Unique Récurrente ne mettra-t-elle jamais en scène une action ou un dialogue supposément unique (ou trop visiblement unique) répété à tous les PJ se présentant. Cf le contre-exemple du forgeron et sa pile de têtes de chef des bandits.

On pourra donc résumer chaque MISSION sous la formule suivante :

• NPC a besoin d'aide pour une tâche (permanente, récurrente ou unique),
• PJ aide NPC.
• NPC et sa faction récompensent PJ.

LES ARCS NARRATIFS

Une MISSION peut être totalement indépendante d'un point de vue de son récit ou bien s'intégrer au sein d'un arc narratif. Un arc narratif constitue un ensemble de MISSIONs et/ou rites et/ou métiers répondant à une même trame, souvent autour d'un ou de plusieurs NPC.

EXEMPLE :

• L'arc narratif du "Parfumeur" regroupe(ra) plusieurs MISSIONs Uniques et/ou Uniques Récurrentes mettant en scène les besoins d'approvisionnement et de transport du parfumeur ou certains évènements ayant trait au parfumeur ou à son activité. Un ou plusieurs rites pourront également s'intégrer à ce même arc narratif, ainsi que d'éventuels métiers ou events.

Un arc narratif permet de lier entre eux des éléments de contenu de Ryzom, de mettre en lumière certains NPC en les amenant de façon récurrente et logique dans les aventures vécues par les joueurs. L'arc narratif offre également un premier niveau de méta-histoire permettant d'apporter plus d'intérêt, de suivi et de cohérence au contenu du jeu.

NPC ET OBJETS REACTIFS

Les personnages et objets mis en scène dans le cadre d'une MISSION (comme d'un rite) peuvent être créés spécifiquement pour cette MISSION, exister précédemment en jeu (pour un autre rite, un métier, une autre MISSION...). La réutilisation de personnages et objets déjà existants dans les créations ARK est conseillée dans la mesure du possible car elle donne davantage de cohérence à l'univers et donnera une plus grande "épaisseur" aux NPC en les rendant moins liés à une unique fonction.

LES HUBS

Afin de pouvoir être réutilisés dans plusieurs rites, métiers ou MISSIONs, les NPC et objets réactifs disposent chacun d'un script ARK nommé "Hub" redirigeant le PJ qui les sollicite en cliquant sur eux vers les différents scripts des missions, métiers et rites selon les informations des diverses DB liées.

Le "Hub" permet au NPC ou à l'objet de réagir de façon cohérente à la sollicitation d'un PJ revenant vers lui, son objectif achevé, et de répondre autrement à un PJ ayant une autre MISSION ou épreuve en cours ou n'ayant commencé auprès de lui aucune MISSION, épreuve ou rite. Il permet également de faire intervenir le NPC ou l'objet dans un nouveau Rite ou une nouvelle MISSION sans devoir vérifier et éditer un grand nombre de scripts. Un NPC ou un objet déjà présent en jeu (via le système ARK), et qui devra être réutilisé pour une nouvelle MISSION devra donc voir son "Hub" édité afin d'y ajouter les nouvelles redirections (et éventuels dialogues) nécessaires.

Exemple :

REDÉMARRAGE : FICHIERS "NPC SPAWNER" & "OBJETS SPAWNER"

Après chaque redémarrage du serveur, 2 scripts sont lancés, permettant d'ajouter les éléments nécessaires aux rites, métiers et MISSIONs. Ils contiennent respectivement tous les NPC et objets avec leur "nom technique", "nom visible", leur position, leurs caractéristiques et le lien vers le "Hub" s'ils sont sélectionnés par un PJ.

Au moyen de ces deux seuls scripts, l'équipe relançant le serveur de jeu pourra donc remettre en ligne tous les NPC et les objets (ou relancer l'un ou l'autre dans le cas d'un souci technique).

Ce contenu a vocation à être ajouté "en dur" aux éléments gérés par le serveur de jeu, et non par ARK. Le contenu de ces deux scripts est donc transitoire.

ABANDON D'UNE MISSION EN COURS

Un joueur peut abandonner une MISSION depuis le "Journal des Missions" du PJ.

Contrairement à un rite, l'annulation d'une MISSION obligera le PJ' à tout recommencer depuis la STEP 1 s'il décide de la reprendre.

Les anciennes informations contenues dans la DB seront remises à zéro. Les scripts de MISSION' doivent donc vider les éléments ponctuels stockés en DB en tout premier lieu.

LES DIALOGUES

Le LEVEL-DESIGNER veillera à certains points essentiels lors de l'écriture des dialogues des NPC, ayant trait à la cohérence.

Les dialogues tenus par les NPC en jeu doivent refléter le caractère personnel, émotionnel et culturel du personnage, être vivants (utiliser un langage parlé) et le ton doit, autant que possible, différer d'un personnage à l'autre tout en gardant une unité dans les formes culturelles des peuples.

Des mots ou expressions en langues "atysiennes" peuvent être utilisées, à la condition que leur non-traduction n'altère pas la compréhension du dialogue. La grande majorité des joueurs ne parlant pas ces langues inventées par la communauté, le LEVEL-DESIGNER se limitera donc à quelques mots non indispensables dans la compréhension du dialogue.

L'emploi du tutoiement et du vouvoiement sera lié à la nation et la culture des peuples : vouvoiement chez les Matis et tutoiement pour les autres peuples.

Si les dialogues doivent être vivants et s'adresser de façon dynamique au PJ, ils doivent néanmoins prendre en compte le fait qu'ils puissent être prononcés à des centaines de personnages, sur un temps long. Sans toutefois tomber dans un excès d'intemporalité ou d'impersonnalité, le LEVEL-DESIGNER veillera à ne pas utiliser de tournures de phrases trop circonstancielles (l'exemple bien connu du/des gardes du jeu Skyrim se plaignant à toute heure, tout lieu et tout moment de l'histoire, d'avoir reçu une flèche dans le genou est un bon contre-exemple).

L'auteur(e) des dialogues veillera enfin à trouver un bon équilibre dans la longueur des échanges entre le NPC et le PJ, entre la concision nécessaire (afin de ne pas surcharger l'épreuve de texte, au risque qu'un très grand nombre de joueurs ne lise pas les dialogues) et le caractère vivant et cohérent du "parlé" des personnages. Une bulle ne doit que rarement dépasser la phrase et se contenter d'une trentaine de mots (au grand maximum).

De la même manière, le LEVEL-DESIGNER évitera les suites de plus de trois bulles sans que le joueur n'ait à intervenir par des réponses à des questions du NPC ou le besoin de passer à une autre étape dans l'épreuve.

L'usage de la DB peut permettre d'afficher des textes alternatifs (par exemple si au cours d'une MISSION, ARK trouve des informations pour le PJ alors NPC peut dire "Encore vous !".

Des variantes du dialogue peuvent être affichées en fonction des informations récupérées par ARK (saison, heure de la journée, ou choisies aléatoirement dans une liste de textes).

FENÊTRES "JOURNAL DES MISSIONS" & STEPS

Une MISSION apparaissant dans le "Journal des Missions" (qui pour le moment liste également les rites) est composée de :

• Nom technique. Ce nom est utilisé d'une façon interne par ARK et invisible par les utilisateurs. Il est codifié de la façon suivante : XXX-YY-000-REF.
  • XXX pour la nation, le peuple ou le groupe concerné par la MISSION.
    • FYR = Pour les FYRos ou l'Empire fyros.
    • MAT = Pour les MATis ou le Royaume matis.
    • TRY = Pour les TRYkers ou la Fédération tryker.
    • ZOR = Pour les ZORaïs ou la Théocratie zoraï.
    • MAR = Pour les MARaudeurs.
    • RAN = Pour les RANgers.
    • TTT = Pour les TryTonnisTes.
    • TRI = Pour les Tribus de surface ou des primes racines.
    • KAM = Pour les Kamis.
    • KAR = Pour la Karavan.
    • OTH = Pour tout le reste.

• • YY pour le type de mission
    • PM = MISSION Permanente
    • UM = MISSION unique
    • RM = MISSION unique récurrente.

• • 000 pour le niveau de la zone concernée par la mission
    • 050
    • 100
    • 150
    • 200
    • 250

• • REF une codification (incrémentale ou texte) permettant de différencier 2 missions dans la même région et pour les mêmes individus.
    • 017 ou EtableZora

• Titre de la MISSION
  • Ce titre sera traduit.
    • Exemple : "De la Mousse pour l'étable."

• Résumé de la MISSION
  • Ce texte sera traduit.
    • Exemple : "Sai-Ju Fuangi a besoin de mousse pour les mektoubs de l'étable de Zora."

• Descriptif du STEP en cours
  • Ce texte sera traduit.
    • Exemple : "Prélevez 20 'Mousse de Base/Slaveni' d'une qualité au moins égale à 38 sur une créature morte."

Une MISSION est décomposée en plusieurs étapes (STEP), permettant au système ARK d'identifier la progression du PJ dans la réalisation de l'épreuve. L'étape atteinte par le PJ est sauvegardée dans une base de données (DB) gérée par ARK dans le dossier de l'épreuve. Chacune des étapes indique au système ARK l'avancement dans la résolution de l'objectif final (par exemple : STEP 3 ), et au joueur ce que son PJ doit faire précisément (par exemple : rapportez 3 crocs de Ragus Q49 à Ceneus Zecops).

Le numéro de l'étape (STEP) est un élément technique et n'apparaît pas aux yeux des joueurs.

A chaque étape de la Mission (STEP), le contenu textuel décrivant ce qui doit être accompli par le PJ pour passer à l'étape suivante est précisé en une ou deux phrases claires.

Titre de la MISSION

Résumé de la MISSION

Descriptif du STEP en cours

Ce descriptif donne de façon très concise de ce que le PJ doit faire à cette étape de la MISSION.

Ce contenu doit bien évidemment être traduit par l'Équipe de Traduction, une fois la MISSION écrite par le LEVEL-DESIGNER.

Pour des raisons de praticité dans l'écriture des scripts par l'équipe ARK, il est demandé de réaliser un schéma par STEP, ainsi qu'un schéma (Hub) redirigeant le PJ vers le bon script ARK.

WORKFLOW

Voir le schéma

L'équipe LEVEL-DESIGN (membres Ryzom-Forge et membres sous NDA), en collaboration technique avec l'équipe ARK, définit l'histoire et les objectifs Gameplay d'une nouvelle MISSION, selon le plan général d'écriture et les envies de chacun.

Après concertation et validation (avec l'équipe Lore si nécessaire) le LEVEL-DESIGNER écrira la totalité de la MISSION, dans ses moindres détails, effectuant un découpage par STEP, réalisant un schéma pour chaque Hub concerné (ou définissant la mise à jour des Hubs existant). Il listera les éléments graphiques 2D et 3D nécessaires qui seront demandés à l'équipe Graphisme.

Le projet sera écrit en anglais ou dans la langue maternelle de l'auteur(e) avant d'être traduit par l'équipe Traduction. Les auteurs et l'équipe Traduction veilleront à utiliser et conserver la terminologie imposée.

Les mises à jour des scripts "NPC Spawner" et "Objects Spawner" seront à prévoir.

L'équipe Lore, en collaboration avec l'équipe LEVEL-DESIGN, rédigera également une description des nouveaux personnages créés sur le Wiki-Lore EncyclopAtys

Les ajouts et mises à jours des NPC, objets, rites, MISSIONs, métiers et éléments utilisés seront référencés par l'équipe LEVEL-DESIGN sur le Wiki Level-Design (ouvert aux membres de cette équipe).

Les ajouts 2D et 3D, après traduction, seront transmis à l'équipe développement qui les intègrera dans le code du jeu (.shape, icônes...).

L'équipe ARK utilisera les ressources 2D, 3D et les schémas (nouveaux et mis à jour) pour réaliser les scripts de la nouvelle MISSION, dans un dossier distinct.

Les MISSIONs seront classées selon la faction pour laquelle elles sont réalisées. (par exemple : ARK / MISSIONS / "Faction") Au fur et à mesure du développement des scripts ou au terme du travail, les équipes ARK, LEVEL-DESIGN, Développement et Support testeront la MISSION dans son intégralité, veillant à l'équilibre, à la pertinence, aux bugs et possibles "exploits".

Une fois les dialogues, les entrées système, les descriptifs des STEPs et les objectifs figés, la totalité des textes est confiée à l'Équipe de Traduction qui se chargera de fournir les contenus de la MISSION visibles par les joueurs.

La MISSION sera alors testée une dernière fois par l'Équipe de Support afin de détecter les derniers bugs et de veiller à la bonne traduction et aux bonnes correspondances des éléments de textes.

Les différents tests permettront d'établir un temps moyen pour accomplir la MISSION.

Les récompenses proposées seront validées par le responsable de l'Équipe de Développement (en concertation avec l'équipe LEVEL-DESIGN).

Enfin, la MISSION et les éléments validés seront ajoutés au jeu.

L'Équipe de Communication rédigera l'annonce publique de l'ajout de la MISSION à venir, ainsi que la date de mise en service. L'annonce sera traduite par l'Équipe de Traduction, puis publiée par l'Équipe de Communication sur le site www.ryzom.com.