方塊世界（Tetris World）是在嘗試 fantasy console 的過程中實現的一個小作品，雖然小，但是在體驗上進行了仔細考量，這裡將設計過程記錄成文。
起源
差不多去年這個時候，我開始涉足遊戲開發，並在機緣巧合之下選擇製作一款俄羅斯方塊的變種，採用的是捏合不同類型遊戲的思路。由於想捏和的東西越來越多而開發只能在部分業餘時間進行，這個項目斷斷續續進行了一年還尚未完成。在大概 9 個月的時候，我漸漸覺得這種捏和的方式未能回到交互和體驗的本源上來考慮問題，創新性還是被類型遊戲侷限住了。也大概是那個時候，突然有一個場景浮現在我腦中：一片開闊的原野上，若干俄羅斯方塊緩緩飄落。這個場景的氣氛與當今越發競技化的俄羅斯方塊迥然不同。大概 1 個月前我在讀 indienova 的博文時發現了 fantasy console 這一門類，把玩之下發現似乎頗為適合實現這個創意，出乎意料的是，這個遊戲很快地做完了。
設計
遊戲的核心即為上文所述的場景，體驗上要足夠放鬆，可以相對佛系地遊玩。首先確定的是需要寬大的地圖，並可能同時下落多個方塊，為了在這個前提下維持俄羅斯方塊的玩法，有兩個問題必須首先解決：1. 如何切換方塊？2. 如何在寬大地圖下消行？問題 1 彷彿比較簡單，只需要增加兩個切換按鈕就可以了，問題 2 比較核心：由於行太長，實在是太容易發生失誤了，而一旦失誤想通過消上面的行來補救幾乎是不可能的，解決這個問題是遊戲能夠成立的關鍵。
方塊實現
在解決兩個核心問題之前，我先確定了方塊實現的方案。一般用 Tilemap 實現俄羅斯方塊，都會把每種方塊建模成四個 Tile 的組合，在 TIC80 裡這意味著一個方塊會有 24 或 32 個像素寬。由於 TIC80 總共只有 240x136 的分辨率，這顯然會使得地圖顯得很小。為此，我將方塊建模成四個 2x2 方塊的組合，這樣地圖尺寸就大大擴大。在這種邏輯下，我捨棄了原先以 Sprite 為單位的 Tilemap 計算，全部採用像素運算與操作，特別是寫了碰撞檢測的邏輯。
我曾經糾結於多個方塊在空中的碰撞問題，為此設想過多個方案都既不好玩又不好實現，最後決定專注核心體驗避免複雜性，乾脆在空中不做碰撞。
降雪機制
在早期設想的時候我曾經考慮過小精靈這個概念：小精靈定期出現，搬運方塊幫助玩家填空。然而這個概念並不能在我腦中形成一幅和主場景相容的畫面，顯得非常刻意。我也考慮過別的機制，比如特殊方塊可以形成有耐久的圍欄，允許在局部形成更短的行並消除，又比如在 t-spin 等接觸面積大於一定值的落地事件時觸發同色消除等。但最後我覺得這些都太複雜了，“穿透”成為最可行的關鍵詞，在考慮了幾個穿透物的方案後，我回到了最初的比喻：既然方塊像雪片一樣從空中落下，那雪花便是最合適的可穿透降落物。在試玩的過程中，從最低空隙開始堆積的雪花確實能衝抵大地圖帶來的問題。此外，降雪單純隨時間遞增的效用使得玩家即使不做操作也可以慢慢消行，加上融洽的視覺效果，幾乎超出預期地解決了遊戲核心體驗的問題。
受控標識與色彩設計
在具體實現的過程中，本以為已經解決的問題 1 又冒了出來。雖然控制的切換隻是兩個按鍵的事，受控方塊的標識卻有很多選項。最直白的就是加框，但是由於我格外醉心於方塊在夜空中落下的意象，並不能容忍加框這種明顯的人造物來破壞沉浸感。為此只能使用不同的顏色來標識，而這需要和色彩設計綜合考慮。
傳統俄羅斯方塊的色彩系統非常簡單：每個方塊一個色彩。在實際試玩的過程中，我發現這樣會使得堆積的方塊非常花哨凌亂，方塊過多時顯著破壞場景的寧靜感。我希望方塊堆積起來具有相對和諧的顏色，為此限制了色彩的個數，這使得方塊開始形成更和諧的更大色塊。突然我意識到玩家可能想有意識地用方塊堆出一些形狀——這是寬大地圖帶來的意外效果，而當前顏色與方塊綁定的做法使得玩家“塗色”時會受限於可用方塊的種類。
經過一番考慮我重新設計了色彩系統，讓色彩隨時間而不是方塊變化，每隔一段時間，系統會更換新下落方塊將具有的顏色，這樣玩家總是有一批同色而形狀各異的方塊來用，更加容易搭建自己喜歡的圖案。
方塊的色彩選擇的是明亮的暖色系，與之對應，受控方塊的色彩自然就要選用亮色的藍或綠。遺憾的是，這樣我喜愛的亮黃+夜空的色彩對比就無法出現在視野的中央。後來我實現了下落標識的功能，這時藍色就可以只標識在下落標識上，方塊本身則保持原有顏色，但是我又發現在這種模式下玩家的眼睛會集中在底部，同樣不會關注亮黃+夜空的色彩對比。最後這個感受只能留給任由方塊下落的佛系玩家，這是遊戲設計的一點遺憾。
粒子系統
在遊戲設計過程中我經常克服實現一些花哨特效的誘惑，部分是因為 TIC80 的機能和表現力有限，這種限制其實也是 fantasy console 這類開發環境的好處。但是我還是決定在消行這裡作出最棒的視覺效果——消行相比普通俄羅斯方塊太難了，必須要給玩家以驚喜，同時，這個視覺效果應當既華麗又同樣寧靜，具有“不為人知地悄悄發生”的感覺。最後我選擇了飄散的效果，通過控制速度可以同時呈現出能量和輕盈感。
TIC80 沒有自帶粒子系統，我在之前的開發中也並沒有用過其它引擎的粒子系統，大概參考了一下網上的常規設計後就乾脆開始動手實驗。按照單粒子單方向移動->消散->多粒子移動->分批移動->速度擾動的順序逐漸實現一個自然的粒子效果。在實際操作時，我意外地發現最大的挑戰來自像素本身。開始時我用浮點數按幀積累 x 和 y 的值，x 和 y 變化達到一個整數時就結算到位置上，結果導致移動方向只有兩種：45 度和水平，形成非常難看的折線。為此需要讓 x 和 y 協調變化，在固定時間後或移動超過一定距離後才結算距離。
粒子移動完成後，整體分佈效果的處理反而意外順利，引入了隨機速度擾動後，只需要控制隨機的區間就可以實現效果的微調。比如根據 x 的位置改變粒子的基準速度，就可以呈現出向右方開口的效果。這裡還有一個竅門是為了使隨機數被壓縮在靠近 0 的區間，可以簡單使用兩個甚至三個均勻分佈的隨機數相乘，我用這種處理防止散逸的粒子扎堆。
聲音系統
我希望遊戲大部分時間是無聲的，但一度考慮在下雪和消行時播放一句音樂。TIC80 支持 SFX 的定製，但是折騰了好半天后我基本確信無法使用 8bit 達成我心中的音效。我希望下雪時的音樂有一種回憶色彩，而消行時的音樂明亮而輕盈，這需要類似於鋼琴的音色和類似於三角鐵的音色。放棄音樂後遊戲就完全無聲了，作為補償，我突然意識到可以給方塊本身配上音符，就像玩家可以不管消行只是堆圖案，他/她也應當可以不管所有積累的東西只進行即逝的創造。於是我為切換控制的按鍵加上了聲音，如果下落的方塊比較合適，通過橫向擺佈方塊的相對位置玩家就可以編排出趣的樂句。雖然可能根本不會有人這麼玩，這個想法還是讓我非常興奮。實際試玩過程中意外的旋律可能令旁邊的人會心一笑，算是一個不錯的副產品。
音符選擇上，我選擇了 C 大調和 F 大調給前兩種顏色，高八度的 D 大調給最亮的黃色，紅色則用 C 大調的關係小調 a 小調（和聲小調）來銜接。音階的設計理應更花心思，但那已經超過了我的能力範圍。
配置與交互設計
我在交互上一度有過稍顯奇怪的困擾。比如，我執著於不實現遊戲內菜單，實現的枯燥是一方面，另一方面，我覺得這樣一個世界不應該有菜單這種完全控制的意象，更何況 TIC80 的遊戲自帶一個遊戲外菜單。但是為了不同目的的玩家能有最佳體驗，我還是設計了指示物的開關（開便於遊戲，關更有漂浮感），時間和分數的開關（開便於記錄刷分，關避免干擾），把交互簡化成兩個專用的鍵。
鍵位上，TIC80 默認 a 對應 XBOX 手柄上的 X 而 x 對應 B，這使得手柄上正常的左右操作變成了 a 和 x 的奇怪操作，因而我增加了 q 和 w 來切換方塊，這樣的話立即下落對應的 z（手柄上的 A）就顯得干擾太多了，於是我增加了回車來立即下落。
結語
我想我還會使用 fantasy console，可能是 TIC80，也或者購入 PICO-8，這些工具當然不是沒有問題，比如自帶的代碼編輯器對習慣了 vim 的程序員來說過於痛苦，幾乎沒有什麼用，Sprite 編輯器也僅僅夠用，與 Aseprite 這種神器相距甚遠。但是它們的限制和高度集成的特點會潛移默化地塑造開發進程，迫使開發者不斷回到遊戲的核心玩法，是一個非常安適的工作環境。
有一種說法是 fantasy console 適合快速開發原型，這點我之前一直不太明白。由於缺少太多遊戲引擎的便利功能且工作在十分低的抽象上（sprite、map、甚至像素），實現一個在其它引擎裡拖拖拽拽的簡單任務都可能頗費周章。現在我開始理解它可能並非適合任何遊戲的原型開發。對於一個相對複雜的類型遊戲，僅僅建立類型的要件可能就要浪費大量時間，但是對於玩法特殊、渲染特殊的遊戲，所有引擎提供的功能都會變成桎梏——對於這類遊戲沒有什麼比直接畫像素更自在了。
不長的開發時間卻讓我感觸頗多。作為一個全包型且只能在業餘時間進行開發的個人開發者，應當更多地堅持創新的獨立玩法。去實現成熟的類型遊戲機制當然是有益的，那些機制創立之初本身也極富創意，但是由於珠玉在前，很容易陷入繁瑣的細節，反而無法充分體現創意。至少對我而言，理想的遊戲開發是一種接近藝術創作的狀態，尋求的是觸動，而不那麼關心傳統意義上的“好玩”和“吸引力”，還是應當對目標進行精簡，堅持做遊戲的初衷，儘快抓住和發展自己的靈感。
遊戲目前已經移植到 Love2d 引擎上，後續開發將基於這個版本進行，TIC80 的版本已經上傳到 itch.io，可以免費遊玩。Love2d 版也放到了 itch.io 上，目前只是加了封面、彩蛋和一點音樂，收費 2 刀，也希望大家支持。
閱讀更多 電競犀利說 的文章
