nba2k10mp模式不计算数据

nba2k10mp模式不计算数据原因：
1、网络延迟：由于网络延迟等原因，可能会导致游戏数据在传输过程中出现延迟，进而导致数据不准确。
2、服务器问题：如果游戏服务器出现问题，可能会导致MP模式的数据无法正确传输和计算。
3、作弊行为：有些玩家可能会使用作弊程序来获取游戏优势，这些作弊行为也可能会导致数据不准确。

首先，开火方只把开火的信息传送给服务器，服务器把某架飞机开火的消息通知其它所有客户端，其它客户机根据开火飞机开火时的位置和朝向（其它飞机的姿态由服务器通知各客户端）画出子d轨迹（很可能此时画的轨迹并不计算物理特性，只是简单地按直线画图，或者，只进行简单的重力计算，并不会做碰撞计算），所以，所有计算机都能看到某架飞机开火，并看到d道，只是各计算机看到的d道并不完全一致，存在微小的误差。但这并不影响游戏效果。至此，解决了你所提出的“其它人不会观测到你的发射的d药”的问题。
另外，关于我说“没有必要去计算d道和通知客户机”，是对服务器而言的。因为，考虑到服务器的性能和负载能力，计算128架飞机（IL2好像可能128人连线）的d道对服务器要求太高，不太现实。这就是服务器没有必要计算d道的原因。关于“服务器没有必要把子d飞行轨迹通知各客户机”，是因为：1这会造成大量的网络通信。2其它客户机不会计算开火方是否命中（这会由开火方自行计算），它们只关心这次射击的结果（为了正确呈现图像，它们必需知道这个信息），并不关心子d飞行的详细过程。”
看来我是这里唯一认为服务器要计算d道轨迹的人，写的有点长，都看看吧，讨论一下
我尽量说的逻辑性和完整性以及前后呼应
我不同意你的观点，应为漏洞太多，要让程序运行是要符合逻辑的，你作了太多的假设，论证一个理论是否成立可以用假设和推断，但是如果有多个论证那么取信那个所用假设小少者，明白？
我总结一下我的理论
1 我没有否认过客户机要负责计算自己的d道，也就是客户机要计算自己的d道，并显示其路径。
2 服务器同样要做计算，但是有可能和客户机的不一样（延时，或其他原因造成），服务器计算的目的是为其他客户机显示，有人问为什么？因为如果只由客户机计算的话那d道数据完全依赖于客户机的专递，如果客户机网络不好，d道将无法表现，我问就会看到空中有直线飞行的d药，如果有人能观测到这个现象并录像我就改变观点。当前的sky可以说网络状况不完美，但为什么我没有发现这个现象？不能完整解释我的问题的，我将始终保持我的观点，如果给我解释也一定要有足够的逻辑性，不要用可能、大概、也许这样的字眼，我本人是程序员，要有完整的逻辑性，我知道程序中不认这样的语句，凡事都要有确定结果，除非是做抽奖程序才会用到随机算法。
3 服务器除了计算d道以外，还要负责数据传输的工作，如所有战机的位置数据，游戏规则，积分。。。，这点大家意见基本统一。
4 有人说服务器负责计算所有d道数据会占用大量带宽和计算量，这个不完全对，要看程序是怎么设计的，算法如何，如果做的糟糕就会出现这种现象。
首先计算量和传输量不成比例关系，我大个比方，每天的天气预报是个计算量繁重的任务吧需要亿次计算机才能完成，但是如果你是客户机查询天气，那么服务器会返回什么数据呢，是不是传输量并不很惊人？当然这是个比喻，实际情况要比这个复杂的。
再者有人说负责所有人的d道计算，就会造成负载过大，这个就是程序优化的问题，从当今cpu频率来说，这不是什么负担。有负担也不是什么不可完成的任务，记住算法，一个软件特别是游戏软件的命根子就是算法，无论什么引擎，图像质量，3d效果，都以算法为基础，如果不优化那我们每人有能力购置一套能够勉强大大游戏的机器，去用IBM服务器吧，我简单说一下优化方法，当然不会是IL2用的，只是给大家提个醒。
以下有点长请耐心的看看
d道是什么？d道是个矢量线段，对吧，它不会改变方向，它的抛物线很容易用2次曲线来描述，也就说数学模型比较容易，但是如果实时的不停计算这个函数也会给机器带来负担，所以设计游戏是要讲究效率和质量平衡的。在3维游戏里，为体现游戏场景要建立坐标系（分为左手和右手两种3D3用的是右手（好像）），又分为，世界坐标系，视觉坐标系，坐标分为X,Y,Z，在视觉坐标系中X,Y是你面到方向的平面坐标，Z就是景深，还有一个W值也用来表示景物的远近关系，W在矩阵转换中用到，关键的是Z轴，2D都不具备理解Z轴的能力，有个Z-BUFFER听说过吧3D卡的标志？既然是坐标系就有单位可以按比例表现真实距离，IL2中肯定是这样做的。还有一个最小单位用来表现粒度的，也就是刻画的真实性，我们不可能将现实的东西完全模拟出来。好说了一大堆该回到d道优化的问题上了，无论是机q还机炮的轨迹如果等分成小线段，都可以看成是直线，所以直到分段合理就可以乱真了，而且也没必要没个时刻都算，只要在线段的分界处算就行了，进一步优化干脆都没必要算，只要预先把分界点出的数值计算成表格，使用时从表里查询就行了。在一步优化，我们不用每个d药到计算，射击会打出一串d药，那我就一起算因为他们飞行的路径大致相同，我们只要预先确定一个散布值做每颗d药的分量即可，这样看来就算有上百人同时开火，我们的计算量大吗？
这还是我的一点小想法，IL2的不知道要精明多少倍，我认为服务器要计算的理由就是，除此以外，都有各种漏洞没有解决，服务器计算并通知但不做命中判断，只为了给除射击方以外的电脑显示用，这样做到最公平，子d一旦射出就不再受到双方网络影响，作弊？你只能看到你到的电脑中敌机不断中d，但是它照飞不误全无反应！
最后无论是那方计算d道，都存在延时，这是当今无法避免的，但是我劝某些人别想利用这个来个所谓提前躲避，一句话没用！因为延时情况是多变的，每一时刻都不同，在者自己和对方延时不一样时采取策略也不同，又时因该是滞后 *** 作才对，所以如果潜心研究这个倒不如把心思用在提高技术上，认同否？

选择合适的服务器可以提高游戏体验，以下是一些选择服务器的建议：1 选择最近的服务器：选择距离自己最近的服务器可以减少网络延迟，让游戏运行更流畅。2 选择人数较多的服务器：选择人数较多的服务器可以增加游戏的乐趣，因为玩家之间的互动会更多，且服务器管理更为稳定。3 选择游戏类型相符的服务器：不同的服务器可能提供不同的游戏模式或者内容，选择合适的服务器可以更好地享受游戏乐趣。4 选择游戏运营稳定的服务器：选择游戏运营稳定的服务器可以保证游戏的质量和稳定性，并且减少可能存在的BUG和服务器故障等问题。5 选择活跃度高的服务器：选择活跃度高的服务器可以让玩家在游戏中获得更多的参与感和乐趣，同时也可以增加交友机会。

对于联网游戏来讲，同步的方式主要分为两种，状态同步、帧同步。
1、状态同步：顾名思义，是指的将其他玩家的状态行为同步的方式，一帮情况下AI逻辑，技能逻辑，战斗计算都由服务器运算，只是将运算的结果同步给客户端，客户端只需要接受服务器传过来的状态变化，然后更新自己本地的动作状态、Buff状态，位置等就可以了，但是为了给玩家好的体验，减少同步的数据量，客户端也会做很多的本地运算，减少服务器同步的频率以及数据量。
2、 帧同步：RTS游戏常采用的一种同步技术 ，上一种状态同步方式数据量会随着需要同步的单位数量增长，对于RTS游戏来讲动不动就是几百个的单位可以被 *** 作，如果这些都需要同步的话，数据量是不能被接受的，所以帧同步不同步状态，只同步 *** 作，每个客户端接受到 *** 作以后，通过运算可以达到一致的状态（通过随机种子保证所有客户端随机序列一致），这样的情况下就算单位再多，他的同步量也不会随之增加。
总结一下：
1、对于回合制战斗来讲，其实选用哪种方式实现不是特别重要了，因为本身实现难度不是很高，采用状态同步也能实现离线战斗验证。所以采用帧同步的必要性不是很大。
2、对于单位比较多的RTS游戏一定是帧同步，对于COC来讲，他虽然是离线游戏，但是他在一样输入的情况下是能得到一样结果的，所以也可以认为他是用帧同步方式实现的战斗系统。
3、对于对 *** 作要求比较高的，例如MOBA类游戏有碰撞（玩家、怪物可以互相卡位）、物理逻辑，纯物理类即时可玩休闲游戏，帧同步实现起来比较顺畅，（有开源的Dphysics 2D物理系统可用 它是Determisti的）。
4、对于战斗时大地图MMORPG的，一个地图内会有成千上百的玩家，不是小房间性质的游戏，只能使用状态同步，只同步自己视野的状态。
5、帧同步有个缺点，不能避免玩家采用作弊工具开图。

---