对话同样要求玩家和角色双方交换信息。 玩家正在和谁说话？ 目前正在下雨吗？ 角色喜欢玩家吗？ 玩家可能会说些什么？
我以前使用JSON进行分层对话，但是需要对数据库做一些更复杂的操作以引入响应和回复。
游戏如何知道对话是否结束或应该在何时让玩家选择响应？ 最初我以为我可以坚持以与游戏知道角色应该感受到的情感相同的方式进行操作。 例如，以“ * sus *”结尾的对话允许游戏知道角色应该换掉他们的“可疑”面孔。 因此，也许我可以说出来，如果对话以“ * res”结尾，则应该允许玩家做出回应。
无论出于何种原因，这都会导致许多问题。 角色一次只能显示一种情绪，而分层的其他命令会使引擎感到困惑。
当前的解决方案更简单，在JSON中添加一个新字段“ response”，然后游戏会简单地检查此字段是否为空。 如果内容存在，则显示该内容。
下一个挑战是对话树。 给玩家多于一件事的话，您就开始分支角色响应的可能对话。
在我的上个游戏《 Kingdom Ka》中，我正在处理少量非常分支的对话。 特别是在第一次对话中，玩家与游戏本身进行了交谈，以说服游戏是人类。 我花了几天时间，提供尽可能多的对话分支，以使其保持自然和对话的感觉，从而允许在成千上万的可能路径中得出最终结论。
幸运的是，尽管“花园之路”将进行更多对话，但选项将大大减少。 Kingdom Ka是一个谈论话题的游戏，The Garden Path将是（其中包括）一个关于倾听的游戏。
播放器将始终显示三个选项。 第三个永远是“再见”（因为如果玩家想保释，我该阻止谁？）。 为了简单和易于管理，我戏弄了其他两个选择，它们只是一张开心的脸和一张悲伤的脸（是和否）。
但是，为什么要传递书面文本可以赋予的所有可能的味道呢？ 如果向玩家询问一个更哲学的问题，一个简单的笑脸突然感觉有点多余，或者至少有点太狭窄。
这两个选项中的绝大多数将询问角色是否愿意说话，或者询问他们是否有想要完成的任务。 总而言之，根本不需要一个允许庞大的对话树的系统。
因此，响应是一个字典，其中包含三个条目，每个条目包含一个包含以下数据的数组-文本所说的以及NPC应该响应的“类型”。 如果玩家想聊天，则游戏可以进行许多适当的对话中的任何一种。 如果玩家说“再见！” 如果愿意，我可以写数百种不同的告别消息，并且游戏中的角色会随机说一个。 如果响应更具体，则“类型”可以是唯一的标识符，因此将给出唯一的答复。
ew
我现在对此感到满意，但是我很兴奋，现在我处于一个理论上可以开始为游戏编写内容并将其放入其中的阶段。
