U3d跨场景开发解决方案

摘要

     需要说明的是，本人也不确定跨场景开发这个词是会出现怎样的歧义。简单的说，就是多人合作的升级，不再是多个人在一个Project目录下各负责某个模块，而是一部分人负责某一个工程。将工程分为不同的类型，以便于程序的扩展和维护。有些时候调整其中一个工程就可以实现变化，这样的划分的意义将凸显。设想有如下的场景：你有一个逻辑完善的程序框架，其中部分资源经常需要调整，或则是这部分资源调整就可以实现完全不同的关卡。而你只需要通过加载不同的配制信息，不改变任何逻辑就可以满足需求。此时，你应该会意识到，部分资源不应该放在逻辑程序中，而应该封闭起来，需要的时候加载出来。这样不仅维护了资源配制的安全性，还体现了程序的可扩展能力。

目录

    也许本文的解决方案不是最好的，但确实已经在项目开发中使用，在这里介绍给有相同需求的同仁，希望对其有所启发。下面是关键的几个点：

        1.好好利用unity3d自身的优势

        2.资源自动关联是本方案的核心

        3.共享内嵌同步版本

        4.资源发布及资源加载方案

一、好好利用unity3d自身的优势

    unity3d是一个基本脚本的引擎，其中一个脚本开发的好，可以用在多个对象上，只需要修改部分参数就可以实现不同的显示和逻辑等效果。正是因为这样，资源和代码的关系并不是传统游戏那个分离。有很多文章建议回到传统的开发方案上一，将资源和代码分离，用到的时候在加载资源。但这样明显是十分困难的，毕竟游戏引擎就应该让问题变得简单而不是让人烦恼。为此还是需要坚定对prefab的信念，提升使用prefab的能力。而prefab的加载中的三种方案只有一种可以满足跨工程，那就是AssetBundle。

二、资源自动关联是本方案的核心

    Assetbundle的打包后，可以利用WWW脚本加载出来，但脚本却不好处理。实际上逻辑需要改变的程序，可以加载lua脚本来实现，或直接使用反射来实现脚本动态。本文不做热更新任何说明，因为这个解决方案不涉及脚本的更新，且适用所有的平台。在一个工程中配制好之后凭什么可以在另一个有相同脚本的工程中自动进行关联？那就是GUID,每一个导入到unity3d 的Asset目录下的文件都会生成一个.meta文件，除非你设置了隐藏。这个.meta文件就记录了资源的关联信息。如果你希望在资源自动关联，那么请确保两个工程中的.meta文件是相同的。

三、共享内嵌同步版本

   预制体和脚本的关联，非和脚本的名字进行关联。都是和.meta中的GUID进行关联，你需要做的仅仅是将需要保存信息和配制的脚本放置到一个版本库中，在资源工程和逻辑工程中进行共享。那么.meta就自动可以同步了。值得注意的是unity的控制台有没有提示guid重复的黄色警告，如果有，就要小心.meta被重写和资源关联丢失的问题了。共享版本的最大问题当然不是这个，而是你的资源工程应该尽量删除不直接需要的库引用，而没有这些库或是代码，共享的代码必然要报错！此时，不要惊慌，因为在资源项目中并不需要执行这些代码。所以注释掉就好了，但注释也有讲究，不是//也不是/**/，而是利用宏定义，确保在你的逻辑工程中，这些代码并没有被注释。

四、资源发布及资源加载方案

   以上的三个点理解了就可以做你自己的跨场景开发了，但实际上使用不同工程的资源包还需要一个资源加载的工具，这个工具可以在unity AssetStore 上下载免费或付费的，但目前应该没有一个和本方案贴切的加载及发布工具。所以为实现这样的一套流程，本人也有常规的资源打包器和资源加载器上进行了一定的修改，可见github。主要的功能就是可以定义多个长期保存的发布规则，每个规则中需要打包的资源不尽相同。具体打包那些资源就看你的用户需要了。

五、后续

   1.动态添加资源包设想

         由于以上的方案中是直接在从资源路径加载，所以只需要修改配制就可以实现不同的关卡加载。如果你能把用户需要的资源制作成一个压缩包如zip，那么程序就可以实现从这个资源包中解压后更新到你的程序中。而你的逻辑工程没有进行任何改变，这样你的程序也不需要进行任何打包，用户只需要到你的商店购买相应的资源就可以进行其他效果的体验。

   2.如果需要选择性打包,可以参考这个工程：CrossProject