游戏：Superconductor

作者：@indiebard‍ , @落葉子‍ 

链接：https://ldjam.com/events/ludum-dare/47/superconductor

主题

这次LD的主题是stuck in a loop，我在投票选主题的时候给它投了中立（不支持也不反对），没想到最后选上了。当时很害怕选出一个不能做解谜的主题，因为最后一轮投票里和解谜相关的主题大多都惨败，能选上stuck in a loop对我而言算是很幸运了。

拿到这个主题一看，第一反应就是非欧空间，各种从屏幕左边出去从右边进来，但预料到这种想法会烂大街（最后果然好多人都做这个）。之后想到了一个光学解谜和音乐结合的想法。之前有过光路和音乐结合的例子（典型的就是Micron这个游戏），运动的粒子碰到反射镜的时候会拐弯并且发出乐音。 如果我们要求最后组成的光路是个回路，那么对应的音乐就是一个music loop，这时loop就双关了。

因为我搞不定音效这块所以去找了一个音乐大佬 @BLumia‍ 帮忙，顺手写了一下整个游戏的机制草稿（写给大佬看）。但写的时候越写越觉得不对劲，这东西真的能设计出关卡吗。边写的时候边开始做像素图块（光导箭头，发射器的图案），然后扔到Tiled这个软件里做地图。之后慢慢意识到问题很大，如果要保证足够的音乐性就要丧失解谜的灵活性，反之亦然。这个矛盾不是两三天之内就能解决的。

下午突然就有了一个新的机制想法，就是最终demo里我们用的这个机制。能想到它，起因有二。一是在想如果删掉这个音乐光学游戏里音乐的部分，尽量简化机制，可以得到什么。二是如果我们反过来想这个问题，不是让玩家“构建”一个loop，而是原来就有一个loop在让玩家来“维护”，会不会有意思。

因此机制的雏形就有了：开始的时候光构成一个回路。光转折的地方是由transmitter（游戏里用箭头简化表示）控制的。每次操作可以改变一个箭头的方向，但光必须仍然构成回路。

然后游戏的名字也有了，因为构成回路的无限能量容易让人想到超导体。

找苦力

这里不说找队友而说找苦力是因为感觉自己无法维持一种稳定的游戏制作伙伴的关系，因此只能临时找人帮忙。想找的原因有二，一是可以让自己更有动力，二是可以在设计关卡的时候注入多种不同的角度。

我最先尝试联系的是 @落葉子‍ ，是在见证者解谜游戏群里认识的一个大佬。在见证者群里大家有互相出新题的习惯，落叶子出的题并不多，但其中有两道让我觉得特别惊艳，不是两道难题，而是非常think outside of the box的那种题。这是在设计解谜里非常重要的，在已有机制里寻找可以突破的口，创作让人惊艳的关卡。最后证明我并没有找错人，最后落叶子出了几道不错的关卡。感谢大佬。

关卡设计

设计逻辑解谜的关卡，本身更像是在解一个更meta的谜题。目前感觉在这一过程中至少有两层不同的解谜层次：

1. 设计一个关卡，是一个解谜的过程。首先要保证关卡有解，排除特别非预期的解法，这是基本要求。如果没有达到这个要求，则还要想办法看怎么调整能让它有解。更上一层楼的要求：怎么把一个关卡做的有美感（比如对称）又不失难度？另外，精简的关卡一般比复杂冗余的关卡更出色：那些“小而难”的关卡往往是一个紧凑的解谜游戏的亮点。构造这种关卡本身就是一个极具挑战的谜题。再上一层楼，怎么设计合适的提示和逻辑陷阱？

2. 探索已有机制，是一个meta解谜的过程。这点很像Jonathan Blow等大佬特别强调的，首先关卡设计者要自己去探索、反复把玩这些机制，把收获的成果凝练之后用用关卡的形式呈现给玩家。做法有很多，比如在关卡编辑器上随便涂鸦，看看有没有原本没想到的机制组合使用方法；在已有关卡上增删一些东西，看看有没有新的意料之外的解法。有时还可以引入其他解谜游戏的context，比如能不能用自己的机制去实现别人的功能，Baba is you那类解谜比较喜欢做这种事情。

其实更上面应该还有一层，就是怎么挑选、引入、调整新机制。但这个我还没什么体会，因为做这种游戏做的还不够多。

第2点是非常重要的。玩别的解谜游戏玩多了，很容易感受到那个作者有没有吃透自己的机制。吃透了自己的机制，往往一两种机制就能玩出花来（随便举两个好的例子就是Stephen's Sausage Roll和Recursed）。没吃透自己的机制，往往一两个机制只能设计很肤浅的两三关，然后必须引入新的机制才能继续。一整个游戏下来动辄引入几十个新机制，而机制和机制之前又没有什么强的联系（机制太多时，有的机制之间还会互相矛盾，增加游戏bug的可能性），这种解谜游戏好评的概率极低。

为什么要强调设计解谜的过程本身也是一种解谜？有两点原因。一是，我们需要训练玩解谜的能力，类似的也需要训练做解谜的能力。这不是一朝一夕就能完成的事情。二是，要享受制作解谜的乐趣。如果你不喜欢玩解谜游戏，那么很遗憾你不适合制作解谜。另一方面，如果在设计解谜的时候体会不到一种“类似于玩解谜的乐趣”，那说明制作者还没有掌握合适的解谜设计方法，或者说这个解谜机制本身很不合适，应当反省。

解题器

最近逻辑解谜界有以Dis Pontibus作者Marcos Donnantuoni为首的一个算法辅助谜题生成的派系。其要点就在于把关卡设计和机制探索的任务全部地或者部分地交给机器来完成。其核心包括一个谜题生成器和一个解题判别器。这个想法鼓舞了我很多，以至于我第二天上午的时候用C++写了一上午解题器。写是写出来了个雏形，已经能解简单的题目了，但下午的时候突然想引入一个推箱子的机制，但推箱子的状态数多到爆炸，程序无法承载，于是就没写下去。

写关卡生成器和解题器到底必不必要？答案是否定的，因为有的逻辑解谜根本写不出高效的解题器或者生成器。但有没有帮助呢？答案是，对于某些解谜游戏确实有。其中一点就是，算法确实能帮我们探索机制。Marcos认为这点非常有益。

之前我在见证者群内出题的时候也用到了类似的技巧，我们给见证者游戏里的每个符号设计了一套新的机制，然后首先我们用编程实现这套机制的判定和求解（照着https://witnesspuzzles.com/ 的开源代码改的），这时关卡设计就变得相对高效了，每次修改关卡之后立刻就能知道是否有解。我会刻意把解给隐藏掉，只让程序返回”有解“或”无解“。有解时再去自己尝试解这个题，这样也能更好的判断这个题的难度。

但是在这次Ludum Dare中这个解题器最后没有用场。目前的算法还支持不了这么复杂的关卡生成和判别。

业界

独立游戏现在赚钱很难，解谜游戏赚钱更难。之前Steam游戏节有过统计，解谜这个大类是Steam游戏节收益最惨淡的一类（这里的收益指游戏节通过Demo展出而获得的愿望单增量）。大厂不愿意扶持解谜，The Talos Principle算是罕见的特例。Recursed算是非常精品的独立解谜，但到现在都收不回本。

做解谜最主要的动力，从外界的压力来看，只能来源于自己。上面说的一点“要享受制作解谜的乐趣”这点就很重要了。

做ludum dare本身也差不多，ludum dare本身不看好解谜，打分的时候大部分玩家也不喜解谜。主要参赛的动力需要来源于自己。说服自己去做一件事情是最困难的。如果自己做的游戏不是自己喜欢的，那就不要做。

我没有强迫自己做一个ludum dare 的作品。我只是很喜欢在第一天下午想到的这个机制，享受了一次探索机制的乐趣，并且最终把它整理成了这个Demo。如果没有这样的想法，我可能就不提交了。

游戏编程

解谜里编程的重要性一般低于关卡和机制设计。当然这次我们采取了更简单的做法，那就是完全不写流程代码而偷懒使用PuzzleScript。之前学了点Godot和Love2D仍然感觉手生，并且感觉时间不够，并且在第一天下午想到新机制后经过一顿胡乱分析觉得可以用PuzzleScript实现，因此就用了PuzzleScript。

PuzzleScript的优势在于超级快速的开发，劣势在于音乐，音效，画面分辨率和自定义操作这几项都完蛋了。

写的时候遇到最大的问题就是光路的逻辑实现。把光从一个回路移动到另一个回路的过程，简单的说就是不断直线延长光的“头部”，碰到箭头转弯，直到遇到已有的光路，就判定形成了一个环。那些不在新的“回路”里的光需要消失，消失的方法就是让光的“尾部”不断消失，直到回路里有光照射到这个“尾部”即可。

这个很直观的想法是有问题的。如果光从一个小回路流入一个大回路，因为头部“增长”的速度和尾部”消失“的速度一样快，光的总长度不会变，因此光永远不会填满这个大回路，而是在大回路里面死循环打转。解决的方法就是让头部“增长”的速度快于“尾部”消失的速度。

这其实跟一个算法面试题差不多，怎么样不用辅助空间去在一个链表里找环，解法就是让一格指针走的快一个指针走的慢。原本对这种根本不优化复杂度的算法不抱有好感，但没想到确实在编程语言受限（PuzzleScript更类似于基于规则的自动机）的时候的确用的上。