基于自然语言处理和2D/3D预可视化的自动化故事板的制作方法
本公开总体涉及故事板(storyboard)创建，并且更具体地，涉及将自然语言处理(nlp)技术应用到剧本(script)以便提取可在元数据上创建故事板的元数据。此外，本公开涉及剧本的一个或更多个方面的二维(2d)/三维(3d)预可视化。
背景技术：
故事板可指代描述表征媒体形式(诸如电影、表演等)的技术参数和艺术参数的一系列图像或绘图。这些参数的示例可包括用于创建媒体所基于的故事的镜头类型、角色位置、动作、摄像机、照明等。传统的制作团队遵循借此开发或编写剧本的过程。然后可由故事板艺术家将剧本转换成视觉表示。故事板可用于使仍处于媒体项目(例如电视、真人电影、动画、戏剧、漫画、小说和其它形式的媒体或表演)的早期阶段的故事、每个角色的出现、退出、一个或更多个动作等的时机以及对应的环境可视化。故事板创建通常是由一组故事板艺术家执行的迭代并且冗长的过程，其通过手工或借助于数字草图软件来为视觉表示画草图。
关于剧本编写的过程，编写者经常关注维持贯穿单个故事或多个相互关联的故事(诸如电影系列或电影世界所基于的故事)的逻辑一致性。例如，电影和随后的续集可具有魔法主题或世界作为遵循一套规则或参数的背景。为了编写与此魔法主题或世界一致的剧本，编写者必须专注于遵守这些规则或参数。通常，编写者变得全神贯注于遵循此类规则或参数的需要，并且不再关注故事发展。
技术实现要素：
根据一个实施例，一种计算机实现的方法包括：基于剧本的一个或更多个元素呈现剧本的视觉表示；基于对剧本的一个或更多个元素的一个或更多个来更新呈现更新的剧本的视觉表示；生成知识库，该知识库包括从剧本或更新的剧本推断的信息以及关于剧本或更新的剧本的规则元数据和用户查询中的至少一个；用剧本或更新的剧本生成一个或更多个角色演变的视觉表示；分别基于剧本或更新的剧本实时生成和更新故事板；以及生成剧本或更新的剧本的二维(2d)或三维(3d)预览。
附图说明
参考以下附图根据一个或更多个各种实施例详细描述本公开。提供附图仅用于说明的目的，并且只描绘典型或示例实施例。
图1是根据各种实施例的可被执行以提供剧本工作流程并且生成一个或更多个可视化(诸如2d可视化、故事板和/或3d预可视化)的示例操作的流程图。
图2是系统架构的示意图，其中可实现图1的工作流程和视觉生成操作。
图3a至图3l示出由适于执行图1的工作流程和视觉生成操作的平台的用户界面提供的示例功能性。
图4是根据各种实施例的系统架构的示意图，其中工作流程和视觉生成操作系统与一个或更多个应用或外部部件交互工作。
图5a是根据各种实施例的到外部处理部件的解析请求消息的示例。
图5b是响应于图5a的解析请求消息的解析结果消息的示例。
图6a是根据各种实施例的到外部处理部件的解析交互组请求消息的示例。
图6b是响应于图6a的解析交互组请求消息的解析交互组结果消息的示例。
图7是前端到后端和后端到前端接口的示例实现方式。
图8是根据各种实施例的用于自然语言处理的示例架构/工作流程。
图9是根据各种实施例的规则和错误定义的示例。
图10是根据各种实施例的包括规则和错误定义的基于自然语言处理的剧本开发的示例。
图11示出根据各种实施例的在剧本开发期间与组交互相关联的可视化面板的示例功能性。
图12是可用于实现本公开中描述的实施例的各种特征的示例计算部件。
附图并非详尽无遗，并且不将本公开限制于所公开的精确形式。
具体实施方式
各种实施例涉及平台或工具集，用户可用该平台或工具集使用各种视觉表示来创建或编辑剧本、自动确定主题关系、实施主题规则/参数以及创建故事板。此外，该平台可提供故事的预可视化。用户可为创意过程中涉及的导演、编剧、故事板艺术家和/或其它用户。在一些实施例中，平台可包括独自或者彼此结合提供剧本创建或分析/处理功能的各种部件。另一个功能是时间线功能，其呈现角色如何在故事或场景内演变的图形表示作为剧本的功能。另一个功能是故事板功能，其允许用户生成并且/或者更新剧本。该平台的又一个功能包括上述预可视化，其允许用户以实时或接近实时的方式查看剧本的场景，例如，当使用平台开发剧本时剧本的运行预览。
图1是根据各种实施例的可被执行以提供剧本工作流程并且生成一个或更多个可视化(诸如2d可视化、故事板和/或3d预可视化)的示例操作的流程图。可结合图2描述图1，图2是图1的工作流程和可视元素生成的示意图。在操作100处，接收剧本的一个或更多个元素，并且呈现剧本的视觉表示。用户可通过在前端应用/ui202(图2)中键入剧本或通过将剧本上传到前端应用/ui202中来通过或使用前端应用/ui202输入剧本。剧本可为文本格式，并且可显示在编辑面板204上。各种实施例可在编辑面板204中以不同方式(例如，具有协助剧本编写的附加特征的传统线性剧本布局)呈现或显示剧本。
前端分析引擎206和/或后端分析引擎212可用于解析剧本。前端分析引擎206和后端分析引擎212可驻留在相同的设备或网络上，或者它们可彼此远程定位。例如，前端分析引擎206可驻留在其上实现前端应用/ui202的用户设备上，而后端分析可在远程定位的后端服务器210上实现，并且经由一个或更多个网络连接到前端应用/ui202。网络可为任何通信网络，诸如蜂窝或数据网、卫星网、内联网、外联网、虚拟专用网(vpn)、局域网(lan)、无线lan(wlan)、广域网(wan)、个域网(pan)、互联网的一部分、公共交换电话网(pstn)的一部分或它们的任何组合。
根据剧本的复杂性、待执行的分析的类型以及/或者实现前端应用/ui202的设备或处理器的处理能力，可选择特定的分析引擎以对剧本操作。
例如，前端分析引擎306可用于从剧本提取元数据。也就是说，前端分析引擎206可被编程有自然语言处理功能性，使得它可分析剧本的文本并且确定有意义的语言(诸如指示角色、动作、角色之间的交互、对话等的语言)的存在。例如，前端分析引擎206可提取指示角色的元数据，例如，基于确定或已知为名称的文本。前端分析引擎206可提取指示动作的元数据，例如，基于指示动作的文本诸如动词。前端分析引擎206可提取指示地点的元数据，例如，基于在剧本中找到的地点的已知名称(地理地点和/或固定地点)或其它文本地点信息。
然而，后端分析引擎212也可用于解析剧本。因此，后端分析引擎212可用作对由前端分析引擎206执行的解析的二次检查。例如，如果剧本包含大量的复杂元数据，并且后端分析引擎212可较快地解析剧本，则可利用后端分析引擎212来解析。如果剧本以仅由后端分析引擎212识别的语言编写，则可再次利用后端分析引擎212而不是前端分析引擎212。在一些实施例中，前端分析引擎206可用于解析剧本，而后端分析引擎212可用于通过检查相对于后端分析引擎212的编译器部件214的逻辑一致性来执行更透彻的“故事分析”。在一些实施例中，解析可被转移到外部部件或系统，诸如自然语言处理(nlp)核心224(在下面更详细地描述)，例如，在处理要求和/或速度需要专用的nlp系统时。
为了训练前端分析引擎206和/或后端分析引擎212，可使用已知词或最常用词来开发逻辑形式语言以表示或指示角色、地点、动作等。使用自然语言处理功能性，前端分析引擎206和/或后端分析引擎212可发现并且/或者提供可由可视化引擎208使用以生成剧本的可视化的信息(在下面更详细地描述)。
重新参考图1，在操作102处，接收对剧本的一个或更多个元素的一个或更多个更新，并且呈现更新的剧本的视觉表示。因此，前端分析引擎206、后端分析引擎212和/或nlp核心224可执行上述处理以解析并且分析更新的剧本或剧本的更新元素。
另外，使用自然语言处理功能性，前端分析引擎206、后端分析引擎212和/或nlp核心224可在与根据各种实施例开发的逻辑形式语言相当的提取的元数据之间构建关系。例如，后端分析引擎212可解析剧本并且确定当前场景中存在两个角色a和b。基于指示角色a和b参与的一些动作的附加提取元数据，可对角色的情绪状态、位置、关系等进行确定/预测。如上所述，各种实施例可编译一个或更多个剧本并且检查逻辑不一致。可在用于构建情境“世界”的此提取的元数据上确定关于是否存在逻辑不一致的确定。根据各种实施例的解析可允许从剧本实现可视化并且允许检查编译并且/或者提供与vr相关的制作建议。
应当注意，前端分析引擎206/后端分析引擎212和nlp核心224两者都可访问关于剧本的一个或更多个方面的历史信息或与元数据相关联的已知信息，以便进一步增强它们构建情境世界的能力。例如，一个或更多个持久数据存储(其示例可体现为持久数据资料库220)包含关于先前制作的媒体内容中的角色的动作和口述历史的信息，例如，在当前制作的电影中引入的角色是情境一致的。如将在下面进一步论述的，持久数据资料库220可包含可根据其它实施例利用的进一步的信息。
应当注意，后端服务器210可包括剧本同步引擎216和剧本存储装置218，其可为一个或更多个数据库或数据储存库。剧本同步引擎216可操作以同步剧本的一个或更多个迭代(iteration)。例如，前端应用/ui202可为可同时在一个或更多个设备上实现的基于网络的或脱机的应用。这允许用户使用不同的设备开发剧本。剧本存储装置218可用于存储来自不同设备的剧本的不同迭代或版本。剧本同步引擎216可访问正在进行的剧本的不同迭代或版本、比较不同的迭代或版本并且相应地更新每个，使得用户能够在他/她的设备中的任一个上继续开发剧本。
重新参考图1，在操作104处，生成知识库，该知识库包括从剧本或更新的剧本推断的信息、关于剧本或更新的剧本的规则元数据和用户查询中的至少一个。在一些实施例中(在下面描述)，使用知识元素表示在剧本或更新的剧本中概述的信息。另外，角色系统(也在下面描述)可用于基于知识元素在主题上连接两个或更多个角色。在两个或更多个角色彼此交互时，可创建交互组(在下面描述)。可使用nlp核心224(图2)根据前述规则元数据生成知识库。
在操作106处，生成剧本或更新的剧本内的一个或更多个角色的演变的视觉表示。也就是说，各种实施例可呈现由用户输入并且由前端分析引擎206、后端分析引擎212和/或nlp核心224解析的剧本的可视化。图3e中示出此时间线的示例。与图3a中的剧本的文本表示相比，图3e使用反映贯穿剧本的角色演变的时间线格式。
在操作108处，实时生成反映剧本的故事板或反映更新的剧本的更新的故事板。在操作110处，生成代表剧本或更新的剧本的2d/3d预览以呈现给用户。在操作108和110中，创建某种形式的抽象或渲染的可视化以表示剧本的场景或方面。也就是说，剧本从文本转换成视觉元素。
可使用表示场景元素(例如，角色、道具、摄像机等)的抽象元素来生成2d可视化，诸如一个或更多个场景的2d自顶向下视图，尽管可使用前端应用/ui202中的其它可视化。用户可“运行”剧本并且在视觉上将所得到的场景作为抽象2d表示进行观察。可视化可实时呈现剧本的不同方面。例如，当用户经由编辑面板204开发或编辑剧本时，可视化引擎208可从前端分析引擎206/后端分析引擎212和/或nlp核心224接收从解析的元数据收集的信息。可视化引擎208可使用此信息来生成剧本的相关方面的角色时间线和/或2d表示。应当注意，为了简单起见，可视化引擎208可呈现剧本部件的抽象表示，例如，角色、摄像机、道具等。当用户继续开发并且/或者编辑剧本时，2d可视化可反映当前对剧本的一次或更多次开发和/或编辑。
在一些实施例中，可视化引擎208可非实时地呈现2d可视化，诸如，如果用户希望将剧本的可视化视为目前为止开发/编辑的。可视化引擎208可以其当前形式呈现剧本的2d制定。应当注意，剧本存储装置218还可用于存储剧本的不同迭代或版本，使得可视化引擎208可访问不同的迭代或版本以呈现给用户。以这种方式，用户可在开发或编辑期间以不同的形式或阶段看到剧本的可视化。
可视化引擎208利用视觉隐喻语言来生成可视化。如上所述，可从剧本提取场景元数据(例如，角色、道具和动作)，并且用于生成第一可视化。例如，可使用3d模型库，其中3d模型根据视觉外观或其它参数进行参数化。此参量表示可被称为“智能客体”。此外，可利用被称为“可供性(affordance)”的可能在客体中的任何两对之间的不同种类的交互的一个或更多个目录。例如，从剧本获得的元数据可被映射到智能客体的一个或更多个实例以及在它们之间调用的对应的可供性。以这种方式，vr环境的一个或更多个元素可从场景元数据变换成实际的视觉表示。
剧本中的每个角色(如果存在于当前呈现的场景中)在可视化中具有位置和取向。对于道具也是如此，并且如果有必要，则对于设备诸如灯、音频设备和/或摄像机等也是如此。这些场景元素的位置可随时间而改变。当用户“播放”剧本时，可视化可动态地更新以示出越过的元素的移动，例如，创建上述2d自顶向下预览的检查点。检查点可指代参考时间点。可根据需要实时、减速和/或加速查看预览。可使用初步定时检查。然而，虚拟空间中的事件的定时可与2d故事板上的事件的定时明显不同，因为如上所述，可在vr环境的360度空间中存在/发生不同的角色、道具、交互、动作等。因此，前端分析引擎206/后端分析引擎212和nlp核心224中的一个或更多个为了场景的不同方面之间的一致性可调整任何事件定时或定时检查。
在一些实施例中，可生成“加热图(heatingmap)”。加热图可指代剧本元素与另一个剧本元素的关系的视觉表示。例如，加热图可用于表示角色与摄像机或其它角色的接近程度。从此类加热图收集的信息可向用户提供关于使用“行为召唤(calltoaction)”暗示(hint)的引导。行为召唤暗示可涉及针对观众的将他们的注意力吸引到场景的特定部分的一些提示(cue)，例如，照明的微妙增加将观众的注意力引导到场景的此部分中的一些动作或角色或其他元素。其它行为召唤可包括但不限于使用更响亮的音频来将观众引导到此音频的源。在某些情况下，加热图信息可用于告知用户或编剧应该通过插入对话或者使一个或更多个角色参与某些动作等来解决的场景的一个方面。
当用户开发或编辑剧本并且/或者调整可视化的一个或更多个方面时，可视化引擎208反映相对于第一可视化的适当变化。应当注意，可由用户通过编辑面板204与剧本交互来实现改变。另外，用户可使用可视化本身来修改场景的一个或更多个方面，因为可视化是作为交互式前端应用/ui202的一部分呈现的。例如，第一可视化可反映剧本的当前状态，如编辑面板204中阐述的。然后，用户可通过与第一可视化交互来调整客体、道具、角色的放置，以及调整这些客体、道具和/或角色的移动速度。因此，可视化引擎208可基于来自编辑面板204的信息或输入生成可视化，其中编辑面板204可包括用于剧本编辑的部分以及用于呈现并且/或者编辑可视化的部分。
如果用户希望添加在解析剧本期间未识别的客体，则可手动添加(再次通过编辑面板204的可视化部分)，之后前端分析引擎206/后端分析引擎212和/或nlp核心224将跟踪未来对此客体的所有引用。在一些实施例中，前端分析引擎206/后端分析引擎212和/或nlp核心224可更新编辑面板204中的剧本以反映通过可视化添加和/或在元数据解析阶段期间未识别的任何客体、角色等。在一些实施例中，可使用与编辑面板204分开的单独的可视化面板或部分来向用户呈现可视化(未示出)。
在一些实施例中，持久数据资料库220可包含与一个或更多个角色、草图(图像和视频)相关联的服装的图像，或者可用于创建并且/或者编辑剧本或可视化的各方面的任何其它相关信息或数据。
故事板的生成也可由可视化引擎208执行。用于生成故事板的过程类似于上述2d可视化的生成。然而，从剧本解析并且与可视元素相关联的角色、道具和其它元素反映在一系列静止图像中。故事板可在编辑/可视化面板204上呈现。故事板可以不同的格式(例如jpeg、png、tiff、pdf等)打印或导出。
再次，类似于2d可视化和故事板生成，剧本或更新的剧本可用于生成存在于剧本的场景中的摄像机、地点、客体等的3d表示。也就是说，可使用2d可视化中利用的抽象表示来呈现3d预览。3d预览可用于根据情境和/或主题的凝聚力、一致性、美学魅力等来评估剧本或故事。例如，编写者可向潜在的制片人呈现3d预览，或者导演可向一个或更多个演员呈现3d预览。导演可在涉及真人动作电影的实际排演之前，或者在用于动画制作的对角色、场景元素等进行动画处理之前观看3d预览。在一些实施例中，可在剧本开发/编辑期间向用户呈现3d预览而不是2d自顶向下可视化。在一些实施例中，可将3d预览输出到增强现实(ar)或vr渲染应用/设备。例如，3d预览可通过预览设备222(图2)呈现给用户。如上所述，预览设备222可为hmd、透视显示器、视频透视显示器、膝上型计算机、智能手机、平板计算机、移动设备、投影仪、监视器、电视和/或其它显示器。
应当注意，在一些实施例中，可视化可被用作用于基于剧本或故事创建实际vr体验的基础。也就是说，用户可将客体、道具、角色等的抽象表示与完全实现的数字表示相关联，可添加背景等，使得可视化可被转换成实际的媒体内容。技术诸如摄影测量法可被用于将2d内容转换成3d模型/内容以用于vr体验。
应当注意，后端分析引擎312的编译器214可用于分析剧本的一致性并且提供解决任何不一致的建议。也就是说，可针对结构和/或情境有效性来分析文本剧本(例如进入到前端应用/ui202或经由前端应用/ui202上传的一个文本剧本)。也就是说，可针对任何逻辑不一致来分析剧本。可从“线性”或传统2d体验视角以及从虚拟现实(vr)体验视角分析剧本。
例如，编译器214可接收关于从剧本提取的元数据的信息以及从前端分析引擎206/后端分析引擎212和/或nlp核心224从其导出的任何信息或数据。编译器214可利用此信息来检查剧本的当前迭代或版本的结构有效性。例如，编译器214可确定是否存在任何结构错误。结构错误可指代与“物理”表示相关联的错误，例如，摄像机放置、道具放置等中的错误，其在场景中不是物理上可实现的。结构错误的示例可以是摄像机“穿过”道具的场景，这是不可能的，并且应该被识别。编译器214还可确定是否存在任何情境错误。情境错误可指代基于故事的不一致，例如，用户具有在场景中提到的特定角色，其中此角色尚未进入此场景中，或者角色在先前场景中被杀死。
编译器214可生成关于该错误的一个或更多个通知。该一个或更多个通知可仅仅是告知用户存在不一致性的通知，以及涉及剧本的位置和/或一个或更多个方面或一个或更多个元素的通知。在一些实施例中，该一个或更多个通知可为对用户的关于纠正不一致性的解决方案的推荐。例如，后端分析引擎212可根据解析的元数据确定场景的特定部分中的两个或更多个角色之间存在交互。编译器214可分析此信息并且确定应该根据此现有交互向观众提供行为召唤提示。因此，编译器214生成通知，该通知建议用户插入行为召唤提示，诸如照明改变或音频提示，从而将观众引导到此交互。
如上所述，所公开的平台提供创建并且编辑剧本的能力、使用视觉时间线表示角色演变的能力、生成故事板的能力以及生成预可视化的能力，不管是2d还或3d。在图3a至图3l中描述和示出这些功能的示例。
图3a示出剧本布局视图，其具有在ui中呈现的附加特征，以协助以自然英语编写叙述故事。可为前端应用/ui202的实施例的示例ui300包括编辑面板302。编辑面板302(其可为前端应用/ui202的编辑/可视化面板204的实施例)用于呈现剧本的文本表示。用户可添加、编辑、删除并且/或者查看剧本。
剧本可包括一连串场景。每个场景可被认为包含在本文中被称为“模块”的元素。模块可描述剧本的每个句子(1个模块＝1个句子，与其书面内容无关)。模块可被认为是故事的“原子”部分。模块的示例可为以下中的任一种：地点、对话、转变或动作。用户可在句子中描述模块，将模块添加或拖动到剧本或现有的模块中。图3a示出这些模块的表示。在用户希望将模块引入剧本中时，用户可选择期望的模块并且将其拖动到编辑面板302上的剧本中的期望点。
地点模块设置故事的新环境。对话模块设置角色的口头会话。转变模块设置从一个状态改变到另一个状态的一段时间，其通常在每个场景的开始和结束时使用。动作模块设置场景角色所采取的表达动作。图3b示出用户悬停在放置到剧本中的动作模块上的示例。
地点、对话和动作模块具有选择摄像机镜头的选项。选择摄像机镜头图标后，将打开情境菜单，并且为每个模块提供选项列表。例如，图3b示出用户悬停在放置到剧本中的动作模块上的示例。可相对于可选择的“摄像机镜头”图标，向用户呈现用于查看动作的选项。
默认情况下，平台可为给定的模块推荐最合适和最常见的镜头。虽然这是自动化的过程，但是用户可选择通过从列表中选择另一个来手动编辑所选择的摄像机镜头。该列表可包括常见类型的镜头、常见角度的镜头和常见摄像机移动的选项。如果用户对给出的列表不满意，则在列表的末尾提供创建新摄像机镜头的附加选项。此选项允许用户为他们自己的个性化摄像机镜头创建和分配名称。
每个模块并且因此每个摄像机镜头将创建可生成的故事板的框架。图3c中示出摄像机镜头列表304的示例。如图所示，摄像机镜头列表304包括为用户生成的各种不同的摄像机镜头图像。如上所述，可识别(例如，如被推荐)或在默认情况下选择摄像机镜头列表304中的特定摄像机镜头选项，在这种情况下是“远景镜头”。然而，用户可从列表中选择另一个摄像机镜头，在这种情况下是角色“玛丽(mary)”的“中景镜头”。应当注意，在一些实施例中，摄像机镜头可被认为是模块本身，并且摄像机镜头模块选项可提供给用户。
在一些实施例中，用户可将声迹与他们(或另一个人)的语音一起录制在任何对话文本上作为语音剪辑。与对话相关联的声迹将在3d可视化中自动被动画处理。分配给语音剪辑的角色将使用唇同步技术进行动画处理，使得角色预览(例如，3d预可视化)精确地镜像对话中的语音。如果用户不使用他/她自己的语音记录对话，则平台可提供默认的计算机生成的语音或上传对话的选项。
图3d示出记录对话界面306的示例。如图所示，用户可选择记录剧本文本的口头对话的选项，例如，玛丽的对话框“这是什么意思”。在记录之后，用户可回放口头对话，例如，史蒂夫(steve)的对话“好的，妈妈。我会再联络你……”与口头对话相关联的持续时间可被确定并且呈现给用户。还可呈现口头对话的视觉表示，诸如模拟示波器。用户可希望确定与口头对话相关联的音量级和/或定时。
如上所述，剧本可上传到平台。也就是说，可上传特定平台格式或其它第三方格式的剧本。在一些实施例中，平台可执行从非本机平台格式到本机平台格式的转换。另外，剧本可以另一种形式导出，例如pdf、rtf、txt等。
如上所述，时间线视图可用于说明场景中每个角色的演变，作为剧本的图形2d表示。图3e中示出此时间线视图的示例。该时间线视图可在编辑面板302中呈现。也就是说，用户可在文本剧本表示视图和时间线视图之间切换。x轴表示不同的角色，而y轴表示时间。为了完全区分，可为每个角色分配其自己的颜色。角色之间的任何交互(交互视图)的表示是从解析的剧本自动创建的。该剧本可在从上到下以角色为中心的透视图中表示。这与通常水平呈现的现有技术中的其它时间线不同。以这种方式，用户可在文本剧本视图(也是垂直呈现的)和时间线视图之间切换，并且将每个模块的位置(一个接一个)或元素(按时间排序)作为参考，在两个视图中都可用。在一些实施例中，时间线视图可与文本剧本视图(也是垂直呈现的)一起/结合文本剧本视图呈现，使得在剧本创建或编辑期间分析/引用时间线视图和文本剧本视图两者。应当理解，可自动生成时间线视图。然而，用户仍然可从时间视角编辑剧本。
在可滚动容器中存在用于每个角色、摄像机和智能客体的线和控件。另外，环境声音文件也可放置在这里。通过悬停在模块上，用户可获取信息，添加新动作、交互和对话，添加新角色和智能客体等。线上的元素表示对话框和动作模块，并且也可将线上的元素拖动到不同位置和重叠位置(在同时发生各种动作或对话或动作和对话时)。时间线中的每个改变都会影响文本剧本视图。例如，如果用户决定按时将元素定位在另一个位置(即，在动作之后定位对话)，则相同的改变将反映在剧本视图中，并且模块将相应地调整到新时间。
图3e示出根据各种实施例的时间线视图的示例。时间线可包括一个或更多个角色时间线，其示例是角色时间线302a。“气泡”302b可表示待由编辑面板302中表示的特定场景中的角色说出的对话。用户可已经进入此对话，或者此对话可已经存在，并且用户正在检查以察看在场景中特定时间点与特定角色相关联的对话。元素302c向用户呈现背景音频。
应当理解，用户可通过选择并且例如根据用户的期望效果拖动角色时间线来操纵ui300的一个或更多个方面，例如，角色时间线。例如，在角色时间线被带到一起或彼此靠近时，它指示所表示的角色通过剧本对话或一个或更多个动作与其它角色相互作用。可呈现指示角色在场景中存在或从场景中退出的不同表示。例如，实线时间线可指示角色的存在，而虚线时间线可指示角色已经离开场景。
用户可使用时间线控制器或指针302d来“滚动”通过编辑面板302中的剧本/时间线。时间线控制器302d可根据其当前定位的位置与时间相关联。
转变在时间线视图中表示为水平块302e，其在此时间期间影响场景中的所有元素。在用户没有定义转变时，默认情况下，转变将是剪切。如果定义了特定的转变，则模块之间将发生转变。转变的持续时间也可延长或减少。
其中所有角色的时间线聚集在一起的情况可被称为宏交互。所有角色/客体具有相同的交互，共享空间或会话(对话)中的任一个位置。宏交互可与组交互区分开，组交互中存在不同位置的角色或具有单独的会话。时间线可划分为不同的可识别区域，以区分每个组的交互。组交互的示例是由区域302f勾画的，其表示角色史蒂夫和埃文(evan)之间的某种一个或更多个交互。另一个“组”可包括角色玛格利特(margaret)。
应当理解，角色可从其起点处于特定场景中，或者可在任何点处进入。同样，角色可在场景结束时或在场景结束之前的任何时间离开场景。图3g示出在编辑面板302中的时间线可视化中表示的场景。如图3g所示，角色玛丽从开头开始出现在场景中，但在场景期间在点302g处离开。另一方面，未出现在场景开头的角色埃文在场景中途的点302h处进入。
可使用空闲模式来描述在角色在场景中但没有动作或者没有参与任何交互时角色的状态。例如，导演可希望在场景中包括角色，但仅限于“被动”容量。图3h示出此类空闲模式的示例，其中角色玛丽在场景中，但不参与任何交互或动作。可使用玛丽的时间线的修改的表示(在这种情况下，她的空闲状态的指示302i(在8秒标记处))以及用于表示在空闲模式期间的她的时间线的散列线302i'。
如上所述，故事板视图可为基于剧本生成的另一个输出。图3i示出此类故事板308的示例。故事板308可包括以帧组成的一连串图像。每个帧都可表示来自剧本的模块。重新参考图3c，故事板308中的一连串图像可由用户在摄像机镜头选择期间选择(或者自动选择/默认用于此场景)的图像组成。
图3i还示出2d可视化310。在2d可视化310中呈现摄像机310a、表示为元素310b和310d的角色玛丽和史蒂夫，以及帐幕(tent)310c的表示。如前所述，可视化引擎208(图2)可用于生成包括2d可视化和故事板的可视化。验证引擎208可根据待生成的可视化的类型来选择不同的视觉或图形表示和/或视觉取向。也就是说，2d可视化310呈现表示角色或客体的抽象元素，诸如球体/圆形，而故事板308依赖于实际图像来表示角色和客体。应当理解，用户可已经选择将特定图像与特定角色相关联。用户可访问可使用的图像的数据存储。可提供选项以隐藏/显示当前场景中的角色(演员)、隐藏/显示当前场景中的一个或更多个摄像机，以及调整表示摄像机可观察的场景的一个或更多个部分的视场(fov)，使得用户可规划元素的定位。
图3i中还示出ui控制面板312，其可由用户用来在控制剧本的不同方面或各种可视化(例如，时间线视图、故事板、2d可视化和3d可视化)之间切换。ui控制面板312还可呈现与这些不同方面相关联的相关信息，诸如与涉及角色的动作或对话相应的时间或帧。如前所述，时间线控制器302d(图3a)可用于遍历剧本或时间线视图。ui控制面板312可反映当前剧本、时间线、故事板或2d/3d可视化的相关方面，并且可根据用户选择查看的剧本、时间线等中的位置进行更新。
图3j示出上述加热图功能性的示例。可结合2d可视化310(或在3d可视化中)生成加热图314。在此示例中，颜色可用于指示场景的两个或更多个方面或元素的接近度，然而，可利用指示接近度的其它方法。在此示例中，加热图指示角色310b和310d之间的关系，其应由用户用例如行为召唤来提出。在一些实施例中，黄色、橙色和红色光谱中的颜色可表明接近度的水平或等级，而蓝色或绿色光谱中的颜色表明接近度的缺乏。应该理解，除了仅接近度之外，加热图还可反映任何类型的相关信息。例如，动作或移动以及声音可反映在加热图中，其中可使用不同的颜色来表示反映动作、移动、声音的强度或量的等级或水平，不管是否存在角色/客体，等等。在一些实施例中，加热图的颜色可用于指示查看者在场景中给定的摄像机位置可消耗多少信息。
图3k示出示例2d可视化310的增强视图。应当了解，每个元素(角色/客体)的较暗部分可表示元素的取向或视图点。例如，角色310b表示为例如向右“看”，而角色310d表示为朝向角色310b向上看。如上所述，元素310c可为帐幕，其可表示为具有定位在其中角色310b定位在场景中的方向上的开口/门。此视图提供用户创作的故事的抽象、简约预览，并且隐藏了理解角色或其它元素之间的空间关系所不必要的所有细节。
图3l示出场景的3d预览或预可视化的示例。在此示例中，3d预览被表示为鸟瞰图。角色和客体可由对应的3d模型/图像表示。使用动画表示动作和/或交互。声音/对话(不管是由用户如上所述输入还是稍后引入)也可作为3d预览的一部分呈现。此3d预览为用户提供简单并且有效的方法来掌握何处、如何、何时以及哪些角色/客体进行交互。应当注意，可在此3d预览中调整摄像机视图。也就是说，可在创建3d预览时考虑并且生成所有的视角。摄像机视图可由用户致动摄像机310a的表示来控制。还应当理解，3d预览代表fov和/或实际由摄像机310a捕获的场景的一部分。
为了总结用户的视角，所公开的平台通过可单独地或彼此结合地操作的各种部件(图2)来提供剧本、可视化和预览功能性。在一些实施例中，它们共享定义的接口，并且可支持附加的部件/功能性。
在一些实施例中，ui本身用网络技术(html5、node.js、angular.js和级联样式表(css))构建，并且因此符合多平台。用虚幻引擎在webgl中构建的ui控件可提供上述2d和3d可视化或预览。后端功能性可用c#编写，并且包含处理用户输入的所有逻辑以创建一致的故事。外部部件，如持久数据资料库220和nlp核心224，可支持数据处理(nlp服务器及其接收数据的预处理和后处理，用java和prolog编写)，并且可适应多个设备的云功能性。存储在持久数据资料库220中的数据可被生成/存储在类似项目的结构中，以实现一致性和符合度目的。
已经由后端逻辑准备的场景元数据可通过javascript客体表示法(json)界面递送到控件。ui“页面”(即，剧本和时间线视图)以及它们的相关联的控件/其它ui控件由它们自己的typescript类和预定义布局表示。这些视图内的容器由后端通过edge.js提供到页面的数据动态填充。ui控件最初包含待运行的所有模型、环境和动画，然而，后端提供以预定义3d格式上传模型的逻辑。
关于后端逻辑，每个输入(读取剧本文件期间由用户或由系统)将由后端逻辑解析，并且决定将如何处理数据。可将数据发送到外部部件以进行一致性检查并且识别人员、动作和客体。然而，逻辑也可决定此文本是否仅与对话/直接语音相关，并且只需要用对应的对话模块表示。
收集的所有数据都将用于生成多个输出：用于剧本和时间线视图的检查过逻辑一致性的故事、用于构建场景预览并且还生成对外部部件的请求的视觉控件的丰富的数据。另外，后端还将为持久层提供接口。
一致性检查，用其动作识别角色和客体都基于自然语言处理(斯坦福nlp核心(stanfordnlpcore))。如上所述，在一些实施例中，这些功能可由前端分析引擎204、后端分析引擎212或nlp核心224中的一个或更多个来处理。在一些实施例中，由于依赖于大量的存储器消耗和处理时间的强烈处理需要，此处理被移交到nlp核心224。这还可减小客户端(后端和对应的前端ui)上的复杂性。此外，表示为系统200(图2)的平台(或平台的部分)可包括其它外部操作/元素，例如，元数据处理元素226，其富含元数据以在自然语言解析之前和之后处理甚至更多的功能。例如，一个或更多个元数据处理元素226可用于识别角色是否在某些动作期间死亡并且该角色不能继续第二动作。
平台的持久层满足多种需要。基于xml和文件夹结构，保存项目并且可加载该项目，例如，在持久数据资料库220处/在持久数据资料库220中，项目可互换以用于协作，并且它们构建其它应用的基础，其它应用即vr和增强现实(ar)应用。图4示出突出平台外部连接和扩展/交互的示例平台400。图4示出平台的前端402/后端410的表示，其包括前述ui控件、接口和逻辑(其可为图2的前端/ui202和后端服务器210的相应实施例)。还示出外部内容部件424的示例，其可为nlp核心224(图2)的实施例，以及持久数据部件422的示例，其可为持久数据资料库222(图2)的实施例。此外，平台400可包括应用启动器428，该应用启动器428可用于启动其它部件/应用(例如，下面的ar部件432/vr部件434)。另外，平台400可包括协作部件430，该协作部件430允许平台400和其它系统/应用以及ar部件432和vr部件434之间的分别的交互。ar部件432和vr部件434可通过3d预览可发送到的预览设备222(图2)或其它系统或设备的实施例，以用于呈现或用于增强/虚拟化实现。
应当注意，平台400可被配置成使得其通过使用电子框架与各种操作系统(例如，os-x、microsoftwindows等)兼容。为了确保能够允许用户和其它实体/提供商进行协作，项目基于文件并且可互换。这可扩展到数据库和/或云共享。借助鲁棒后端逻辑，可处理请求，并且还可启用个人数据加密。
可使用“端应用(side-application)”(ar部件432/vr部件434)来实现ar/vr设备或应用的上述使用，该“端应用”使用例如头戴式显示器(hmd)提供完整的ar体验/vr体验。该“端应用”可访问相同的持久数据，并且可使用相同的算法来构建项目(一致的故事和时间线)。然而，该“端应用”可提供与故事交互的不同方式，因此用户能够浏览创建的故事，从而进行一连串交互，并从而总体上管理故事。
以这种方式，用户可非常早地预可视化故事。编写的每个句子(例如描述两个演员之间的动作)将引起具有对预定的或学习到的条件的正确解释的自动化动画。这些详细的可视化允许用户专注于未来的任务，这些任务在3d预览中比文本块更加用户友好。
平台400管理用户输入(鼠标、键盘和语音)和系统输入(读取现有项目)、逻辑本身、外部连接和持久数据。这包括但不限于(如上所述)：在ui中拖放标准和自定义控件；使用外部自然语言部件即时(just-in-time)并且按需解析书面文本；录制口头文本以保存为音频文件或通过语音到文本引擎解析；提供库函数(创建、选择、存储客体如演员、地点、场景、客体、摄像机等)以及对应的适当动作和方法诸如动画；将用户定义的地点上传为模型或180度视频/360度视频；定义摄像机剪切、移动和转变以及它们的位置和取向。
在一些实施例中，平台400被实现为客户端-服务器架构。这引起可在本地在用户的计算机上运行的平台，但仍然能够在远程服务器上具有自定义部件/模块、数据处理和/或甚至单页。
平台400的前端402可包含两个主视图和多个管理页面、两个独立控件、库控件和模块控件。另外还有多个页面和模式窗体(modalform)，以用于管理一个或更多个项目和创建内容。平台400的视图和管理页面中的每个由其功能类中的单个页面和特殊逻辑表示。项目范围的逻辑和控件可用于每个页面。node.js、javascript和typescript还有html5的使用将提供用户和视图、模式窗体和模块化控件之间的交互。
与剧本视图相关联的ui允许用户插入模块并且构建剧本。如前所述，可用不同的模块，例如“对话”、“动作”、“转变”和“地点”。用户可将该不同的模块拖动到剧本视图上。ui确定模块被插入的位置：最重要的是，在两个现有模块之间还是在最后处。嵌入式控件可包括模块列表：(如上所述)带有“对话”、“动作”、“转变”和“地点”。为了上传剧本，提供允许用户以预定义的格式(具有标签的文本文件)上传剧本的控件。ui将告诉逻辑解析剧本，并且逻辑将自己确定不同的类型(识别对话、动作等)，需要由外部部件(自然语言引擎)处理的内容等等。对于剧本打印，提供控件以用附加描述标签或不用附加描述标签直接从可视文本呈现pdf。
由逻辑中的软件命令模式表示的附加控件允许撤消和重做动作。控件提供音频记录，如前所述，允许用户上传音频(以用作环境背景声音或直接传递到语音到文本引擎)以进行进一步处理。可实现另一个控件以允许用户在剧本中搜索角色和词。例如，可实现键盘快捷键控件以允许用户使用不同的快捷键在当前模块下方创建新模块。也可根据需要实现过滤，例如，通过角色、具有/不具有录制的音频的显示对话框等过滤。
剧本视图提供上述控件的所有功能，以将所需事件发送到具有所有所需自变量的逻辑。此外，它示出不同的ui样式(标签)，以实现快速识别以下中的一个或更多个：场景开始和结束的位置；地点改变的位置；剧本中的摄像机剪切掉和转变成什么；以及不同样式的所有模块(即斜体的被动描述文本、演员用其名称和颜色作为标签的口头文本)。
时间线视图允许用户以时间方式察看和修改故事。角色、客体和一个或更多个摄像机由水平线表示，而演员/客体/一个或更多个摄像机的动作、转变和对话在对应的线上示出为不同的扩展线(框)。这些方面可由用户完全交互。用户可悬停在将显示另外的信息的框上。例如，悬停在对话框上将在光标的工具提示中显示对话文本。
嵌入式控件可包括以下内容：添加/编辑环境声音，其允许用户记录/删除将在ui中表示为声波的环境声音；添加/编辑演员/客体/摄像机，其允许用户使用此菜单将已知的演员/客体/摄像机添加到场景。应当注意，每个添加的演员/客体/摄像机可由线表示，但不一定是强制性的；添加/编辑动作/交互，其中如果用户悬停在线上，在光标到达线(靠近)时出现图标，从而帮助用户在给定的时间直接向对应的用户添加/编辑动作/交互(由线的位置确定)。
根据用户选择的内容可出现不同的模式窗体(即，如果用户选择“添加动作”，则窗体示出与添加动作相关的所有可用动作)。
以这种方式，用户可调整或扩展剧本或者甚至从头开始构建剧本。上面提到的所有控件都提供它们的期望功能(例如，通过在交互时将数据发送到后端)。此外，还提供某些专门功能。可具有拖动框的功能和重新调整框大小的功能，用户可使用该功能以将显示的模块(线上框)拖动到新的时间，虽然该框不能改变所有者(从一个演员拖动到另一个)。另外，用户可重新调整框的大小，这将引起模块的新的持续时间。演员的自定义动作也是可用的——这些可以是例如“标记为场景外”、“标记为空闲”、“进入场景”和“标记为非空闲”。
利用所有演员、客体和场景内客体的前述简单(2d)和复杂(3d)视觉表示，可向用户提供具有不同级别细节的非常早的预可视化。这些级别包括显示/隐藏摄像机视场，以及显示/隐藏动作诸如客体和或演员之间的移动和交互。这些控件用3d引擎(虚幻)构建，并且作为webgl客体提供，以便与后端以及前端直接同步。
嵌入式控件可包括显示/隐藏热图控件，该热图控件使得层可见(由3d引擎控制)并且将动作(热量)显示为地形上的叠加。嵌入式控件还可包括显示/隐藏场景中显示/隐藏所有演员的演员控件、显示或隐藏场景中所有摄像机的所有视场的fov控件。通过所有这些控件，用户可在编写剧本期间规划后续步骤。
此外，提供允许用使用输入设备诸如鼠标进行缩放的控件，以及允许用户播放特定场景的播放/动画控件。
提供允许用户获得项目中可用的所有演员、客体和地点的概况的库控件。更多功能，如创建、复制和删除内容(演员、客体和地点)也是可用的。这些控件不需要与3d引擎或webgl构建相关，而是可用与主窗体(node.js和html5)相同的技术构建。3d视觉表示可作为缩略图获得。
可向用户提供支持完整创意工作流程、项目编辑等的多个页面(视图)。所有页面大多具有类似的功能，因为它们允许用户注册具有所有所需属性的客体、验证这些属性，并且将它们保存在后端逻辑中。所有进一步处理(例如，存储到持久数据)可由后端处理。
后端逻辑用c#编写并且具有用于前端的定义的连接器。当前，平台400可服务于两个前端，例如主ui、edge.js上的电子客户端以及在相同接口上构建的webgl。后端功能分成多个服务，其中每个服务由接口表示(基于zenject依赖注入框架)。应用层次结构从中央类开始，以用于处理和管理项目加载、保存和卸载以及项目创建的应用的一个实例。应用和项目类两者都为修改其管理的资源的所有事情提供事件。
后端控制下列不同类型的数据：项目、场景、实体(亦称客体)、外观(所有客体具有应该如何呈现预览的预定义的外观)。这是由以下定义的：每个预览引擎都可自己确定如何呈现的原语、可供性描述(在下面论述)以及(智能)客体(具有给定的一组可供性、定义的名称和外观的每个智能实体的构造)。这也可由以下定义：(智能)演员(扩展的智能客体，但用于具有独特颜色的演员)、(智能)摄像机(扩展的智能客体，但具有一组不同的默认可供性)，以及前面提到的充当用于创建场景的“构建块”的模块。每个模块都具有开始和结束时间(其可通过逻辑计算(通过对话的长度)，也可由用户通过ui中的操作给出)。更进一步地，这可通过交互组(表示随时间连结的给定一组演员/客体的客体。该平台提供了在场景内具有简化表示的能力，即使发生了很多事情)。此外，后端提供对诸如以下功能的访问：nlp-客户端(即，从nlp核心224发送和接收数据(图2)；解析器(解析服务，其只通过逻辑本身或用户直接输入来接受字符串并且返回预期的结果集(即客体列表、产生的可供性等)；以及提供存储并且读取项目和实体的方法的持久层。
关于可供性，平台400使用被称为“可供性”的内建工具。可供性与动作(例如，拾取石头)不同。相反，它是必须恢复的方向。可供性的所有者(石头)提供一组所有者已经控制的可供性。用户(演员)启动动作(拾取)，但所有者(石头)控制并且执行它。此结构提供给平台400通过简单的方法控制动作的能力。
如上所述，平台400可使用外部资源，诸如nlp核心224来处理数据和用户输入。为了降低客户端应用本身的复杂性和需要(存储器消耗数据库)，方面如自然语言解析并且因此这些输入的预处理和后处理都在外部服务器上执行。因此，平台400可向外部资源发送请求。json结构使用诸如图5a中所示的这些描述来解析从平台400到外部部件诸如nlp核心224的请求消息。解析结果消息可使用诸如图5b中所示的这些描述。类似地，在图6a中示出在交互组请求消息中使用的描述，并且在图6b中示出在交互组结果消息中使用的描述。
平台400的接口可用于连接前端逻辑和后端逻辑。可用edge.js建立连接，edge.js是包装函数，其允许通过定义的edge.js接口调用逻辑动态链接库。接口可处理不同的输入，例如，来自鼠标或输入设备事件、键盘快捷键等的拖放输入。该接口还包含用于在两侧(c#和node.js)上存储复杂客体的容器。因此，平台400能够附接可读取c#的前端和(具有定义的json结构的)所有其它的前端。图7示出示例前端到后端接口和后端到前端接口。
应该注意，平台400可以它们应该被处理的方式来管理用户输入和设备。书写输入(例如，在用户手动输入剧本时)可直接发送到例如nlp核心224。此外，来自后端的事件还可与外部部件接合，例如，在加载剧本时，并且直接处理它。此外，可使用应用启动器428启动外部应用，例如ar应用432/vr应用434。这些可执行件或部件可为完全独立的，但是访问相同的持久数据。为了交换数据，平台400能够读取项目文件夹和文件。具有平台400的不同实例(或前端/ui)的不同用户可例如经由协作部件430进行协作。
上面已经论述了自然语言处理的使用，并且在本公开的情境中可用于解析剧本、推断知识/信息等。虽然已知各种形式的nlp，但是自然语言能力对从复杂故事中推理信息提出了挑战。也就是说，在能够通过读取故事来匹配人类大脑的推理水平之前，自然语言理解具有长的路要走。
另一个挑战在于分析、比较和分类从脚本或剧本中提取的信息的能力，以便提供上述允许用户创建/编辑剧本、生成预览等的功能性，同时保持情境一致。计算叙述领域在故事图的帮助下大大推动表示叙述，但是这些当前的数据结构不能直接从基于文本的故事中形成。当以用户可容易地察看哪些角色当前正在彼此交互并且出现在故事中的相同地方的方式来向用户表示角色之间的关系时出现其它困难。
根据各种实施例，预期使用基本/原子知识元素(也称为知识字节)。知识字节表示封装在剧本中的信息。另外，将知识字节彼此进行比较以形成知识字节之间的成对关系的含义允许识别类似并且矛盾的知识字节。
另外，各种实施例使用允许知识字节基于叙述中的角色与一个或更多个角色相关联的角色系统，该角色以信念和期望的形式体验这些知识字节。这创建了故事中知识拥有的连贯表示。此外，每个角色系统可对其拥有的信息使用逻辑推理。借助于知识字节之间的关系，可识别叙述中不同角色之间的信念/期望矛盾或类似性，使得未来的工作能够朝向将角色之间的关系定义为意图和信念的组合。
此外，各种实施例使得剧本创建者能够相对于规则表添加推论规则和错误。规则表能够解析结构化的自然语言文本，以生成某些类别的规则和错误，然后角色系统可使用该规则表，使得它们能够对所拥有的信息做出逻辑推断。
更进一步，引入交互组的想法，其中在故事期间的某个时间内彼此交互的角色被认为是组。在角色一起执行动作或者角色从一个地方移动到其它角色已经存在的另一个地方时，自动创建交互组(图3f)。
图8示出如根据各种实施例实现的用于自然语言处理的示例架构/工作流程。它示出如何通过自然语言理解处理源自用户的创意内容，并且进一步解析成知识字节流并且馈送到各种角色系统和剧本系统中。此外，由剧本系统和角色系统完成的推论和推理引起呈错误和信念-期望关系的形式的反馈，该反馈被中继回用户。规则表和角色表分别充当逻辑和角色背景检索的替代形式。
用户界面的输入以三种不同的形式呈现。原始剧本本身用于构建系统的知识库。原始剧本可指代主要故事情节的表示，例如，单个角色的动作以及角色之间的交互和角色对话。原始剧本可存储在故事知识库中。
元数据诸如规则表允许系统理解和做出推理，并且角色表是信息检索的另一个源。也就是说，元数据允许以故事世界知识库的形式指定规则和/或错误定义。此外，元数据可用于添加关于存储在角色知识库中的角色(例如，背景信息)的信息。
来自用户的查询也是输入形式，其中输出以查询和信念-期望关系的形式来自剧本系统和推论系统。查询允许关于待通过使用知识推论系统(在下面描述)获得/确定的存储在故事知识、故事世界知识以及角色知识库中的知识的推论。可使用nlp核心224来分析输入作为信息流的基础，nlp核心224还可创建知识字节。
然后使用例如斯坦福核心nlp框架分析用户提供的所有输入，其中广泛使用增强型++依赖性图。处理动作和对话框以创建并且保存包含新信息的知识字节。在用户问题的情况下，进行关于存储信息的推理，并且基于推理的输出呈现给用户。如果在文本分析期间存在任何问题，则也会将适当的错误返回到用户界面。
如前所述，知识字节是传递到系统例如平台400(图4)上的信息的基本元素或“原子”。解析器可用于将所有信息转换成知识字节流，然后可将该知识字节流传递到相应的角色广告剧本系统。
剧本系统存储存在于剧本中，并且也存在于角色系统中的所有知识字节。该剧本系统可访问每个角色的知识库，并且基于类似或矛盾的信念和期望检查错误和关系。
角色系统包含多个知识库和逻辑推论系统，例如，用于故事或叙述中的每个角色的一个角色系统。角色系统负责存储故事的快照，以表示每个角色对它们周围的世界的感知，以及以推论系统的形式的它们的“大脑”。这些系统也允许以角色为中心的表示以及对故事的推论。
规则表用于定义故事的规则和错误定义。规则在自动转换成逻辑推论系统使用的形式后，可由用户以自然语言提供规则。一旦存在来自用户的查询，逻辑推论系统就将存储在剧本和角色系统中的信息与规则表中提供的信息相组合，以回答问题，显示故事中的可能的错误或不同角色的信念之间的关系等。图9呈现为示例句子创建的规则，从而识别角色的信念和期望并且包含关于交互的时间和地点的信息。
在一些实施例中，一个角色表对应于故事中的一个角色并且用于定义其背景——在实际剧本开始之前发生的历史。其中包含的所有信息都被添加到对应的角色系统，并且在询问关于角色及其知识的问题时使用。
图10呈现允许用户创建故事剧本并且指定规则和错误定义的工具，其可经由前端/ui202(图2)呈现。它的布局类似于编辑面板204的布局。图10示出以问题“谁拥有王冠？”的形式的示例查询，其在分析用户提供的整个剧本之后生成响应。以这种方式，用户可容易地解决或先发制人地避免任何主题或情境不一致，而不必例如手动重新读取剧本。
图11示出交互组的另一个示例实现方式(也在上面描述并且在图3f中示出)。图11示出包括角色玛丽、玛格丽特、埃文和露西(lucy)的第一交互组1100。第二交互组1102包括角色史蒂夫和罗纳德(ronald)。应当理解，可在角色玛格丽特加入角色玛丽、埃文和露西时形成交互组1100。
现在将论述关于知识字节的特定细节。如上所述，知识字节可被定义为关于叙述的最小信息单元。该叙述可表示剧本中存在的任何类型的信息，诸如动作、对话或问题。此外，知识字节还支持存储地点、时间点和其发生位置的坐标。这样做是为了处理可用于空间推论的空间知识，这可用于支持较新形式的叙事。
知识字节的结构如下：
·唯一id-从剧本中提取的每个知识字节都具有唯一的标识符；
·时间点-每个知识字节都具有时间点，以保持跟踪首先生成此知识字节的叙述中的时间点；
·坐标-每个知识字节与三维坐标相关联，以允许空间推论和知识字节的表示；
·地点-考虑到文本媒介是剧本，知识字节也可存储它们被创建的地点，以允许基于地点的表示和推论，以及基于地点的问题；
·主体-知识字节的主体；关系-被存储的关系；
·客体-关系的客体；
·关系修饰语-知识字节使用关系修饰语来存储关于关系的附加信息(通常用于介词)；
·关系客体-关系客体存储可伴随关系修饰语的客体；
·关系问题-如果知识字节是问题，则关系问题存储问题标签，并且允许平台查看用户提出的问题；
·否定标志-否定标志允许知识字节保持跟踪否定；
·说话者-在使用知识字节来表示来自对话的信息时，对话说话者被存储为知识字节的一部分(并且可用于比较从多个源了解类似或对比信息的角色)。
将信息分解为知识字节的重要性在于，这些知识字节以信念或期望的形式表示信息，并且可横跨多个角色的知识库被存储。横跨各种角色的知识库的知识字节的此链接允许有趣和有启发性的推理(在下面论述)。
将知识字节作为用于处理关于故事的信息的数据结构的引入实现了许多有用的操作。可基于不同参数对这些知识字节进行分类和取向。知识字节可根据时间以及空间或地点进行分类，取决于用户选择以通过用户输入提供到系统的信息量。替代性地，知识字节也可基于角色的知识进行对齐。例如，可观察横跨各种角色的信息分布。
如上所述，可根据各种实施例创建和使用不同的知识库。
故事知识库负责存储存在于剧本中的所有知识字节，以及对各种角色的引用。来自剧本的每个知识字节都被馈送到故事知识的知识库，并且这也允许对存储在此知识库中的信息进行推论。
故事世界知识库负责存储与故事世界相关的所有知识字节。也就是说，与特定故事世界或系列相关联的规则、主题、参数等相关的任何知识字节可存储在故事世界知识库中。以这种方式，可避免任何潜在的不一致，甚至是横跨故事。
角色知识库用于形成每个角色拥有的信息的知识库，并且以便允许推论系统能够让每个角色在故事世界中按照他们自己的一组信念和期望运作。具有用于每个角色的单独的角色知识库的好处是，它允许编剧向每个角色提出问题，并且基于角色系统拥有的信息来衡量他们的反应的差异。
此外，每个角色知识库存储具有某些包装器信息的知识字节，其描述角色特定知识库和知识字节之间的关系。特定关系的包装器包含有关角色对知识的置信度、角色学习信息的时间点以及指代知识字节是信念还是期望的标志的信息。还存储来自角色推论系统的反馈，以便发送回ui。
知识推论系统的核心是逻辑推论环境。此外，所有的角色知识库和故事知识库都具有它们自己的逻辑推理环境。他处理了故事世界知识，并且知识字节馈送到推理系统中。查询推理系统是否存在任何可能的错误，以及每当用户将问题指向特定角色时。
角色系统可使用逻辑推论以执行推论能力。借助于规则，可从存储在知识字节中的信息进行推导并且提取较深的信息。逻辑系统的另一个用途是回答问题，例如，生成prolog查询、横跨各种实例查询它们，并且响应于用户问题或信念-期望关系返回报告结果。用于java的gnuprolog可用于实现逻辑知识推论系统。也就是说，可使用多种类型的prolog事实来存储知识字节的各个部分。
信念事实存储或表示来自知识字节的最重要信息，并且将其作为信念存储在角色系统的推论系统中。信念事实采取两种形式：
信念(id、主体、关系、客体、否定标志)。
信念(id、主体、关系、客体、否定标志、关系修饰语、关系客体、关系问题)。
期望事实是指与信念事实所表示的信息相同或类似的信息，除了它们作为期望存储在推论系统中。它们采取两种形式：
期望(id、主体、关系、客体、否定标志)。
期望(id、主体、关系、客体、否定标志、关系修饰语、关系客体、关系问题)。
地点事实表示地点或场景信息，并且参考知识字节id。地点事实的格式如下：
地点(id、地点)。
置信度事实将置信度水平存储为从0到1的浮动值，并且具有以下格式：
置信度(id、置信度)。
坐标事实类似于置信度事实，但是坐标事实表示关于知识字节的坐标的信息。
坐标(id、x、y、z)。
时间事实允许用时间推论能力构建推论系统，并且具有以下格式：
时间(id、时间)。
另外，可使用推论系统中的规则和错误。用户可通过故事世界知识库添加它们。规则/错误的格式化可变化(以上关于图9示出和描述其示例)。
横跨知识库的推论涉及各种知识库中的知识字节的比较，以便检查它们是否具有类似性或矛盾性。寻找知识字节之间的可能的联系对于横跨知识库进行推理是必不可少的。使用wordnet可提取知识字节中使用的关系的同义词和反义词。可比较知识字节以形成它们之间的关系。可使用各种算法来比较类似性和知识字节。
基于两个知识字节之间的词汇比较来计算相关因子θ，这是对它们的相关程度的度量。θ从-1到+1变化，其中-1指代矛盾关系，+1指代知识字节之间的类似性，而较接近0的θ表示知识字节可不相关。
还考虑时间点和置信度测量以分析知识字节之间的关系。默认情况下，在一个实施例中，为了使置信度的影响比时间更强，已经分配了0.8的权重给置信度和0.2的权重给时间。在一些情况下，对于一些知识字节配对，存在为置信度和时间指定权重的自定义值的能力。在可需要两个知识字节的时间或置信度的差异对两个知识字节确实相关的可能性的不同水平的影响的情况下，这可为相关的。
对于任何两个知识字节，θ指代相关知识字节的相关分数。此外，知识字节的时间和置信度值可分别由tx和cx指代。可假设n是剧本的最终时间点。
下面表示用于确定两个知识字节之间的关系的等式。
为了形成知识字节，直接从用自然语言编写的剧本提取必要的信息。与用户交互的工具是用c#编写的，并且在本地运行。编剧能够提供三种不同类型的输入：动作、问题和对话，每种都在特定指定类型的输入字段中。
在一些实施例中，自然语言理解可在运行用java编写的解析器并且与斯坦福核心nlp框架(即，nlp核心224)(图2)协作的远程服务器上独立地执行。本地客户端和服务器之间的信息交换使用通用json格式执行。核心nlp允许使用一组选定的注释器，并且可根据用户的需要调整任何注释器的特定属性。可为每个查询单独设置这些属性。
在解析剧本时，可通过向每个文本输入分配说话者字段来区分不同种类的输入——剧本的动作、问题的问题和对话的当前说话的演员的名字。
可假设用户在由逻辑连接的句子组成的段落中输入文本，并且每个新的“想法”应该被放到新的段落中，即，必须由用户创建新的动作、对话或问题输入字段。
解析任何段落的第一步涉及对段落中的整个文本应用共同参考解决方案，其重点在于基于先前分析的句子，将演员/客体/地方的真实名称分配给人称代词(“他、“它们”、“它”等等)。示例输入“亚当(adam)购买新电话并且他使用它”将被转换成“亚当购买新电话并且亚当使用新电话”。
此外，可使用coref注释器，并且可将coref.算法属性设置为“神经”，以便使用较精确(但较慢)的基于神经网络的解决方案。替代性地，如果速度更受关注，则不需要分配coref.算法属性的特定值，以便依赖更基本的确定性系统。
在应用共同参考解决方案之后，然后将文本分成单独的句子，稍后标记化/令牌化(tokenize)这些单独的句子并且提取单个词(令牌)。每个令牌通常与其它令牌相关，其类似于树状选区和依赖图。也就是说，提取主体、关系和客体——所谓的关系三元组。作为三元组生成的基础，根据一个实施例使用斯坦福开放信息提取。替代性地，如果错过许多可能的关系，则可创建自定义管线并且用于处理更复杂的句子。这些更复杂的句子包括一般时态、进行时态、过去时态和现在时态，以及主动语态和被动语态。
创建知识字节的标准方法涉及提取：
·主体-名词-与关系形成主体依赖关系
·关系-动词-通常是依赖树的根
·客体-通常是名词-与关系形成客体依赖关系
·否定标记-布尔-如果关系、客体或关系客体具有任何否定(否)依赖关系，则为真
·关系修饰语-通常位于关系客体之前，并且与其形成案例依赖关系(例如“转到某人”)
·关系客体-通常与关系形成名词修饰语(nmod)依赖关系(例如“转到某人”)
·关系问题-在7.3节中描述
·从知识字节部件提取的标准方法存在一些例外。最常见的情况是使用动词“待(tobe)”，因为根据情境，其具有不同的含义：
·辅助动词(aux)，通常是进行时态的情况，例如对于句子“亚当正在去到上学(adamisgoingtoschool)”实际关系将是“去(go)”
·被动辅助动词(auxpass)，用于被动语态，例如对于句子“亚当被选择(adamwaschosen)”实际关系是“是(was)”并且客体是“选择(chosen)”
·系动词(cop)，主要用于描述主体，例如对于句子“亚当是诚实的(adamishonest)”，实际关系是“是(is)”并且客体是“诚实的(honest)”。
应当注意，可不设置客体(参见表1中的第一示例)或者不必是名词，如在关系令牌和客体通过开放式分句补语(xcomp)连接时的情况下)。例如，然后将例句“亚当不喜欢去到上学(adamdoesnotenjoygoingtoschool)”解析为知识字节的扩展形式，如表1的第二个示例所示，其中客体为动词“去(going)”。对于涉及超过一个主体、关系或客体的句子可创建若干三元组，每个三元组由一个主体、一个关系和一个客体/无客体组成，如表1的第三个示例所示。另外，可提取与动词形成advmod依赖关系的状语修饰语，虽然该状语修饰语不一定需要形成知识字节的一部分。
每个段落和段落中的每个句子被索引并且用于提供适当的定时，保存为知识字节中的时间点。从一个句子生成的所有三元组被分配相同的时间，并且得到的动作被设置为同时发生。可假设问题和对话以这样的方式遵循类似的结构作为动作，使得也可提取主体、关系、客体、关系修饰语和关系客体。
关于解析问题，最大的差异是提取问题词的可能性，例如“谁(who)”，“什么(what)”等。通过寻找主体或客体(类似于动作)来找到它们，同时确定它们是以“wh”开头的关系代词并且处于句子的开头。
此外，通过以特定角色的名字开始问题，可询问或指向特定角色的问题。例如，在问了问题“亚当，谁遇见艾萨(isa)？(adam,whomeetsisa？)”或“亚当，告诉我，谁遇见艾萨？(adam,tellme,whomeetsisa？)”后，可接收到告诉我们亚当目前所知道的遇见或已经遇见艾萨的角色的关于存储在亚当的角色系统中的知识的回应。
对话框的不同之处在于说话者被设置为说话的演员的名字。在共同参考解决方案期间，我们另外将人称代词的任何用法与词目“i”匹配到演员的名字。在分析角色的陈述时，尝试将收集的信息添加到角色的知识系统中。这样做是为了能够执行/获得关于角色的知识的推论，并且在稍后问问题时将其与其它角色的知识进行比较。
在分析动作时，可推断出演员对于他在对话中陈述的内容的置信度程度。这是通过检查演员是否正在使用表2中所示的一组置信度词中的词中的一个来完成的。每个词被分配从0(不可能的动作)到1(确定动作发生)的范围内的特定值。例如，亚当所陈述的句子“我认为佛伊泰克(wojtek)拥有王冠(ithinkthatwojtekownsthecrown)”将引起创建包含信念“佛伊泰克拥有王冠(wojtekownsthecrown)”的知识字节，其中置信度为0.4。
可假设直接在剧本中提供的所有句子具有等于1的置信度。
此外，可在信念(由具有某种置信度的对话中或剧本中的演员正常陈述)和期望之间进行区分。通过在剧本或对话框中在提供的句子中查找词诸如“想要(want)”、“希望(wish)”、“需要(need)”来识别后者。因此，句子“亚当吃巧克力(adameatschocolate)”和“亚当想要吃巧克力(adamwantstoeatchocolate)”将创建具有类似组成的知识字节，但是前者将被解析为亚当的信念而后者则被解析为亚当期望吃巧克力。
对于期望，置信度测量不被关注，因此置信度可一直被设置为等于1。
为了比较知识字节，确定两个比较知识字节中的动词是同义词还是反义词或两个都不是可以是重要的。为了解决此问题，可使用词网络(wordnet)词典。在查找同义词时，可对属于与查询的词相同的同义集的所有其它词执行检查。在寻找反义词时，可使用内置的词网络反义词列表。
规则表允许编剧创建规则，该规则将实现对关于故事和角色的信息的自动推理。除此之外，可提供错误定义，使得可确保故事的一致性。编剧可在创建故事期间的任何时间检查可能的错误。
可用自然语言提供规则和错误，并且规则和错误被自动转换成prolog语言结构。为了解析规则表，可使用令牌正则表达式(tokensregex)。令牌正则表达式是指包含在斯坦福核心nlp中的框架，以用于在(一系列)令牌上创建正则表达式。可对分配给由令牌化器注释器提取的单个令牌的属性执行检查——词目，命名的实体和词性。可使用正则表达式的三种主要模式，模式中的每种都寻找规则表输入字段中提供的特定句子结构：
·类型模式
·推理模式
·错误模式
表3中示出用于不同模式的正则表达式，并且表4中示出具有创建的规则的示例句子。可以所有大写字母键入主体和/或客体的名称以对每个主体和/或客体制定一般规则(参见表4中的推理和错误模式示例)。在其它情况下，可创建特定主体和/或客体的规则(参见表4中的类型模式示例)。
可组合模式。例如，可组合推理中的类型模式和错误模式。也可组合共同参考以及解决期望和否定。此外，在创建规则表时，可包括关于地点的信息(通过包括执行指定的动作时的某个角色和时间)。表5中呈现此类复杂句子的示例。
表1：解析的知识字节的示例
表2：置信度词
表3：规则表模式的正则表达式
表4：规则表模式的示例句子
表5：创建规则表时的示例复杂句子
角色表包含在实际故事开始之前已经发生的单个角色的描述和故事。它们是在利用动作中使用的解析方案的同时创建的。角色表允许编剧添加有关角色的更多背景信息，这些背景信息可能不一定在剧本本身中使用。此外，每个动作都被添加到指定的演员的角色系统，这允许角色表中包含的信息也将用于角色的推论能力。
图12示出可用于实现本文公开的系统和方法的各种特征的示例计算部件，例如，系统200和/或系统400的一个或更多个元件、其中可实现前端应用/ui202的用户设备、后端服务器210、数据资料库220、预览设备222、应用启动器428、ar部件432/vr部件434、nlp核心224等。
如本文所使用的，术语部件可描述可根据本申请的一个或更多个实施例执行的给定功能性单元。如本文所使用的，可利用任何形式的硬件、软件或它们的组合来实现部件。例如，可实现一个或更多个处理器、控制器、asic、pla、pal、cpld、fpga、逻辑部件、软件例程或其它机构来组成部件。在实现时，本文描述的各种部件可实现为分立部件，或者所描述的功能和特征可在一个或更多个部件之间部分或全部共享。换句话说，在阅读本说明书之后，如对于本领域普通技术人员明显的是，本文描述的各种特征和功能性可在任何给定的应用中实现，并且可以各种组合和排列在一个或更多个单独的或共享的部件中实现。即使可将功能性的各种特征或元素单独地描述或要求保护为单独的部件，但是本领域普通技术人员将理解，这些特征和功能性可在一个或更多个常见软件和硬件元件之间共享，并且此类描述不应该要求或暗示使用单独的硬件或软件部件来实现此类特征或功能性。
在使用软件全部或部分地实现本申请的部件的情况下，在一个实施例中，这些软件元件能够被实现为以可执行关于其描述的功能性的计算部件或处理部件操作。图12中示出一个此类示例计算部件。根据此示例-计算部件1200描述各种实施例。在阅读此说明书之后，相关领域的技术人员将明白如何使用其它计算部件或架构来实现本申请。
现在参考图12，计算部件1200可表示例如在自调整显示器、台式计算机、膝上型计算机、笔记本计算机和平板计算机；手持计算设备(平板计算机、pda、智能手机、手机、掌上计算机等)；工作站或其它具有显示器的设备；服务器；或者如对于给定的应用或环境可为可期望的或适合的任何其它类型的专用计算设备或通用计算设备中找到的计算能力或处理能力。计算部件1200还可表示嵌入在给定设备内或者以其它方式可用于给定设备的计算能力。例如，计算部件可在其它电子设备(诸如，例如导航系统、便携式计算设备以及可包括一些形式的处理能力的其它电子设备)中找到。
计算部件1200可包括例如一个或更多个处理器、控制器、控制部件或其它处理设备，诸如处理器1204。处理器1204可使用通用处理引擎或专用处理引擎来实现，诸如，例如微处理器、控制器或其它控制逻辑。在所示示例中，处理器1204连接到总线1202，但是任何通信介质可用于促进与计算部件1200的其它部件的交互或用于外部通信。
计算部件1200还可包括一个或更多个存储器部件，在本文简称为主存储器1208。例如，优选地，随机存取存储器(ram)或其它动态存储器可用于存储待由处理器1204执行的信息和指令。在待由处理器1204执行的指令的执行期间，主存储器1208还可用于存储临时变量或其它中间信息。计算部件1200可类似地包括只读存储器(“rom”)或耦合到总线1202的其它静态存储设备，以用于存储处理器1204的静态信息和指令。
计算部件1200还可包括一种或更多种形式的信息存储机构1210，其可包括例如介质驱动器1212和存储单元接口1220。介质驱动器1212可包括驱动器或其它机构以支持固定存储介质或可移除存储介质1214。例如，硬盘驱动器、固态驱动器、磁带驱动器、光盘驱动器、压缩磁盘(cd)或数字视频盘(dvd)驱动器(r或rw)，或者可提供其它可移除的介质驱动器或固定的介质驱动器。因此，存储介质1214可包括例如硬盘、集成电路组件、磁带、盒式磁带、光盘、cd或dvd、或由介质驱动器1212读取、写入或访问的其它固定介质或可移除介质。如这些示例所示，存储介质1214可包括具有计算机软件或数据存储在其中的计算机可用存储介质。
在替代性实施例中，信息存储机构1210可包括用于允许将计算机程序或其它指令或数据加载到计算部件1200中的其它类似工具。此类工具可包括例如固定存储单元或可移除存储单元1222和接口1220。此类存储单元1222和接口1220的示例可包括程序盒和盒接口、可移除存储器(例如，闪存或其它可移除存储器部件)和存储器插槽、pcmcia插槽和卡，以及允许软件和数据从存储单元1222传输到计算部件1200的其它固定存储单元或可移除存储单元1222和接口1220。
计算部件1200还可包括通信接口1224。通信接口1224可用于允许软件和数据在计算部件1200和外部设备之间传输。通信接口1224的示例可包括调制解调器或软调制解调器、网络接口(诸如以太网、网络接口卡、wimedia、ieee802.xx或其它接口)、通信端口(诸如，例如usb端口、ir端口、rs232端口蓝牙(bluetooth)
在本文件中，术语“计算机程序介质”和“计算机可用介质”通常用于指代暂时介质或非暂时性介质，诸如，例如存储器1208、存储单元1220、介质1214和信道1228。这些和其它各种形式的计算机程序介质或计算机可用介质可涉及将一个或更多个指令的一个或更多个序列传送到处理设备以用于执行。在介质上体现的此类指令通常被称为“计算机程序代码”或“计算机程序产品”(其可以计算机程序或其它分组的形式分组)。在执行时，此类指令可使得计算部件1200能够执行如本文所论述的本申请的特征或功能。
虽然以上根据各种示例性实施例和实现方式进行描述，但是应该理解，在单独的实施例中的一个或更多个中描述的各种特征、方面和功能性不限于它们对与它们一起描述的特定实施例的适用性，而是相反地可单独地或以各种组合的方式应用于本申请的其它实施例中的一个或更多个，无论是否描述此类实施例以及无论此类特征是否被呈现为所描述的实施例的一部分。因此，本申请的广度和范围不应受上述示例性实施例中的任一个的限制。
除非另有明确陈述，否则本文件中使用的术语和短语及它们的变体应被解释为开放式的而非限制性的。作为前述内容的示例：术语“包括”应当被理解为“包括但不限于”等含义；术语“示例”用于提供论述中项目的示例性实例，而不是其详尽或限制性列表；术语“一”或“一个”等应当被理解为“至少一个”、“一个或更多个”等含义；并且形容词诸如“常规的”、“传统的”、“正常的”、“标准的”、“已知的”和类似含义的术语不应被解释为将所描述的项目限制在给定时期或者如给定时间可用的项目，而相反地应该被解释为包括现在或将来的任何时间可获得或可知的常规的、传统的、正常的或标准的技术。同样地，在此文件涉及对于本领域普通技术人员明显或已知的技术的情况下，此类技术包括这些对现在或将来的任何时间本领域技术人员明显或已知的技术。
在一些情况下，扩宽单词和短语诸如“一个或更多个”、“至少”、“但不限于”或其它相似短语的存在不应被理解为意味着在可缺少此类扩宽短语的情况下意图或需要更窄的情况。术语“部件”的使用不暗指作为部件的一部分描述或要求保护的部件或功能性都在公用封装中配置。实际上，部件的各种部件中的任一个或全部，无论是控制逻辑还是其它部件，可组合在单个封装中或单独维护，并且可进一步分布在多个分组或封装中或横跨多个地点分布。
另外，本文阐述的各种实施例是根据示例性框图、流程图和其它图示来描述的。在阅读本文件之后，如对于本领域普通技术人员将变得明显的是，可在不限制所示示例的情况下实现所示实施例以及其各种替代性方案。例如，框图和其随附的描述不应被解释为强制要求特定的架构或配置。
- 还没有人留言评论。精彩留言会获得点赞！