不同于《Maze War》这种低效的处理方式，《Quake》换用了一套更加先进的方案。
每一名玩家要在每一帧内都汇报操作。
只有局内所有人都广播完了操作，下一帧才会开始。
加上一些优化用的预测和回滚，整个游戏这才勉强算是能够正常运作了。
不过P2P也催生出了一个非常严重的问题。
一卡俱卡。
好处是不会有人因为网络差就被别人血虐。
但坏处也在这里，所有人都要跟着一起卡，一旦局里有个卡比，谁也别想玩过瘾。
这个问题几乎无解，目前社群里比较主流的解决方案就是……搬家。
如果两人之间的物理距离变近了，那网络延迟自然也会变低。
这也是林立新现在在这儿琢磨的原因。
他需要寻找到一个更优秀的方案，以应对接下来的新作。
“《Quake》现在的联机代码也已经过时了，不适合高速发展的互联网时代。”
“是……”
卡马克轻轻点了点头。
尽管这里面有很多他当初的奇思妙想，是他最引以为傲的‘荣耀’。
可即便如此，他也不得不承认这件事。
过时了。
时代发展的速度远远超过了任何人的想象。
兴许一年前还毁天灭地无往不利的东西，一年后就会变成无人问津的过时老梆子。
就像是i486轻而易举地就超越了ATHENA当初独领风骚的参数那样。
“不必担心，我们其实已经有差不多的技术栈了，只不过它还欠缺一些优化。”
林立新看到卡马克那有些受损的骄傲，出声安慰了一句。
对于一位真正的天才来说，技术被否定的确是一件很不舒服的事。
“客户端预测和服务器权威，咱们过去曾经尝试着做过。”
林立新回忆着。
纵观GAMENOVA的技术积累，从来都没少跟互联网打交道。
这里面用到的技术简直无奇不有。
上到《Quake》里的大量网络通信优化才得以实现的真实时联机，下至《Stars！》中用到的PBEM电子邮件同步……
可以说是只要是他们能想到的技术，基本都曾尝试着用过了。
历史能够证明，C/S模型绝对是符合时代发展方向的道路，至少在林立新的记忆中，在21世纪20年代后，现代游戏业也仍然遵守着这个规范。
当然这个C/S并不是后来V社的反恐精英，而是指的Client/Server模型，也就是客户端/服务端模型。
一个服务器，对应多个客户端。
客户端负责处理所有只需要本地处理的内容，比如渲染画面、播放声音、处理输入等。
而服务器则是只需要从完全数据的角度来处理各个客户端发送的输入信息。
哪怕是到了现代，各路开发者们也仍然是在这个卡马克创造的体系上不断缝缝补补。
某种意义上算是一种绿皮科技。
靠着堆带宽和叠优化强行把问题给解决了。
这其中最关键的一个优化机制，同样是卡马克所创造的。
于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】那行上，
“我们要在服务器处理信息时，稍微……偏心一点，偏向射击者。”
“可那样不是又会导致……”