作者：無404-NotFound；首發(fā)知乎

https://zhuanlan.zhihu.com/p/1923390640600884593

從熱愛走入實踐：設計與技術的交匯起點

從兒時被一段段精彩劇情和刺激戰(zhàn)斗深深吸引，到如今從業(yè)游戲策劃，十余年來，我一路從熱愛走向?qū)I(yè)。隨著對游戲設計與制作理解的不斷深入，我愈發(fā)意識到：設計與技術并非對立，而是彼此成就。借此機會，想結合一些項目經(jīng)歷與開發(fā)體會，聊聊二者之間那些微妙的聯(lián)系。

游戲設計（Game Design）這個詞最早出現(xiàn)在我的大學時期。作為游戲設計專業(yè)的學生，我系統(tǒng)學習了大量理論知識，并在一次次校園項目中不斷實踐、打磨對這些概念的理解。什么是游戲設計？在 Anna Anthropy 的《Rise of the Videogame Zinesters》中有一個我至今印象深刻的定義：“A game is an experience created by rules” —— 游戲是一種由規(guī)則構建的體驗。那么，游戲設計，就是創(chuàng)造這些規(guī)則與內(nèi)容的過程。它不僅關乎玩法的構思，更是對玩家體驗的深度編排。

在校期間自己主導了兩項目的設計和落地，既做核心玩法設計也寫代碼。那個過程讓我很快明白：有些想法聽起來很酷，但真要做出來，技術難度可能遠超預期。很多“天馬行空”的設計，如果不考慮資源和實現(xiàn)方式，最終可能只能停留在GDD（GameDesignDocument 游戲設計文檔） 上?，F(xiàn)在工作中我還是鼓勵新人大膽創(chuàng)新，但我也會提醒他們，好的創(chuàng)意要有落地的邏輯支撐，想象力和技術實現(xiàn)之間的橋梁不能斷。

設計落地之路：設計如何到落地

要理解為什么設計與技術之間會出現(xiàn)沖突，首先需要回到一個核心問題：設計是如何一步步走向落地的？

在我參與的大多數(shù)項目中，策劃方案的輸出往往是整個設計流程的起點。我個人的習慣是，接到需求后，先進行初步拆解——這些需求可能來自上級，也可能存在不合理或模糊之處。因此，我會先從目標中抽象出關鍵模塊，按功能或系統(tǒng)進行分類，再逐一展開腦暴。比如在關卡設計中，我會圍繞核心玩法、環(huán)境要素、引導節(jié)奏等方向發(fā)散思考；而在戰(zhàn)斗設計中，則更多聚焦于招式表現(xiàn)、反饋節(jié)奏與場景互動等內(nèi)容。接著，我會將這些腦暴的內(nèi)容進行整合，對照最初的設計目標進行校準，篩選、收束出真正關鍵的表現(xiàn)點和機制原型。這個階段，我稱之為“雛形設計”——它既是創(chuàng)意的第一輪成型，也是走向技術落地前的第一道篩選。

在此，我想進一步展開一點我的設計方法論——我個人在項目中一直實踐的，是游戲設計中廣為人知的 MDA 設計模型。MDA 分別代表 Mechanics（機制）、Dynamics（動態(tài)） 與 Aesthetics（美學）。雖然直譯為“機制、動態(tài)、美學”，但我在實際使用中更傾向于這樣理解：

• 機制（Mechanics）：即游戲的底層規(guī)則與系統(tǒng)框架，例如玩家可以跳躍、攻擊、有血量等，它決定了游戲“怎么玩”、有哪些限制與交互方式；
• 動態(tài)（Dynamics）：是機制與玩家行為互動后產(chǎn)生的具體游戲內(nèi)容和反饋，例如《馬里奧》中“跳躍”機制+敵人設計形成了“踩烏龜”這樣的動態(tài)玩法；
• 美學（Aesthetics）：本質(zhì)是玩家獲得的主觀感受，我更愿意將其稱為“情緒體驗”，如《鬼泣》中連招帶來的爽快感、恐怖游戲中的壓迫感等。

在我早期的設計實踐中，我更多是從“機制”出發(fā)：思考要設計什么系統(tǒng)，它能產(chǎn)生哪些動態(tài)內(nèi)容，然后再進一步去想它會帶來什么樣的感受。但隨著經(jīng)驗積累，我逐漸轉(zhuǎn)向了一種更有效的思考方式——從“感受”出發(fā)倒推設計：先設定我希望玩家獲得什么樣的體驗，再逐層拆解出可能引發(fā)這種體驗的內(nèi)容與機制。這種從玩家視角出發(fā)的“感受 → 內(nèi)容 → 機制”思維路徑，讓我的設計過程變得更順暢，也更具方向性。

比如在關卡設計中，如果我希望營造出“恐懼”的體驗（Aesthetics），我會思考哪些元素能讓玩家感到害怕（Dynamics）：幽閉環(huán)境、突然出現(xiàn)的敵人、陰暗燈光等；接著再進一步設計這些元素的生成邏輯、觸發(fā)方式與節(jié)奏控制（Mechanics），最終形成一個完整的恐怖關卡系統(tǒng)。

戰(zhàn)斗系統(tǒng)設計亦然。如果目標是讓玩家“打得爽”，那這就是預期的感受。再往下思考，是哪些元素能產(chǎn)生“爽感”：華麗的連招、打擊音效、血量飛濺等。而在操作層面，若我們希望玩家通過連續(xù)按鍵獲得高反饋，便可設計出如“連招系統(tǒng)”這樣的機制來承載這些元素。

在完成“雛形設計”之后，我通常會根據(jù)其中的核心內(nèi)容，整理出一份可執(zhí)行的正式需求文檔。這往往也是設計與技術的第一次正面交匯。理論上，它應該清晰表達設計目標、系統(tǒng)邏輯、關鍵流程與邊界條件；但在實際工作中，尤其是對于新手策劃來說，這一步常常是問題高發(fā)點。一些策劃會不自覺地在文檔中“指導程序怎么寫代碼”，試圖以策劃身份去干涉實現(xiàn)邏輯；也有一些需求完全脫離當前項目的技術框架，導致程序難以落地，甚至會引發(fā)重構風險。我曾經(jīng)就經(jīng)歷過一個項目，策劃方案中提出的系統(tǒng)設計，若要實現(xiàn)，必須徹底重寫底層框架——最終，這一方案自然被否決。

因此，真正的“可執(zhí)行需求”關鍵不在于有多宏大，而在于“能執(zhí)行”。對我個人而言，我更傾向在設計輸出前，就主動與程序溝通，了解當前的技術架構：哪些功能是現(xiàn)有框架能直接支持的，哪些屬于新增內(nèi)容？而這些新增內(nèi)容，大致的開發(fā)成本是多少？是否有替代方案？

這樣的習慣不僅讓我寫出的需求更具可落地性，也逐漸促使我走向技術策劃的方向。站在技術實現(xiàn)角度看設計、站在玩家體驗角度拆技術，成為我之后項目中越來越自然的思維路徑。也正是這種持續(xù)的“設計-技術”溝通意識，逐步引導我從純策劃崗位，向“技術策劃”的角色過渡。

接下來，這份需求文檔將進入評審流程。第一步通常是由策劃Leader或主策進行初審，評估方案是否具備足夠的趣味性與合理性，設計是否符合當前版本目標，開發(fā)成本是否在預期范圍內(nèi)。一旦策劃側(cè)對齊了設計方向，便會進入更關鍵的一步——綜合評審會。綜合評審通常由程序、美術、策劃等多部門參與，各方會從各自角度評估方案的可行性與實現(xiàn)成本。這也是設計真正接受現(xiàn)實檢驗的時刻：看似合理的創(chuàng)意可能在程序角度是高風險；美術資源可能無法支撐某些設想；而技術實現(xiàn)上的瓶頸，常常讓設計者被迫面對“無法落地”的現(xiàn)實。

老實說，這個階段往往是很多策劃夢想破碎的地方——紙面上的完美構想，常常在現(xiàn)實中寸步難行。但也正是在這樣的碰撞中，設計才真正變得成熟與可行。

策劃走向成熟的基石：技術理解力

在我參與的項目中，真正因技術限制導致設計擱淺的情況其實并不多，更多時候的瓶頸來自美術資源的協(xié)調(diào)與成本分配（這部分暫且不作展開）。但不可否認，在某些項目階段，技術限制確實存在，它們大多集中在以下幾個方面：

1. 程序員個人能力或經(jīng)驗不足，無法完成復雜系統(tǒng)的設計或優(yōu)化；
2. 項目開發(fā)周期緊張，即使方案可實現(xiàn)，但沒有足夠時間排期或測試；
3. 策劃設計確實脫離現(xiàn)實，不考慮現(xiàn)有架構或邏輯限制，方案本身難以執(zhí)行。

我始終認為，在當前這個信息高度流通、開源方案豐富的互聯(lián)網(wǎng)時代，幾乎不存在真正“完全做不到”的東西。大多數(shù)所謂“無法實現(xiàn)”，往往是綜合權衡下的結果：人力、時間、風險與性價比。但在這段落中，我不打算討論程序員能力或項目管理的問題，只想從策劃的角度，談談對技術的理解與責任感。

在過往項目以及與同行交流中，我經(jīng)常聽到這樣的話：“我只是一個策劃，為什么要了解程序？”但實踐經(jīng)驗一次次告訴我：不懂程序原理的策劃，很難成為一名真正優(yōu)秀的策劃。優(yōu)秀的設計，從來都不是閉門造車。設計必須依托實現(xiàn)，否則就會陷入反復返工的死循環(huán)：設計→實現(xiàn)失敗→重改方案→目標偏離初衷→玩家體驗受損，最終甚至團隊士氣也會被拖累。而這種“反復返工”帶來的挫敗感，策劃自己最清楚。

所以我始終認為：懂程序原理，是策劃的底層競爭力。這不代表策劃要寫代碼，而是要懂基本的邏輯結構、常見的實現(xiàn)思路、系統(tǒng)之間的依賴關系。只有這樣，才能寫出真正具備可行性、風險評估與邏輯閉環(huán)的設計方案，才能讓“想法”不只是空中樓閣。

在實際項目中，我曾遇到一個典型的“技能系統(tǒng)混亂”案例。項目本身有大量技能設計需求，每個技能既有個性化特性，也存在大量共通結構。按理來說，這是一個非常適合做模塊化、模板化處理的系統(tǒng)。

然而當我接手時，系統(tǒng)已經(jīng)有了初步實現(xiàn)，但卻存在兩個嚴重問題：

1. 每個技能都使用一個獨立的實例對象，沒有任何邏輯復用，這對策劃的配置和維護帶來了巨大壓力；
2. 程序方面也沒有做共通邏輯封裝，導致功能重復實現(xiàn)。一旦有改動需求，就意味著需要手動修改每一個技能實例——不僅低效，還極易出錯。

更糟糕的是，當時負責該系統(tǒng)的策劃與程序都對這套框架理解不深，導致系統(tǒng)“既不能用、也沒人敢動”，形成了典型的設計與實現(xiàn)雙端脫節(jié)的狀況。

介入后，我第一步是深入了解該系統(tǒng)的底層架構，明確技能實例本身的職責和數(shù)據(jù)流向。在我看來，數(shù)據(jù)邏輯與表現(xiàn)邏輯是可以且應當解耦的：

• 實例應專注于“如何展示技能效果”；
• 數(shù)據(jù)邏輯則負責“從哪里獲取數(shù)值、如何驅(qū)動行為”。

基于這一理念，我采取了如下優(yōu)化策略：

• 構建技能實例父類：將所有技能的共通階段（如啟動、命中、結束）抽象為可繼承的基礎流程；
• 采用階段復寫模式：讓不同類型的技能繼承父類，并按需復寫特定階段的邏輯；
• 分類技能實例結構：按技能類型進行結構分類，再將表現(xiàn)與數(shù)據(jù)綁定，方便策劃直觀使用；
• 數(shù)據(jù)層統(tǒng)一入口：技能表現(xiàn)所需的參數(shù)統(tǒng)一從數(shù)據(jù)邏輯中讀取，而不是散落在每個實例中。

最終，這一方案實現(xiàn)了邏輯高復用、表現(xiàn)高分離、配置高集中的目標，避免了“100個技能寫100個實例、策劃要打開100個實例”的災難性維護局面。

分享這個案例的目的，并不是為了吐槽項目存在的問題，而是想說明一個更重要的觀點：當策劃具備一定的技術理解能力時，往往能更有效地抽象設計邏輯，提升需求本身的清晰度與可執(zhí)行性。有了這樣的技術視角，策劃在撰寫需求時，能夠更準確地預判系統(tǒng)結構、識別潛在風險，并針對實現(xiàn)路徑做出合理規(guī)劃。正因如此，設計方案在進入程序、美術等環(huán)節(jié)時，往往更具可落地性，極大減少了跨部門返工與系統(tǒng)重構的情況發(fā)生。

反向驅(qū)動：技術成就設計

在我的個人項目中，我深刻體會到：越了解技術，所做的設計迭代就越明確、越高效。這一點在我研究《影之刃零》的過程中體現(xiàn)得尤為明顯。還記得第一次看到它的 PV 時，那種華麗又極具武俠質(zhì)感的技能演出讓我既震撼又好奇——這些看起來復雜又精致的技能，是如何實現(xiàn)出來的？帶著這個疑問，我開始深入學習 Unreal（虛幻） 技術，尤其是技能系統(tǒng)和動畫表現(xiàn)相關的內(nèi)容。隨著研究的深入，以及《影之刃零》實機演示的發(fā)布，我逐漸意識到：這些令人印象深刻的技能背后，很多其實是機制驅(qū)動下的動態(tài)表現(xiàn)結果。比如其中一個技能“仙人指路”，表面看起來是華麗的連擊，但本質(zhì)上是處決機制+角色周圍敵人分布共同觸發(fā)的視覺效果。

這也啟發(fā)我反向思考：機制設計其實可以為表現(xiàn)提供無限延展的空間。以處決機制為例，我可以設計多種觸發(fā)條件和判斷方式，從而導出更多豐富的表現(xiàn)形態(tài)——比如多敵人處決、特定陣型下的處決動畫、不同角度的擊殺演出等。這些變化并不一定需要重做動畫或系統(tǒng)，而是通過合理利用機制驅(qū)動，讓戰(zhàn)斗體驗在技術可承載的前提下產(chǎn)生豐富的視覺反饋。

《影之刃零》實機視頻截圖，鏈接：https://youtu.be/_EonL-sReug?si=1W-1XXa7ZqbATccc

自己復刻的處決：【ARPG戰(zhàn)斗開發(fā)記錄24（復刻《影之刃：零》0-回歸初心?。?【精準空降到 00:30】

https://www.bilibili.com/video/BV1Xp7ezjEDp/?share_source=copy_web&vd_source=6365cf6c32e8d6e511526528d2cf1d75&t=30

在實際開發(fā)中，為了將“仙人指路”這一多目標處決表現(xiàn)落地，我會先反復自問幾個關鍵問題：

1. 我是否應該在原有的處決技能中細分不同的處決表現(xiàn)？
2. 我該如何準確判斷當前是否滿足觸發(fā)條件？
3. 這個判斷邏輯是否需要持續(xù) Tick 檢測？

針對第一個問題，我借助了虛幻引擎的 GAS 框架，以及程序中的對象設計思維，找到了解決方向。我選擇繼承原有已開發(fā)的處決技能 GA_Execution，并在子類中復寫 CanActivateAbility，以支持不同條件下的處決觸發(fā)。同時在觸發(fā)后再次判斷環(huán)境狀態(tài)，以確保在技能執(zhí)行時仍滿足表現(xiàn)條件。

至于第二個問題——如何判斷“當前情況”是否滿足特定處決表現(xiàn)，我在技能觸發(fā)時檢測了玩家前后是否存在有效的敵人、這些敵人是否在指定范圍內(nèi)、是否處于可處決狀態(tài)等一系列條件。只有滿足這些邏輯判斷，才會執(zhí)行類似“仙人指路”的群體處決表現(xiàn)。

而第三個問題——是否需要通過 Tick 持續(xù)判斷，答案是明確的：不應該。Tick 會帶來不必要的性能開銷，也會引發(fā)不穩(wěn)定的邏輯狀態(tài)。通過在技能觸發(fā)時的一次性判斷即可滿足需求，更穩(wěn)定也更高效。

這一設計思路也為后續(xù)的開發(fā)打下了良好的基礎——在保持靈活配置的前提下，支持多種處決拓展，同時提升了系統(tǒng)的可維護性與功能迭代速度。

知其然，更知其所以然：在技術中實現(xiàn)設計理想

以上內(nèi)容，都是我在實際項目中一點一滴積累下來的所見所感。我始終認為，策劃需要理解技術，技術也應理解設計。游戲設計從來都不是孤立的藝術，它是一門融合了邏輯、美學、交互和工程的綜合性學科。尤其對于策劃崗位而言，具備復合型的能力早已不是加分項，而是基本要求。

設計與技術從不對立，它們本應是相輔相成、互相驅(qū)動的雙輪。策劃若能理解技術、熟悉工具，就更容易將抽象想法轉(zhuǎn)化為可執(zhí)行的方案，推動設計真正落地。在我的日常工作中，我總是傾向于用現(xiàn)有資源與技術手段快速實現(xiàn)原型，驗證可玩性，以此反哺設計思路，達成“知”與“行”的統(tǒng)一。同時，這種技術理解也顯著降低了我與程序的溝通成本，讓團隊協(xié)作更加高效順暢?？鐚W科的認知融合，是策劃成長的加速器，也是團隊成功的催化劑。

以上僅是一些個人的淺顯理解與經(jīng)驗分享，如有偏頗之處，歡迎指正交流。我也將始終保持一顆學習之心，在設計與技術的交匯處，繼續(xù)探索下去。

參考資料：

1. “Rise of the Videogame Zinesters”, Ch3 (By Anna Anthropy)