One thing you’ll probably leave out of your game’s post-mortem, but shouldn’t

Having issues? The source could be the source. Whether you’re a team of one or 1,000+, smooth collaboration with a single source of truth can feel impossible.

When your team is wrapping up a big project and going through its post-mortem, discussing what went well and what could be better, you may not be thinking about your version control system (VCS), specifically. You might not be considering whether your VCS could serve your team better – or if it could be the tool standing in your way. 

So many teams struggle with communication gaps or not being on the same page, which can lead to major delays in your project. Before your team starts writing code for the next big thing, it could change the game for everyone to take a step back and look at your tools. What’s helping, and what’s hurting the work?

Rapid release cycles, large file sizes, and distributed teams working on mission-critical applications can prove challenging in even the best-coordinated companies, regardless of size. A good VCS should give your team a highly efficient workflow so that programmers and artists can collaborate quickly without compromising on performance, iteration speed, or branching and merging capabilities.

Questions for your post-mortem

Consider these questions in your next retrospective to diagnose whether an imperfect source code management (SCM) workflow could be the culprit that’s slowing down your pipeline.

Were our workflows more optimized or more disruptive? 

Not everyone’s workflow is the same. 

Game developers benefit from distributed version control for branching and merging, but artists rely on simpler, centralized file-based version control. Everyone has to work together. Something as basic as the tool used to manage these different use cases can cause huge problems with your build, resulting in everything from communication breakdowns to even lost work. If it lacks the flexibility to serve both centralized and distributed uses, version control can be a major performance and efficiency blocker. 

Are team members able to focus on execution without having to worry about disrupting someone else’s work? Have an honest conversation to determine if that could be the issue behind missed deadlines, bugs, and other challenges you encountered. 

How much time did we spend learning how to use our VCS tool vs making the game?

When it comes to your team’s source of truth, you should have as few barriers to access as possible. 

Whether you’re a small or large team, you’ll be made up of diverse experience levels and workflows. Your source code management could be slowing down your pipeline without your even realizing it, especially if you’re using a DIY solution patched together from different tools like Git or BitBucket or even a single tool that isn’t optimized for building a game. Many studios end up spending crucial time away from development writing their own internal documentation and SLAs just around version control. 

Is this an issue for the team? Gauge how accessible and intuitive the team feels your current VCS approach is – particularly those without the extensive technical know-how.

Were we quickly adapting to feedback, or were we putting out fires?

Feedback – both external and internal – can arrive rapidly. 

Your speed as you adapt to change is crucial to your game’s success. An inability to react quickly can clog your backlog, and make everything suddenly feel urgent. 

The technology should enable agility, not stand in its way. When changes are made, the source code is going to be the first step. Building a game with big files and huge repos, speed is going to be a challenge, not just for download and upload speed, but even the speed at which you’re able to isolate changes. Is it taking minutes or seconds? 

The ability to implement feedback and smoothly make changes can only improve the quality of your game while minimizing headaches. Determine whether speed was hampering your success during game development, and, if so, consider a VCS designed with binary files and huge repository sizes in mind.

How prepared were we when something went wrong? 

It would be nice if things could go right 100% of the time, but unfortunately, that’s rarely the case.

What’s worth assessing, though, is how prepared your team was to deal with issues, and, just as important, what kind of support they felt they had when issues did arise. In terms of a VCS, this could mean anything from integration with other tools, platforms, or game engines, or it could even impact security. 

Have an open conversation with your team about how they handled the issues they ran into with VCS. Did they feel they had strong support from the tool, either self-serve on forums or with direct guidance via email or phone? How responsive was the vendor when there were issues? 

You shouldn’t have to do it alone. Even if a significant problem didn’t come up during this game, being able to assess how fully supported your team was in implementing and maintaining something as crucial as source code can pay huge dividends for your next project.

Don’t let the tool stand in the way. Get started with Plastic SCM for free. 

Equip your team with the tools to do their best work together. Try Plastic SCM Cloud Edition for free or sign up for a 30-day free trial of Enterprise Edition for up to 5 users.

*First 3 users and 5 GB are free. After that, the price depends on active user count and total repository storage. Check pricing and conditions here.