一款遊戲的開發，肯定伴隨大大小小的修改和調整。
創作者不能怕改。但問題是，改東西需要花時間。一些看似簡單的改動，背後程式邏輯可能要好幾天，甚至幾星期才能修正。
對於不懂程式的人，有時很難判斷東西好不好修。所以今天就來說一下，對程式來說什麼樣的修正會令我們頭痛呢？
先以一個草莓奶油蛋糕為例子：
當我們已經弄好蛋糕，卻突然想把草莓全部改成芒果。理論上很簡單，只要把草莓都拿掉，改放芒果就行。
而如果要把奶油都去掉，改成巧克力漿……雖然有點費工，不過理論上也行，小心把奶油都刮掉就好。
但今天想把麵粉去掉，改成香蕉蛋糕，那基本上就只能打掉重來了。
簡單來說，遊戲有分「外在」和「內在」。
一般而言最外在的就是美術，只要功能完整，換圖或換3D模型都只是替換檔案。（但不一般的情況是更換美術後過於吃效能，導致程式要做效能管理。）
其次是一些數值相關的，比如武器傷害、技能冷卻時間等，除非不小心改成「0除以0」，不然很少有意外。
操作手感和關卡設計那些大概也是草莓。
而「更改或增加遊戲功能」是奶油，處理時有可能傷及本體，但還不至於出大問題。
舉個例子，假如企劃突然想要「精確迴避時有子彈時間」，這時程式除了把功能寫出來，還要多次測試確保舊有動作不會出bug。
要知道程式的世界是連「上下次序倒轉」也有機會出錯的，一個看似問題不大的新功能也隨時會令遊戲當掉。
至於遊戲核心則是蛋糕底，更改下去的破壞程度不一。2D平台改成橫向射擊還算可以，卡牌遊戲改成3D動作——直接混在一起做成巫師3還比較快((X
在上述前提下，再舉一個可能更易理解（？）的例子：
2D平台遊戲《瑪利歐創作家2》。
這遊戲能讓玩家設計關卡，或遊玩他人設計的關卡。
程式已經分割好不同功能的方塊讓玩家自由組合，這是「把設計元素都規劃成草莓」的好例子。
而因為要追求穩定性，玩家能動的亦只有草莓。要處理奶油——比如新增磚塊功能、新增變身道具等，玩家並沒有這樣的權限。
至於蛋糕底更不用說——畢竟這已經是市售成品:D
Btw，上述是最簡單的例子。
真實開發情況會複雜很多。功能與功能之間互相影響，就如同拔走草莓時，上面總會沾點奶油。
要判斷什麼影響較大，靠的當然是經驗。
極端做法是「久病成醫」，每次改動都抓住程式問詳細，當被否決得多時，自然知道怎麼改會出事。
另一做法是參考一下不同遊戲的模組（Mod），畢竟大部分遊戲模組都是建基於本體內容之上。
最常見的是更改模型——如同本文一開始所說，這只是簡單的換圖檔。
其次新增武器、道具等也不少見。
但這其實也分兩類：一種是「新增模型，但道具效果基於遊戲已有內容」。比如遊戲內有「火球術」，這時新增一個「手榴彈」，那就只是用不同的美術模型來觸發技能，本質上仍歸類為草莓。
另一種則是連道具效果也改掉，比如新增一個「追蹤彈」系統，而整個追蹤功能都是自己寫。這就是奶油，隨時與本體程式衝突，容易閃退甚至開不了遊戲。有時亦會因「遊戲本體更新」而令模組不能用。
最後的「蛋糕底」模組，不見得會有，但正因沒有所以才算蛋糕底。
會動到最底層的遊戲核心，所花心力已經和開發新遊戲差不多。除非是對遊戲很有愛，或是遊戲本體相對自由（比如麥塊）才會出現這類模組。
總括而言，企劃在調整時儘量只動到草莓和奶油就好。
話雖如此，什麼是草莓什麼是奶油其實程式決定的。
上面說過「操作手感和關卡設計『大概』是草莓」，其前提是程式有把事件規劃好。
比方說，一個2D平台遊戲，有「一般地版」、「移動平台」、「運輸帶」3種地型。而程式一開始把這些地型都分成不同物件處理。導致企劃想要「移動平台＋運輸帶」時，程式就要新增第4個物件。
但假如一開始規劃好，「移動平台」是「一般地板＋小風扇」；「運輸帶」是「一般地板＋滾輪」。那麼要達成企劃想要的新功能，只要把「一般地板＋小風扇＋滾輪」就好。
一些奶油會因為規劃得當而變成草莓。反過來亦然，沒規劃好就什麼都是奶油，甚至是蛋糕底。
但我相信「程式規劃」是所有寫程式的人的目標:D
企劃找程式合作時，就先相信他們有這能力。假如真的做不出來，再來討論怎麼處理……老實說，溝通才是企劃最最最重要的技能（所以我做不來;-;）。
