大家好，我是《長明火計劃》當中另類卡牌遊戲“招式對決”的主程暗黑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