什么特质会让你立刻觉得一个游戏技术策划（Technical Designer）很靠谱？
我个人对这个问题非常感兴趣，因为我花了至少5年在设计和实践（我自己经历了大小7个项目，虽然大多最后因为其他原因都没上）这样一套机制并且可以说基本解决了这个问题！我并不想藏着他，我也和很多朋友分享了，同时也感谢他们提出了很多意见，包括细节和优化等方面，正因为互相之间的借鉴和交流，我到今天已经把这套机制归纳的非常好了，还是想把它分享给更多想做好游戏的人，希望大家能进一步交流，把它更完善化，以形成一种规范，这套机制适用于任何类型的游戏开发，因为他是一个很棒的思路。 首先分析一下可扩展性：我从一个设计师的角度来看，所谓的可扩展性是——你并不知道策划下一个设计的是什么，但是你需要在尽可能不改动核心代码的基础上去把它实现了，并且在调试的时候（甚至是上线之后要做调整的时候），你可以并不伤筋动骨的去修改它。这里除了你要有好的代码规范外，还需要抽象一套机制来实现它。 最早开始想这套机制的动力是因为我在起凡工作，看了代码之后我感觉是完全无扩展性的，当我想要设计一个新的英雄的时候，要去修改代码已经几乎是不可能的了，于是我便思考，如果我要做一套WoW的技能、buff系统，应该是怎样的呢？于是我总结、归纳、抽象了这样一套东西，并且最早在三国争霸2项目中投入实际使用。 2年前我在GameRes发过相关的帖子： 实际上，好的策划的脑洞是非常大的，你真不知道他会设计出什么样的技能，但你并不能说一些设计因为无法实现就理所应当被埋没了，（我对策划设计Dota类游戏的思路要求是开放的，发挥想象力的： ）因此我想了这样一个机制，他们的核心在于： 1，明确区别了AOE\Buff和技能3块，策划应该从这个角度出发思考问题。 2，这既然是一套机制，你可以把它用在任何游戏的框架当中。比如我要做一个Dota传奇的卡牌游戏，一样可以用这套机制，但是核心在于——你的策划要有能力归纳出游戏中的回调点。 当然我们在使用这套机制的时候，逻辑上实现并没有任何问题，但是我们一样会遇到一些从逻辑变成动画的困难，尤其是当我们的战斗在服务器上一瞬间完成了，但是要把结果告诉客户端吗，并且有客户端重新验算一遍的时候，因此我在之后有总结了一套作法，来完成这个事情： 这个解决的是，当你有各种有趣的buff，但是又想不大改客户端的时候，你应该这样去建立这个框架。你可以想象如果你做一个MT类型的游戏，战斗是服务器一瞬间的，但你又要客户端重演，我们举个例子： 比如我门设计了在MT类型游戏中加入地形因素：可以有火海，火海每回合开始的时候对所有场上敌我英雄造成火焰伤害。 然后有个英雄是一只凤凰，凤凰有2个被动效果： 1，受到火焰伤害的时候变成治疗自己相当于伤害值的血量。 2，战斗中第一次死亡可以复活，回复最大生命值50%，如果在火海中则回复100%。 这样一个英雄和地形，我们如何实现呢？如果你看了我上面的几套机制，并且理解了，那基本没有难度，你根本不需要硬编码。但这里有个问题，我如何让客户端重现？这就是上面这篇说的关键了。 希望以上这些我多年的经验总结能够对游戏人有所帮助！ ——————————2015 08 15 更新一条 —————————————— 看来感兴趣的人还是不少的，于是我发了一些关于这套机制的实际运用方式在GameRes上，主要是想说——这套东西核心还是离不开策划的设计的，同时放开脑洞去思考，才是最重要的：