Move Code Lines

《Move Code Lines》，顾名思义，是一款要求玩家通过“移动代码行”解谜的游戏。
本作的每个关卡会给出一段被打乱的程序，玩家需要将这些程序重新摆回正确的顺序，来生成和给定的目标一致的输出。本作具体使用的编程语言类似Python这样的高级程序设计语言，随着游戏进行，本作会逐渐引入函数、分支、循环、递归等现实编程中的概念，在后续的关卡中甚至还会引入输入，此时玩家不仅需要拼好程序，还要提供合适的输入样例，才能得到符合目标的输出。
总体而言，我对本作的看法有好有坏。接下来就先说说本作的一些优点吧：
优点——优化解谜体验
如果玩法就是上面描述的这样，那自然就会有一个问题：如果遇到代码行数很多的乱序程序，那玩家很难仅凭输出和打乱的代码就看出来这段程序原本想做什么。可是如果限制代码行数本身，那么谜题设计的可能性就会大打折扣，所以本作选择通过其它方面的设计来帮助玩家理解谜题的意图：
1 (1). 本作对“程序可以怎么打乱”作出了限制：将整个程序用若干空行分隔，任何代码行无论怎么打乱，也无论玩家怎么移动，都不会离开它上下最近的两个空行之间，大大限制了打乱的可能性。
1 (2). 同时，这种对打乱作出的限制让整段程序有了明显的顺序分段，于是中间就可以夹入一些更简单的“测试样例”。比如一个程序是这样组织的：乱程序段A之后有一个输出，然后是乱程序段B，再有一个相关的输出。在这个例子中，第一个输出只和它前面的程序段A有关，而本作会将这个输出设计成某种“测试”，以至于只要这个输出的结果正确，就能够验证A结构的正确性。这样一来，玩家就可以合理地将整个谜题划分为多个小谜题，并分而治之。
2. 有时，输出中也会有一些特殊的分段标识，用来表示需要被多次执行的循环体/函数体的开始/终止，这种标识会给输出分段，这样玩家就知道哪些输出是要在循环体/函数体的一次执行之内生成的。
3. 即使程序被打得很乱，很多时候玩家也可以根据正常程序的结构限制来推断一些关键结构的位置，像是变量要先声明后使用，变量只能在对应的定义域里使用，大括号要配对这样的事实会很有用。
4. 在很多谜题中，变量名、函数名也往往暗示/明示了对应的变量/函数的功能。
5. 有些基本函数（比如从输入读一个向量/数组）只有在第一次出现时需要玩家去拼，在后续的谜题中就会直接以正确的顺序给出，玩家不需要再拼更多次。
不过即使本作在优化解谜体验的方面作出了努力，接下来还是要说到我认为本作的一些，不能说一定是“不足”吧，至少也是值得探讨的问题：
问题1——对外界知识的要求
我玩过许多有编程要素的游戏，尤其是Zachtronics的作品，虽然你可以说只有学过编程的玩家才会想去玩这种游戏，但无论怎么说，那些作品好歹还是加入了类似手册的教程，用来解释其中使用的虚构语言，这对不管接没接触过编程的玩家都是重要的参考资料。然而这种“教程”在本作中不能说不存在，只能说很少。我认为如果让一个完全没有接触过编程相关知识的玩家来玩这款游戏，那基本上是不太可能。
而我所说的“外界知识”并不只包含“编程知识”。事实上，本作的一些谜题还需要你有一些数学和算法相关的知识才能比较好的理解。比如某一个谜题涉及计算最大公因数的欧几里得算法（辗转相除法），这就需要你同时知道“最大公因数”是什么，“辗转相除法”是什么，以及怎么构造这个谜题要求你构造的东西（要求输入两个数a、b，满足和为c，最大公因数是d）。这些在游戏里完全没有教学或者相关铺垫，我觉得一个没有这些知识的玩家，想要在游戏中直接根据那一点信息猜出来这段代码的作用并最终完成谜题，是有困难的。
其实单独是对外界知识有要求这一点，在我看来并不直接算是“缺点”。我承认也有人喜欢具有对外界知识要求的解谜，这也是一个值得探索的方向，即使我自己从来都不算特别喜欢这样的游戏。要知道为什么我将其列为“问题”，还需要结合下一节来看：
问题2——谜题设计
总体来说，我认为本作的谜题中有太大一部分重心从本作的“核心机制”——“移动代码行”——偏离了出去。
本作中很多谜题都分为以下几个步骤：拼程序、理解程序、构造输入。“拼程序”这一步骤基本都没有难度，只要拼出一个“正确”（能通过编译）的、能够用到所有语句的程序，差不多就一定是对的了，这还得“归功于”本作在上述“优化解谜体验”一节所做的事情。没想到吧，之前所说的“优点”在这居然反转了，只能说在一个游戏的设计里，没有任何一个设计是孤立的，也没有任何一个设计是绝对好或者绝对不好的。而在拼出程序之后，理解它的功能一般都不难，很多时候程序本身甚至是经典算法的实现，比如BFS（广度优先搜索）。于是就只剩下“构造输入”这一步是可能的出题点了。
我先不评价本作这些“构造题”的质量，就单纯看看我上面的描述，读者可以想一想它有什么问题。提示一下，本作的标题是“Move Code Lines”（移动代码行），这本应该是本作的核心创意、核心机制，结果你告诉我它在很多谜题里基本不属于需要特别考虑的东西？啊？既然这样，那为什么不干脆去掉这些无所谓的挪移，转而专门做一个根据程序和目标输出构造输入的游戏，叫做“白盒测试”什么的？
哦，原来是有原因的：在本作的最前几章和最后几章，有一些关卡确实是以“移动代码行”为重心的。在这些谜题中，可能有很多种方法能排列出一个能过编译的程序，但这些代码行的具体顺序才是影响整个程序输出的关键：函数、循环、分支这些，摆放得有一点不同，代码行运行的顺序和次数就会发生很大变化。这些程序也一般不是要实现什么很具体的、能抽象为更高层逻辑的功能，单纯就是为了谜题而设计的。通过仔细思考代码的执行流（就是“运行顺序”的学术说法），推理出每个代码行要放在哪里，才能以正确的顺序和次数运行，进而生成出正确的结果，在我看来是独属于“移动代码行”这个核心机制的可能性。12-5在我看来就是一个很不错的这样的谜题。
然而这样充分利用本作核心机制的谜题在本作中实在很少，在引入的编程概念足够多之后，本作的谜题设计几乎全部转为了本小节一开始所提到的“套路化”谜题，在我看来实在是遗憾。
如果我们不管这个所谓的核心机制，就把“输入构造”当成本作的核心玩法，那本作的这些谜题又做得如何呢？我承认，这种“逆向工程”有时还是挺有意思的，但很快我就意识到，有些问题感觉只能通过“瞪眼法”（直觉）或者“枚举”（试错）来得到答案，其中有些甚至需要我动用“场外援助”，比如计算器、方程组解题器等数学工具，甚至我自己写的Python枚举程序（13-4和13-5这两关）。
我是不太清楚这些谜题不枚举的话要怎么做出来。如果真的设计之初就是想让玩家利用场外工具解题，那也算是一种探索方向，比如一些谜题中用到计算器也只是为了辅助计算，构造的思路还是要自己思考的。但个别需要自己写程序枚举的谜题，就是要玩家自己把游戏本身给的程序重写一遍，然后再在外面套一层枚举程序，这我就实在看不出来有啥独特的挑战性。
再换一个角度，如果把本作当成一个以教学编程知识，而不是设计出“Eureka”（顿悟）时刻，为目的的“教育游戏”，那前面的“对外界知识的要求”就又说不通了，对于完全不懂的玩家，我认为不太可能在本作开启ta的编程学习之路，而对于我这样有编程经验的玩家，本作的编程难度只能说是浅浅的“复习”，好像哪边都没讨好。所以，退一万步讲，本作好像只适合用于给编程新手“巩固”在外界已学的知识。好吧，搞了半天，我可能并不是本作的目标受众。
其它问题
其实这个问题不足以再凑一段了，但是还是想要说一下。
本作不保存每一关的进度，无论是程序顺序，还是已经构造的输入。你要么一打开一关就坚持把它做完，要么就得用其它办法记录你的进度，对于后期一些复杂的谜题来说比较尴尬。
总结
总的来说，我认为本作是一款自我定位比较混乱的解谜游戏，很多设计都让我感觉“两头不到岸”，处于一种尴尬的中间状态。以“移动代码行”为标题和核心机制，但大多数谜题的重心却不在这上面，而是在“构造输入”上；可能想要让玩家通过场外工具解谜，但却没有设计出来让玩家感觉这么做很巧妙的谜题；可能想要在某种程度上做一款“教育游戏”，但缺乏系统教程，试图让玩家自己领悟的设计又不太能说通，对真正有编程经验的玩家来说又有点太简单了。最终本作给我的观感就是，有一些想法，但是没有把这些想法组织起来进行系统探索的能力，和我玩过的这位作者之前的一个作品《Markov Alg》在我看来问题差不多。
不过我认为虽然本作整体的设计方向混乱，但还是有一些有意思的单个谜题的，所以最终我还是选择给出下面的结论：
可以推荐。

更详细的讨论同样去看老船长的评测吧，这是我简单体验这个作者的第三款游戏。
和另一款Escape hard driver比较接近，比较简陋的UI，沾编程元素，需要有相关基础知识才能游玩，游玩方法也不是直接编程，同样差点意思。