The title basically says it all. I have a large team of developers (5-10 people) who have to work on the same scene/scenes. However, when several people accomplish their tasks, we often have merge conflicts resulting in loosing some of the work when we try to merge them correctly. We know about text serialization of the scenes and we properly configured the project to integrate it in our workflow. However, merging scenes is really a nightmare. Even with such plugins as UniMerge.
I am aware of the fact that you actually can create as many prefabs as you want and lately construct the scene out of them (maybe dynamically), however it doesnāt solve our problems completely, since sometimes you have to change the instances of the prefab based on the functionality in concrete scene and pass few object references around. Additionally we would like to have our scene active so that artists can construct the level right in the scene file and store it there.
So yeah, I would like to hear from people how do they manage large projects in Unity, assets merging, prefabs/scenes merging etc.
Btw, we use Git if this info is relevant for answering my question.
Thank you for the tip. Can I use this tool with some kind of evaluation period? My managers wonāt buy anything that is not going to solve our problems completely for the whole team. Also, if I understand correctly, this tool basically divides the scene into several scenes. Do they still retain connections between them? Some object references etc.
Also, I would really like to hear from experienced project managers with large teams and projects how do they actually organize their Unity workflow so that everyone can work in parallel. I couldnāt find any decent information across the web. I would really appreciate if you could point me in some directions.
Never hurts to ask. Hereās the contact page for the developer.
Valentin Simonov write a blog post on this. I only mention it because I came across it while searching futilely for Schell Gamesā excellent Unite 2011 presentation on Scalable Game Development. (Does anyone know why it was apparently scoured from the web after 2012?) Their presentation had some great tips for large Unity projects. You can download the slides here at least: http://unite.schellgames.com/
I would like to know how others handle this too, we use Git, and right now levels have to be owned by one person. Sort of like āchecking outā a level. Anytime weāve worked on the same level its a nightmare and the merge fails.
One strategy we started using is a basic Game setup scene, with main character in place, and the Game Manager. This scene is owned by the programmer and starts up the game. It then loads additively a Level Design scene, which is owned by the artist and level designer. That way the artist can work on level design, while the programmer tweaks the interactions.
We just donāt use scenes. Everything is handled in separate projects, and then just bundled for load at runtime. Since the everything is just code (on the eng side), merging is simple.
Sure, with no scenes, merges would be easy! But, how do you design levels? We need to test and tweak the placement of objects in the scene to get the right level of difficulty. And, visually, we are constantly making adjustments.
You can just use separate projects or scenes to build your content and add as a prefab or as an assetbundle. Or optimally, store you āsceneā (level) in a data structure, then you have your staging project/scene that can run through the scene and store the info needed to reconstruct it. An addition benefit of this is that since you are parsing the scene, you can also optimize on fly as needed. (batching meshing/materials, etc).
We have around 7 projects, models/fx/environments/ui/etcā¦ and one main project. The main project has virtually no content at all, just one scene with a single script called āengineā. Everything else is loaded as/when needed. The other projects are where content is assembled, the content is then exported as assetbundles. Our team is about 20-30, and we can all work without running into (asset) conflicts. If we are working in the same area, or on something that will span more than a few hours, we create a local branch in GIT. For level building, the designers have a tool that lets them set up a scene and tune however they want, then the whole thing is stored as .json data.
There are other ways to do it as well. But basically scenes get very clunky and problematic as the project or team grows. They can be pretty fragile and difficult to repair if you rely on connecting things via editor/public vars. (and have you discovered, have multiple hands on it).
Thanks for the link. I already saw it before posting on this forum. Unfortunately I havenāt found the answers for my questions. Asset Server maybe the good alternative, but we are working with free Unity version, so this is not an option for us right now.
I consulted with some of my friends who happen to work on Unity games and they told me that they actually donāt have any scenes too. They store everything in prefabs and later they load everything from those prefabs and place it on the scene according to configuration files, created by tools provided to level designers.
Thanks for pointing this out. I think we should try to employ this method. I hate public object references, since it is just destroying the purpose of the prefabs, because you cannot change them freely. However, this approach is harder than simply working with Unity and saving scenes. You basically have to create your own scene serializer, donāt you? With all of the pitfalls such as properly serialized collections of components and so on. At least in our case, since we donāt have Pro version of Unity, so we cannot separate projects and build them into Asset Bundles.
Yup, it is more work for sure. Unity is like Flash in that respect. For simple/small stuff you knock stuff together fairly quickly and with little effort. But as you scale up (project size or staffing), the quick and simple stuff doesnāt work anymore. Even with asset bundles, there are challenges, as they cannot include any code, you still have to serialize some elements.
Proper structuring of project and good communication IMO. That way you can isolate areas people work on while others work on other ones so thereās no conflicts and talk with others when you may be messing with an area someone else is working on. You should know whoās working on the AI, whoās handling the user discovery and whoās handling the proxy servers message forwarders etc.
You donāt always get the luxury of the former(adopted projects) but communication is a life saver in every situation. Optimally, a project would have numerous folders with subfolders intuitively named that also help split responsibilities(Models/Structures is separate to Prefabs/Structures). Same with code, you donāt dump everything into subfolders in your project, you want separate .dlls which also has the benefit of enforcing modular and reusable code.
I get problems with merging conflicts, I hate them with a passion and itās usually settled within a couple minutes by talking with the person responsible. You canāt have everyone chaotically changing everything, you need to learn to work together or not at all.
I havenāt combined projects like people here have, but I have had a project where I coded a custom serializer for levels and the builds were āstubsā that contained nothing more than the .dlls required and an entry point level. Weād export scenes from other projects with the serializer and these would be loaded in at runtime and most unique code was handled with Playmaker.
Here is the article, summarizing my thoughts about this pov http://www.intelligent-artifice.com/2013/05/unity3d-for-teams-of-6-people-or-more.html
You canāt yell out load āIām locking this!ā every time you want to change the scene, component or prefab. And you actually want to work on those in parallel anyway, because there is no ideal isolated modules, belonging to the developer, which other developers canāt touch or shouldnāt rely on. What if someone is developing some kind of system you rely on, often changing its interfaces and public object references? Yelling every time you use this system and want to modify it to do your job is not productive at all. Also, when you try to merge YAML scenes, it doesnāt really matter who made the changes, you canāt do the merge properly when different scenes have different references, ids, whatever after they have been converted to text. Some plugins do that, but not particularly good (maybe you can point me into the right direction on how to do that?). You can even loose some references to images after you think you completed the merge successfuly, which is quite sad situation. Resolving scene merge conflicts often results in loosing the work of your coworker or self.
Thereās a semantic merge tool coming in Unity 5.0.
That said, Iām curious what your experience of other (non-distributed) version control systems for game development is like outside of Unity. Every place Iāve worked has had some kind of āexclusive checkoutā system in place - whether itās enforced by the software, or enforced by grabbing a cuddly toy that represents the system youāre working on, or whatever - at the very least for the binary art assets.
Iām dealing with this stuff as we speak and we donāt have these issues because we split responsibilities. When our responsibilities collide in a single class, we usually settle it by communication. I donāt see how this is complicated, all you have to do is be organized and have a proper structure to everything. The only time itās hard is at the beginning stages of development when a ton of code will be made and changes will be everywhere, scenes are split up into prefabs and typically two people wonāt be working on the same one at the same timeā¦if they do, then the other guy goes out for a coffee or works on something else.
Thereās no āIām looking at this!ā every time we are changing something. People know what theyāre responsible for. On a very large team this would be harder, but on a very large team you usually have someone dedicated to managing everyone(and changing things willy nilly isnāt appropriate). 6 or so people, not a problem in my experience.
Itās not acceptable to change whatever you want and merge later. Communication is important and you need to take time out of your day to do it. If youāre not willing to do it, you will have problems. Itās that simple.
Ideally it would all be brought in at run time from prefabs on separate scenes dedicated to them. Right now, the project Iām on, the only thing thatās there is the terrain and a few other objects(which Iām trying to get rid of), all new work is in separate scene files that contain things like the Inventory UI or the Chat UI etc. No one should be touching the same scene or code and like Iāve said, if in the bad situation we have to merge(which hardly happens except for the beginning stages of a project) then we do it. Scene merges are rare and should never occur, they typically involve someone working on something else for a bit or taking a coffee break.
This is just the way it is, thereās no perfect solution to it right now sadly. The best solution is to be organized. If you canāt do that or think that isnāt an option, you may be not suited for working with others.
Does it work with scenes too? If so, that would be awesome. How much will it be?
[quote=āDabeh, post:15, topic: 563709, username:Dabehā]
Does it work with scenes too? If so, that would be awesome. How much will it be?
[/quote]To the first question, yes it does; to the second question, itās going to be bundled with Unity but I canāt yet say whether itāll be in Free or Pro.
Me too, because thereās only two approaches I can think of thatād work for scaling up: those based on splitting up the work as per zombiegorillaās description, and those based on genuine multi-user environments. Either is going to incur a significant cost somewhere, and that cost is why large games are so much more complex (and expensive) to make compared to small ones. 10 times more content doesnāt mean 10 times more work. It probably means closer to 20 times more work, because you not only have to manage the work but also the systems that manage the workā¦
Unity had a blog post where they demo additive scenes, which might end up in a future 5.x version. It seems to be modeled after UE4ās sublevel system, which is a great way to subdivide scene work among people.
In the meantime, we use Advanced Additive Scenes as well which provides close to the same functionality except for the cross-scene linkages.
For the OP, there are no direct linkages between subscenes (one scene can be made up of multiple subscenes in this system), but we have a system for fixing up linkages at runtime.
Much more convenient than our old system of treating prefabs as levels, though it does have its quirks when running under Unity 5.
We just abandoned the idea of prefabs as level designs because it incurred a huge cost in scene loading. It appeared that Unity had to assign all prefabs unique IDs, including all the scene elements even if the prefab was not instantiayed.
I supspected a large studio might have a custom scene serializer that sets up the levels via code. I assume that means all the prefab placements, linkages and properties are stored in a data file. Then, they must have a tool to visualize this and test it. That sounds almost exactly like, say, a āsceneā! Seems like this is something the standard scene should already be able to do.
I donāt have any. Our previous project was made with Flash and we merged everything together pretty much fine, because there were no āinternal idāsā system in the first place. Everything were explicit, thus clear to everyone. However not only it was a little bit easier than our current project, we donāt have a lot of Unity experience in the team. That is why I am asking for help. We have already tried several approaches and it turned out they were wrong.
Maybe you are right. We are in the middle of the starting stage that is why we have so many conflicts - we still donāt have defined and set in stone responsibilities for each part of the code and design. The core systems in our project are still changing a lot, that is why we have a lot of merge conflicts. However I didnāt mean that we have code merge conflicts. We have to merge components, game objects, prefabs and the scene itself (this is especially hard when internal idās in two different projects are not the same).
It is true that we didnāt separate everything in the scene. For example, our main scene contains everything - from giant game object with lots of managers to the level representation and GUI system. I know, this is wierd, but it was our idea about Unity-way of doing things. We are now trying to switch to more compelling strategy, that is why I am asking in the first place =) I also wonder what do you do in case of refactoring if your responsibilities are set within the specific field of the project code. Also, I really wonder if āScene for everythingā ideology works well. How do you organize links between them? How do you load the scene with GUI into everything else? How do you tweak the same components in parallel?