Questions about optimal workflow in Unity

News & General Discussion
1

Heya folks,

I know this is a topic discussed to death and I already searched and looked up many articles, post mortems, blog entries and whatnot, but I still feel somewhat unsatisfied with the results. Ultimately I’m looking for answers for these question:

  • How do you work collectively within Unity?
  • How to version control assets (2D Sprites, 3D models, Audio)?
  • How do you work on multiplatform projects (PC and Consoles)?

I’ll go into detail with each question. Let’s start with the first one.

1) How do you work collectively within Unity?

Now a little bit of background to my past workflow with Unity and our team. Almost two weeks ago we released a game which was in development for over 2 years. Within these two years we worked with Unity 4.X to Unity 5.4.5p3, which was the Unity version used to ship the game. Now as for the coders it was absolutely fine for us to throw our scripts into Git/Bitbucket and work with source control. But when it come down to design levels, I had to copy my Unity Project, save it to USB and give it to our leveldesigner, who designed a scene and put the scene to our dropbox. I took the scene, included it again in my project. Rinse and repeat.

This was and is, frankly put, a terrible workflow. But in a way it was safe. What I mean is that with this workflow we never had any problems with our scene-files. In the beginning we tried to source control the very scene-files, but that generated lots of problems, so we ditched that.

My ideal workflow-wish would be:

  • there is only one Unity Project, no bullshit with handing projects via USB or something like that
  • everyone of the team has access to it
  • everyone can add assets to the project and others can update their project-instance to get/download the new files
  • several people can work on the same scene

Now I know there is Unity Collaborate, but from what I heard it is pretty buggy and I’m sick of working with buggy stuff…what would be possible alternatives and how would you go about setting them up? For example when we do use git/bitbucket, is it wise to put the whole Unity Project into source control? Wouldn’t that burst the storage limit of the repository pretty fast?

2) How to version control assets?

Now as for our assets, we didn’t really version control them. It was more like backing them up, which is probably a way of version controlling…an ancient way. The thing is, what gets versioned controlled and what not?

Example:

The artist makes a source sprite in Photoshop which is set to 4096*4096. This will be the Raw PSD file with all the layers needed to work on, which might get big in filesize, depending on all the information stored into the PSD. Then it gets scaled down to let’s say 120x210 and exported as PNG and is about 100kb big. This PNG will be added to our Assets-Folder in Unity.
Which file should be version controlled? I’d say the Raw PSD since it’s the file which will get changed, but if we’ll version controll ALL of our big PSD files we’ll reach the limit of our repository storage pretty fast, and we also got all the other necessary assets. Should there be a dedicated repository only for assets or even only for texture assets? What are your best practices?

3) How do you work on multiplatform projects (PC and consoles) ?

If some of you folks have any experience with multiplatform development with Unity, especially when it comes down to working on games which have been released to PC and different consoles, I’d love to hear how your Unity setup looks like. What I mean: do you have only one Unity Project for all platforms or do you have a Unity Project for each platform? Also, do you have the same Unity Editor for the project or projects or do you have a Unity Editor for each platform, since I was told that you need a specific Unity License and a specific Unity Editor for development with the Nintendo Switch, for example. I don’t know if that’s still the case for all the current consoles.
And how do you keep version controlling the project(s) - each platform one repository?

I hope you folks can help me out here, since we’d like to have at least a better workflow for the next project :smile:

2

Everyone on the team needs to use version control for starters. It’s up to you to pick which one works best for you, but that just has to happen.

Which means the repository too big is not really a valid excuse. If you can’t afford $30 a month to host Perforce on say aws/azure, no sympathy. If you don’t have anyone that can set that up, some sympathy, but not a whole lot. You just need to get this one sorted and if you value your time then even an extra $100 month is going to be money well spent.

I have a strong preference for the simplest solution that works. I’ve seen a lot of hair brained schemes over the years with most of them being overly complicated. I like Perforce, and I’ve heard good things about Plastic SCM. The main thing I look to avoid is multiple different scm’s and multiple repositories if it can be helped. Simpler is better.

For the same reason I also don’t like lots of separate projects or VS solutions for that matter in the repo. Two VS solutions (one for server/shared code) and a single Unity project in the repo.

For art there are a few valid approaches. The one I like is have a separate top level folder for art, but keep it in the main repo if possible (depends on what version control you use). From there you can copy art once it’s ready into the main Unity project, or artists can just have a local Unity project to create asset bundles from and then commit the bundles to the main Unity project.

I don’t like rigid workflows which is why I don’t like forcing art to be in asset bundles until release. You should engineer that part or at least know how you will do it because it will eventually be a thing most likely. But you lose productivity being rigid while iterating. You lose productivity from having to reason about too many moving parts also.

Branching is the big pain point in my experience. But you can totally punt on that until you release something. Just keep it mind it’s going to be a thing.

3 Likes
3

For number one, I like breaking scenes up and using additive loading at run time. That way you seldom need multiple people working on the same scene. You can break scenes up along functional lines. Give the artists their own scene for art. Give the game designer a scene for interactivity. Give the programmers a scene for random scripts. And so on.

Also prefab everything. The only reason to access a scene is to place the prefabs. Once the prefabs are places, all work can be done on the prefab instead of the scene.

4

We use ftp mapping within git repo to easy the non-tech users. Ftp maybe an old protocol today, it still robust.
Since we have our own rack, there is not much worrying about the disk space and third party service. Raw files are important, because they are the most editing source, I would suggest keep the raw as much as you can.

What makes version control chaos, is the duplicates, where fixes and edits may lost if branches are out of control. Regular rebase is essential, it flattens the repo graph, and less chaos.

On multiplatform project, since duplicates are bad, we commit all scripts, assets outside project.
If we avoid mixing the platform-only code in single file, we can avoid platform branching, because the platform-only code are sitting on their own files, which are clear within single branch, and tag is quite useful here.

However, I still don’t have a good solution for Unity multiplatform project, due to platform-only settings. I would love to hear others about this.