免费unity源码

程序员摸爬滚打了五年 , 难道必须要读源码吗?源码就好比内功心法 , 外面使用的框架只不过是招式 , 一个内功深厚的人 , 平A都威力十足 , 所以必须看
学习Unity引擎更好还是学习UE4引擎更好?显然 , UE在这方面有着决定性的优势 。不过就当前的时间点 , UE和Unity的差距也不算特别巨大 , 并不存在代差 , 这和Unity和coscos的差距并不相同 。因此即使选择Unity作为基础来开发3A游戏也并非是不现实的(如果Unity在其他方面有优势的话 , 比如价格) , 只是并非优解 , 需要投入较大的开发成本 。
如果局限到移动领域 , 由于移动的机能限制以及用户成分 , 对新技术的需求较低 , UE在这方面就不再存在优势 , 但总得来说 , 也没有太明显的劣势 。事实上 , 两款引擎都可以满足目前的移动开发需求 , 虽然各有缺陷 , 但缺陷都可以比较简单地通过二次开发补足 。
注意 , 我并不是说引擎的内置功能是够用的 。就现在的移动开发需求而言 , 只使用引擎内置功能谁都不能很好的完成工作 。甚至可以说 , UE在功能的完整性上还略逊一筹(但是功能细节更多) 。但考虑引擎功能的时候不能只考虑内置功能 , 还要考虑那些已经针对引擎开发好的免费/付费三方扩展 , 他们和引擎的内置功能在使用上并没有区别 。
总得来说 , UE在移动开发的适用性上确实还是要差一些 , 但这个差距并没有那么大 , 更完全没有“不可行”这回事 。但是在之前大部分情况下确实称不上是优解 , 于是就没有被开发商所选择 。
简而言之在现在这个时间点 , 即使假设Unity因为某些原因而被国内封杀 , 只要UE还在 , 那么国内游戏业也不会完蛋 , 甚至都不会迎来很长时间的停滞 , 而且这个停滞更多是在人员学习成本而非改造的工作量上 。
(但是以前确实不行 , 但以前Unity也完全不能想PC主机那边的事儿对吧?)
【免费unity源码】功能扩展效率
如果需要对引擎进行扩展……总得来说区别不大 , 但通常情况Unity会具备一定优势 , 但并不多 。
Unity并不开放源码 , 它是通过开放一些底层接口来支持自己的扩展性的 , 而且处理得很好 。而UE对于扩展性的处理方法就是“开放源码” 。虽然看上去通过开放源码扩展功能比起使用引擎提供的底层接口更加Dirty , 但实际上也没有那么糟糕 。UE的源码同样也是分层的 , 如果你只关心你需要关心的部分 , 心智负担并不会太高 。如果一套源码仅应用于少量项目并且不关心在其他项目的兼容性 , 通过修改源码更新功能并不能算是一个难以处理的工程缺陷 。而且只要UE官方不要频繁重构 , 也能够正常同步UE自身的后续更新(哈哈 , 这点是很难保证 , 但重写渲染这种事也不会总有的 , 总之需要预备好合并版本的人力)
UE在这方面的缺陷其实主要体现在 , 每个用户扩展后的功能不容易通过社区与其他用户共享 。同一个问题 , 某个Unity开发者解决了 , 它就能直接把工程打包放到网络上(或者扔进商店)让其他用户直接使用 , 但UE的开发者就只能写一些教程来教其他用户怎么改 。这会导致你通过网络解决问题的效率变慢 。但如果你的问题本来就无法借助网络解决 , 那这个缺陷就等于不存在 。而且这个缺陷也只是交流没有Unity方便 , 而非不能 。
此外 , 直接通过修改源码来扩展功能 , 也就意味着这部分内容并没有官方教程以及参考 , 毕竟官方不可能每个功能都教你怎么改 , 那也太多了 。但一些常见的修改需求还是会有其他开发者的分享的 。但是一旦涉及到不常用的修改 , 恐怕就很容易陷入可能性的汪洋之中 , 对开发者的水平就具备了比较高的要求 。
(当然还有个问题是引擎的编译速度……但毕竟改引擎是低频操作 , 类似的情况还是忍忍吧 , 不要乱动Core这样的地方编译速度还是可以接受的 , 否则很容易陷入一次编译一小时的情况)
Unity虽然在扩展上要简便许多 , 但如果你的游戏有比较高的要求 , 依然会遇到必须修改引擎才能获得最优结果的情况 。而由于平时无法看到源码 , 只能使用黑盒测试 , 做性能调优方面的工作也尤其不利 。并且如果想接入一些三方中间件 , 直接接入源码也比从C#中转更加高效 。
而Unity其实也是可以购买源码的 。通过使用额外的资金购买源码后也就可以达到和UE同一水准 。不过这里其实有一个很严重的“坑”:和UE的源码不同 , Unity的源码实际上属于“别人的”商业机密 , 一旦泄露会产生非常严重的问题 。因此各公司对Unity源码的保护都是非常严格的 , 这自然会导致一般员工源码的阅读权和修改权严重受限 。当然 , 对Unity源码的修改内容也更不可能“泄露”了——你甚至都不能讨论 , 哪怕只是说说原理辅助解决使用上的引擎性能问题都不行 , 找公司外的人员帮忙处理问题当然更不行了 , 更不会有社区什么事儿 。因此 , 如果准备对引擎做出比较彻底的改造 , 相比直接使用UE , 购买Unity引擎源码这个方案绝对称不上是优解 。
虽说这也不是一个很严重的问题(概率小) , 但终究会让人觉得心里有些没底 , 从而对技术选型产生一定的影响 。
技术开发效率
虽然UE逻辑代码使用的是C , 但是已经经过了包装 , 内置了自动垃圾回收和反射 , 并提供了支持垃圾回收的整套数据容器 。如果使用最新的C编程规范 , 尽可能使用引用写法 , 并严格禁止各种所谓的“技巧” , 代码看上去和C#其实并没有太大的区别 。
而且C也并不算一个很困难的语言 , 觉得C难的程序员多半并没有接触过C , 毕竟

    推荐阅读