The Shotgun team dedicated a big part of the company's focus this year to figuring out what tools we could provide to make the lives of Games teams easier, in much the same way we've done for VFX. We started our endeavor earlier this year by organizing an advisory board, at GDC, with some of the leading Games companies to discuss the problems they were trying to solve in their pipelines. The intel we collected percolated into a plan of attack and in order to validate that plan we decided to put together a proof of concept. We got so much positive feedback from the Games companies we showed it to that we felt we were in a good place to start implementing phase 1 of our Games / Perforce plan. Since then I've spent the past few months discussing, developing, iterating & refactoring Shotgun's Perforce workflow and now we're ready to show it off.
What is Perforce?
While most of the Shotgun team started in VFX or Animation, my background lay in Games. So rather than assume that everyone has the same frame of reference as me when I talk about Perforce, I thought it might be worth highlighting a few notes. Perforce is a traditional Source Control Management (SCM) system widely used by Developers for managing versioned files, similar to Subversion and Github. In recent years Perforce has gained significant traction with the Games world, in particular for versioning Art Department content. Perforce is now also rousing interest from VFX teams, who see the potential it can provide to help them work across multiple sites and locations.
How do Games companies working with Perforce differ to a VFX workflow?
While there are a lot of similarities between VFX and Games, two key areas where they diverge are in the storage of the versioned data that artists access and the fact that Games artists essentially work in a versionless world. All the versioned data lives on a Perforce server and each user has a local copy of the latest version of the files they need. Typically, Perforce is configured to only allow a single artist to 'check-out' and edit a file at any given time. Changes are then submitted to the server and the latest version is retrieved from the server as needed. With this workflow it means that referencing multiple versions of a single file are not possible (typically only the latest is available) which also means that version numbers are no longer needed.
How will it work with Shotgun?
We've extended the Publish and File Manager apps through custom hooks to be able to essentially 'check-out' / 'check-in' a file from/to Perforce. We've also created a daemon which is responsible for pushing this information from Perforce into Shotgun so it's all trackable.
We're excited to be coming to a point with our Perforce integration that we can start to hand over our Phase 1 workflow and get your feedback. We've still got plans for what we think should come next but want to hear what you think about our initial implementation, what would help your studio and what other issues we have yet to tackle. If you're interested in getting your hands on what we've done so far then please email firstname.lastname@example.org.