Production workflow improvements
The upcoming release of Unity 5.0 has a myriad of new features coming but also a number of improvements to workflows and production especially when working in a team will the improvements be beneficial.
One of biggest annoyances when working in a team is conflicts in the scene files. This can easily happen when multiple people are working on the same scene file at the same time. Most often this is because of prefab instances. Simply opening a scene and saving it again without modifying anything would make unity write all the prefab instances to the scene file which would certainly create conflicts if someone else was doing the same.
These types of conflicts in prefab instances were often hard to solve because they might be IDs and other properties where is was not always apparent how to resolve the conflicts.
The fact is that we don’t really need to write the prefab instances to the scene files, but for historical reason we have been doing that up until Unity 5.0.
In Unity 5.0 prefab instances are no longer written to the scene file.
This is illustrated in the picture on the left. Here I have created a simple scene in Unity 4.6 containing a prefab which has a Cube, a Sphere and a Capsule GameObject. On the left you see how all the instances are written to the scene, on the right only the reference to the prefab and the prefab instance modifications are stored in the scene file.
The only conflicts related to prefabs will now be in the prefab modifications which means two people modified the instance of a prefab in a scene and that should be a lot simpler to resolve.
A second cause for conflicts that is hard to solve and has been a problem for people working in a team is lightmapping.
In Unity 4.6 lightmapping properties like lightmap offset and scaling is stored in each Renderer that is included in the lightmap which means these properties are stored in the scene file. If two artist were both changing the same scene and doing lightmapping all these properties would probably conflict, resulting in a lot of tiny conflicts all over the scene file. Even if the changes to gameobject did not conflict. There can be a lot of these conflicts and you can’t just chose to use one of the updates to the scene file because you might lose work that was done in the other update, but will have probably have to make that choice and redo some of the work because resolving each and every conflict could be even more time consuming.
Lightmap setting and all the properties related to lightmapping like the uv-offset, uv-scaling and the lightmap indexes are as of Unity 5.0 stored in a separate asset. In case two people modify a scene and then bake the lightmapping, the lightmapping asset will of course conflict, but chances are that the changes in the scene file will not conflict and if they do it should be much easier to solve. The lightmapping would still need to be rebaked but that will most likely be less time consuming than trying to resolve the conflict or redo a modifications in the scene.
Scene Merging Tool
Of course there will still be situations where scene files will conflict, but having eliminated prefab instances and lightmapping properties these conflict will mostly be related to actual changes made by an artist and should be much simpler to resolve. To make it even simpler to resolve these conflict we have developed a scene merging tool which knows the semantics of a scene file and is able to merge scene files based on objects and not simple text comparison. The tool works as a premerger which means you can set up your version control system to do merging of a scene before launching a three-way merge tool or if you are using the builtin VCS support in Unity you can enable the scene merging tool through Editor Settings.
Tracking scene dirty state
Not only are the conflicts annoying but constantly being asked to save the scene because it is dirty even though you did not make any changes is also annoying. Things like changing the docking position of a window or inspecting certain assets could make the scene appear dirty when obviously you did not change anything in the scene. Indirect changes to the scene like rebaking the lightmapping would also mark the scene dirty. For Unity 4.6 this was actually correct behaviour but since all lightmapping related data was moved to an asset it will no longer require you to save the scene again.
In order to fix the issue of falsely marking the scene as dirty we have moved the tracking of the scene dirty state to the undo system. Everything you do related to scenes in the editor is undoable, when a new item is added to the undo stack the UndoManager will inspect the item and see if the change is related to the scene or to an asset, if it is related to the scene the UndoManager will increase the dirtyness of the scene. When you then perform an undo the dirtyness of the scene will actually decrease, so you can make a bunch of changes to your scene, undo them all and the scene will no longer be marked as dirty. Of course redoing will then make the scene dirty again.