NIMS - Specific Scenario Software (for live action role-playing games)

There are many scripting programs and many reasons to write your own script. But, like all working tools, scenario software adapts to the requirements of the domain. For this reason, the program for developing a movie script is not suitable for writing a computer game script and vice versa. My field is even more specific - I developed the NIMS program (a set of master plotter tools) for creating live action role-playing scenarios (hereinafter referred to as RI).

Blitz questions:

Is it used? Yes, the project is already two years old. During this time, more than 20 games have been made at NIMS.

Is it paid? Free - donationware.

In this post I will talk about the types of scenario tasks, the specifics of writing scripts for the Republic of Ingushetia, what NIMS can do and about the features of its implementation.

In the picture is a social network based on the plots of RI “Port Arthur”, MG S & M (clickable).

Disclaimer 1: Board role-playing games are an independent kind of games and I will mention them as NRI.

Scripting task classification

For many centuries, the script as a phenomenon belonged exclusively to the scene. At the end of the 19th century, cinema appeared, and at the end of the 20th, diverse games (computer, desktop, live action, etc.). And there are scenarios everywhere. From an artistic point of view, they are similar and subject to the same laws of screenwriting. But from the point of view of the presentation of information, each application of scenarios sets its own tasks. Let's try to figure it out.

Scripting tasks can be divided by the presence / absence of interactive with the viewer / user. Cinema, TV shows, books, theater require non-interactive scenario . Accordingly, the viewer can in no way influence the course of the narrative and as a result there is only a scenario. In contrast, there are interactive scenarios that involve the influence of the viewer. These are scenarios of various games.

Interactive scripts can be divided into closed and open. Closed scripts require a description of all possible options for the development of history. For example, scripts for computer games and role-playing game books.

Open interactive scripts , in turn, can be divided according to the degree of mastery. In board role-playing games, such as D & D , all actions of players are communicated to the master and he leads the story. These games are completely masterful , and the player cannot take a single step without a master.

A large number of players interact in the Republic of Ingushetia within the framework of rules and agreements established before the game. Masters do not need to follow every step, but their competence usually remains to resolve controversial issues and patching up the rules errors during the game. Once again, the players interact with each other autonomously , without the intervention of the master.

Disclaimer 2: the dogma described here is not a typical variant, the NDT are autonomous, the RIs are auto-dependent and the full range of intermediate variants is still there.

Scenarios for live-action role-playing games

Development of RI has certain requirements. During the development process, a model of the world is created, which is populated by characters, and conflicts are prescribed. Often for the game you need to come up with dozens of active characters and dozens of open stories that have resolution methods.

Before the game, the player is given an introductory description of his character's position: background, relatives, friends, enemies, property, conflicts, positions of factions on key issues, etc. Summarizing, in the introductory you can put any information that "can play."

And one more disclaimer: what is described here is also not a dogma. There are games without any introductory at all, or some of the players have introductory ones, and some have none. A player can see his introductory game directly on the game, or he can take part in its development several months before the game, indicating what he wants to play with and with whom.

A significant part of the introductory is the prehistory, designed to answer the questions "Why ...?": "Why do I hate the king?", "Why are our homes hostile?", "Why is it important for us that the ritual goes well?"

Each player must receive his piece of information and operate it on the game. The scourge of writing introductory is inconsistencies. Any event from prehistory is retold many times and with different accents, because each participant sees the situation in his own way. Not only must each fact be painted in several versions, but in the event of any changes, all these changes must be duplicated in each of the options. For example, if 5 characters were involved in an episode, then in the case of the slightest change in this episode, you need to make 5 edits, not just one. This situation leads to a large number of inconsistencies.

The NIMS project is designed to develop RI scenarios, which implies the presence of many stories with a large number of participants. With its help, information is distributed between players, and the process of writing texts is accompanied by control mechanisms to eliminate inconsistencies and identify "forgotten" lines.

Process of writing introductory

The condition of the problem: there is a story in which many characters are involved. It is necessary to provide each character with that part of the story that is known to him.

You can solve this problem in the forehead: Frodo, your background is like this, Gandalf, your background is like that. The problem that we face is the out of sync information. For example, we will write in the introductory Frodo "Whistle loudly if you see orcs." And to all the other members of the Brotherhood of the ring, we will forget to write this, and they will not know what Frodo’s whistle means. It is even “better” if we write about “the whistle of Frodo” only to half of the Fellowship of the ring.

This problem can be solved by introducing another text - the text of the original story, on the basis of which we will write adapted texts or adaptation texts for each character. The text of the original will state “Before the journey, the Fellowship of the Ring agreed that Frodo would whistle at the sight of the orcs.” Frodo will have: "We agreed that at the sight of the orcs I would whistle." All the rest: "Hearing Frodo's whistle, I run to save him from the orcs."

But there is the following problem. We know very well who enters the Fellowship of the Ring. But in another situation, we may not know everyone who was present in the event. An example of such a situation: the council, which decided what to do with the ring. We know for sure that the whole Fellowship of the Ring was there, Elrond, and there could well be someone else (even if this contradicts the original source). If a decision was made on this board that needs to be fixed in the introductory, then we get uncertainty - who of the 140 characters in our game was on the board and knows something?

To solve this problem, we divide the story into events, where the event is the unity of time, place and characters. We fix the event: “Council of the ring, time: 3018/10/25 12:00, participants: ..., event description: ...” Now we know for sure who was the participant of the event. Each participant has his own vision of the event, which we describe in adapting the event. The adaptation of the whole story for the selected character consists of all the adaptations of the events with this character.

The final stage: all adaptations are written, we group them into text files by character. In one picture it looks like this:

As a result, we get structured data, which in addition are suitable for visualization:

1. We can form a chronology of events, both for each story, and individually for each character.
2. Social network in a sociological sense. We have many characters, and we can interpret their fact of being in one event as a social connection between each of the participants in the event. At a minimum, they could see each other, but in most cases the characters actively interact with each other.

An example of the chronology of the base-example for the Lord of the Rings (clickable):

An example of a social network with the game RI "Mad Mad Max", Mk. Albion (clickable):

Character Relations

The character relationship table is widely used in the RI and NRI. The relationship table is a square table in which each row and each column corresponds to a character, and in the cells of the table we write down the relationship of character A to character B. Interesting point: the characters do not have to be familiar with each other in order to relate to each other. The lower-level character may have some abacus with the mafia boss, but the mafia boss himself may be completely unaware of this.

Dossier

A dossier is a list of facts about a character. The structure of the dossier is determined by the master of the game, since important information for one game is not important for another. For example, the character's age can influence the admission to flying on any game about space, but in the Lord of the Rings there is no binding for age and nothing depends on it.

Dossier is, of course, good, but it is useful not in itself, but in combination with the ability to search for characters on it. For example, we need to add a young unmarried nobleman to a romantic story. Adjust the filter: age “up to 30”, nobility, marital status “idle”, sort by increasing age.

Character groups

Developing the idea of ​​the filter, we came to groups of characters. For example, we have a group on the game of the Templars, and we want to provide the history of the order only to people from this group. Solution to the forehead: Petya, Vitya, Boria Templar, we include them in the group, the text for the group is displayed in the introductory. Then Vitya goes to the assassins, Gosh takes his place, and we manually edit the lists of groups. Instead, we can collect a filter by dossier: a fraction of the Templars. Only those characters that pass this filter will be shown text for the Templars, and no problems with manual data updates.

Plot map

The plot map is a tool for working through inter-factional conflicts. The tool is also quite famous in RI and NRI. I used this article as a specification. In short - there are forces acting on the game that somehow relate to each other. For example, the good want to destroy the evil, and vice versa. There are resources that are passive, but fall within the scope of interest groups. For example, if you count the One Power Ring as a resource, then the good ones want to destroy it, the evil ones want to capture it, the neutral ones want to use it effectively. On the basis of the plot map, we can plan a list of conflicts that will be decided by the game and make a plot for them.

About implementation

The initial requirement for the system is autonomy. I wanted the role-playing master to have the opportunity to work from a laptop where there is a bad connection. For example, on the food court or even on the landfill. That is why NIMS is made as an application, and not as a service (most of the systems for RI with similar functionality are services).

The second requirement is the absence of executable files and installers. Because they litter the system, because they are laid out on file storage facilities with the ability to install any unnecessary garbage, etc.

In order to do this, you need a virtual machine on the user's computer, and it is - this is a browser. Actually, this is how NIMS is implemented - an archive with a stand-alone web page that opens in a browser.

This was my first application written entirely in JavaScript, so I tried to minimize the use of libraries and frameworks.

The implementation as a stand-alone web page has the following unpleasant side effects:

• there is no access to the file system, so it is impossible to make the “Save” button and so that everything is imperceptibly saved to the file. Instead, the current base version is downloaded from the page. Similarly, when opening a system, not the last base is shown, but an example base. You need to download the latest working database at the beginning of work manually. Yes, this is inconvenient, but the risk of losing data due to a failure of localstorage and analogs is even worse.
• the inability to use files with "non-standard extensions" (hello Chrome). For example, you cannot put docx in the page folder and, if necessary, download it via a GET request. Similarly, the l20n library does not work with its ftl files. From the server - please. I solved the first problem by coding docx to base64 and saving to js file. I solved the second problem by creating a bicycle.
• the inability to call executable programs, even when you really want. Here it is necessary to note the introductory formation subsystem - so we wrote everything, it is necessary to save it to a file and send it to the player by mail or print. The primary requirement was to “save the intro in docx” (I did not invent this). I implemented this using docxtemplater. It allows you to generate docx files from a template. That is why I needed to load the docx template into the page in the previous paragraph upon request.

And, by the way, the lack of executable files and the possible offline result in the fact that I can not use an external DBMS. Just something in the in-memory browser. I chose the bike path and made data storage as a JSON object with JSON Schema validation at boot. The JSON object is stored in a plain text file called the “base”.

Otherwise, this is a regular SPA.

Shortly after the release, I was informed about the problem: the games that only one master is working on, a minority. Therefore, the possibility of joint work on the game by several masters is a matter of life and death of the project.

Problem: we have a working core, but sharpened for autonomous work. How to ensure the joint work of several masters?

Solution: rewrite the kernel to work with the base for asynchronous operation and modify it so that it can run on node.js. Offline mode works as before. The server mode distributes the web page, and all calls to the kernel are converted to the Remote Procedure Call to execute requests on the server. What used to be the kernel interface becomes the API. Along the way, the server mode extends the API functions of user management and access control.

As a result, both offline and server solutions use the same core. Schematically it looks like this:

Materials

For users, we have prepared a lot of materials:

• Online presentation - a brief description of the basic concepts for users who are not familiar with NIMS.
• Screencasts - videos where I tell you how to use NIMS.
• Documentation - a complete description of the concepts used and the implemented functionality.
• Online demo - uploaded to the Internet offline version. Comes with a base example, which illustrates, if not all, then the majority of implemented features.

Offline version can be downloaded here . Checked work in Chrome and Firefox. It should work regardless of the OS, but it was not specifically tested.

As for the source code, the project is divided into client, server and text resources:

• The client includes all the script functionality.
• Text resources are an example base, presentation, documentation, and upload templates.
• The server is an extension of the client's kernel for working with rights and organizing remote access for several users. This part of the project is currently not made public.

Conclusion

The NIMS project provides an opportunity to look at screenwriting from a different angle. Scenarios for RI are unfinished stories and there is no need to form a consistent narrative for the viewer / reader. In RI, each player receives his piece of information and acts on this basis, as well as in reality. In this case, the task of the screenwriter is not only to tell the story, but also to distribute the story among the actors.