从热爱走入实践：设计与技术的交汇起点
从儿时被一段段精彩剧情和刺激战斗深深吸引，到如今从业游戏策划，十余年来，我一路从热爱走向专业。随着对游戏设计与制作理解的不断深入，我愈发意识到：设计与技术并非对立，而是彼此成就。借此机会，想结合一些项目经历与开发体会，聊聊二者之间那些微妙的联系。
游戏设计（Game Design）这个词最早出现在我的大学时期。作为游戏设计专业的学生，我系统学习了大量理论知识，并在一次次校园项目中不断实践、打磨对这些概念的理解。什么是游戏设计？在 Anna Anthropy 的《Rise of the Videogame Zinesters》中有一个我至今印象深刻的定义：“A game is an experience created by rules” —— 游戏是一种由规则构建的体验。那么，游戏设计，就是创造这些规则与内容的过程。它不仅关乎玩法的构思，更是对玩家体验的深度编排。
在校期间自己主导了两项目的设计和落地，既做核心玩法设计也写代码。那个过程让我很快明白：有些想法听起来很酷，但真要做出来，技术难度可能远超预期。很多“天马行空”的设计，如果不考虑资源和实现方式，最终可能只能停留在GDD（GameDesignDocument 游戏设计文档） 上。现在工作中我还是鼓励新人大胆创新，但我也会提醒他们，好的创意要有落地的逻辑支撑，想象力和技术实现之间的桥梁不能断。
设计落地之路：设计如何到落地
要理解为什么设计与技术之间会出现冲突，首先需要回到一个核心问题：设计是如何一步步走向落地的？
在我参与的大多数项目中，策划方案的输出往往是整个设计流程的起点。我个人的习惯是，接到需求后，先进行初步拆解——这些需求可能来自上级，也可能存在不合理或模糊之处。因此，我会先从目标中抽象出关键模块，按功能或系统进行分类，再逐一展开脑暴。比如在关卡设计中，我会围绕核心玩法、环境要素、引导节奏等方向发散思考；而在战斗设计中，则更多聚焦于招式表现、反馈节奏与场景互动等内容。接着，我会将这些脑暴的内容进行整合，对照最初的设计目标进行校准，筛选、收束出真正关键的表现点和机制原型。这个阶段，我称之为“雏形设计”——它既是创意的第一轮成型，也是走向技术落地前的第一道筛选。
在此，我想进一步展开一点我的设计方法论——我个人在项目中一直实践的，是游戏设计中广为人知的 MDA 设计模型。MDA 分别代表 Mechanics（机制）、Dynamics（动态） 与 Aesthetics（美学）。虽然直译为“机制、动态、美学”，但我在实际使用中更倾向于这样理解：
- 机制（Mechanics）：即游戏的底层规则与系统框架，例如玩家可以跳跃、攻击、有血量等，它决定了游戏“怎么玩”、有哪些限制与交互方式；
- 动态（Dynamics）：是机制与玩家行为互动后产生的具体游戏内容和反馈，例如《马里奥》中“跳跃”机制+敌人设计形成了“踩乌龟”这样的动态玩法；
- 美学（Aesthetics）：本质是玩家获得的主观感受，我更愿意将其称为“情绪体验”，如《鬼泣》中连招带来的爽快感、恐怖游戏中的压迫感等。
在我早期的设计实践中，我更多是从“机制”出发：思考要设计什么系统，它能产生哪些动态内容，然后再进一步去想它会带来什么样的感受。但随着经验积累，我逐渐转向了一种更有效的思考方式——从“感受”出发倒推设计：先设定我希望玩家获得什么样的体验，再逐层拆解出可能引发这种体验的内容与机制。这种从玩家视角出发的“感受 → 内容 → 机制”思维路径，让我的设计过程变得更顺畅，也更具方向性。
比如在关卡设计中，如果我希望营造出“恐惧”的体验（Aesthetics），我会思考哪些元素能让玩家感到害怕（Dynamics）：幽闭环境、突然出现的敌人、阴暗灯光等；接着再进一步设计这些元素的生成逻辑、触发方式与节奏控制（Mechanics），最终形成一个完整的恐怖关卡系统。
战斗系统设计亦然。如果目标是让玩家“打得爽”，那这就是预期的感受。再往下思考，是哪些元素能产生“爽感”：华丽的连招、打击音效、血量飞溅等。而在操作层面，若我们希望玩家通过连续按键获得高反馈，便可设计出如“连招系统”这样的机制来承载这些元素。
在完成“雏形设计”之后，我通常会根据其中的核心内容，整理出一份可执行的正式需求文档。这往往也是设计与技术的第一次正面交汇。理论上，它应该清晰表达设计目标、系统逻辑、关键流程与边界条件；但在实际工作中，尤其是对于新手策划来说，这一步常常是问题高发点。一些策划会不自觉地在文档中“指导程序怎么写代码”，试图以策划身份去干涉实现逻辑；也有一些需求完全脱离当前项目的技术框架，导致程序难以落地，甚至会引发重构风险。我曾经就经历过一个项目，策划方案中提出的系统设计，若要实现，必须彻底重写底层框架——最终，这一方案自然被否决。
因此，真正的“可执行需求”关键不在于有多宏大，而在于“能执行”。对我个人而言，我更倾向在设计输出前，就主动与程序沟通，了解当前的技术架构：哪些功能是现有框架能直接支持的，哪些属于新增内容？而这些新增内容，大致的开发成本是多少？是否有替代方案？
这样的习惯不仅让我写出的需求更具可落地性，也逐渐促使我走向技术策划的方向。站在技术实现角度看设计、站在玩家体验角度拆技术，成为我之后项目中越来越自然的思维路径。也正是这种持续的“设计-技术”沟通意识，逐步引导我从纯策划岗位，向“技术策划”的角色过渡。
接下来，这份需求文档将进入评审流程。第一步通常是由策划Leader或主策进行初审，评估方案是否具备足够的趣味性与合理性，设计是否符合当前版本目标，开发成本是否在预期范围内。一旦策划侧对齐了设计方向，便会进入更关键的一步——综合评审会。综合评审通常由程序、美术、策划等多部门参与，各方会从各自角度评估方案的可行性与实现成本。这也是设计真正接受现实检验的时刻：看似合理的创意可能在程序角度是高风险；美术资源可能无法支撑某些设想；而技术实现上的瓶颈，常常让设计者被迫面对“无法落地”的现实。
老实说，这个阶段往往是很多策划梦想破碎的地方——纸面上的完美构想，常常在现实中寸步难行。但也正是在这样的碰撞中，设计才真正变得成熟与可行。
策划走向成熟的基石：技术理解力
在我参与的项目中，真正因技术限制导致设计搁浅的情况其实并不多，更多时候的瓶颈来自美术资源的协调与成本分配（这部分暂且不作展开）。但不可否认，在某些项目阶段，技术限制确实存在，它们大多集中在以下几个方面：
- 程序员个人能力或经验不足，无法完成复杂系统的设计或优化；
- 项目开发周期紧张，即使方案可实现，但没有足够时间排期或测试；
- 策划设计确实脱离现实，不考虑现有架构或逻辑限制，方案本身难以执行。
我始终认为，在当前这个信息高度流通、开源方案丰富的互联网时代，几乎不存在真正“完全做不到”的东西。大多数所谓“无法实现”，往往是综合权衡下的结果：人力、时间、风险与性价比。但在这段落中，我不打算讨论程序员能力或项目管理的问题，只想从策划的角度，谈谈对技术的理解与责任感。
在过往项目以及与同行交流中，我经常听到这样的话：“我只是一个策划，为什么要了解程序？”但实践经验一次次告诉我：不懂程序原理的策划，很难成为一名真正优秀的策划。优秀的设计，从来都不是闭门造车。设计必须依托实现，否则就会陷入反复返工的死循环：设计→实现失败→重改方案→目标偏离初衷→玩家体验受损，最终甚至团队士气也会被拖累。而这种“反复返工”带来的挫败感，策划自己最清楚。
所以我始终认为：懂程序原理，是策划的底层竞争力。这不代表策划要写代码，而是要懂基本的逻辑结构、常见的实现思路、系统之间的依赖关系。只有这样，才能写出真正具备可行性、风险评估与逻辑闭环的设计方案，才能让“想法”不只是空中楼阁。
在实际项目中，我曾遇到一个典型的“技能系统混乱”案例。项目本身有大量技能设计需求，每个技能既有个性化特性，也存在大量共通结构。按理来说，这是一个非常适合做模块化、模板化处理的系统。
然而当我接手时，系统已经有了初步实现，但却存在两个严重问题：
- 每个技能都使用一个独立的实例对象，没有任何逻辑复用，这对策划的配置和维护带来了巨大压力；
- 程序方面也没有做共通逻辑封装，导致功能重复实现。一旦有改动需求，就意味着需要手动修改每一个技能实例——不仅低效，还极易出错。
更糟糕的是，当时负责该系统的策划与程序都对这套框架理解不深，导致系统“既不能用、也没人敢动”，形成了典型的设计与实现双端脱节的状况。
介入后，我第一步是深入了解该系统的底层架构，明确技能实例本身的职责和数据流向。在我看来，数据逻辑与表现逻辑是可以且应当解耦的：
- 实例应专注于“如何展示技能效果”；
- 数据逻辑则负责“从哪里获取数值、如何驱动行为”。
基于这一理念，我采取了如下优化策略：
- 构建技能实例父类：将所有技能的共通阶段（如启动、命中、结束）抽象为可继承的基础流程；
- 采用阶段复写模式：让不同类型的技能继承父类，并按需复写特定阶段的逻辑；
- 分类技能实例结构：按技能类型进行结构分类，再将表现与数据绑定，方便策划直观使用；
- 数据层统一入口：技能表现所需的参数统一从数据逻辑中读取，而不是散落在每个实例中。
分享这个案例的目的，并不是为了吐槽项目存在的问题，而是想说明一个更重要的观点：当策划具备一定的技术理解能力时，往往能更有效地抽象设计逻辑，提升需求本身的清晰度与可执行性。有了这样的技术视角，策划在撰写需求时，能够更准确地预判系统结构、识别潜在风险，并针对实现路径做出合理规划。正因如此，设计方案在进入程序、美术等环节时，往往更具可落地性，极大减少了跨部门返工与系统重构的情况发生。
反向驱动：技术成就设计
在我的个人项目中，我深刻体会到：越了解技术，所做的设计迭代就越明确、越高效。这一点在我研究《影之刃零》的过程中体现得尤为明显。还记得第一次看到它的 PV 时，那种华丽又极具武侠质感的技能演出让我既震撼又好奇——这些看起来复杂又精致的技能，是如何实现出来的？带着这个疑问，我开始深入学习 Unreal（虚幻） 技术，尤其是技能系统和动画表现相关的内容。随着研究的深入，以及《影之刃零》实机演示的发布，我逐渐意识到：这些令人印象深刻的技能背后，很多其实是机制驱动下的动态表现结果。比如其中一个技能“仙人指路”，表面看起来是华丽的连击，但本质上是处决机制+角色周围敌人分布共同触发的视觉效果。
这也启发我反向思考：机制设计其实可以为表现提供无限延展的空间。以处决机制为例，我可以设计多种触发条件和判断方式，从而导出更多丰富的表现形态——比如多敌人处决、特定阵型下的处决动画、不同角度的击杀演出等。这些变化并不一定需要重做动画或系统，而是通过合理利用机制驱动，让战斗体验在技术可承载的前提下产生丰富的视觉反馈。
《影之刃零》实机视频截图，链接：https://youtu.be/_EonL-sReug?si=1W-1XXa7ZqbATccc
自己复刻的处决：【ARPG战斗开发记录24（复刻《影之刃：零》0-回归初心！）】 【精准空降到 00:30】
https://www.bilibili.com/video/BV1Xp7ezjEDp
在实际开发中，为了将“仙人指路”这一多目标处决表现落地，我会先反复自问几个关键问题：
- 我是否应该在原有的处决技能中细分不同的处决表现？
- 我该如何准确判断当前是否满足触发条件？
- 这个判断逻辑是否需要持续 Tick 检测？
针对第一个问题，我借助了虚幻引擎的 GAS 框架，以及程序中的对象设计思维，找到了解决方向。我选择继承原有已开发的处决技能 GA_Execution，并在子类中复写 CanActivateAbility，以支持不同条件下的处决触发。同时在触发后再次判断环境状态，以确保在技能执行时仍满足表现条件。
至于第二个问题——如何判断“当前情况”是否满足特定处决表现，我在技能触发时检测了玩家前后是否存在有效的敌人、这些敌人是否在指定范围内、是否处于可处决状态等一系列条件。只有满足这些逻辑判断，才会执行类似“仙人指路”的群体处决表现。
而第三个问题——是否需要通过 Tick 持续判断，答案是明确的：不应该。Tick 会带来不必要的性能开销，也会引发不稳定的逻辑状态。通过在技能触发时的一次性判断即可满足需求，更稳定也更高效。
这一设计思路也为后续的开发打下了良好的基础——在保持灵活配置的前提下，支持多种处决拓展，同时提升了系统的可维护性与功能迭代速度。
知其然，更知其所以然：在技术中实现设计理想
以上内容，都是我在实际项目中一点一滴积累下来的所见所感。我始终认为，策划需要理解技术，技术也应理解设计。游戏设计从来都不是孤立的艺术，它是一门融合了逻辑、美学、交互和工程的综合性学科。尤其对于策划岗位而言，具备复合型的能力早已不是加分项，而是基本要求。
设计与技术从不对立，它们本应是相辅相成、互相驱动的双轮。策划若能理解技术、熟悉工具，就更容易将抽象想法转化为可执行的方案，推动设计真正落地。在我的日常工作中，我总是倾向于用现有资源与技术手段快速实现原型，验证可玩性，以此反哺设计思路，达成“知”与“行”的统一。同时，这种技术理解也显著降低了我与程序的沟通成本，让团队协作更加高效顺畅。跨学科的认知融合，是策划成长的加速器，也是团队成功的催化剂。
以上仅是一些个人的浅显理解与经验分享，如有偏颇之处，欢迎指正交流。我也将始终保持一颗学习之心，在设计与技术的交汇处，继续探索下去。
参考资料：
1. “Rise of the Videogame Zinesters”, Ch3 (By Anna Anthropy)
文/无404-NotFound
原文：https://zhuanlan.zhihu.com/p/1923390640600884593
| 
发表于 