Es gibt viele Skriptprogramme und viele Gelegenheiten, um ein eigenes Skript zu schreiben. Wie alle Arbeitstools passt sich die Szenariosoftware jedoch den Anforderungen des Themenbereichs an. Aus diesem Grund eignet sich ein Drehbuchprogramm nicht zum Schreiben eines Skripts für ein Computerspiel und umgekehrt. Mein Bereich ist noch spezifischer - ich habe das NIMS-Programm (eine Reihe von Tools für die Master-Storyline) entwickelt, um Skripte für Rollenspiele mit Live-Action (im Folgenden: RI) zu erstellen.
Blitz Fragen:
Wird es benutzt? Ja, das Projekt ist bereits zwei Jahre alt. In dieser Zeit hat NIMS mehr als 20 Spiele gemacht.
Wird es bezahlt? Kostenlos - Spendenware.
In diesem Beitrag werde ich über die Arten von Szenarioaufgaben, die Besonderheiten des Schreibens von Skripten für die Republik Inguschetien, die NIMS ausführen kann, und die Merkmale seiner Implementierung sprechen.
Das Bild zeigt ein soziales Netzwerk basierend auf den Plots von RI „Port Arthur“, MG S & M (anklickbar).
Haftungsausschluss 1: Brettspiele sind eine eigenständige Art von Spielen, die ich als NRI bezeichnen werde.
Klassifizierung von Skriptaufgaben
Viele Jahrhunderte lang gehörte das Drehbuch als Phänomen ausschließlich zur Szene. Ende des 19. Jahrhunderts erschien das Kino und Ende des 20. Jahrhunderts - verschiedene Spiele (Computer, Brett, Live-Action usw.) und überall gibt es Szenarien. Aus künstlerischer Sicht sind sie ähnlich und befolgen die einheitlichen Gesetze des Drehbuchschreibens. Unter dem Gesichtspunkt der Form der Darstellung von Informationen stellt jeder Anwendungsbereich von Skripten seine eigenen Aufgaben. Versuchen wir es herauszufinden.
Skriptaufgaben können durch das Vorhandensein / Fehlen von Interaktivität mit dem Betrachter / Benutzer unterteilt werden. Kino, Fernsehsendungen, Bücher und Theater erfordern ein nicht interaktives Szenario . Dementsprechend kann der Betrachter den Verlauf der Geschichte nicht beeinflussen und am Ende gibt es nur ein Szenario. Im Gegensatz dazu gibt es interaktive Szenarien, die den Einfluss des Betrachters betreffen. Dies sind Szenarien verschiedener Spiele.
Interaktive Skripte können in geschlossene und offene Skripte unterteilt werden. Geschlossene Szenarien erfordern eine Beschreibung aller möglichen Optionen für die Entwicklung der Geschichte. Zum Beispiel Skripte für Computerspiele und Rollenspiele.
Offene interaktive Szenarien können wiederum bedingt nach dem Grad der Masterabhängigkeit unterteilt werden. In Brettspielen wie D & D werden alle Aktionen der Spieler dem Meister mitgeteilt und er erzählt. Diese Spiele sind vollständig vom Meister abhängig und der Spieler kann ohne einen Meister keinen einzigen Schritt machen.
In der Republik Inguschetien interagiert eine große Anzahl von Spielern im Rahmen der vor dem Spiel festgelegten Regeln und Vereinbarungen. Meister müssen nicht jeden Schritt befolgen, aber ihre Kompetenz bleibt normalerweise die Lösung von strittigen Problemen und das Patchen von Regelfehlern während des Spiels. Ich betone noch einmal, dass die Spieler autonom miteinander interagieren, ohne dass ein Zauberer eingreift.
Haftungsausschluss 2: Das hier beschriebene Dogma ist keine typische Option, vielmehr sind NRIs autonom, RIs sind autodependent und es gibt immer noch eine ganze Reihe von Zwischenoptionen.
Szenarien zu Live-Action-Rollenspielen
Die RI-Entwicklung hat bestimmte Anforderungen. Während des Entwicklungsprozesses wird ein Modell der Welt geschaffen, das von Charakteren bewohnt wird, und Konflikte werden aufgezeichnet. Oft müssen Sie für ein Spiel Dutzende von aktiven Charakteren und Dutzende von offenen Geschichten mit Auflösungsmethoden entwickeln.
Vor dem Spiel erhält der Spieler eine einführende Beschreibung der Position seines Charakters: Hintergrund, Verwandte, Freunde, Feinde, Eigentum, Konflikte, Fraktionspositionen zu Schlüsselthemen usw. Zusammenfassend können Sie in der Einleitung alle Informationen einfügen, die "spielen können".
Und noch ein Haftungsausschluss: Der hier beschriebene ist auch kein Dogma. Es gibt Spiele ohne Öffnung, oder einige der Spieler haben eine Öffnung, andere jedoch nicht. Der Spieler kann seine Einführung direkt in das Spiel sehen und einige Monate vor dem Spiel an dessen Entwicklung teilnehmen, wobei er angibt, mit wem und mit wem er spielen möchte.
Ein wesentlicher Teil der Einführung bezieht sich auf die Vorgeschichte, um die Fragen „Warum ...?“ Zu beantworten: „Warum hasse ich den König?“, „Warum befinden sich unsere Häuser im Krieg?“, „Warum ist es für uns wichtig, dass das Ritual gut verläuft?“
Jeder Spieler muss seinen Teil der Informationen erhalten und im Spiel bearbeiten. Die Geißel beim Schreiben einer Einführung sind Inkonsistenzen. Jedes Ereignis aus der Geschichte wird wiederholt und mit unterschiedlichen Akzenten nacherzählt, da jeder Teilnehmer die Situation auf seine Weise sieht. Jede Tatsache sollte nicht nur in mehreren Versionen beschrieben werden, sondern auch im Falle von Änderungen müssen alle diese Änderungen in jeder der Optionen dupliziert werden. Wenn beispielsweise in einer bestimmten Episode 5 Charaktere beteiligt waren, müssen Sie im Falle der geringsten Änderung in dieser Episode 5 Änderungen vornehmen und nicht eine. Diese Situation führt zu einer Vielzahl von Inkonsistenzen.
Das NIMS-Projekt wurde entwickelt, um RI-Szenarien mit mehreren Geschichten mit einer großen Anzahl von Teilnehmern zu entwickeln. Mit seiner Hilfe werden Informationen zwischen den Spielern verteilt und das Schreiben von Texten wird von Kontrollmechanismen begleitet, um Inkonsistenzen zu beseitigen und „vergessene“ Zeilen zu identifizieren.
Einführender Schreibprozess
Problembedingung: Es gibt eine Geschichte, an der viele Charaktere beteiligt sind. Es ist notwendig, jedem Charakter den Teil der Geschichte zu geben, den er kennt.
Sie können dieses Problem direkt lösen: Frodo, Ihre Hintergrundgeschichte ist dies, Gandalf, Ihre Hintergrundgeschichte ist dies. Das Problem, mit dem wir konfrontiert sind, sind nicht synchronisierte Informationen. Zum Beispiel schreiben wir in der Eröffnung Frodo "Pfeife laut, wenn du Orks siehst." Aber wir werden vergessen, dies allen anderen Mitgliedern der Bruderschaft des Rings zu schreiben, und sie werden nicht wissen, was Frodos Pfeife bedeutet. Es ist sogar "besser", wenn wir über "die Frodo-Pfeife" nur die Hälfte des Rings der Bruderschaft schreiben.
Dieses Problem kann gelöst werden, indem ein anderer Text eingeführt wird - der Text der Originalgeschichte, auf dessen Grundlage wir für jeden Charakter angepasste Texte oder Anpassungstexte schreiben. Der Originaltext lautet: "Bevor die Ringgemeinschaft sich auf eine Reise begab, stimmte sie zu, dass Frodo beim Anblick der Orks pfeifen würde." Frodo wird haben: "Wir waren uns einig, dass ich beim Anblick der Orks pfeifen werde." Alle anderen: "Nachdem ich Frodos Pfeifen gehört habe, renne ich, um ihn vor den Orks zu retten."
Es gibt jedoch das folgende Problem. Wir wissen genau, wer in die Bruderschaft des Rings eintritt. In einer anderen Situation kennen wir möglicherweise nicht jeden, der bei der Veranstaltung anwesend war. Ein Beispiel für eine solche Situation: Ratschläge, bei denen entschieden wurde, was mit dem Ring geschehen soll. Wir wissen mit Sicherheit, dass sich die gesamte Bruderschaft des Rings, Elrond, dort versammelt hat und dass es durchaus jemand anderen geben könnte (auch wenn dies der ursprünglichen Quelle widerspricht). Wenn in diesem Rat eine Entscheidung getroffen wurde, die in den einleitenden festgelegt werden muss, dann bekommen wir Unsicherheit - welcher der 140 Charaktere unseres Spiels war im Rat und weiß etwas?
Um dieses Problem zu lösen, teilen wir die Geschichte in Ereignisse auf, bei denen das Ereignis die Einheit von Zeit, Ort und Charakteren ist. Wir legen das Ereignis fest: „Rat des Rings, Zeit: 3018/10/25 12:00, Teilnehmer: ..., Beschreibung des Ereignisses: ...“ Jetzt wissen wir genau, wer der Teilnehmer des Ereignisses war. Jeder Teilnehmer hat seine eigene Vision der Veranstaltung, die wir in der Anpassung der Veranstaltung beschreiben. Die Anpassung der gesamten Geschichte an den ausgewählten Charakter besteht aus allen Anpassungen von Ereignissen mit diesem Charakter.
Letzte Phase: Alle Anpassungen werden geschrieben, wir gruppieren sie nach Zeichen in Textdateien. Auf einem Bild sieht es so aus:
Als Ergebnis erhalten wir strukturierte Daten, die auch zur Visualisierung geeignet sind:
- Wir können eine Chronologie der Ereignisse erstellen, sowohl für jede Geschichte als auch individuell für jeden Charakter.
- Soziales Netzwerk im soziologischen Sinne. Wir haben viele Charaktere und wir können ihre Tatsache, an einer Veranstaltung teilzunehmen, als soziale Verbindung zwischen jedem Teilnehmer der Veranstaltung interpretieren. Zumindest konnten sie sich sehen, aber in den meisten Fällen interagieren die Charaktere aktiv miteinander.
Ein Beispiel für die Chronologie der Ereignisse der Basisstichprobe des Herrn der Ringe (anklickbar):
Ein Beispiel für ein soziales Netzwerk aus dem Spiel RI "Mad Mad Max", Mk. Albion (anklickbar):
Zeichenbeziehungen
Die Tabelle der Zeichenbeziehungen wird häufig in RI und NRI verwendet. Die Beziehungstabelle ist eine quadratische Tabelle, in der jede Zeile und jede Spalte dem Zeichen entspricht. In den Zellen der Tabelle wird die Beziehung von Zeichen A zu Zeichen B aufgezeichnet. Ein interessanter Punkt: Die Zeichen müssen nicht miteinander vertraut sein, um miteinander in Beziehung zu stehen. Ein Charakter von unten mag eine Art Abakus mit dem Mafia-Boss haben, aber der Mafia-Boss selbst ist sich dessen möglicherweise überhaupt nicht bewusst.
Dossier
Das Dossier ist eine Liste von Fakten über den Charakter. Die Struktur des Dossiers wird vom Meister des Spiels bestimmt, da wichtige Informationen für ein Spiel für ein anderes nicht wichtig sind. Zum Beispiel kann das Alter eines Charakters die Zulassung zu Flügen in einem Weltraumspiel beeinflussen, aber im Herrn der Ringe gibt es keine Beziehung zum Alter und nichts hängt davon ab.
Das Dossier ist natürlich gut, aber es ist an sich nicht nützlich, sondern in Kombination mit der Fähigkeit, nach Zeichen darauf zu suchen. Zum Beispiel müssen wir einer romantischen Geschichte einen jungen unverheirateten Adligen hinzufügen. Richten Sie einen Filter ein: Alter „bis 30 Jahre“, Nachlass „edel“, Familienstand „ledig“, sortiert nach aufsteigendem Alter.
Zeichengruppen
Als wir die Idee eines Filters entwickelten, kamen wir zu Gruppen von Charakteren. Zum Beispiel haben wir eine Templergruppe im Spiel, und wir möchten den Verlauf des Ordens nur Personen aus dieser Gruppe zur Verfügung stellen. Die Entscheidung in der Stirn: Petya, Vitya, Borya Templer, wir nehmen sie in die Gruppe auf, der Text für die Gruppe wird in der Einleitung angezeigt. Dann geht Victor in Attentäter, Gosha tritt an seine Stelle und wir bearbeiten die Listen der Gruppen manuell. Stattdessen können wir den Filter durch ein Dossier sammeln: die Templerfraktion. Nur die Zeichen, die diesen Filter bestehen, erhalten Text für die Templer und keine Probleme bei der manuellen Aktualisierung der Daten.
Grundstückskarte
Die Handlungskarte ist ein Werkzeug zur Erarbeitung von Konflikten zwischen Fraktionen. Das Tool ist sowohl in RI als auch in NRI sehr bekannt. Ich habe diesen Artikel als Spezifikation verwendet. Kurz gesagt - es gibt Kraftgruppen, die auf das Spiel einwirken und sich irgendwie aufeinander beziehen. Zum Beispiel wollen die Guten das Böse zerstören und umgekehrt. Es gibt Ressourcen, die passiv sind, aber in den Bereich des Interesses von Gruppen fallen. Wenn Sie zum Beispiel den Ring der Allmacht als Ressource betrachten, wollen die Guten ihn zerstören, die Bösen wollen ihn erobern, die Neutralen wollen ihn effektiv nutzen. Basierend auf der Handlungskarte können wir eine Liste von Konflikten planen, die vom Spiel gelöst werden, und eine Storyline für sie erstellen.
Über die Implementierung
Die anfängliche Systemanforderung ist Autonomie. Ich wollte, dass der Rollenspiel-Meister von einem Laptop aus arbeiten kann, auf dem die Kommunikation schlecht ist. Zum Beispiel an einem Food Court oder sogar auf einem Trainingsgelände. Aus diesem Grund wird NIMS als Anwendung und nicht als Dienst erstellt (die meisten Systeme für RI mit ähnlichen Funktionen sind Dienste).
Die zweite Voraussetzung ist das Fehlen ausführbarer Dateien und Installationsprogramme. Weil sie das System verstopfen, weil sie auf Dateiwaschanlagen ausgelegt sind und unnötigen Müll usw. neu installieren können.
Um es anzukurbeln, benötigen Sie eine virtuelle Maschine auf dem Computer des Benutzers, und es ist - es ist ein Browser. Auf diese Weise wird NIMS implementiert - ein Archiv mit einer eigenständigen Webseite, die in einem Browser geöffnet wird.
Dies war meine erste Anwendung, die vollständig in JavaScript geschrieben wurde, daher habe ich versucht, die Verwendung von Bibliotheken und Frameworks zu minimieren.
Eine eigenständige Webseitenimplementierung hat die folgenden unangenehmen Nebenwirkungen:
- Es gibt keinen Zugriff auf das Dateisystem, daher ist es unmöglich, auf die Schaltfläche "Speichern" zu klicken, und alles wird diskret in einer Datei gespeichert. Stattdessen wird die aktuelle Version der Datenbank von der Seite heruntergeladen. Ebenso wird beim Öffnen des Systems nicht die letzte Datenbank angezeigt, sondern eine Beispieldatenbank. Es ist notwendig, die letzte Arbeitsbasis zu Beginn der Arbeit manuell zu laden. Ja, dies ist unpraktisch, aber das Risiko eines Datenverlusts aufgrund eines Fehlers der lokalen Speicherung und der Analoga ist noch größer.
- Unfähigkeit, Dateien mit "nicht standardmäßigen Erweiterungen" (hi Chrome) zu verwenden. Beispielsweise können Sie docx nicht in den Seitenordner einfügen und bei Bedarf über eine GET-Anforderung laden. Ebenso funktioniert die l20n-Bibliothek mit ihren ftl-Dateien nicht. Vom Server - bitte. Ich habe das erste Problem gelöst, indem ich docx in base64 codiert und in einer js-Datei gespeichert habe. Ich habe das zweite Problem gelöst, indem ich ein Fahrrad gebaut habe.
- die Unmöglichkeit, ausführbare Programme aufzurufen, selbst wenn Sie es wirklich wollen. Hier ist es notwendig, das Subsystem für die Bildung von einleitenden zu notieren - hier haben wir alles geschrieben, wir müssen dies in einer Datei speichern und es per Mail oder Druck an den Player senden. Die Hauptanforderung war, "das Intro in docx beizubehalten" (dies ist nicht das, was ich mir ausgedacht habe). Ich habe dies mit einem docxtemplater implementiert. Sie können damit docx-Dateien nach Vorlage generieren. Zu diesem Zweck musste ich auf Anfrage die docx-Vorlage auf die Seite im vorherigen Absatz laden.
Übrigens führen der Mangel an ausführbaren Dateien und ein mögliches Offline dazu, dass ich kein externes DBMS verwenden kann. Nur etwas im In-Memory-Browser. Ich habe den Radweg gewählt und den Datenspeicher als JSON-Objekt mit Validierung des JSON-Schemas beim Booten erstellt. Das JSON-Objekt wird in einer Nur-Text-Datei namens "base" gespeichert.
Im Übrigen handelt es sich um ein reguläres SPA.
Kurz nach der Veröffentlichung informierten sie mich über ein Problem: Spiele, an denen ausschließlich ein Meister arbeitet, eine Minderheit. Daher ist die Möglichkeit einer gemeinsamen Arbeit mehrerer Meister am Spiel eine Frage von Leben und Tod des Projekts.
Problem: Wir haben einen funktionierenden Kern, der jedoch für autonomes Arbeiten geschärft ist. Wie kann die Zusammenarbeit mehrerer Meister sichergestellt werden?
Lösung: Wir erstellen den Kernel neu, damit er für den asynchronen Betrieb mit der Datenbank zusammenarbeitet, und ändern ihn so, dass er auf node.js ausgeführt werden kann. Der Offline-Modus funktioniert wie zuvor. Im Servermodus wird eine Webseite verteilt, und alle Aufrufe des Kernels werden in Remote Procedure Call konvertiert, um Anforderungen auf dem Server auszuführen. Was früher eine Kernel-Schnittstelle war, wird zu einer API. Auf dem Weg dorthin erweitert der Servermodus die API um Funktionen zur Benutzerverwaltung und Zugriffssteuerung.
Infolgedessen verwenden sowohl Offline- als auch Serverlösungen denselben Kern. Schematisch sieht es so aus:
Material
Wir haben viele Materialien für Benutzer vorbereitet:
- Online-Präsentation - eine kurze Beschreibung der Grundkonzepte für Benutzer, die mit NIMS nicht vertraut sind.
- Screencasts sind Videos, in denen ich über die Verwendung des NIMS spreche.
- Dokumentation - eine vollständige Beschreibung der verwendeten Konzepte und der implementierten Funktionalität.
- Online-Demo - Offline-Version im Internet veröffentlicht. Es wird mit einer Beispieldatenbank geliefert, die, wenn nicht alle, die meisten implementierten Funktionen veranschaulicht.
Die Offline-Version kann hier heruntergeladen werden . Überprüfte Arbeit in Chrome und Firefox. Es sollte unabhängig vom Betriebssystem funktionieren, dies wurde jedoch nicht speziell getestet.
Der Quellcode ist in Client-, Server- und Textressourcen unterteilt:
- Der Client enthält alle Skriptfunktionen.
- Textressourcen sind eine Beispielbasis, Präsentation, Dokumentation, Upload-Vorlagen.
- Server ist eine Erweiterung des Client-Kerns zum Arbeiten mit Rechten und zum Organisieren des Remotezugriffs für mehrere Benutzer. Dieser Teil des Projekts ist derzeit nicht öffentlich verfügbar.
Fazit
Das NIMS-Projekt bietet die Möglichkeit, das Drehbuchschreiben aus einer anderen Perspektive zu betrachten. Szenarien für RI sind unvollständige Geschichten, und es besteht keine Notwendigkeit, daraus eine konsistente Erzählung für den Betrachter / Leser zu bilden. In RI erhält jeder Spieler seine Informationen und handelt auf dieser Grundlage sowie in der Realität. In diesem Fall besteht die Aufgabe des Drehbuchautors nicht nur darin, die Geschichte zu erzählen, sondern sie auch auf die Charaktere zu verteilen.