如今的大牌游戏都是动则10G、20G的,build系统已经成了一个创新的新领域。暴雪在GDC2013上就讲了他们自主研发的分布式build系统。
游戏的build不只要build程序代码,还包括各种美工资源的预处理,比如资源提取、校验、格式转换、组合等。而且这些资源普遍比较大,比如一个纹理图片的原始图片文件就可能有10M,模型的原始文件比如fbx或collada。Build系统会根据需要从原始资源提炼出不同分辨率的版本,以适应不同性能的客户端,而且各个分辨率级别的定位,也会随着市场的变化而需要调整。
当然,其实这里所说的build系统已经超出了狭义build的范畴,自动化测试、打包和监控面板等都在其内,也就是常说的CI(持续集成)系统。习惯上仍然叫build系统一是因为历史比CI这个词悠久,二是因为build部分是重中之重。
不同于源码的build,一个游戏项目的总原始资源量可能要上百G,而且有不少XML等适合中间处理的格式,加上复杂的算法,比如mesh简化、光照预计算、生成用于physics的model等,整个build一次所需的时间可想而知。所以,build过程通常需要集群来跑。嘛,三台破机器也可以算个小集群啦。
说起集群,性价比高的无非就是linux集群了。Windows集群成本太高,除非用D版,而且性能确实比linux差。但事实上也很难完全避免Windows,毕竟它是一个主要的目标发布平台,不少工具是必须在Windows的节点上跑的。
既然在说集群,这个build工具就已经排除普通的build工具了,而必须是分布式build了。不过呢,这个我也不熟,有兴趣的自己研究,可以去看暴雪在GDC201
说说游戏制作的build系统
最新推荐文章于 2021-04-26 17:55:10 发布
本文探讨了游戏制作过程中的构建系统,详细介绍了如何利用持续集成(CI)技术优化build流程,确保游戏代码的稳定性和高效编译。通过实例分析,展示了build系统在游戏开发中的重要角色和常见实践。
摘要由CSDN通过智能技术生成