去当unity游戏开发实习生应该具备哪些能力和知识？
0x01。项目前期规划中的问题
这里我们指的不是策划的需求，也不是游戏性的计划，而是作为一个Unity项目，我们需要在一开始就定义和制定好规范和标准。作为一个Unity项目或者软件项目，这部分非常重要，因为项目的前期规划随着项目的开发时间越长越难修改。
不清楚支持的最低型号。
作为Unity项目，首先要明确需要支持的最低设备标准。项目团队应该有这样的设备供开发和QA团队使用。
否则，项目的优化将是不可能的。
资源标准不明确
开发过Unity项目的同学可能都有过类似的经历，就是开发过程中的资源标准不明确。这通常是由于在早期项目规划中没有注意资源标准造成的。
所以在项目前期，最好明确模型中顶点数量、纹理资源大小格式等资源标准。
您还应该对每个帧开销中花费在脚本和渲染上的时间有一个目标和预期。
没有合理的资产装配线
这里的意思是资源要按照一定的流程和标准从art导入到Unity项目中。
许多项目以性能问题告终，因为没有合理的资产管道。因此，项目中的资源标准无法管理，许多冗余或不兼容的资源被内置到最终的安装包中。
所以作为项目团队，每个人都必须指定一个自动化的资产流水线。为资产的规格和标准制定明确的规格，并在自动化脚本中进行设置。
比如，texture是否开启读/写？纹理的压缩格式？尺寸？非人类模型在导入时会关闭装备吗？动画模型是否启用了优化游戏对象选项？等一下。
没有合理的建设和QA流程。
也有很多项目建设不顺利，建成的版本很难管理。规划或者QA往往是为某个功能的开发找一个包。
所以项目组可以思考以下问题:
有专门的打捆机吗？
一个新特性是如何发布到最终发布版本的？
是否有自动化可持续集成设施(CI)？
QA应该如何反馈bug，如何有效管理？
正式项目直接在演示原型上开发。
这也是常见的情况。在一些项目团队中，少数人会在前期开发一些试玩游戏。演示通过后，他们将开始开发正式的项目。
这时候就会出现一个问题，就是在Demo的基础上直接开发正式项目。因为很多Demo只是为了演示游戏性，所以代码中有很多具体的Hack来尽快实现需求。
如果正式项目以此为基础，到后期维护会比较麻烦。
除了上面提到的问题，还有一些其他需要注意的内容，比如制定统一的编码标准，确定光照模式(RealTime？混合？烤的？)等等。
0x02。项目开发过程中的问题
经过项目的前期策划阶段，到了项目的开发阶段，项目团队可能会犯哪些错误？一些不好的做法可能会减缓项目的开发进度，增加项目团队成员的焦虑。
不重视版本管理
许多团队不不重视版本管理，或者他们对git等版本管理不熟练。
当然，有很多关于git最佳实践的信息。建议项目组进行内部培训和普及，让每个人(编程美工策划等)都能操作符合规范的版本管理。
对于Unity项目，序列化的格式建议设置为文本序列化。
设置提交挂钩:
静态数据存储在Json或XML文件中。
很多团队喜欢或者习惯用Json文件或者XML文件来保存一些静态数据，在游戏运行的时候加载。但是使用Json或者XML文件保存数据会有以下问题:
装载速度慢。解析时会有内存开销。所以最好使用二进制来保存数据，Unity内部也提供了scriptableObject来帮助保存数据。
项目包含未使用的资源、插件或冗余库。
这也是很多团队的通病。一些废弃的资源没有及时处理，留在项目中甚至内置到最终发布版本中，造成了不必要的开支。
另一个问题是冗余或具有相同功能的多个库。比如项目中使用的很多插件都是使用Json解析库，会造成冗余。
仅在编辑器中测试性能。
这是一个非常不好的发展习惯。因为编辑器的性能成本是在编辑器中测试的，而不是在真正的目标平台上。因此，在创建概要文件时，必须在目标平台的设备上完成。否则只能得到误导性的数据。例如，在Editor中，APIGetCompon
unity3d对美术资源的加密方式有哪些？
C#代码混乱。深入来说，你可以尝试修改mono加载dll的。官方有一个开源的monogit。
楼上说assetbundle是加密的。如果在这里添加资源文件名，也可以使用md5哈希。
如果使用其他脚本来加密参考脚本语言本身，lua可以使用luajit，