{"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.