Perhaps some of the most common questions I hear from other developers are about the workflow to use when working with Unity, especially when they go from working alone or in teams of two or three people into working on projects a little larger with more than six or seven people. In these larger scale projects it is very likely that at least two people have roles that involve working on the same aspect or area of the project at the same time.
In order to have a healthy development, having each one of the team’s members doing a great work is just not enough. It is necessary to have an adequate workflow that allows the development to have fluidity during the whole cycle, this, however, is not an easy task to achieve, from planning to implementation, work methods have to be considered for all the areas involved in the development.
If you have worked with Unity on teams of several people, maybe you have found yourself in the situation of having to work in the same scene as one of your colleagues and you will know how complicated it can be, especially when your project is stored on a version control system, if by mistake you didn’t realize you were working on the same scene as someone else, putting together those changes can be quite complicated and a very painful process. Unity Collab helps you a lot in collaborative work, you always have small indicators that let you know who is working on what.
Even with the help that Collab can provide you, working in the same scene that another person is working at the same time as you are is a complicated process, you can choose to convert all your work into a prefab and then upload your changes only from that prefab, but sometimes different objects in your scene can affect the work of your colleagues. That's why for the development of Bitup we decided to simply avoid working on the same scene, but, we did not want to have a process for the game that only emphasized putting everyone's work together in the same scene, this approach, in addition to adding development time, prevents us from realizing possible implementation errors that we could correct on the fly and not at the end of a sprint.
This is why we decided to work with scenes that we additively load and unload on demand, that is, everyone is working on their own scene but each scene is ready to be merged into another and continue to work without any problem, for example, I am programming all the behaviors of the game in scene A, Prakash is doing level design in scene B and Roy is doing set dress in scene C, inside my scene (scene A) I have created a tiny system that allows to additively load the scene B or the C on the fly and immediately adds elements of the environment and lighting to my scene, if we want to try everything together I can simply press a button and everything runs together without having to go through a process of putting our work together other than synchronizing the repository.
Here is a small example of how it works.
This method is working for us at the moment, later I will work on dynamically load and unload game areas so I hope I can make this system work with that one without many complications.