Downloaded 18 times
Uploaded byPerforce
Is Trunk-based Development Easy in Game Development?
Trunk-based development in game development can enhance stability and agility but requires adequate tooling to manage challenges related to continuous integration and branching. The document highlights the complexity of AAA game development and emphasizes careful management of binary assets through componentisation and short-lived branches to avoid merge conflicts. Perforce is presented as a key tool for effectively managing version control and collaboration among large teams across various domains.
More Related Content
![[1216 박민근] 게임회사취업및이직에관한조언](https://cdn.slidesharecdn.com/ss_thumbnails/1216-111117021737-phpapp01-thumbnail.jpg?width=640&height=640&fit=bounds)
![[DEVIEW 2021] 1000만 글로벌 유저를 지탱하는 기술과 사람들](https://cdn.slidesharecdn.com/ss_thumbnails/1000-deview-220204010915-thumbnail.jpg?width=640&height=640&fit=bounds)
![[세미나] 특이점이 온다](https://cdn.slidesharecdn.com/ss_thumbnails/2015-160310041803-thumbnail.jpg?width=640&height=640&fit=bounds)
![오딘: 발할라 라이징 MMORPG의 성능 최적화 사례 공유 [카카오게임즈 - 레벨 300] - 발표자: 김문권, 팀장, 라이온하트 스튜디오...](https://cdn.slidesharecdn.com/ss_thumbnails/t3s1-221108101729-c6b32f4f-thumbnail.jpg?width=640&height=640&fit=bounds)
![DevOps : mission [im]possible ?](https://cdn.slidesharecdn.com/ss_thumbnails/devops-mission-impossible-final-150729142355-lva1-app6891-thumbnail.jpg?width=640&height=640&fit=bounds)
Similar to Is Trunk-based Development Easy in Game Development?
![[CCP Games] Versioning Everything with Perforce](https://cdn.slidesharecdn.com/ss_thumbnails/versioning-everything-ccp-games-slides-130524110821-phpapp02-thumbnail.jpg?width=640&height=640&fit=bounds)
![[Perforce] Component Based Development in Perforce](https://cdn.slidesharecdn.com/ss_thumbnails/component-based-dev-slides-130523180330-phpapp02-thumbnail.jpg?width=640&height=640&fit=bounds)
![[NetherRealm Studios] Game Studio Perforce Architecture](https://cdn.slidesharecdn.com/ss_thumbnails/game-studio-perforce-architecture-paper-130523181105-phpapp01-thumbnail.jpg?width=640&height=640&fit=bounds)
![[NetherRealm Studios] Game Studio Perforce Architecture](https://cdn.slidesharecdn.com/ss_thumbnails/game-studio-perforce-architecture-slides-130523181224-phpapp02-thumbnail.jpg?width=640&height=640&fit=bounds)
![[Ubisoft] Perforce Integration in a AAA Game Engine](https://cdn.slidesharecdn.com/ss_thumbnails/perforce-aaa-game-engine-slides-130523170858-phpapp01-thumbnail.jpg?width=640&height=640&fit=bounds)
Is Trunk-based Development Easy in Game Development?
- 1. Is Trunk-based Development Easyin Game Development? Sven Erik Knop Perforce Software
- 2. Challenges in GamesDevelopment • Why is Games Development so hard? – Besides the obvious I mean … • Average AAA game: – 100 of thousands of files – 1 TB+ source code and assets at HEAD – 50GB + changes a day – 100+ Team size
- 3. Consequences • Continuous integration –Builds take minutes (incremental) to hours (full) – Smoke tests? – Full tests? • Who broke the build? • HEAD is not stable!
- 4. Coding practices compared •Different ways to organise your sources • There is no single best way – Team size – Target platform: Mobile/Console/PC/4K/… – Rate of change – Iteration frequency
- 5. Single Code Line Head StableHead still stable?
- 6. Development branches Long-lived developmentbranches can cause problems
- 7. Task/Feature branches Keeping featurebranches short-lived avoids severe merge conflicts
- 8. Vignette: mergeable objects •3-way merge for text documents
- 9. 3-way merge forbinary assets? • Images? • 3D models? • Sound files? • Locking! • Across branches?
- 10.
- 11. Trunk-based Development Trunk Release Extended testingfor release Requires tooling! Stable
- 12. Milestone branches Stabilise inseparate branch Merge fixes, ignore hacks
- 13. Summary • Stability versusAgility • Trunk-based development can offer both – If supported with the right tools • Careful with branching of binary assets – Consider componentisation instead
- 14. Perforce • Perforce helpsdelivery teams build complex products collaboratively, securely and efficiently. • Commonly used for… – Software – Games – Electronics – Animations – Chipsets – Medical Devices – Internet of Things
- 15. Who uses Perforce? 13,000 20,000 users 9,500 users 500+ terabytes 5,000+ users coders & designers 10,000,000 Perforce xact/day Everything! 11,000+ users Chips Games & Animation Cloud/SW Electronics Systems Automotive
- 16. Perforce Helix Contributors Consumers FlexibleWorkflows Version control, code reviews, simple file sharing Fast and Scalable From 10 to 10,000+ on a each trunk Every File Efficiently handles large, often binary, data Everywhere Supports geographically distributed teams Secure Granular permissions, theft risk monitoring Open and Extensible APIs and integration hooks for customization
- 17. Streams Parent-child relationship betweenstreams Development and release stream types Virtual streams for easy componentisation
- 18. Conclusion • Trunk-based developmentis a good thing • Requires the right tools • Recommendation – Componentisation – Protected release streams – Keep everything in one repository
Editor's Notes
- #2 Trunk based development (TBD): single shared codeline for the whole team Every change is immediately visible to all other members in the team. One famous proponent of TBD is Paul Hammond (http://paulhammant.com/2013/04/05/what-is-trunk-based-development/). TBD avoids errors through late merges of long-living development branches. TBD requires Continuous Integration (CI) to ensure the quality of the trunk.
- #3 [Animation] 2 steps The problem with games (in general) is the size of the assets: The move to high definition consoles increases the size of the assets into a game manifold Games used to be delivered on a single Floppy disk! Remember floppy disks? 720KB! Then came CDs. 700MB. Then came multiple CDs. N * 700MBs Now most (Windows) games come on DVDs – 4.5 GB per layer, 8.5 GB for a dual-layer DVD-R. Ever installed Shadow of Mordor? 5 DVDs, or a single 25 GB download – so you better have high speed broadband. On the console that is a single Blu Ray disk, 25GB as a single layer. These games are the finished article, all assets compiled and compressed – in HD format. 4K is looming, which will quadruple the space requirements again! So, what are the consequences?
- #4 We cannot do trunk based development – and keep the trunk stable. What are the alternatives? Let’s have a look at some of these ideas
- #5 Caveat: this talk is simply there to show you that there are other ways. By no means do I want to insinuate that I know all the answers. Your way might be better suited to decide how to code and organize your game.
- #6 [Animation] So here is the naïve version of TBD – a neat linear succession of individual changes, at the end of which is a stable release. Alas, as your developers and artists add changes, the picture changes. Because of the time it takes to build and test each check, you cannot hold of the submit of a change until it is verified – or no one can ever submit any changes. This means that any game studio that uses a single code line for coding their game will wind up with a pointer to the last stable verified version, while the head is most likely broken.
- #7 [Animation] So what about branching? Well, short live branches often work quite well, as long as I remember to update the branch and test before I deliver the changes back to the shared trunk. This is called the merge-down / copy-up protocol (explain depending on the audience) What about long-lived branches? The problem with long-lived branches is that the trunk moves away from the branch, which makes merging/copying a lengthy and potentially destabilizing process. This can be addressed by updating the development branch on a regular basis (a rebase), but, neglecting that, merging long-lived branches can be very painful.
- #8 So the alternative is short-lived task or features branches – which avoids the complexity of merging large amounts of history. Another, and more and more popular way when using trunk-based development, is to add feature toggles, avoiding the need to branch for a new feature completely. No branching, no merging. But what is merging anyway?
- #9 lets have a look at merging two text files. The only way this can be done effectively is with the help of a third file – the base. This gives rise to the notion of the 3-way merge. When you look at the base and the changes both in source and target (marked in green), you can see that with the help of the base we can calculate the real changes in both source and target, and merge both files together, leaving only one real conflict (for D). Without the base we would have two additional conflicts – making the merge a lot more uncomfortable and potentially error prone.
- #10 [Animation] And for binary assets? For the majority of file types merging the files will be impossible – there simply is no tool out there that can calculate the difference of an arbitrary set of binary files in a meaningful (i.e. mergeable) way. Where does this leave us for a development shared across a large team? <click> Locking? The locking workflow is extremely useful here, since the alternative is that two artists touch the same file and one of them will loose all their work – since their efforts cannot be merged. <click> Across branches? Locking across branches does not work – and not that people have not tried that. Perforce has many requests to make locking across branches possible – and the answer is always the same: What do mean by locking across branches? See, if I change and submit one file in my development branch, the lock gets removed – that is the workflow of a lock. If someone else has the same file branched into her development branch before I modified this file – and then checks the file out after me and submits it, there is no lock anymore, so both our modifications still clash – and one of us will loose all work.
- #11 One way to solve this conundrum if you still want to use branching is to split out the binary files into a separate codeline. That is: break down the game into its components and develop each part separately. There are two essential ways to do that: keeping text and binary source files in a single trunk, but filtering out the files depending on the user. So artists would get only the binary assets (or a subset thereof) and maybe a compiled game engine to test the result Developers might get a compiled set of the binary assets or only the text file. Each file, whether text or binary asset, when submitted, appears directly in the shared trunk totally separate trunks for code and assets, importing the required files (or compiled artifacts) as needed Despite the separation, you should still have full control over the whole project, since each individual component should be stored in a central repository – the single source of truth
- #12 There is an alternative to all this – and Frank Campagner from Guerrilla Games has talked about this at the Perforce Merge conference 2014: They tried different approaches but in the end came up with a single trunk but with a twist – a separation between the trunk and the stable version. Instead of just simply marking a stable version on the trunk, changes (bundled by features) are promoted through a tool written by Guerrilla Games. This tool lists all eligible features together with their testing status. Once a feature has passed all tests it can be promoted to the release branch – which itself is never touched directly – only through a controlled release. Testers and interested parties can then use any version of the release branch – every single instance has passed all tests thrown at it. This way Guerrilla Games have a releasable version at least every week.
- #13 Besides the different ways to organize your code lines for games, one method you should definitely adopt: Use a separate branch for your milestones. Why? Because you will probably find that you need to take shortcuts for your milestone and introduce some hacks to get the game into a state it can be demonstrated. This hacks have a tendency to stay behind if you do this in the trunk – so separate the milestone into its own branch, fix the version there, then decide which of this changes are worthwhile keeping and which changes should be better be left behind.
- #18 What do branches give us? Talk about virtual streams as well as a way to keep everything in a single trunk and yet be able to work only on a small subset.