《极乐迪斯科》:无知之幕的两面,在游戏里和玩家沟通

本文探讨了游戏《极乐迪斯科》中概率机制导致的玩家体验问题,批评了游戏设计中过于明确的成功概率提示误导了玩家预期,提出了游戏设计应通过机制一致性与意符一致性实现更好的玩家沟通,减轻无知之幕的影响。
部署运行你感兴趣的模型镜像


最近我在玩《极乐迪斯科》(Disco Elysium),这游戏确实有很多亮眼的想法,我也很享受游戏作家跟我玩的文字游戏。但从游戏设计角度来说,我认为它有重大缺陷。
 


展开说缺陷之前,必须先说说《极乐迪斯科》的核心玩法循环(Core Gameplay Loop)。由于游戏没有战斗,所以就是和各种NPC对话/环境交互,触发各种事件,事件会推进进程,但进程发展如何,要靠“掷骰”决定。

既然是“掷骰”,就涉及概率,而这游戏提升成功概率的方法就是完成事件/对话,获得升级点升级自己的技能。
 


为了让玩家能对掷骰结果心里有数,所以设计师们将成功概率直接写了出来告诉玩家。单独看这是个很好且常规的做法。

但当我在玩游戏5个小时后,连续碰到两次不同的成功概率大于80%,却还失败的掷骰结果,我觉得被游戏玩了,所以很不爽。后来我思考不爽的情绪是怎么产生的,发现这款游戏和玩家之间的沟通出了问题。

在游戏设计的过程中,策划会头疼一件事:我该如何在保持不确定性的基础上,让玩家对结果大致心里有数?

我把它称为游戏设计的“无知之幕”。
 


这个问题在很大程度上影响玩家情绪,所以它值得被讨论、解决。

游戏设计的无知之幕

1971年政治哲学家约翰·罗尔斯提出了一个思想实验,叫“无知之幕”。意思概括说就是制定规则的人,和被规则约束的人,中间就像隔了一片幕布一样。制定规则的人看不到幕布另一面的人都是怎么样的。而被规则约束的人,也不知道自己的命运会是如何。所以在制定规则时,为保证公平,应摒弃对于当前社会的认知。

在游戏设计中,无知之幕一面是游戏策划;另一面则是玩家。

对于政治哲学来说,摒弃对当前社会的认知是解决无知之幕的方法。但对于游戏来说,和玩家沟通,帮助玩家了解未知的可能性,才是无知之幕的解决方法。

如果游戏内没有提示和教学的话,玩家完全不可能预知自己的行为结果。这时候玩家那一面的无知之幕就出现了。

作为规则制定者,游戏策划要保证公平性。公平性不是一味偏袒某一方,这就意味着玩家不可能次次都获利。玩家总会受挫。但我发现,对于玩家来说,并不是惩罚和受挫会让人觉得不公平。而是当挫折和惩罚来临时,玩家不知道、未预期,才会觉得不公平。所以游戏处处需要铺垫,需要设计提示,设计教学。

提示和教学该怎么设计是个技术活,也是我在这里说的沟通问题。

游戏策划有责任帮助玩家建立对于游戏的正确预期,大到游戏主题,小到具体某个抉择。

像《极乐迪斯科》在掷骰之前,告诉了我成功的概率有80%之高,还特别用文字告诉我,这是个高概率成功的事件。但最后我还是连续两次栽在高概率成功的事件上。这个过程就是在给玩家建立错误预期。
 


这主要是游戏没有给随机数加规则限制的问题。但另一方面,游戏开发者在用“真随机数”的情况下,依然用常规方式告诉玩家概率有多高,误导了玩家,这是技术性失误。和《Xcom》的错误相似。
 


其实这款游戏还有很多很多类似的误导。但我不想把文章写成《极乐迪斯科》的评论文,所以其他的都先不讲。

那怎么样才算是正确和玩家沟通,并建立预期呢?

很多策划一想到和玩家沟通,就想到用文字,或者限制玩家行动的强引导。但良好的游戏沟通要依靠机制和意符。

这就是我要讲的主题,用游戏的方式和玩家真诚沟通,减轻无知之幕的负面影响,让玩家能对自己的每一步行为有正确的预期。

要做到真诚沟通,主要涉及两点,机制的一致性和意符的一致性。

机制的一致性

机制的一致性,并不是顺拐,不要求所有机制都只有单一或固定结果。而是先要预判一个或多个机制(联合)产生的结果,然后考察其影响是否都一致。

比如“塞尔达传说”系列,炸弹的用途多种多样,可以伤害敌人,可以炸碎不牢固的石块,同样也能炸伤玩家自己。这个机制的影响是一以贯之的,即玩家可以利用炸弹获利,但也可能误伤自己。

要是你给“塞尔达”设计一个扔炸弹的怪,那怪的炸弹和怪之间的关系该如何呢?

当然应该是连怪也能一起伤害了。

这样玩家就能因为事前学到的知识(炸弹是不分敌我的),而自然而然开发出引导怪被自己的炸弹炸到的战术。这就是玩家的“Aha!”时刻。

但反过来,如果怪物的炸弹无法伤害怪物自己,就会给玩家一种认知错乱的感觉。虽然很短暂,玩家会及时调整认知,但这是个负面影响,买手机靓号累积多了就会爆发大不满。

意符的一致性

意符是一个设计名词,指的是在物品的某个方面,具有让人明显知道该如何使用它的“符号”。而通过意符使设计可视化是非常重要的。

在工业设计领域有一个很有名的案例。我管它叫“推拉把手问题”。


上图是我们常见的推拉门。这么看,你可能觉得没问题。但如果这样呢:
 


不写字就不知道哪个是拉哪个是推。从工业设计角度说,这样的设计缺乏意符,是有问题的。下图的设计就更具有意符,即使不用文字大家也能知道哪面推哪面拉。
 


像这种意符问题,在日常生活中可能不会暴露,但在紧急情况下会出现危险。所以现在逃生门的门把都设计成了推动条,这是符合逃生者的预期行为和意符的设计。
 


说回游戏设计。游戏里的意符是通过特殊的视效,比如布局、灯光、外形等展现的。

在高层游戏设计里,利用目标和障碍表达出玩家可用的选择,就是意符的作用。
 


比如上图(《Dishonored》)用两个敌人和各种看上去能走的路,来帮助玩家建立目标和对行动路线的预期。

在底层游戏设计里,意味着一个东西要根据其功能作用,有相关的外形设计。

比方说能被玩家打开的门看上去就应该能被打开,不能被打开的门看上去就不能被打开。
 


上图左边的门被封的很严实,一看就不能打开,探索型玩家就不用走冤枉路去开它了,避免了负面情绪。而以后玩家遇到类似的门,也要是不能被打开的。

这里虽然分开讲了意符和机制,但这两者其实高度相连,设计时应考虑两者间的联系。

比方说同样是上文说的“塞尔达”的炸弹怪。如果把炸弹或者怪的外形特殊设计一下,即使炸弹不会炸伤怪,玩家也不会有不好的体验,因为不寻常的外形代表新的东西。既然是新的东西,就不会干扰旧有的认知。

结论

一款缺乏沟通,或沟通前后不一致的游戏,会导致玩家不再信任策划给出的提示,加重叛逆情绪,更大概率做出策划预料外的“跳桌行为”。而一款到处充满提示文字、强引导的游戏更会显得啰嗦臃肿。

不要轻易打破玩家已有的认知。用游戏的方式,和玩家保持沟通才是游戏乐趣的体现,获得的反馈也更准确。

您可能感兴趣的与本文相关的镜像

Linly-Talker

Linly-Talker

AI应用

Linly-Talker是一款创新的数字人对话系统,它融合了最新的人工智能技术,包括大型语言模型(LLM)、自动语音识别(ASR)、文本到语音转换(TTS)和语音克隆技术

<think>我们正在讨论使用Fungus插件在Unity中实现类似《极乐迪斯科》风格的对话系统。根据引用[1]引用[2],Fungus是一个用于创建对话系统的可视化插件,它提供了对话流控制、角色对话绑定、对话显示等基本功能。《极乐迪斯科》的对话系统特点:1.复杂的对话树:对话选项会根据玩家的技能、状态、物品等动态变化。2.技能系统:技能(如逻辑、共情等)会影响对话选项的出现成功概率。3.内心独白:角色内心的多个声音会以对话形式呈现,并与技能关联。4.叙事深度:对话选项会导向不同的故事分支,具有较高的自由度。分析Fungus的能力:1.Fungus的核心是流程图(Flowchart)对话块(Block),可以构建分支对话树。2.Fungus支持变量(包括布尔、整数、浮点数、字符串),可以存储技能值、物品状态等。3.在对话文本中可以使用条件语句(If)变量替换,从而根据变量值显示不同的选项或文本。4. Fungus提供了自定义命令的能力,可以通过编写C#脚本来扩展功能。实现可行性:1.基本对话树:Fungus的流程图可以轻松实现分支对话。2.动态选项:使用条件判断(If命令)来控制选项的显示。例如,当某个技能值达到一定数值时,才显示特定的选项。3.技能检定:在对话选项的执行中,可以调用自定义命令来执行技能检定(随机数+技能值),并根据结果跳转到不同的分支。4.内心独白:可以创建代表不同技能的对话块,根据技能值的高低决定是否触发这些块。需要扩展的部分:1.复杂的技能系统:Fungus本身没有内置的技能系统,需要开发者自己设计技能变量检定机制。2.状态影响:玩家状态(如醉酒、受伤)也需要作为变量存储,并在对话条件中检查。3.对话选项的动态隐藏:Fungus的条件分支可以隐藏选项,但需要手动设置每个选项的条件。结论: Fungus可以实现类似《极乐迪斯科》的对话系统,但需要开发者进行较多的脚本扩展变量管理。对于复杂的技能检定状态系统,可能需要编写自定义的Fungus命令来集成。具体实现步骤建议:1.使用Fungus的变量系统创建代表技能状态的变量。2.在对话块中,为每个选项添加条件判断(使用If命令),检查技能值或状态是否满足。3.对于技能检定,创建一个自定义命令,该命令接收技能名称,然后进行随机数检定,并将结果存储在变量中。然后在对话分支中根据检定结果跳转。4.内心独白可以通过多个并行的对话块实现,当满足条件(如技能值达到)时,执行对应的对话块。注意:由于《极乐迪斯科》的对话系统极其复杂,完全复制其所有功能将非常耗时。但Fungus提供了足够灵活的工具来构建核心机制。相关问题:1.如何在Fungus中创建自定义命令?2.如何管理大量的对话分支以避免混乱?3.Fungus能否处理《极乐迪斯科》中那种多个技能同时影响同一个对话选项的情况?</think>基于Fungus的功能特性极乐迪斯科》对话系统的核心机制,以下是可行性分析及实现方案: ### ✅ 可行性分析 1. **对话树与分支逻辑** Fungus的**流程图(Flowchart)系统**可完美实现《极乐迪斯科》式的多分支对话树。通过添加`If`条件命令**变量系统**(如`Boolean`/`Integer`变量),可动态控制选项显示: ```csharp // 示例:根据智力技能值解锁选项 if (flowChart.GetIntegerVariable("INT") >= 5) { flowChart.ExecuteBlock("隐藏选项_解密线索"); } ``` 2. **技能系统集成** 通过Fungus的**自定义命令**扩展技能检定: - 创建`SkillCheckCommand`类继承`Command` - 在`OnExecute()`中实现骰子机制: ```csharp public class SkillCheck : Command { [SerializeField] string skillName; public override void OnExecute() { int skillValue = flowchart.GetIntegerVariable(skillName); int dice = Random.Range(1, 101); bool success = (dice <= skillValue); flowchart.SetBooleanVariable("CheckResult", success); Continue(); } } ``` 3. **角色内心独白** 利用**角色绑定功能**实现: - 创建"理性"、"感性"等虚拟角色 - 在`Say`指令中切换不同角色头像文本颜色 - 通过变量控制独白触发条件(如`flowChart.GetBooleanVariable("酒精中毒")`) ### ⚠️ 需扩展的功能 1. **UI深度定制** 《极乐迪斯科》的环形菜单需重写`SayDialog`: - 继承`SayDialog`类重写`SetCharacter`方法 - 使用UGUI实现放射性选项布局 ```csharp protected override void SetCharacter(Character character) { // 自定义角色头像位置对话气泡 } ``` 2. **叙事状态同步** 需要外部脚本管理全局状态: ```csharp public class NarrativeState : MonoBehaviour { public Dictionary<string, int> Skills = new(); public List<string> UnlockedConcepts = new(); void SaveToFungus() { var fc = Fungus.Flowchart.Find("GameFlow"); foreach (var skill in Skills) { fc.SetIntegerVariable(skill.Key, skill.Value); } } } ``` 3. **实时检定的动画** 使用**Unity动画系统**配合Fungus: - 创建骰子旋转动画 - 在自定义命令中触发`Animator.Play("DiceRoll")` - 动画事件回调检定结果 ### 📊 实现评估 | 功能 | Fungus原生支持 | 需扩展程度 | |---------------------|----------------|------------| | 分支对话树 | ✅ | ⭐ | | 变量驱动选项 | ✅ | ⭐ | | 技能数值存储 | ✅ | ⭐⭐ | | 动态检定机制 | ❌ | ⭐⭐⭐ | | 特殊UI布局 | ❌ | ⭐⭐⭐⭐ | | 多线程叙事状态同步 | ❌ | ⭐⭐⭐ | ### 💡 结论 **Fungus能实现70%基础功能**,尤其擅长分支叙事变量管理。但需通过以下扩展实现《极乐迪斯科》特色: 1. 编写5-10个自定义命令处理技能检定 2. 重构`SayDialog`的UI布局 3. 开发外部状态管理器同步数据 4. 结合DoTween实现骰子动画 > 推荐方案:**Fungus核心+自定义C#模块**,既能利用可视化编辑优势,又能满足复杂机制需求[^1][^2]。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值