1.【十一】重新起步
【十一】重新起步
哈,源码没想到吧,源码本专栏还有再次更新的源码一天。
其实是源码看到这个之后,决定把热更新也整合进去。源码既然要整合热更新,源码gmsh源码分析那现在的源码框架不得不重新写一次,因为代码最终要编译成Dll的源码。
这次重写的源码话,我做出了如下选择:
脚本语言:xLua
Unity版本:Unity .3.5 (VS)
文件夹设置:游戏工程的源码建立
没啥好说的,中规中矩建一个3D工程。源码随意新建一个脚本,源码用VS打开,源码在“解决方案管理器”视图找到Unity相关的源码引用,其属性为:
把路径里用到的源码东西打包复制到Dll工程的3rd目录下,供Dll工程引用。然后再找到pdb2mdb.exe和mono.exe:
如果电脑里有多个Unity版本,则可能会有多个该程序,选择对应版本的即可,等下要用的是路径,pdb2mdb.exe是初识源码DLL的调试符号转换器,不生成mdb就没法调试DLL中的代码。
类库工程建立
依旧是中规中矩创建一个类库的工程。先添加刚才准备好的Unity相关程序集引用,然后打开项目属性,设置生成后事件:
此处就使用了mono和pdb2mdb的路径,生成之后复制到游戏工程中。这里随便写了一个测试类,在游戏工程中可见,Dll中已经有这个类了。
打上断点,黑金 源码挂上调试。然后运行游戏工程,好的,成功断住:
接入xLua
将Plugin放进游戏工程中,将Src下的源码分别放进Editor目录和DLL工程中,测试一下:
没毛病,成功启动Lua虚拟机。接下来就是要配置xLua,选择一些可能要在Lua端使用的C#内容,按照xLua文档所示,源码生鲜直接整个静态类静态List,把要用的东西码入。
这里我根据个人的判断添加了如下内容:
然后调整一下配置生成器的路径:
然后执行一下生成命令,更新Dll工程,然后编译一下。是时候测试了。
也确实打印出来了“hello”字样。
API定义生成
写这种脚本语言,没有个编辑和调试插件其实是挺蛋疼的。这里推荐luaide,taskflow源码直接在vscode插件里找就可以,收费也比较便宜。
不过暂时还没有用它的打算,而是先接入它的api定义生成,这样编写Lua的时候可以相对直观的看到C#中一些api和数据的写法。
放进工程目录之后,修改导出路径,然后注释掉LuaIdeApi.cs里的菜单标签和自动生成;在xlua的生成函数末尾添加LuaIdeApi的生成即可。
这样,每次生成xlua内容的时候就会自动把api定义也更新,可以说是非常完美。
VS Code准备
用VS Code打开了Lua文件夹之后,会发现Unity生成的.meta文件也被计入了其中,因此我们要设定过滤,保证VS Code开发环境的清爽:
另外我比较习惯折叠代码,这点VSCode的Lua样式还没有,手动打开配置一下:
加载Lua
在编辑器下的开发应当越快越好,越高效越好,所以加载的时候,就有必要设计一种编辑器下的加载模式,跟使用AssetBundle或者其他自定义数据存储形式的生产环境不同,该模式应当做到修改Prefab\Lua等资产之后,无需打包即可立刻启动。
因为是为了测试xLua的加载,所以一切从简:
其中LoadContext是一个发起加载的上下文,该结构我暂时还没想好填充什么,不过也无关紧要,对于现在的测试来说,只要保证LoadLua方法可用就行。
这里使用System.IO.File而不是用AssetDatabase的原因是,“*.lua”在Unity中会被认为是DefaultAsset,无法被当做TextAsset处理。
在测试用的MonoBehavior类中用require('Game/Game'),打印成功。
Lua的class实现
才疏学浅,自己写的果然又长又臭,这里使用了quick-cocos2d-x的实现,但是因为我并没用到什么native C++的东西,所以大笔一挥,只保留了基本的Lua Object的内容:
好,我们来稍加测试一下:
表格的使用
将Excel表格生成成如下形式,代码可参照之前的内容:
使用一个_Data.lua来封装所有对数据表的查询操作:
测试,然后通过: