Il existe de nombreux programmes de script et de nombreuses occasions d'écrire votre propre script. Mais, comme tous les outils de travail, le logiciel de scénario s'adapte aux exigences du domaine. Pour cette raison, un programme de script de film n'est pas adapté à l'écriture d'un script pour un jeu informatique et vice versa. Mon domaine est encore plus spécifique - j'ai développé le programme NIMS (un ensemble d'outils pour le scénario principal) pour créer des scripts pour des jeux de rôle d'action en direct (ci-après RI).
Questions éclair:
Est-il utilisé? Oui, le projet a déjà deux ans. Pendant ce temps, NIMS a fait plus de 20 matchs.
Est-ce payé? Gratuit - donationware.
Dans cet article, je parlerai des types de tâches de scénario, des spécificités de l'écriture de scripts pour la République d'Ingouchie, que NIMS peut faire et des caractéristiques de sa mise en œuvre.
La photo montre un réseau social basé sur les parcelles du RI «Port Arthur», MG S&M (cliquable).
Avis de non-responsabilité 1: les jeux de rôle de société sont un type de jeux indépendant et je les désignerai par NRI.
Classification des tâches de script
Pendant de nombreux siècles, le scénario en tant que phénomène appartenait exclusivement à la scène. À la fin du XIXe siècle, le cinéma est apparu, et à la fin du XXe - divers jeux (ordinateur, plateau, action en direct, etc.) et partout il y a des scénarios. D'un point de vue artistique, ils sont similaires et obéissent aux lois uniformes de l'écriture de scénario. Mais du point de vue de la forme de présentation de l'information, chaque domaine d'application des scripts pose ses propres tâches. Essayons de le comprendre.
Les tâches de script peuvent être divisées par la présence / absence d'interactivité avec le spectateur / utilisateur. Le cinéma, les émissions de télévision, les livres et le théâtre nécessitent un scénario non interactif . En conséquence, le spectateur ne peut pas influencer le cours de l'histoire et il n'y a finalement qu'un scénario. En revanche, il existe des scénarios interactifs impliquant l'influence du spectateur. Ce sont des scénarios de différents jeux.
Les scripts interactifs peuvent être divisés en fermés et ouverts. Les scénarios fermés nécessitent une description de toutes les options possibles pour le développement de l'histoire. Par exemple, des scripts pour des jeux informatiques et des livres-jeux de rôle.
Les scénarios interactifs ouverts , à leur tour, peuvent être conditionnellement divisés en fonction du degré de dépendance du maître. Dans les jeux de rôle, tels que D&D , toutes les actions des joueurs sont communiquées au maître et il raconte. Ces jeux dépendent complètement du maître et le joueur ne peut pas faire un seul pas sans maître.
En République d'Ingouchie, un grand nombre de joueurs interagissent dans le cadre des règles et accords établis avant le match. Les maîtres n'ont pas besoin de suivre chaque étape, mais leur compétence reste généralement la résolution de problèmes litigieux et la correction d'erreurs de règles pendant le jeu. J'insiste encore une fois sur le fait que les joueurs interagissent de manière autonome , sans l'intervention d'un sorcier.
Disclaimer 2: le dogme décrit ici n'est pas une option typique; plutôt, les NRI sont autonomes, les RI sont autodépendants et il existe encore une gamme complète d'options intermédiaires.
Scénarios de jeux de rôle en direct
Le développement du RI a certaines exigences. Dans le processus de développement, un modèle du monde est créé, qui est habité par des personnages, et des conflits sont enregistrés. Souvent, pour un jeu, vous devez trouver des dizaines de personnages actifs et des dizaines d'histoires ouvertes avec des méthodes de résolution.
Avant le jeu, le joueur reçoit une description introductive de la position de son personnage: antécédents, parents, amis, ennemis, biens, conflits, positions des factions sur les questions clés, etc. En résumé, dans l'introduction, vous pouvez mettre toutes les informations qui "peuvent jouer".
Et un autre avertissement: celui décrit ici n'est pas non plus un dogme. Il y a des jeux sans aucune ouverture, ou certains joueurs ont une ouverture, mais certains n'en ont pas. Le joueur peut voir son introduction directement au jeu, et peut participer à son développement quelques mois avant le jeu, en indiquant avec quoi il veut jouer et avec qui.
Une partie importante des comptes rendus d'introduction de la préhistoire, conçue pour répondre aux questions «Pourquoi ...?»: «Pourquoi hais-je le roi?», «Pourquoi nos maisons sont-elles en guerre?», «Pourquoi est-il important pour nous que le rituel se déroule bien?»
Chaque joueur doit recevoir sa portion d'information et la faire fonctionner sur le jeu. Le fléau de la rédaction d'une introduction est l'incohérence. Tout événement de l'histoire est raconté à plusieurs reprises et avec des accents différents, car chaque participant voit la situation à sa manière. Non seulement chaque fait doit être décrit dans plusieurs versions, mais également en cas de modifications, toutes ces modifications doivent être dupliquées dans chacune des options. Par exemple, si dans un certain épisode 5 personnages étaient impliqués, alors en cas de moindre changement dans cet épisode, vous devez effectuer 5 modifications, et pas une seule. Cette situation entraîne un grand nombre d'incohérences.
Le projet NIMS est conçu pour développer des scénarios RI impliquant plusieurs histoires avec un grand nombre de participants. Avec son aide, l'information est diffusée entre les acteurs, et le processus d'écriture des textes s'accompagne de mécanismes de contrôle pour éliminer les incohérences et identifier les lignes «oubliées».
Processus d'écriture d'introduction
Condition du problème: il y a une histoire dans laquelle de nombreux personnages sont impliqués. Il est nécessaire de fournir à chaque personnage la partie de l'histoire qu'il connaît.
Vous pouvez résoudre ce problème de front: Frodon, votre histoire est la suivante, Gandalf, votre histoire est la suivante. Le problème auquel nous sommes confrontés est l'information non synchronisée. Par exemple, nous écrivons dans l'ouverture Frodon "Sifflez fort si vous voyez des orcs". Mais nous oublierons d'écrire ceci à tous les autres membres de la Confrérie du Ring, et ils ne sauront pas ce que signifie le sifflet de Frodon. C’est encore «mieux» si nous n’écrivons sur «le sifflet Frodon» que la moitié de l’anneau de la Confrérie.
Ce problème peut être résolu en introduisant un autre texte - le texte de l'histoire originale, sur la base duquel nous écrirons des textes adaptés ou des textes d'adaptation pour chaque personnage. Le texte original se lira "Avant de se lancer dans un voyage, la Communauté de l'Anneau a convenu qu'à la vue des orcs Frodon sifflerait." Frodon aura: "Nous avons convenu qu'à la vue des orcs je sifflerai." Tout le monde: "Après avoir entendu le sifflet de Frodon, je cours pour le sauver des orcs."
Mais il y a le problème suivant. Nous savons parfaitement qui entre dans la Confrérie du Ring. Mais dans une autre situation, nous ne connaissons peut-être pas tous ceux qui étaient présents à l'événement. Un exemple d'une telle situation: des conseils sur lesquels ils ont décidé quoi faire de l'anneau. Nous savons avec certitude que toute la Confrérie de l'Anneau, Elrond, s'y est réunie, et il pourrait bien y avoir quelqu'un d'autre (même si cela contredit la source d'origine). Si une décision a été prise à ce conseil, qui doit être fixée dans les introductions, alors nous obtenons une incertitude - lequel des 140 personnages de notre jeu était au conseil et sait quelque chose?
Pour résoudre ce problème, nous divisons l'histoire en événements, où l'événement est l'unité de temps, de lieu et de personnages. Nous fixons l'événement: «Conseil du ring, heure: 3018/10/25 12:00, participants: ..., description de l'événement: ...» Maintenant, nous savons exactement qui était le participant de l'événement. Chaque participant a sa propre vision de l'événement, que nous décrivons dans l'adaptation de l'événement. L'adaptation de l'histoire entière pour le personnage sélectionné consiste en toutes les adaptations d'événements avec ce personnage.
Phase finale: toutes les adaptations sont écrites, nous les regroupons en fichiers texte par caractère. Sur une image, cela ressemble à ceci:
En conséquence, nous obtenons des données structurées qui sont également adaptées à la visualisation:
- Nous pouvons créer une chronologie des événements, à la fois pour chaque histoire et individuellement pour chaque personnage.
- Réseau social au sens sociologique. Nous avons de nombreux personnages, et nous pouvons interpréter leur fait d'être dans un événement comme un lien social entre chacun des participants à l'événement. Au minimum, ils pouvaient se voir, mais dans la plupart des cas, les personnages interagissaient activement entre eux.
Un exemple de la chronologie des événements de l'échantillon de base du Seigneur des Anneaux (cliquable):
Un exemple de réseau social du jeu RI "Mad Mad Max", Mk. Albion (cliquable):
Relations avec les personnages
Le tableau des relations entre les caractères est largement utilisé en RI et NRI. Le tableau des relations est un tableau carré dans lequel chaque ligne et chaque colonne correspond au caractère, et dans les cellules du tableau nous enregistrons la relation du caractère A au caractère B.Un point intéressant: les personnages n'ont pas besoin de se connaître pour se relier entre eux. Un personnage d'en bas peut avoir une sorte de boulier avec le patron de la mafia, mais le patron de la mafia lui-même peut ne pas le savoir.
Dossier
Le dossier est une liste de faits sur le personnage. La structure du dossier est déterminée par le maître du jeu, car les informations importantes pour un jeu ne sont pas importantes pour un autre. Par exemple, l'âge d'un personnage peut affecter l'admission aux vols sur certains jeux spatiaux, mais dans le Seigneur des Anneaux, il n'y a pas de relation avec l'âge et rien n'en dépend.
Le dossier est, bien sûr, bon, mais il n'est pas utile en soi, mais en combinaison avec la possibilité de rechercher des personnages dessus. Par exemple, nous devons ajouter un jeune noble célibataire à une histoire romantique. Mettre en place un filtre: âge «jusqu'à 30 ans», succession «noble», état civil «célibataire», tri par âge croissant.
Groupes de personnages
En développant l'idée d'un filtre, nous sommes arrivés à des groupes de personnages. Par exemple, nous avons un groupe de Templiers dans le jeu, et nous voulons fournir l'historique de l'ordre uniquement aux personnes de ce groupe. La décision au front: Petya, Vitya, Borya Templars, nous les incluons dans le groupe, le texte du groupe est affiché dans l'introduction. Puis Victor se lance dans des assassins, Gosha vient à sa place, et nous éditons manuellement les listes de groupes. Au lieu de cela, nous pouvons collecter le filtre via un dossier: la faction des Templiers. Seuls les personnages qui passent ce filtre recevront du texte pour les Templiers, et aucun problème avec la mise à jour manuelle des données.
Carte du terrain
La carte graphique est un outil pour résoudre les conflits entre factions. L'outil est également assez connu à la fois en RI et en NRI. J'ai utilisé cet article comme spécification. En bref - il y a des groupes de force agissant sur le jeu qui sont liés les uns aux autres. Par exemple, le bien veut détruire le mal, et vice versa. Certaines ressources sont passives, mais relèvent de l'intérêt des groupes. Par exemple, si vous considérez l'anneau de toute-puissance comme une ressource, les bons veulent la détruire, les méchants veulent la capturer, les neutres veulent l'utiliser efficacement. Sur la base de la carte de l'intrigue, nous pouvons planifier une liste de conflits qui seront résolus par le jeu et faire un scénario pour eux.
À propos de la mise en œuvre
L'exigence initiale du système est l'autonomie. Je voulais que le maître du jeu de rôle puisse travailler à partir d'un ordinateur portable où la communication est mauvaise. Par exemple, dans une aire de restauration ou même sur un terrain d'entraînement. C'est pourquoi NIMS est conçu comme une application et non comme un service (la plupart des systèmes pour RI avec des fonctionnalités similaires sont des services).
La deuxième exigence est le manque de fichiers exécutables et d'installateurs. Parce qu'ils obstruent le système, car ils sont disposés sur des lavages de fichiers avec la possibilité de réinstaller toutes les ordures inutiles, etc.
Pour le démarrer, vous avez besoin d'une machine virtuelle sur l'ordinateur de l'utilisateur, et c'est - c'est un navigateur. En fait, c'est ainsi que NIMS est implémenté - une archive avec une page Web autonome qui s'ouvre dans un navigateur.
C'était ma première application entièrement écrite en JavaScript, j'ai donc essayé de minimiser l'utilisation des bibliothèques et des frameworks.
Une implémentation de page Web autonome a les effets secondaires désagréables suivants:
- il n'y a pas d'accès au système de fichiers, il est donc impossible de faire le bouton "Enregistrer" et que tout soit discrètement sauvegardé dans un fichier. Au lieu de cela, la version actuelle de la base de données est téléchargée à partir de la page. De même, lorsque le système est ouvert, pas la dernière base de données n'est affichée, mais une base de données exemple. Il est nécessaire de charger manuellement la dernière base de travail au début du travail. Oui, cela n'est pas pratique, mais le risque de perdre des données en raison d'une défaillance du stockage local et des analogues est encore pire.
- incapacité à utiliser des fichiers avec des «extensions non standard» (salut Chrome). Par exemple, vous ne pouvez pas placer docx dans le dossier de pages et, si nécessaire, le charger via une requête GET. De même, la bibliothèque l20n avec ses fichiers ftl ne fonctionne pas. Depuis le serveur - s'il vous plaît. J'ai résolu le premier problème en encodant docx en base64 et en l'enregistrant dans un fichier js. J'ai résolu le deuxième problème en créant un vélo.
- l'impossibilité d'appeler des programmes exécutables, même quand vous le voulez vraiment. Ici, il est nécessaire de noter le sous-système pour la formation de ceux d'introduction - ici, nous avons tout écrit, nous devons l'enregistrer dans un fichier et l'envoyer au lecteur par courrier ou impression. La principale exigence était de "garder l'intro dans docx" (ce n'est pas ce que j'ai imaginé). J'ai implémenté cela avec un docxtemplater. Il vous permet de générer des fichiers docx par modèle. À cette fin, j'avais besoin, sur demande, de charger le modèle docx dans la page du paragraphe précédent.
Et au fait, le manque de fichiers exécutables et un possible hors ligne se traduisent par le fait que je ne peux pas utiliser de SGBD externe. Juste quelque chose dans le navigateur en mémoire. J'ai choisi la piste cyclable et fait le stockage des données en tant qu'objet JSON avec validation du schéma JSON au démarrage. L'objet JSON est stocké dans un fichier texte brut appelé "base".
À tous autres égards, il s'agit d'un SPA régulier.
Peu de temps après la sortie, ils m'ont informé d'un problème: des jeux sur lesquels travaille strictement un maître, une minorité. Par conséquent, la possibilité d'un travail conjoint sur le jeu par plusieurs maîtres est une question de vie ou de mort du projet.
Problème: nous avons un noyau fonctionnel, mais affûté pour un travail autonome. Comment assurer la collaboration de plusieurs maîtres?
Solution: nous refaisons le noyau pour travailler avec la base de données pour un fonctionnement asynchrone et le modifions pour qu'il puisse s'exécuter sur node.js. Le mode hors ligne fonctionne comme auparavant. Le mode serveur distribue une page Web et tous les appels au noyau sont convertis en appel de procédure distante pour exécuter des requêtes sur le serveur. Ce qui était une interface noyau devient une API. En cours de route, le mode serveur étend l'API avec des fonctionnalités de gestion des utilisateurs et de contrôle d'accès.
Par conséquent, les solutions hors ligne et serveur utilisent le même noyau. Schématiquement, cela ressemble à ceci:
Matériaux
Nous avons préparé de nombreux supports pour les utilisateurs:
- Présentation en ligne - une brève description des concepts de base pour les utilisateurs qui ne connaissent pas NIMS.
- Les captures d'écran sont des vidéos où je parle de la façon d'utiliser le NIMS.
- Documentation - une description complète des concepts utilisés et des fonctionnalités implémentées.
- Démo en ligne - version hors ligne publiée sur Internet. Il est livré avec un exemple de base de données qui illustre, sinon tous, la plupart des fonctionnalités implémentées.
La version hors ligne peut être téléchargée ici . Travail vérifié dans Chrome et Firefox. Cela devrait fonctionner quel que soit le système d'exploitation, mais cela n'a pas été spécifiquement testé.
Quant au code source - le projet est divisé en ressources client, serveur et texte:
- Le client inclut toutes les fonctionnalités de script.
- Les ressources textuelles sont un exemple de base, de présentation, de documentation, de modèles de téléchargement.
- Le serveur est une extension du noyau client pour travailler avec les droits et organiser l'accès à distance pour plusieurs utilisateurs. Cette partie du projet n'est pas actuellement accessible au public.
Conclusion
Le projet NIMS offre une opportunité d'examiner la scénarisation sous un angle différent. Les scénarios pour RI sont des histoires incomplètes et il n'est pas nécessaire d'en faire un récit cohérent pour le spectateur / lecteur. Dans RI, chaque joueur reçoit son information et agit sur cette base, ainsi qu'en réalité. Dans ce cas, la tâche du scénariste n'est pas seulement de raconter l'histoire, mais aussi de distribuer l'histoire entre les personnages.