一个失败者的总结，希望对新人有所启发

apache2

本文可能很不专业，但是作为对连续这几个月求职失败的经历做出的总结，我还是写了下来……

主要针对数值、平衡、优化、执行效率的总结

我以前对数值的理解，一直局限在了随机性和公平性的设计思路上，最近读了WOW的圆桌理论，忽然领悟到了优化和执行效率的重要性。

之前我制作的游戏，虽然很小，但是执行效率普遍不高，我想一方面是我太能用并行了，另一方面就是判定上太罗嗦，根据这个，我想出了如下思路。

首先对WOW的圆桌理论简单概述一下，这是一个针对判定的算法，大致可以理解为他是一个幸运大转盘，被平分为了100个区域，指针转到哪个区域，就对应哪种判定，但是他最大的特点是有优先级，也就是区域内优先分布优先级高的奖品，如果100个区域先被占满了，那么很遗憾优先级低的奖品就不会被分配上了。

举个例子来说，如果一个人的躲闪为90%，那么另一个人的命中为20%，但是由于躲闪的优先级高，所以很遗憾，攻击者命中他的概率最高只有10%，这同时也解释了WOW盲目堆命中是没有作用的，但是这样一来公平性是否就被削弱了那？我想考虑到了权衡利弊，一次判定只ROLL一次随机数，相比对数值的优化，起到了很大的作用。

在我之前设计的命中和伤害里，我通常是先判定是否命中，然后才判断是否暴击，最后判断伤害总量，虽然优先级和公平性都体现出来了，但是至少要ROLL到3次以上，或者同类数值比较超过3次，罗嗦了不少。我之前只想到了随机性对玩家的惊喜、公平性对玩家的敷衍，可是和暴雪的设计理念比起来，现在看来需要学习的东西，太多了。

不过后面又仔细查了一些数据，发现WOW对公平性依然做出了体现，有这样一规则，每相差1等级，抵抗几率增加2%，也就是说如果攻击比自己高3个等级的人，那么优先级最高处，就判定了你最少有6%的几率攻击失败，这样一来同等级的比装备，而同装备的比等级，不但做到了平衡，还非常具有说服力了。

这里我又联想到了一条关于WOW资料片巫妖王之怒的一新闻，说是人物70级以后，等级越高，命中等级、暴击等级什么的所发挥的效率越低，我想1是保证了70以后的装备有足够的提升空间，肯定属性要比70的高，但又不能高的太离谱，2是防止了圆桌超过100%情况的发生，例如躲闪+招架如果超过了100%，那么玩家去70级以下副本不就无敌了吗，3是防止玩家穿70级积攒下的紫色装备，而跳过80级的蓝色装备，导致升级速度过快。

我又分析了一下WOW的BOSS掉落，虽然并不知道公式，但是圆桌理论确实提供了很高的执行效率，例如把BOSS可以掉落的装备，分布在1-100之间的数值上，那么转盘ROLL到几，就掉落几号对应的装备，而决定每次掉落几件装备的功能，就是一共ROLL了几次，难怪我们公会有个负责开BOSS的MM，每次都开出3件相同职业的T6，总被大家骂是黑手，不过这样计算起来，他的人品还相当的稳定那。

对比我以前设计的BOSS掉落装备，每一件都ROLL一次，确实实行效率太底了，还有一点不得不说的，就是WOW把ROLL的随机数，全服务器共享，这个更加优化了效率，而且不用每个需要ROLL的地方都对应一个随机数，同时还增加了公平性，就好像大家都喝一口井里的水，不用担心随机数列的问题。

例如我需要生成一个1-100的ROLL数，那么只设置一个随机数，攻击判定可以调用他，BOSS掉落可以调用他，玩家ROLL点也可以，好多都可以，不过前提是需要调用的范围，是1-100，或者2-101，这样长度的。

在这里我想到了以前我刚学JAVA时，设计的一段代码，其实很小儿科，就是指定一个范围在1-100的数，然后从1-100这100个数里对比相同的，通常用循环，需要循环100次，我当时处于好奇，就写了先判断这个数，是比50大还是小，然后在1-50或者50-100里对比，我当时没觉得什么，可是那时的JAVA老师一劲的说我有数值优化的天赋，现在回想起来，这样一来确实做到了优化，因为节约了49次判定。

类似的情况，我又突然想出了好多可以应用优化的地方。例如以前我统计杀怪任务的数量，就是纯并行，记录数量。现在我想其实可以这样来，首先需要一个变量，记录玩家从一诞生就开始，总杀怪的数量，然后每杀一个这种怪，也就是怪物死亡时自动触发，变量加1，一方面做到了玩家可以随时知道我击杀这种怪物的总数量，另一方面可以优化任务判定。

例如玩家目前击杀A怪的总数为100，那么玩家接到一个需要杀10个这样怪的任务，是否完成任务根本不需要用并行去监控，而是用接受任务时A的数值100加上任务需要杀的数值10，那么每次玩家需要判断这个任务是否完成时，直接判断玩家击杀过A怪的总数就可以了，如果总数大于110，那么就说明完成了，尤其针对循环类日常任务，优化了不是一点半点。

数值策划的求职就暂时这样告一段落了，我下一次面试是应聘剧情策划，希望大家可以祝我好运，同时感谢论坛里的每一位对我提供过帮助的朋友，谢谢你们。

sea_bug

圆桌理论我觉得只是在程序实现上做的一种优化处理，安排好各类概率，然后用一次随机数即可获得一次判定，而避免反复多次比较而获取的判定，从服务器效能来说，可以节省不少。

中草药

学好数据结构再来看数据优化

bigpear

所有运算都用同一个Roll,这个想法不错。当地图够大，需要大量Roll函数时，的确不如开一个线程，专门形成Roll函数，别的地方都调用这个函数得到Roll值。这样性能还稳定点，如果认为这个线程性能消耗太大，那只要降低运行频率或改这个Roll算法就可以了。

bigpear

杀怪总数，这个有待商议。如果都记录的话，玩家存储的对象是不是太大了？而且很多时间杀怪是没有必要记录的。不过这个的确是一个可行的解决办法，只是不知道和现在一般的做法比哪个更好！

bigpear

missiyou: Re: Re:一个失败者的总结，希望对新人有所启发



与其你这么说，还不如说是遗传算法．
有遗传．概率大就遗传选择机率就大．
为了保证公平．有时时候也...

遗传算法是比较强，但解析消耗的时间多啊！特别是调用数量级大的函数，性能问题就卡死了。

nowpaper

已经很专业了，你能将问题归结并且研究有成果，说明是一个有心之人，确实比很多求职者光说不练来的强。

ada0564

新人来拜读。。

祝你成功