大家好，我是《长明火计划》当中另类卡牌游戏“招式对决”的主程暗黑Zero。
前两天我们的“招式对决”实机演示宣传视频正式发布了（没看过的请猛击《长明火计划》玩法部分实机演示），不知道大家对于这个小游戏的感想如何？作为这个小游戏的制作者，我想在这篇文章里给大家分享一下这个小游戏策划过程当中的一些趣事，以及我们是怎么把这个小游戏从0到1做出来的。
1. 从战棋，到自走棋，再到卡牌对战
不知道从什么时候开始，给AVG里面配上一个小游戏成为了一种特别流行的玩法，比如打个棒球什么的。这种配套的小游戏确实对整个作品的游戏性有很大的提升，于是给我们的正篇游戏搭配一个小游戏一开始就在我们的计划之内，也是最初我来到这个制作组的原因。
不过我们最初并没有打算做一个卡牌游戏，而是打算做一款战棋游戏。当时我还在上大学，然后有一天海马和Kyan把我拉到一个咖啡馆里，给我讲了一下午那个游戏怎么玩，在纸上画了一个棋盘，然后用扑克牌来代替卡牌，说这个游戏的机制是“绝妙的设想”，尽管我玩了一下午都没玩明白。（海马注：但是海马和Kyan当时沉迷这个游戏沉迷了好几周）最早期的这个战棋游戏大约是有一个5x5的网格棋盘，双方各有一个基地，然后每回合双方都可以出牌，牌分为攻击、移动、特技、人物四种，人物就是可以召唤一个角色到战场上，攻击、移动、特技就是选择一个人让他来干这个事，最后先把对方基地打爆的一方获胜。这个游戏其实设计得还挺是那么回事的，我也在读研摸鱼的时候已经把这个游戏做出一个能玩的版本了（甚至还能联机对战！），但后来随着项目的搁置（具体情况请猛击做个AVG能做上七年？游戏立项期的弱智操作盘点！），这个游戏也就不了了之，没有再继续进行下去。其实我觉得这个要是做完的话可能挺好玩的，不知道以后还会不会有机会继续把这个搞完。
之后再和海马谈到小游戏的事就已经是两年以后了，我知道他们还在做这个项目的时候其实也很惊讶，然后海马描述了一个新的自走棋的游戏设计。我没怎么玩过自走棋，不过我听完他讲这个玩法以后第一感觉就是“这我感觉还没有公主连结的竞技场好玩”，随后我们就达成一致——这不是一个好的设计。海马之后又提出过一些别的设想，但要不就略显单调，要不就实现成本过高。这时候，身为洛克人老粉的我突然想起了一个上古冷门游戏叫《洛克人EXE 芯片挑战》，我一直记得这个游戏的战斗系统很有意思，实现起来应该也很简单，我就跟海马说我们要不要参考一下这个游戏的玩法，做一个类似的卡牌对战游戏？然后我花了一晚上给海马讲明白了这游戏是怎么玩的，海马一听就被吸引住了。他觉得这个玩法框架不仅有趣且简洁，而且可供自由发挥的地方很多，于是我们的大方向就差不多定下来了。
一句题外话：因为这个游戏脱胎于《芯片挑战》，这也就是为什么我们有时候会口误，把招式叫成芯片的原因（笑。
虽然这是个超级冷门的上古游戏，但我们也不想完全照抄它的玩法，所以海马设计了一些新的玩法来使它变得更有趣（同时也让我的工作更难做x），从结果上看，是把这个玩法改到了“妈都不认识”的地步——比如在《芯片挑战》里所有人的招式树都只有同一种，但海马设计了好多种不同的招式树，而且还区分了4列和5列的招式树，引入了“对轴”的概念，玩法设计空间一下就大多了；《芯片挑战》里命中与闪避是随机的，海马引入了“集中力”的概念来减少过量的随机性给玩家决策带来的负面体验；以及最显著的变化是，在《芯片挑战》里芯片的路径是完全随机的，玩家没有决策空间，一旦放好了芯片就只能干看着，对局中唯一的动作就是召唤助战。海马和Kyan觉得这样玩家的参与度太低了，于是经过一系列尝试与模拟，最后提出可以提供两条随机路径让玩家选择，这样整个游戏的策略性一下子就上来了。
总体设计方案提出以后，大家都觉得这个游戏能做出来，而且玩起来也会比较有意思，所以最终我们就拍板决定搞这么一个“招式对决”小游戏了。
“招式对决”的实机画面
2. “招式对决”是怎么做出来的
确定要做这样一个类似于卡牌对战的游戏以后，制作prototype的任务就轮到我来操刀了。
要想在AVG的正篇故事之外做一个玩法相对自由的小游戏，挑选一个自由度高的游戏引擎就很重要。这个引擎一定要能够支持直接写代码，而不是只能实现显示对话，显示图片，播放转场等等事先定好的功能。我花了大概两天的时间调研了一下当时主流的AVG制作引擎，最后发现有一个叫做Ren'Py的东西看上去很有前途。我记得当时敲定这个引擎的一大原因是我发现我知道的好几款商业级别AVG就是拿这个引擎制作的，这说明Ren'Py这个引擎能够很好地支持一款商业级别游戏的出品。然后深入研究了一下，发现这个引擎实际上就是一个Python的上层语言，实际上调用的底层库是pygame，所以可以直接写python，甚至可以rpy和py混着写。那这就方便多了，做一个弹幕射击游戏都能做得出来。所以我和海马商量了一下就决定用这个引擎了。
然后要面临的问题就是，卡牌游戏要怎么做呢？在prototype阶段，海马先设计了大概20多个招式，但是我显然不能把这些招式给硬编码到游戏里，因为将来可能会扩展到100个、200个招式（事实上，现在真的有这么多），如果每一个招式都写一段代码的话，那这个游戏工程可就会立刻膨胀到无法维护了。所以，我回想了以前自己似乎用过一个叫做RPG Maker的东西，那个里面就是把各种数据都存在了一个单独的数据库里，以达到“数据与计算分离”的效果，这显然对我们的游戏也非常合适。所以我也采用了这样的设计思想，将所有的人物信息，卡牌信息，关卡信息等等都存在了一个数据库里，游戏本身并不存储数据，而只是会在启动的时候将数据库里面的内容加载进来。这样的好处就是当我们需要改动卡牌数据的时候（比如调整卡牌的攻击力、效果，增减关卡），完全不需要修改代码。这样也给我省了很多的工作量（笑）。此后我们设计的专精系统，必杀技系统，地下城系统，每一个系统归根结底其实就是一张数据库当中的表，只需要很少量的代码支持，这个游戏就可以扩展出非常多的玩法。这在游戏初期我们对玩法尚处于探究阶段的时候显得尤其宝贵，无论是什么样的新玩法，我们都可以很快制作出来然后试玩，并且以最小的代价做出调整，以将最好的效果呈现给玩家。
另一个问题是，如何描述这些卡牌的效果呢？每一张卡牌的效果都可以千变万化，既可以是“给对方造成15点伤害”这样简单的效果，又可以是“给对方造成15点伤害，给对方下一个招式造成1点信心度打击，此后3回合我方物抗+50%“这样复杂的组合效果。若是给每一张卡牌都单独写一段脚本，那就会引入很多的重复劳动，而且会让策划的改动成本很高：比如海马要是想给卡牌改攻击力，他必须读懂我的脚本代码才能改，而这样设计的后果就是所有做这种改动的任务都会落在我自己头上（……）；但另一方面，海马的想象力非常天马行空，因此我们又不能给卡牌简单地划分几个大类（攻击，打信心度，buff等等），然后规定一种卡牌只能干一类事，这样稍微复杂一点的效果就实现不了了。我后来参考了一下别的独立卡牌游戏制作的经验，就是建立一套自己的描述语言来描述卡牌的效果。比如“Attack: 15”就是“给对方造成15的伤害”，“Buff: Self, Defense+10%, 3 rounds”就是“给使用者增加一个防御+10%的Buff，持续3回合”。这样，只要我们的程序能够解析我们自己的语言并调用合适的代码，就能实现任意的卡牌效果。并且我们可以通过将几种效果任意地组合起来的方式来实现一张卡牌拥有多个效果的功能。这个东西的学名叫做Domain Specific Language（DSL）。这套系统在实现专精的时候也发挥了非常大的作用。
有了数据计算分离 + DSL的设计，我们的后续开发和迭代都轻松了很多。直到这个时候我才意识到，实际上我们做了一个基于Ren'Py的卡牌游戏引擎，其实是写在数据库里面的内容才真正定义了这个游戏。如果这样的工作让我们对于游戏本身的设计能更准确、更高效地呈现给玩家的话，那么我觉得这个小引擎的任务就算是圆满成功了。
我也想借此机会特别感谢Ren'Py的社群。如果没有他们的帮助，我们恐怕会耗费五倍十倍以上的时间来完成这个游戏。软件的生态和社群究竟有多么重要，这次我也充分地领教了这一点。
感谢大家的阅读，希望大家能够来支持我们的《长明火计划》，体验一下“招式对决”这款我们精心设计的“小”游戏！
暗黑Zero@唐扬Studio