哪怕是到了现代，各路开发者们也仍然是在这个卡马克创造的体系上不断缝缝补补。
某种意义上算是一种绿皮科技。
靠着堆带宽和叠优化强行把问题给解决了。
这其中最关键的一个优化机制，同样是卡马克所创造的。
于1996年提出的‘QuakeWorld’理念。
也就是GAMENOVA早就已经用上了的客户端预测。
客户端不等服务器回应，先把操作处理完，等到信息传回后再尝试修正。
这样一来便大大地优化了那种按下按键后角色要等一会儿才会给出回应的割裂感。
按键不再黏手，也不会不跟手。
这套系统被一直保留到了现代FPS体系里。
……
卡马克和山姆一人一台PC，跟林立新这边联机在一起。
简单试玩了几局，林立新便停了下来。
到这里已经足够了，他也就是捎带手蹭点经验而已。
其实打从一开始他就已经有了一点想法。
如果要从技术的层面看待FPS类游戏的发展史。
做出过贡献最大的，除了卡马克和他的idSoftware之外，就只有一家了。
Valve，V社。
起源引擎以及《半条命》、《反恐精英》等一众作品，简直就是FPS的超大型实验田。
接过了idSoftware的棒，带领FPS游戏继续向着现代前进。
“咱们之前做的客户端预测虽然解决了移动上的卡顿，但在面对真正交火的时候没有任何帮助。”
林立新简单总结了一下，随后看向卡马克，
“不过我们可以延续这个思想，做出‘客户端侧武器预测’，类似移动的处理方式。”
这就是维尔福所采用的第一项优化技术了。
“让客户端自主决定是否开枪了？这……不太好。”
卡马克眉头微微一皱，难得顶了一句。
他曾经在设计客户端预测的时候考虑过这一点，但因为各种原因后来又将其废除了。
最大问题在于……作弊。
一个卡逼可以轻而易举地靠着延迟戏弄所有人。
如果刻意控制自己的网速，有的时候能起到奇效。
“不不不，它只是在演戏。”
林立新摆摆手，起身来到白板前，抄起笔便迅速画上了密密麻麻的内容，
“你们看，在现在的《Quake》里，卡顿感的主要来源其实就在开火这一层。”
“玩家虽然移动上不会有卡顿感，但如果是按下鼠标尝试开火，这些延迟仍然存在。”
“想象一下一位玩家在按下开火键后，要等待上百ms才会看到自己手里的枪开火了。”
“这种体验是十分令人恼火的。”
他解释的足够清楚，哪怕是山姆在此刻也听明白了。
“所以是……假开火？看起来开火了，实际上是自己客户端这边模拟出来的？”
“没错，真正的情况完全由服务端计算决定，仍然是靠信息进行回滚修正。”
第526章 无解的问题
子弹够不够，命中情况如何，对方的血量还有多少？
等到服务器把这些东西都搞清楚，这才会把数据回传给客户端。
如果客户端这边执行的东西被服务器否定了，那再尝试修正。
如果服务端说目标死掉了，客户端才会渲染出对方似掉的动画效果。
“啊！是的，应该如此！”
卡马克眼神一亮。
这种即时感才是联机最欠缺的东西。
让客户端尽可能哄着玩家先玩着，剩下的事情由服务器慢慢想办法解决。
想到这儿，他便立马要离席跑去开工。
但林立新立马喊住了他。
“别急啊，这才哪到哪，这只是个第一重保险。”
林立新直接伸手在白板上抹出一片空白，搓了搓手把油墨蹭掉，这才继续道，
“这样做虽然解决了即时响应的问题，但却会让《Quake》出现一个全新的BUG。”
他在上面写下两行字。
【FAVOR THE SHOOTER】（满足射击者）
【RESPONSIVENESS】（响应性）
这两种观念，就对应了在FPS这条道路上的两类完全不同的优化思路。
刚才设计的这个客户端预测，其实就是非常典型的响应性设计。
响应性设计的主张是：当玩家执行了一个操作时，他应该立刻得到反馈。
“你们看，这种设计最大的好处是什么？当然是符合玩家的直觉，操作干脆干练，简直就像是在玩本地游戏，完全感受不到联机的延迟。”
林立新在写着‘响应性’的位置点了点。
“可它并不是完美的，它最大的问题就是……打不中人。”
卡马克眨巴眨巴眼，等待着林立新继续说下去。
因为现在这两条放在一起，完全是在左脑搏击右脑。
刚才才说了客户端预测不能干预服务器判断，这样才能确保一致性和足够公平。
现在却又要把打不中人拿出来说。
“预测错误导致的回弹、子弹数量不对导致的只能听见枪响但没有开枪的情况、打中了人却没打中……”
林立新如数家珍地一条一条罗列着现在联机系统的罪状，
“为此，我们需要引入第二条优化策略。”
他的手向上移动，点在【FAVOR THE SHOOTER】那行上，
“我们要在服务器处理信息时，稍微……偏心一点，偏向射击者。”
“可那样不是又会导致……”
山姆开口道，不过还没说完，便被林立新给打断了。
“别急，我不是说让射击者完全本地化处理，命中与否仍然是服务器负责的。”
“……”
这下不管是山姆还是卡马克都没招了，静静等着林立新给出最终的答案。
“Lag Compensation（延迟补偿）。”
林立新解释道，
“预测能解决手感，而延迟补偿解决的是公平。”
他在板子上画了三个方块，让其中两个通过一个箭头连接到最上面那个。
显而易见的，这是个非常简略的客户端/服务端模型。
“你看，假设我们的延迟是100毫秒，那我们在游戏中看到的画面，实际上就是100毫秒以前的内容，而我们如果在这个时候开枪，打中的也是100毫秒以前的对手。”
这就坏菜了。
理论上来说，如果玩家是绝对精准地瞄准着目标进行开火，在这种情况下是永远都不可能击中正在移动的目标的。
除非这位高手能够牛逼到精准地推算出自己的实时延迟，并根据对方现在的运动状态、心理情况、战术策略等各种因子，综合推算出对方的下一步动向，并提前瞄准对应的位置。
但这显然是不可能的。
职业选手最多也就是计算个提前量打跟枪。
真正的完全预测根本就不是人脑能解决的。
哪怕是计算机也不可能完整计算出来。
“呐，问题就在这儿了，这样一来，玩家便会有种明明开枪了、也瞄准了、也打中了，甚至目标脑袋都飙血了，却毛事都没有，一点血皮子都没掉的诡异错位感。”
“而解决这个问题的办法也非常简单。”
林立新重新伸手，写下一个单词。
【Rewind】
当然不是以撒里的那种，不过也的确是差不多的思想。
“Rewind（回滚），确切地说是服务器回滚。”
“服务器不再实时进行计算，而是保存一份包含所有玩家最近几百毫秒以内的所有快照。”
这才是Valve的看家法宝。
比起前面的预测，这套系统的重要性完全是次世代的，彻底解决了高延迟环境下打不中人的苦恼。
“几百毫秒内的快照……”
卡马克喃喃道，忽然灵光一闪，似乎猜到了林立新是什么意思，
“林你的意思是……当玩家的射击信息发送到服务器时，不再根据实时状态进行处理，而是……检查快照？”
“没错。”
林立新满意地点点头，脸上露出笑容，
“我们让服务器去判断……当玩家开枪的那一刻，这个世界是什么样子的。”
当网络包发送到服务器的时候，服务器会根据状态调取对应的缓存，检查命中或是其它信息。
完成计算后再将结果和必要的修正信息返回给玩家这边。
整个过程大概会比原本增加几毫秒的延迟，但换来的效果却绝对值得。