Best practices regarding scene(s) for collaborating effectively

I acknowledge that this question is rather large, so I will try to print out my teams current setup, which hopefully makes it easier to give a concise answer as to which parts of the setup can be improved.

So, the background. We are a team of 16 people broken down as this:
1 Project Manager,
1 Game Designer,
1 Producer,
1 Level Designer,
1 Sound Engineer
1 Art Director
1 Technical Director
3 3D Artists (Animation, Modelling, Rigging)
6 Programmers (including 1 lead)

And on top of that a QA team of 7 people, they are, however, not too relevant for my issues.

I’ve set up a pipeline where we mainly use git to all management, including assets (the actual human merge tool for the binary files would be the technical director). This works great 90% of the time, and all prototypes are merely on their own branch until they have been processed.

The workflow is pretty good, however, the single largest bottleneck in this setup is managing the scene(s). I’ve tried figuring out how other setups are working, but without any ‘real’ amazing answer. The issue comes when you have 1 master scene. This scene is tweaked by the game designer and level designer, further the programmers have to toy with things. Merging/handling this is hell. Currently we have a “MasterScene Meister” post-it. If you have this slip, then you are allowed to make changes to the master scene. As soon as it’s done, you put it back and another one can use it. This is pretty much what I understand Plastic SCM also does albeit their post-it is the digital lock-feature. The main issue with this is the fact that some times you are simply waiting for someone to finish up their master scene, so that you can integrate whatever you need to in to the scene as well.

I’ve seen some people talking about serializing/deserializing the scene, but I have not found too much information regarding this.

My gut feeling is that the issue is not actually attempting to merge 2 versions of the same scene together, but more-so that it’s the entire workflow which is faulty. So what do you do? Are you splitting the scene in to multiple scenes? This obviously allows more people to work on different aspects of the game in terms of scenes (thinking that you could split it to GameScene, UI Scene etc). I have no clue if this actually works in practice.

My main thought has also been, how does big companies deal with this? Any larger game (World of Warcraft, Hitman, Battlefield etc etc) must have had this issue as well, so how do you organize/tool your way out of it? My experience is it’s worst when we are nearing a new build at the end of a sprint, because some changes in the master scene ALWAYS seems to get lost somewhere along the way, so you have to pull in the people who have worked on the different types of features and get everything working together. This especially seems to be true with smaller type games where you have one master scene (mostly touch-games for mobiles/tablets where you don’t have huge environments you load in chunks, but merely have some sort of game screen like endless runners, candy crush-like games etc.)

I’m hoping there’s some best practice I have missed, which makes this odeal easier to work with - because currently it’s the largest bottleneck in the entire pipeline.

we have a smaller team than yours so I’m not sure if this will help you but I’ll share our general workflow.

We use a lock for certain scene files when large changes need to be made - similar to your post-it method. I’m not sure if you mentioned that merging scenes was a problem? We use Team Foundation Server (Visual Studio Online) and when the project settings are set to force text serialisation within Unity, trivial changes merge without an issue. This method also allows for human readable comparisons to be made is required.

You haven’t mentioned using prefabs? We make heavy use of prefabs to break up the larger scene into modules for editing. This means that the designers can be editing the scene, whilst the coders can edit the logic prefabs. Similarly, we also break down some scenes into multiple scenes. For example, we have a lot of our logic components and UI in a separate scene to the levels.

This doesn’t solve all problems but it does decrease the likelihood of team members making conflicting edits.

I hope some of that helped =)