unity3d c#脚本小问题

第一行是在建立一个胶囊基本体，而第二行是获取这个基本体上的刚体组件，如果没有其他代码的话，这个刚体组件还没附加上，可以用AddComponent()函数来附加rigidbody组件。

c#的话，一般用 GetComponent<Rigidbody>() 这种方式来获取

大家都知道，U3D中，我们可以为某个对象编写一个脚本，然后将这个脚本挂在对象上，那这个对象就拥有了相应的能力。 但，由于脚本的威力是无穷的，它不仅可以 *** 作这个对象本身，它同时还能改变整个世界。而U3D这种十分方便的开发模式，和你在FLASH CS中新建一个MovieClip,然后在它的时间轴上写代码如出一辙。 这种代码驱动的方式，在某些场合是非常有用的。

比如。 怪物AI，状态机，一些特殊的效果等（比如，摄相机振动）。

也就是说，如果我们想要让自己的代码很好地管理，那第一步，就是要限制代码与对象的关系。 世界中的任何单体对象，都不应该拥有改变世界（游戏逻辑）的能力。它唯一能做的，就是 *** 作它自己，同时，如果遇上了自己能力以外的事情，必须要向管理器报告。

所以，为了实现数据驱动，我们的游戏大概有以下几种东西。

1、一个逻辑管理器，它决定了整个世界是如何运转，不同对象之间如何交互

2、事件管理器，它负责接收来自各个对象的报靠，比如（啊，有人踩到我了；咦，这是一个传送点耶；哎哟，你为什么点我。） 事件管理器起到事件队列缓存的作用，同时，游戏逻辑应该定时处理这些事件。 当然，这个事件管理器，也是逻辑管理器的一个小弟，如果逻辑管理器觉得不怕麻烦，也可以亲自 *** 刀，负责事件收集。

3、若干对象相关的脚本，用于决定对象能力。 这些脚本不做别的，只做它们自己目标对象相关的事情。 比如，控制一个对象的动画切换，检查敌人是否进入攻击范围等等。 这些脚本，是做为脚本的一种能力挂上去的。当相应事件触发时，他们会将事件通知给事件管理器。 理论上，我们是可以完全避免这样做的， 就像早期的引擎中，对象只是资源，逻辑代码用来 *** 作这些资源。 但是，既然U3D提供了如此便利的东西，我们为何不用呢。 因为有许多事件的检测，U3D已经为我们做好了，并且，也只有挂接在此对象上的脚本，才能够监听到这些事件。 比如OnTriggerEnter

以上就是关于unity3d c#脚本小问题全部的内容，包括:unity3d c#脚本小问题、unity数据驱动脚本怎么看、等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！