有许多脚本编写程序，并且有很多情况可以编写自己的脚本。 但是，像所有工作工具一样，脚本软件也可以适应主题领域的要求。 因此，电影脚本程序不适合编写用于计算机游戏的脚本，反之亦然。 我的领域更加具体-我开发了NIMS程序（用于主故事情节的一组工具），以创建用于实况角色扮演游戏（以下称为RI）的脚本。
闪电战问题：
使用了吗？ 是的，该项目已经两年了。 在此期间，NIMS进行了20多次比赛。
支付了吗？ 免费-捐赠软件。
在本文中，我将讨论场景任务的类型，为Ingushetia共和国编写脚本的细节（NIMS可以做到）及其实现的功能。
图片显示了基于MG S＆M RI“ Arthur港”的地块的社交网络（可单击）。
免责声明1：董事会角色扮演游戏是一种独立的游戏类型，我将其称为NRI。
脚本任务分类
许多世纪以来，脚本作为一种现象完全属于场景。 在19世纪末，电影院出现了，在20世纪末，各种各样的游戏（计算机，棋盘，真人表演等）以及各种场景出现了。 从艺术的角度来看，它们是相似的，并且遵循脚本编写的统一规律。 但是从信息表示形式的角度来看，脚本的每个应用领域都有自己的任务。 让我们尝试找出答案。
脚本任务可以按是否与查看器/用户进行交互来划分。 电影，电视节目，书籍和剧院需要非交互式场景 。 因此，观看者不能影响故事的过程，最终只有一种情况。 相反，存在涉及观众影响的交互式场景 。 这些是各种游戏的场景。
交互式脚本可以分为封闭脚本和开放脚本。 封闭方案要求描述历史发展的所有可能选项。 例如，用于计算机游戏和角色扮演书籍游戏的脚本。
反过来， 开放式交互方案可以根据主机依赖程度来有条件地划分。 在诸如D＆D之类的棋盘角色扮演游戏中，玩家的所有动作都会传达给主人，并由他进行叙述。 这些游戏完全依赖于主人 ，如果没有主人 ，玩家将无法迈出任何一步。
在印古什共和国，大量玩家在比赛前建立的规则和协议框架内进行互动。 大师不需要遵循每个步骤，但是他们的能力通常是解决游戏中有争议的问题和修补规则错误的能力。 我再次强调，玩家无需向导即可自动进行互动。
免责声明2：此处描述的教条不是一种典型的选择；相反，NRI是自治的，RI是自动依赖的，并且仍然存在一系列中间选项。
真人角色扮演游戏场景
RI开发有一定要求。 在开发过程中，创建了一个世界模型，该模型被角色居住，并记录了冲突。 通常，对于游戏，您需要提出许多活跃角色和数十种具有解决方法的公开故事。
游戏开始前，会向玩家介绍其角色的位置：背景，亲戚，朋友，敌人，财产，冲突，派系在关键问题上的位置等。 总结一下，您可以在简介中放入“可以播放”的任何信息。
还有一个免责声明：这里描述的也不是教条。 有些游戏根本没有开放，或者有些玩家开放了，有些则没有。 玩家可以直接看到他对游戏的介绍，并且可以在游戏开始前几个月参与其开发，表明他想与谁一起玩以及与谁一起玩。
简介中有很大一部分用于解释史前史，旨在回答以下问题：“为什么……？”：“我为什么讨厌国王？”，“为什么我们的房屋处于战争状态？”，“为什么仪式顺利进行对我们来说很重要？”
每个玩家必须接收自己的信息并在游戏中进行操作。 撰写简介的祸害是不一致。 历史上的任何事件都会以不同的口音反复地重述，因为每个参与者都以自己的方式看待情况。 不仅应该以多个版本描述每个事实，而且在进行任何更改的情况下，所有这些更改都必须在每个选项中重复。 例如，如果在某个情节中涉及5个角色，那么在此情节中发生最小变化的情况下，您需要进行5次编辑，而不要进行一次编辑。 这种情况导致大量不一致。
NIMS项目旨在开发涉及多个故事且参与者众多的RI场景。 在它的帮助下，信息在玩家之间分配，并且在编写文本的过程中伴随着控制机制，以消除不一致并识别“被遗忘”的行。
入门写作过程
问题的条件：有一个故事，其中涉及许多角色。 有必要为每个角色提供他所知道的故事部分。
您可以直接解决此问题：Frodo，您的背景是这个，Gandalf，您的背景是这个。 我们面临的问题是信息不同步。 例如，我们在Frodo开头写道：“如果看到兽人，请大声吹口哨。” 但是我们会忘记将其写给《指环兄弟会》的所有其他成员，而他们将不知道佛罗多的哨子意味着什么。 如果我们只写“佛罗多口哨”，那只是兄弟会戒指的一半，这甚至是“更好”的。
可以通过引入另一个文本（原始故事的文本）来解决此问题，在此基础上，我们将为每个字符编写改编文本或改编文本。 原始文字将显示为“在踏上旅程之前，指环王团契同意在兽人眼中佛罗多会吹口哨。” 佛罗多将会：“我们同意，在兽人看来我会吹口哨。” 其他所有人：“听说弗罗多的哨声，我正设法将他从兽人中解救出来。”
但是存在以下问题。 我们非常了解谁进入了魔戒兄弟会。 但是在另一种情况下，我们可能不认识参加此次活动的所有人。 这种情况的一个例子：他们决定如何处理指环的建议。 我们可以肯定地知道，整个《指环王兄弟会》艾隆德都聚集在那儿，并且肯定还有其他人（即使这与原始出处相矛盾）。 如果在该理事会上做出决定，而该决定需要在介绍性决定中确定，那么我们会感到不确定-我们游戏的140个角色中有哪个在理事会上，并且知道什么？
为了解决这个问题，我们将故事分为事件，事件是时间，地点和人物的统一。 我们修复事件：“圆环理事会，时间：3018/10/25 12:00，参与者：...，事件描述：...”现在，我们确切地知道谁是事件的参与者。 每个参与者对事件都有自己的看法，我们将在事件的适应过程中对其进行描述。 所选角色的整个故事改编包括与此角色进行的事件的所有改编。
最后阶段：所有改编都已编写，我们将它们按字符分组到文本文件中。 在一张图片中，它看起来像这样：
结果，我们得到的结构化数据也适用于可视化：
- 我们可以为每个故事以及每个角色分别创建事件的时间顺序。
- 社会学意义上的社交网络。 我们有许多角色，我们可以将他们参加一次活动的事实解释为活动中每个参与者之间的社交联系。 至少，他们可以看到彼此，但在大多数情况下，角色会彼此互动。
《指环王》基本样本的事件按时间顺序排列的示例（可单击）：
Mk的游戏RI“ Mad Mad Max”中的社交网络示例。 Albion（可点击）：
角色关系
字符关系表已在RI和NRI中广泛使用。 关系表是一个正方形表，其中的每一行和每一列对应于该字符，并且在该表的单元格中记录了字符A与字符B的关系。有趣的一点是：字符不必彼此熟悉即可相互关联。 从底层开始的角色可能会对黑手党老板有某种算盘，但黑手党老板本人可能完全不知道这一点。
档案
档案是有关角色的事实的列表。 档案的结构由游戏大师决定，因为一个游戏的重要信息对另一个游戏并不重要。 例如，角色的年龄可能会影响某些太空游戏的飞行许可，但是在《指环王》中，年龄与年龄无关，也没有任何关系。
档案当然很好，但是它本身并没有用，但是可以在其上搜索字符。 例如，我们需要在一个浪漫的故事中增加一个年轻的未婚贵族。 设置一个过滤器：年龄“不超过30岁”，财产“贵族”，婚姻状况“单身”，按年龄递增排序。
人物组
提出过滤器的概念后，我们来到了字符组。 例如，我们在游戏中有一个Templar组，我们只想向该组中的人提供订单的历史记录。 前额决定：Petya，Vitya，Borya Templars，我们将它们包括在组中，该组的文本显示在简介中。 然后，维克多（Victor）进入刺客行列，戈沙（Gosha）取代他，我们手动编辑群组列表。 取而代之的是，我们可以通过档案收集：圣殿骑士派系。 只有通过此过滤器的那些字符才会收到圣殿骑士的文本，并且手动更新数据没有问题。
情节图
情节图是解决派系间冲突的工具。 该工具在RI和NRI中也非常知名。 我将本文用作规范。 简而言之-有一些力量群在某种程度上相互影响。 例如，善良想要消灭邪恶，反之亦然。 有些资源是被动的，但属于团体的兴趣范围。 例如，如果您将无所不能的环视为一种资源，则善良的人想要摧毁它，邪恶的人想要夺取它，中立者想要有效地使用它。 根据情节地图，我们可以计划游戏将解决的冲突列表，并为其创建故事情节。
关于实施
最初的系统要求是自治。 我希望角色扮演大师能够在通讯不佳的笔记本电脑上工作。 例如，在美食广场，甚至在训练场。 这就是为什么将NIMS作为应用程序而不是作为服务的原因（大多数具有类似功能的RI系统都是服务）。
第二个要求是缺少可执行文件和安装程序。 因为它们堵塞了系统，因为它们布置在文件清洗中，因此能够重新安装任何不必要的垃圾等。
为了启动它，您需要在用户计算机上的虚拟机，它是-它是浏览器。 实际上，这就是NIMS的实现方式-包含在浏览器中打开的独立网页的存档。
这是我的第一个完全用JavaScript编写的应用程序，因此我尝试尽量减少使用库和框架。
一个独立的网页实现具有以下令人不快的副作用：
- 无法访问文件系统，因此无法单击“保存”按钮，因此所有内容均谨慎保存到文件中。 而是从页面下载数据库的当前版本。 同样，打开系统时，不显示最后一个数据库，而是一个示例数据库。 必须在工作开始时手动加载最后一个工作库。 是的，这很不方便，但是由于本地存储和类似物故障而丢失数据的风险更加严重。
- 无法使用带有“非标准扩展名”的文件（hi Chrome）。 例如，您不能将docx放在页面文件夹中，并且，如果需要，可以通过GET请求加载它。 同样，带有ftl文件的l20n库不起作用。 从服务器-请。 我通过在base64中编码docx并保存到js文件中解决了第一个问题。 我通过制造自行车解决了第二个问题。
- 即使您确实要调用可执行程序，也不可能。 在这里，有必要注意介绍性子系统的子系统-在这里，我们已经编写了所有内容，我们需要将其保存到文件中，然后通过邮件或打印发送给播放器。 主要要求是“使docx保持简介”（这不是我想到的）。 我用docxtemplater实现了这一点。 它允许您按模板生成docx文件。 为此，我需要根据要求将docx模板加载到上一段的页面中。
顺便说一句，缺少可执行文件和可能的脱机导致了我无法使用外部DBMS的事实。 内存浏览器中的某些功能。 我选择了自行车道，并在启动时通过JSON Schema的验证将数据存储为JSON对象。 JSON对象存储在称为“ base”的纯文本文件中。
在所有其他方面，这是常规的SPA。
发布后不久，他们就向我通报了一个问题：严格由一位大师负责的游戏，少数游戏。 因此，几位大师共同参与游戏的可能性取决于项目的生死攸关。
问题：我们有一个工作核心，但对于自主工作却很精明。 如何确保几位大师的协作？
解决方案：我们将内核重新制作为可与数据库一起使用以进行异步操作，然后对其进行修改，使其可以在node.js上运行。 脱机模式与以前一样工作。 服务器模式分发一个网页，所有对内核的调用都转换为远程过程调用，以在服务器上执行请求。 曾经是内核接口的东西变成了API。 在此过程中，服务器模式通过用户管理和访问控制功能扩展了API。
结果，离线解决方案和服务器解决方案都使用相同的内核。 从示意图上看，它看起来像这样：
用料
我们为用户准备了许多材料：
- 在线演示 -对不熟悉NIMS的用户的基本概念的简要说明。
- 截屏视频是我谈论如何使用NIMS的视频。
- 文档 -所用概念和所实现功能的完整描述。
- 在线演示 -脱机版本发布在Internet上。 它附带一个示例数据库，该数据库说明了（如果不是全部）大多数实现的功能。
离线版本可以在这里下载。 已检查Chrome和Firefox中的工作。 无论使用什么操作系统，它都可以工作，但是尚未经过专门测试。
至于源代码-该项目分为客户端，服务器和文本资源：
- 客户端包括所有脚本功能。
- 文本资源是示例库，演示文稿，文档，上传模板。
- 服务器是客户端核心的扩展，用于处理权限并为多个用户组织远程访问。 该项目的这一部分目前尚未公开。
结论
NIMS项目提供了一个从不同角度审视剧本的机会。 RI的场景是不完整的故事，无需为观看者/阅读者从故事中形成一致的叙述。 在RI中，每个玩家都会收到自己的信息并在此基础上以及在现实中行动。 在这种情况下，编剧的任务不仅是讲故事，而且还要在角色之间分配故事。