有一種職場鬼故事，叫「我們靠默契」
前公司的流程是 [機率工程師] 決定玩法 → [遊戲企劃] 包裝主題/營造體感。這在 Slot 行業並不奇怪。數學是命脈，核心玩法由機率工程師掌控合理。
但災難通常發生在規格沒講清楚，雙方試圖用「默契」來填補溝通黑洞。以下這個鬼故事，是當時企劃與機率單位的日常：
企劃：「以上是這次的企劃，看看家人們有什麼反饋？」
機率：「這跟我想的不一樣。不夠專業。」
企劃：「好的！既然我們不專業，那麻煩貴單位指教。」
機率：「遊戲體感是企劃的責任。」
企劃：「不如我們討論下規格，之後比較好合作。」
機率：「我們沒時間，合作久了就會有默契了。」
當企劃被要求靠默契交付，那不是合作，是通靈。
遊戲企劃同樣身為需求的開端，絕對不可以用”默契”來賭運氣。
我們需要一套不靠緣分就能交付的規格方式 ——BDD（行為驅動開發）。
什麼是 BDD?為什麼是規格書神器？
2000 年左右，英國工程師 Dan North 每天被企劃和程式的雞同鴨講搞到頭痛，他發現根本原因是：「大家講的根本不是同一件事！」於是他發明了一個規則，強迫所有功能都用這一句話寫清楚：
使用者 (玩家) 做了什麼 → 系統 (遊戲) 應該發生什麼事
這就是 BDD (Behavior-Driven Development) 的由來。
實戰範例：傳統規格書 vs. BDD 結構化寫法
這樣說可能沒有概念，舉個遊戲規格來做案例。 今天有個遊戲企劃，要寫角色二段跳的規格，來做比較。
企劃乍看了會覺得，這不就只是改寫一般敘事而已？ 不是喔!不是這樣子的！ BDD 寫法用人類語言導入與工程師同頻率的『關鍵字』，帶來了三大質變：
- 對工程師而言： 看到熟悉的格式，看到規格就能直接對應到程式碼結構 不再需要從字裡行間「通靈」或猜測例外狀況。
- 對 QA ： 規格書是一份「天然的測試腳本」，直接照著操作流程即可驗收，大幅減少溝通誤會。
- 對企劃：
強迫自己跳脫散文式敘述，學會「系統化拆解」。下筆時必須釐清「前提」、「時機」與「結果」，這是最好的邏輯訓練。
且未來修改規格時，只要改幾行字，不用像改流程圖那樣大動干戈。
結合原型與 PPT 邏輯?
[《Slot 原型》遊戲企劃還是文件整理師？原型測試是關鍵]提到原型能加速聚焦，那既然做了原型，還需要寫這麼細的 BDD 嗎？ 需要的。而且有了原型，寫 BDD 反而更簡單。
我們可以借用 PPT 動畫窗格 的邏輯：「同時 」 與 「然後」。加上前提與時機，列清楚的 BDD 易如反掌。
預埋測試參數
原型與真實程式架構還是跟原型工具有一定落差， 尤其是在物理手感與動態時間上。 利用 BDD 的補述，可以在規格中「預埋伏筆」，請工程師將企劃需要手動調整的參數直接開在 Debug 介面上。
💡測試參數小提醒：
- 公規不用列： 不要開一堆企劃根本不會去動的參數，那是增加別人工作量。
- 動態超過 0.3 秒建議開「漸變 (Easing)」： 漸變很神奇，同樣的秒數，不同的曲線會有完全不同的打擊感（這是 PPT 測不出來的）。不用指定哪種漸變，請工程師開選單讓你測就知道了。
這樣做，程式可以專心做架構優化，企劃可以慢慢調手感，皆大歡喜。
告別流程圖修改地獄，建立團隊共同語言
有人說：「圖像的吸收效率是文字的 60,000 倍。」 這也許對美術適用，但絕對不適用於邏輯流程圖！
流程圖跟心智圖一樣，只有畫圖的那個人才會感受到 60,000 倍的吸收效率；其他人看到的不是邏輯，而是一盤義大利麵。
如果你對流程不安心，想畫流程圖梳理邏輯，我舉雙手贊成。 但畫完、整理好邏輯後，請轉為 BDD 文字，然後把流程圖丟掉。
流程圖無法像 BDD 那樣詳細交代規格與參數，且修改上更是牽一髮動全身。一段流程的交換，或加一個例外判斷，絕對改線改到企劃懷疑人生。
企劃不會通靈，工程師也不是靈媒。 規格書不是情書，專案也不是戀愛。 靠「默契」跟「緣分」這種玄學，不是在工作；還是留在靈幻電影裡吧。
這篇如果對你有幫助， 歡迎請我喝杯咖啡，讓我繼續寫更多關於遊戲企劃的筆記。