Adopting continuous delivery in AAA console games

Jafar Soltani
{"title":"Adopting continuous delivery in AAA console games","authors":"Jafar Soltani","doi":"10.1145/2993274.2993276","DOIUrl":null,"url":null,"abstract":"Introduction Games are traditionally developed as a boxed-product. There is a development phase, followed by a bug-fixing phase. Once the level of quality is acceptable, game is released, development team moves on to a new project. They rarely need to maintain the product and release updates after the first few months. Games are architected as a monolithic application, developed in C++. Game package contains the executable and all the art contents, which makes up most of the package. During the development phase, the level of quality is generally low, game crashes a lot. Developers mainly care about implementing their own feature and do not think too much about the stability and quality of the game as a whole. Developers spend very little time writing automated tests and rely on manual testers to verify features. It's a common practice to develop features on feature branches. The perceived benefit is developers are productive because they can submit their work to feature branches. All features come together in the bug-fixing phase when all different parts are integrated together. At this stage, many things are broken. This is a clear example of local optimisation, as a feature submitted in a feature branch does not provide any values until it’s integrated with the rest of the game and can be released. Number of bugs could be several thousands. Everyone crunches whilst getting the game to an acceptable level. Rare’s Approach At Rare, we decided to change our approach and adopt Continuous Delivery. The main advantages compared to traditional approach are: •Sustainably delivering new features that are useful to players over a long period of time. •Minimising crunch and having happier and productive developers. •Applying hypothesis-driven development mind-set and getting rapid feedback on whether a feature is achieving the intended outcome. This allows us to listen to user feedback and deliver a better quality game that’s more fun and enjoyable for players. •Reduce the cost of having a large manual test team.","PeriodicalId":143542,"journal":{"name":"Proceedings of the 4th International Workshop on Release Engineering","volume":"124 1","pages":"0"},"PeriodicalIF":0.0000,"publicationDate":"2016-11-18","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":"0","resultStr":null,"platform":"Semanticscholar","paperid":null,"PeriodicalName":"Proceedings of the 4th International Workshop on Release Engineering","FirstCategoryId":"1085","ListUrlMain":"https://doi.org/10.1145/2993274.2993276","RegionNum":0,"RegionCategory":null,"ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":null,"EPubDate":"","PubModel":"","JCR":"","JCRName":"","Score":null,"Total":0}
引用次数: 0

Abstract

Introduction Games are traditionally developed as a boxed-product. There is a development phase, followed by a bug-fixing phase. Once the level of quality is acceptable, game is released, development team moves on to a new project. They rarely need to maintain the product and release updates after the first few months. Games are architected as a monolithic application, developed in C++. Game package contains the executable and all the art contents, which makes up most of the package. During the development phase, the level of quality is generally low, game crashes a lot. Developers mainly care about implementing their own feature and do not think too much about the stability and quality of the game as a whole. Developers spend very little time writing automated tests and rely on manual testers to verify features. It's a common practice to develop features on feature branches. The perceived benefit is developers are productive because they can submit their work to feature branches. All features come together in the bug-fixing phase when all different parts are integrated together. At this stage, many things are broken. This is a clear example of local optimisation, as a feature submitted in a feature branch does not provide any values until it’s integrated with the rest of the game and can be released. Number of bugs could be several thousands. Everyone crunches whilst getting the game to an acceptable level. Rare’s Approach At Rare, we decided to change our approach and adopt Continuous Delivery. The main advantages compared to traditional approach are: •Sustainably delivering new features that are useful to players over a long period of time. •Minimising crunch and having happier and productive developers. •Applying hypothesis-driven development mind-set and getting rapid feedback on whether a feature is achieving the intended outcome. This allows us to listen to user feedback and deliver a better quality game that’s more fun and enjoyable for players. •Reduce the cost of having a large manual test team.
查看原文
分享 分享
微信好友 朋友圈 QQ好友 复制链接
本刊更多论文
在AAA主机游戏中采用持续交付
游戏通常是作为盒装产品开发的。有一个开发阶段,然后是bug修复阶段。一旦质量水平达到可接受的水平,游戏就会发布,开发团队就会转向新项目。在最初几个月之后,他们很少需要维护产品并发布更新。游戏的架构是一个用c++开发的整体应用程序。游戏包包含可执行文件和所有美术内容,这构成了包的大部分内容。在开发阶段,质量水平普遍较低,游戏经常崩溃。开发者主要关心的是执行自己的功能,而不会过多考虑游戏整体的稳定性和质量。开发人员花很少的时间编写自动化测试,并依赖于手动测试人员来验证特性。在特性分支上开发特性是一种常见的做法。这样做的好处是开发人员可以提高生产力,因为他们可以将工作提交给特性分支。当所有不同的部分集成在一起时,所有的功能都在bug修复阶段集中在一起。在这个阶段,很多东西都坏了。这是一个明显的局部优化例子,因为在功能分支中提交的功能在与游戏的其余部分整合并发布之前不会提供任何价值。bug的数量可能有几千个。每个人都在做仰卧起坐的同时将游戏提升到一个可接受的水平。在Rare,我们决定改变我们的方法并采用持续交付。与传统方法相比,这种方法的主要优势在于:•可持续地向玩家提供长期有用的新功能。•最小化加班时间,让开发人员更快乐、更高效。•应用假设驱动的开发思维模式,并获得关于功能是否实现预期结果的快速反馈。这让我们能够听取用户反馈,并为玩家提供更有趣、更优质的游戏。•减少大型手工测试团队的成本。
本文章由计算机程序翻译,如有差异,请以英文原文为准。
求助全文
约1分钟内获得全文 去求助
来源期刊
自引率
0.00%
发文量
0
期刊最新文献
A model driven method to deploy auto-scaling configuration for cloud services Escaping AutoHell: a vision for automated analysis and migration of autotools build systems Get out of Git hell: preventing common pitfalls of Git Your build data is precious, donźt waste it! leverage it to deliver great releases GitWaterFlow: a successful branching model and tooling, for achieving continuous delivery with multiple version branches
×
引用
GB/T 7714-2015
复制
MLA
复制
APA
复制
导出至
BibTeX EndNote RefMan NoteFirst NoteExpress
×
×
提示
您的信息不完整,为了账户安全,请先补充。
现在去补充
×
提示
您因"违规操作"
具体请查看互助需知
我知道了
×
提示
现在去查看 取消
×
提示
确定
0
微信
客服QQ
Book学术公众号 扫码关注我们
反馈
×
意见反馈
请填写您的意见或建议
请填写您的手机或邮箱
已复制链接
已复制链接
快去分享给好友吧!
我知道了
×
扫码分享
扫码分享
Book学术官方微信
Book学术文献互助
Book学术文献互助群
群 号:481959085
Book学术
文献互助 智能选刊 最新文献 互助须知 联系我们:info@booksci.cn
Book学术提供免费学术资源搜索服务,方便国内外学者检索中英文文献。致力于提供最便捷和优质的服务体验。
Copyright © 2023 Book学术 All rights reserved.
ghs 京公网安备 11010802042870号 京ICP备2023020795号-1