这是篇不错的文章，相对比较客观。

说几点吧

1，等级上限的问题，显然，这位作者还不够了解暴雪，60级的等级上限，仅仅4个快捷技能，还有大段没讲完的剧情，一看就是为资料片服务的，现在这套技能系统，60级满级啥的，最多也就是投石问路，为资料片提高等级，物品上限，完善技能系统做准备，我预计资料片很可能就是D2的99级上限，被动技能增加至5-6个，快捷技能键位增加一个，增加70-80级的符文啥的。至于物品等级上限就更容易了，估计源代码里面就是改改类markup文档而已。

不过换句话说D2也就何尝不容易达到所谓的等级上限？好吧，其实D2达到90级别人物就真的差不多了，东西都能用了，还要怎么样，后面的8，9级也就是几个技能点而已，这个时候大家也早就从build转mf了吧。

此外这作者估计也不是软件从业者，级别上限，物品掉落，难度梯度，真的是很容易改动的东西，难改的东西在画面，声光，引擎等一些底层核心的东西。从这次D3的表现来看，我估计他们留了相当多的接口可供扩展。

所以我认为作者这第一点，也就是停留在我不满，我没有成就感，太容易达到满级而没有目标等自我游戏性满足的基础上，当然这是无可厚非的，因为D3也就出来这么久，游戏性个人感受很难一样，也不可避免和D2做比较，这种感受很自然。


2，世界系统，这条我觉得作者是比较客观的，首先是随机地图，这个我同意作者的看法，随机地图不如D2，但是我估计这是考虑到所有运算都在服务器端，为了减轻服务器压力，可能省略了我之前觉得可能会产生的即时随机地图演算，而用了模块化的拼图随机地图，不过，作者须知软件业的名言乃是 done is better than perfect，我相信类即时随机地图的技术不难，但是如果达到了D3这种用户规模，那么在服务器端就会是个大难题，相比之下，有得玩总比服务器随时当机好，不是么？

接下来几条，全抗，暴击还有都是调数据的问题，非常容易，不谈。

至于基础属性，我觉得有个例子，那就是怪物猎人，怪物猎人只有装备的概念，没有角色技能升级啥的概念，但是这游戏可玩性相当高，我个人是花了上千个小时仍觉得技术有很大提高的余地。在D3上面，我是比较赞同这种忽视基础属性，大幅提高技能和装备作用的做法的，这种做法更接近真实世界，当然了，这是萝卜白菜的各有所爱的问题。

白色装备和传奇装备的问题我同意作者的看法，需要改进。

锻造，我不怎么玩锻造，没啥发言权，但是我觉得解决作者这问题也简单，调数据，改配方书掉率，降低锻造成本，但是相应的，AH上又会造成大波动，而玩家频繁自己锻造出牛逼货的代价，也会导致类似上古卷轴5里面锻造过于强大的问题，从而降低游戏的挑战性和重复可玩性，所以我建议这位作者考虑问题要联系其他方面考虑，不要单单只考虑一个方面，D3之余玩家是个游戏，之于暴雪和开发者，他是一个项目，项目的每个方方面面都有蝴蝶效应，往往牵一发而动全身，所以单纯的改动很容易，但是不说完美，完善的改动，则是相当相当难。

技能问题我之前的帖子里面讲过了，我支持现在的改变，作为一个软件从业者，我肯定不希望我的下个产品是上个产品的简单模仿，创新才是软件业的魂，在D3，我就很高兴看到了让我眼前一亮的系统，灵活，摒弃了搭桥技能和绝对冷门技能。至于作者说的不适合D3，我觉得这话其实是不妥的，应该说成，不适合类D2衍生游戏，D3，就是D3，除了剧情世界观上面和D2相关，他不应该和D2在玩法上有什么必然的联系，他应该是个全新的游戏。至于作者说的一招鲜吃遍天的情况，其实是任何此类游戏无法避免的。这涉及到一个海量test case之后的优化过程，试想海量的test case都在一个规则之类找出某种最优解决方案，那么一旦这个规则有所漏洞，那么很快就会被海量test case发现利用并且无限放大，这个所谓的无限放大，就是把其他不那么方便的解决方案的价值弱化到接近于0，直到新的规则弥补这个漏洞，其实这就是个找bug和修bug过程，任何软件无法避免，其实不仅软件，比如法律什么的，也是在不断修正。站在用户的角度，自然是无法接受，但是站在开发者的角度，这叫做无法避免，世上没有完美的事情，所以我想暴雪只能说不断修修补补，至于要弄到所有人都满意，对不起，不可能。

我倒是认同作者那个5buff不能换技能的观点，这个确实是满恶心的，可能是为了提高难度吧。这个也促使大家去找那种一招鲜的方法了。

mf这个问题也是数据问题了，至于作者提到的那个类mf的算法，我觉得需要暴雪官方站出来解释一下算法，但是这是不可能的，因为这种算法一出来，马上有人会得出最佳mf方案，于是游戏又千篇一律了。这种事情无法避免，因为D系列本质是个刷刷刷mf的游戏，反对千篇一律其实本质上是在抵触刷刷刷。呵呵，人类还真是矛盾啊。

最后作者提到的暴雪团队问题，1，2那两条是不怎么正确的，如果我是D3的开发者，我肯定要做出自己的D3，D2最多是个参考，我希望D3被人记住不是因为D2，就这么简单，不知作者有没有实际run项目的经验，反正我run项目的时候，如果之前有类似功能产品，我做的最多精力的地方就是说服用户摆脱一些在用户使用习惯方面的比较，而要当作一个新产品去学习应用，这样用户才能发现我的东西有多么好。

至于危机公关能力，我没怎么看出来，不提，但是我也有这方面感受，那就是前方客户那边闹的再厉害，只要不是核心问题，我就胸有成竹，不就是5mins fix么？BA们，Sales们，给我去吧客户哄哄好就行了。何况暴雪这还只是个对单个用户而言几乎没有经济损失的客户端游戏而已，说道危机公关，未免危言耸听。想想当年的quake3好了，十几年的危机公关呢，虽然游戏不怎么样。

第四点操之过急我基本同意。

做个总结好了，对于D3，我看很多人都是站在纯用户的角度去评论这个游戏，这样自然是不错的，因为用户嘛，最终只有他们才能评判这个产品是好，还是坏，最终还是他们说了算，而产品所作的一切，都必须以用户为起点，我上面说了那么多，只不过是希望大家在站在自己角度之余，能够换位思考，站在从业者，商业流程，产品开发的角度，去思考一下D3的成败得失，会有更深刻更不一样的结论。

我个人倾向于降低buff时间从30min到10-15min。

那是需求分析，不是技术问题。

需求分析应该是贯穿一个产品life cycle的过程，在这个过程中应该随时跟着用户的需求进行调整，算是产品的一部分。站在软件开发的角度来讲，如果能进行简单的调校就能满足用户不同需要的话，这软件做的就是成功的，否则就是事先需求分析做的不够，至于调整成什么样，那涉及到用户具体的需求了。