问Unity3D大型地图建议-多大才算太大？

EN

以单位为单位的贴图本身的大小对性能并不重要。只需记住，Unity (就像任何其他游戏引擎一样)使用浮点数作为几何体，当浮点值太高或太低时，things can get funny。

重要的是你的逻辑、网络和渲染引擎必须处理的数据量。这些是不同的东西，甚至是逻辑/网络数据，它们的限制在很大程度上取决于游戏的架构。

让我们来谈谈网络吧。在这里，有两个参数对于您的限制至关重要:带宽和延迟。带宽是指您可以传输的数据量，延迟是指传输速度。好吧，这个解释是令人困惑的。想象一下，一辆装满硬盘的卡车从一个城市行驶到另一个城市:它拥有巨大的带宽，你可以通过这种方式传输整个数据中心。但是信号传输的延迟是几个小时。另一方面，来自这些城市的两个不同的人可以跳上气球，在夜空中看着对方，打开和关闭手电筒。这样，它们只能交换一位信息，但具有尽可能低的延迟:你不能比光更快。

这还取决于你的网络是如何工作的。例如，RTS游戏经常使用锁步多人架构，可以在数千个单元上操作，但只能在用户之间交换有限数量的数据:他们的输入命令。另一方面，第一人称射击很大程度上依赖于延迟(锁步可能会造成损害)：当你跳跃并发射火箭发射器时，10毫秒比你说你的部队攻击时要重要得多。因此，网络逻辑的组织方式是不同的:每个玩家的计算机都预测将会发生什么，但中央服务器对实际发生的事情拥有权威。当然，我现在写的只是可以使用的架构的一般示例；选择正确的方式进行联网是非常困难的，但也是非常有趣和富有创造性的任务。

现在，让我们来看看逻辑本身。实际上，现代游戏中使用的大多数游戏逻辑在cpu要求方面都相对简单，除非是物理或人工智能。在多人游戏中使用物理本身就足够棘手了，因为同步问题(还记得彩车吗？)；通常，影响谁赢谁输的实际逻辑非常简单:关卡几何完全是静态的，角色使用简单的逻辑移动而没有真正的物理力量，物理通常仅限于碰撞检测。当然，你会看到很多基于物理的视觉效果:被杀死的敌人的布娃娃倒下，爆炸产生的碎石飞来飞去；但这些通常在不同的计算机之间不同步，实际上不会影响游戏本身。

最后，渲染。在这里，有很多不同的约束条件。为了说明它们，我必须描述Unity在不同设备上的整个渲染管道，这显然超出了这个问题的范围。谢天谢地，还有另一种方法！而不是从理论上对这个极限进行推理，只是为了一个实际的原型。在场景中放置不同的游戏资源，在目标设备上运行它，看看它的表现。调整，重复！这些游戏资源可以是完全丑陋的，也可以是无关紧要的；但是，它们必须具有与您要在真实游戏中使用的相同的技术属性:多边形数量、纹理大小、着色器等。例如，假设您想要创建一个类似于COD的多人射击游戏。为了满足你的渲染需求，只需放入N个环境模型，每个模型有N个多边形，使用NxN纹理，放入N个角色和一些带有N个骨骼的骨架动画，也不要忘记一些模拟CPU密集型东西的假逻辑，这样你的性能测量就会更真实。当然，它不会给你一个最终的图片，但这将是一个很好的开始的方式，在你开始制作大量艺术资产之前，这样做是很棒的。

总体而言，游戏性能优化是一个非常广泛和有趣的主题，不可能对这样的问题给出准确的答案。

你可以改进减少相机的剪裁平面来减少可见的渲染距离，也可以使用LOD改进来使你的切片部分具有次要的细节。有关LOD的更多详细信息，请查看此链接：

http://docs.unity3d.com/Manual/class-LODGroup.html

如果你需要更多的改进，你可以制作一个脚本，根据玩家周围的距离在运行时加载地形。

首先，也是最重要的:让游戏发挥作用，以后再优化它。过早的优化是在浪费程序员的时间。

第二点:想想Skyrim和我的世界。当你四处走动时，世界被分成了几个部分，这些部分被加载到后台。使用这种方法(将你的世界分成小块)，你实际上可以拥有无限大的世界。