我正在做一个与团结游戏,并有问题,试图网络同步。确定性模拟是不可能的,因为统一的内部逻辑是基于浮点数的。我试图做出一个解决方案,它适用于一个权威的客户机-服务器模型,在这个模型中,每名士兵的位置被服务器每秒5-10次校正。这是通过发送UDP数据报来实现的,并将采取措施确保交付。在更正之间,客户端尽可能地模拟游戏。
士兵们通常不会直线移动。他们成群结队,并将遇到许多障碍,他们必须通过。士兵以个人身份存在,而不是作为小队目标的一部分而存在。
有一些事情可以做,以减少带宽消耗,这不是这里的重点,因为它们充其量只是暂时的改进。就像只发送正在移动和/或观察的士兵的位置,并在传输之前压缩数据。
问题很简单。如果我有十个士兵到处跑,那就好了,但如果我有一千人,那么带宽的使用就变得不合理了。至少我们需要发送一个士兵id (ushort)和位置(浮动,浮动,浮动)每个士兵。现在是2+4+4+4= 14个字节。可能需要更多的数据,例如面对的方向(士兵从不向上或向下看)。
14 * 10 * 1000 =140 14/S太过分了!
问题是:
可能的解决办法:
我们不是为位置的XYZ轴发送一个浮点数,而是发送一个字节。因为这是-128到127,我们可以读/写它,说新的位置是士兵从最后一个位置开始的最大速度的百分之一。如果有效的话,可以将数据从14字节减少到5字节。但即使是36%的数据,对于1000名士兵来说,仍然是50 is /S。
这可能会在某些时候减少到4个字节,因为士兵并不总是向上或向下移动(Y轴)。但这就像忽视那些没有行动的士兵,而不是问题所在。
另外,如果一次活的士兵不超过一千名,我们可以给士兵分配一个活生生的ID,所以把网络ID从16位缩短到10位,这样我们就可以计算到1024位了。
总之,这将使每个士兵发送的数据从14字节减少到22位(2.75字节)。我怀疑这比第一个保持同步的想法更不可能。结果可能是过于紧张。如果它确实工作,它将是20%的原始带宽,在28 at /S。
..。
任何想法在这一点上都是受欢迎的。我一直致力于制作越来越小的矢量3‘S,但可能有一个更好的方法来实现这一点,做一些完全不同的事情。
发布于 2017-10-19 17:36:56
即使在最快的设置下,标准压缩算法也是相当有效的。作为一个快速测试,我用34k字节填充了一个文本文件。压缩速度最快的7-zip给了我一个1k的文件。大约是原来尺寸的3%。当然,我的数字存储为ascii,但它表明,类似的值可以减少到一个很小的部分。
使用标准算法可能会被其他答案中讨论的特殊技术所超越,但是标准压缩技术应该实现得更快,使用经过良好测试的算法的错误也更少,但是如果结果“足够好”,您可以选择是否希望使用所获得的时间更快地进入市场,或者在用户实际感觉到的领域进行更甜蜜的游戏。
发布于 2017-10-19 16:12:49
在我看来,如果你有1000人在屏幕上,他们是成群结队的,每个人的确切位置不会像你有10人时那么重要吗?
随着总人数的增加,你能让士兵们集合起来吗?所以,当我有10个移动的东西是一个单一的士兵。当我有100人时,他们是10人的小队,只有一个位置和一个队形。当我有1000人的时候,他们是在100个单位的阵型中?
这将允许您无限地缩放,尽管您将忽略细节。
发布于 2017-10-20 20:46:16
你发布的许多想法都是好的。在某个时候,你会达到饱和点,所以你需要做一些权衡。其中一些权衡取决于你的电网有多大,你的单位移动的速度有多快。我将尝试添加几个选项,您可以查看:
您可能可以将方位和速度打包成一个字节。前4位将是方向(在小屏幕上16个方向应该足够好)和第二个4位速度(从最大速度的16级)来表示由于障碍造成的减速。
这需要从14到6之间的数据,但您一次只发送200名士兵的数据。这意味着每名士兵每秒会得到2次更新,但是它有足够的数据来精确地插值差异。这使得数据报从5* 10 * 1000 (50,000字节)变为6* 10 * 200 (12,000)字节。还是不漂亮,但更好。添加快速LZ4压缩,您可能会得到它在1300字节的甜蜜点,路由器将倾向于离开您的数据包。这实际上取决于数据的规律性。
如果总是按照相同的顺序发送数据,则可以为ID保存几个字节。您可以使用2个字节作为组的第一个ID,然后我们将得到一个已知的部队ID顺序。这使我们减少到3* 10 * 1000 +2 (30,002字节)或4* 10 * 200 +2 (8,002字节)。
https://softwareengineering.stackexchange.com/questions/359418
复制相似问题