定，计划总是没有变化快，很多没有预料到的事会让我们的计划无法执行。”
“前面开发者说的几周内就能上线，不会拖到几个月就是这样一个例子。在我们发表这条消息是，我们已经能确信只需要几周就能够做好塔纳安的细节，解决其他地图上的已知bug，然后就能开启飞行补丁了。很简单的事不是吗只用我们把几个字节从0改成1，就大功告成了。”
“然后，我们检测到的bug越来越多，超乎我们想象。我们发现这么小的世界居然无法完整适应飞行的机制，经常会发生玩家坠马摔死的情况。我们发现一些特定的坐骑和职业技能会导致这一问题，有的则是因为一些在线修正导致的，最终使得这些坐骑和技能无法正常使用。我们还发现，只要你从某个特定角度飞进要塞，你就会断线，然后在角色选择画面里卡上半个多小时。”
“查明这些bug，进行修正，测试修成，继而找出更多bug有时这些修正还会导致更多bug加起来的工作时间远远超过了我们的预期。因此，我们此前预计几周就能够上线的计划一直拖到了几个月。”
“现在，请不要误解我的意思：我并不是在这里给错误找借口。我也完全理解玩家因为我们无法信守诺言而产生的不快和愤怒。确实，如果我们事先就能预料到这一点，那么怎么也不会说只需要几周就能开放飞行补丁。我们犯了一个错，对此我表示深深的歉意。”
“但是，上面的解释至少能够让大家明白究竟发生了什么事特别是我们最近所犯的错误实际上，我们对这次的日期较以往有了更为充足的信心，但是，我们依然无法保证从今天到9月1号之间究竟会发生什么事。不过，我们觉得可以给出一个指定日期了。”
“不过说前道后，总会，在上线的最后那么一会出些茬子。可以这样说，即便我们在上线前的那个周六已经修正好了所有的bug，测试结束，等到下周补丁实装，你按下飞行坐骑，准备飞上天空，突然，你就闪回了西部荒野的墓地里。这种情况会发生吗不大可能，是的。但是，依然有这种可能，因此我们必须告知大家，无论如何，都有可能发生意外，这样说也只是为了避免届时发生这样荒唐的事。”未完待续。。
第八百二十一章体感计划
当然，暴雪也解释了玩家们狂喷他们的你们不应该设计一个不能飞行的资料片这个论点。
在蓝贴当中，他们是这样说的。
“实际上，我们确实是按照飞行来设计资料片的，只是除了飞行，其他还有很多内容，结果这些内容导致了飞行无法顺利进行。”
“比如，在德拉诺之王上线时，我们的服务器无法承受大量玩家登陆。结果技术员魔法般地让单个服务器的承载人数提高了几个档次。这样解决了承载力的问题，结果却导致了现在测试服里大量被迫下马踢出副本问题。”
“再比如，几周前，有几项漏洞使得玩家可以通过非正当渠道在德拉诺上飞行比如德鲁伊在飞行形态下离开阿什兰。我们再线修正了这些漏洞，结果这些修正破坏了德拉诺的飞行机制，使得正常飞行也无法顺利进行了。”
“显然，我们本来应该预计到这些内容可能对飞行造成的问题，但是我们低估了它们的严重性及修正难度。当然我们也不能因此而不进行修正，因为它们直接影响到了正式服尤其是服务器承载的问题，当时谁能想到会影响后续飞行呢。”
“在立刻就能让几万人登陆游戏，和未来可能或不可能发生的问题之间，我们立刻做了决定。但是，这样的决定终于引发了结果，现在，我们必须在621和622里面对他们了。”
“那么，再问：如果你们知道新的内容可能会引发飞行问题，为何你们还要在这补丁里加入这些内容，从而延迟飞行上线日期，给玩家找不开心呢”
“因为我们知道这部分内容不会导致飞行问题，结果确实也没冲突。在621622里没有导致飞行延期的内容。”
“负责开发的有多个小组，各司其职。修正德拉诺飞行问题的小组并不负责佣兵模式。职业平衡，宠物，坐骑等事宜。”
技术问题的不可预测性这就是一个非常好的体现。
修正一个错误可能会带来另外的一个错误，这是在游戏开发当中非常常见的事情，但是有的时候必须要先把目前的错误修正了再说，至于之后可能或者不可能出现的问题，那就要交给以后来解决了，比如暴雪特点说了德拉诺之王的刚上线的问题。
当时因为某些原因玩家同时上线的人数过多，毕竟当初人数曾经短暂回复到过一百级，有着很多的玩家。可能是大部分，只能够卡蓝条，看库兰德蛮锤骑着狮鹫的大腿。
玩家不能够上线大概就是一个网络游戏所要面临的最大的问题了。
所以，暴雪的工程师毫不犹豫的选择了先解决这个目前最大的问题，至于修复这个问题可能对于将来造成的影响谁还能管那么多，两害相权取其轻。
自然的，这只是很多跳票问题的原因之一。
而跳票的原因可能有七八个甚至是十几个那么多，想要做好一款游戏，并不是那么简单的事情。
其实杰斯特也挺理解育碧的游戏bug太多的原因。比如说当年的刺客信条：大革命的bug太多，被玩家戏称为大bug，这里面除了qa人员的不够之外，还跟育碧跟其他公司不大一样的开发模式有关。育碧是世界上统筹协作最好的游戏公司。
他们的统筹协作到底能够多么强大呢
举一个简单的例子，在大革命的开发当中，育碧可以同时动用分布在全世界不同的大洲不同的国家城市的旗下工作室同时进行工作，有人负责引擎。有人负责建模，有人负责地图，有人负责关卡
而所有的这些工作。都是在全世界各地的旗下工作室里面同步进行的。
然后再由总部将这些分别开发的子系统统合起来，就成为了一款完整的游戏是不是看着挺简单的，但实际上，因为这种开发模式注定会产生多到不可计数的bug的数量，而大革命据说总的开发人员超过一千名，qa人员可能就超过五百人。
这个人数实在是太少了。
就算是qa的时间占据整个开发时间的一半，也不够他们寻找所有的bug，甚至就连大部分都没有办法寻找。
而寻找到的bug，即便是修复了，可能qa人员也没有办法寻找到修复这个bug的方式会不会带来其他的原因因为实在是太多了。
而这游戏又不可能像是这样开放测试服务器，供给大量的玩家试玩，充当bug寻找者。
所以，当玩家看到大bug的时候，这款游戏的bug才会如同秋雨一样，连绵不绝，当然，统筹开发这种技术绝对是高端的技术，实际上，在杰斯特所在的那个时代，全世界能够玩好这一套的，能够进行分布各地的超过千人的统筹开发的游戏公司，也仅仅只有育碧一家而已。
在经过了大bug的教训之后，育碧缩减了大bug的画面以及系统，精简了开发团队的数量，甚至砍掉了一部分系统，比如说大bug里面为数不多的亮点之一联机系统。