fr:Mission Workflow

Sommaire

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.

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)

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

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.

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

ÉCRIRE UNE MISSION

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

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 :

EXEMPLE d'utilisation d'une DB :

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 :


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 :

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 :

NPC Ciro-Sini Hub.png

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 :

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 WorkflowMissions.png

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.


(Team Level-Design, juillet 2015)


La Forge La Forge
Récupérée de « https://fr.wiki.ryzom.com/w/index.php?title=Mission_Workflow&oldid=45133 »