unity脚本api_Unity 5：API更改和脚本自动更新

unity脚本api

As the breadth of the Unity feature set keeps on growing, and as we build it with more and more engineers at the same time, the necessity for being able to split up the product in separate modules becomes bigger and bigger. Obviously because it is just sound engineering practice. (It’s nice that when you change something in the physics code, that your audio doesn’t break). It also gets us closer to a situation where we could ship updates to different modules at separate timelines. And it’s nice that it gets easier to work on the different components with different teams. There’s one additional reason that is much more user visible: the ability to ship a smaller game. Don’t use particle systems? Don’t pay for them. Don’t use 2d rendering, Don’t pay for it. If you take a look at the WebGL demos that we posted, you can see that the entire unity engine that is converted to javascript (not manually thankfully!) clocks in at about 3mb of compressed javascript. That’s already pretty good, but we know there’s more juice to squeeze out of that. The web is still a platform where size matters a lot, and we want to bring the minimal size of a Unity published WebGL project down further. This is also true for other platforms, but at the moment, WebGL is definitely one of our more size-conscious platforms. So, with many good reasons to modularise the way we write code, test code, and ship code, we’ve started work down that path. There is still a very very long way to go, but if you don’t start you’re not going to get there either, so we started. While doing mostly non-user-visible work on this, we hit some dependencies in our API that need to be cut in order for us to proceed further in our efforts. Let’s look at that API problem: Many moons ago, when we started building our API, the C# code required to do something with a renderer component looked like this

随着Unity功能集的广度不断增长，以及我们同时与越来越多的工程师一起构建它，将产品拆分为单独模块的必要性变得越来越大。 显然是因为这只是合理的工程实践。 (很高兴当您更改物理代码中的某些内容时，音频不会中断)。 这也使我们更接近可以在单独的时间表将更新发送到不同模块的情况。 很高兴与不同团队一起在不同组件上工作变得更加容易。 还有一个更多的用户可见性的原因：发行较小游戏的能力。 不使用粒子系统？ 不要为他们付费。 不要使用2D渲染，不要为此付费。 如果您看一下我们发布的WebGL演示 ，您会看到转换为javascript的整个unity引擎(不是手动地感谢！)的压缩javascript时钟约为3mb。 那已经很不错了，但是我们知道还有很多汁可以榨出来。 网络仍然是一个规模非常重要的平台，我们希望进一步降低Unity发布的WebGL项目的最小规模。 对于其他平台也是如此，但是目前，WebGL绝对是我们更注重大小的平台之一。 因此，出于很多充分的理由对我们编写代码，测试代码和发布代码的方式进行模块化，我们已经开始沿着这条道路开展工作。 还有很长的路要走，但是如果您不开始，也不会到达那里，因此我们开始了。 在进行大多数用户不可见的工作时，我们遇到了API中的一些依赖关系，需要对其进行裁剪，以使我们进一步努力。 让我们看一下API问题：许多月前，当我们开始构建API时，使用渲染器组件执行某些操作所需的C＃代码看起来像这样

void Start() { Rigidbody r = (Rigidbody)GetComponent(typeof(Rigidbody)); r.velocity = Vector3.up; } void Start() { Rigidbody r = (Rigidbody)GetComponent(typeof(Rigidbody)); r.velocity = Vector3.up; }

1 2 3 4 5

void Start() {   Rigidbody r = (Rigidbody)GetComp