Skip to content

Instantly share code, notes, and snippets.

@terrehbyte
Last active May 9, 2016 23:34
Show Gist options
  • Save terrehbyte/9614b70a21454c5761c7 to your computer and use it in GitHub Desktop.
Save terrehbyte/9614b70a21454c5761c7 to your computer and use it in GitHub Desktop.
A rough guide on how2unity4tems.

Unity Collaboration Guidelines

So you want to make a game in Unity with more than one person (meaning, not you!). Here's a quick list of things that you'll want to look out for. You can read the description below them for any relevant steps or information.

1. Unity Versions

As Unity introduces new features and API changes, the stability of your codebase may vary from version to version. For example, if a co-worker uses a new function is introduced in the next version, everyone will have to upgrade their version of Unity in order for their codebase to compile without errors.

If you need to install multiple versions of Unity, install them to separate directories. My hard drive looks something like this:

  • X:\GameDev\Unity 4.6.3f\
  • X:\GameDev\Unity 5.1.0f\
  • X:\GameDev\Unity 5.1.2f\
  • X:\GameDev\Unity 5.2.0RC2\

Major version changes typically introduce changes that aren't backwards compatible. When Unity moved from 4 to 5, a lot of plugins were rendered useless unless updated by their author.

2. Editor Setup

Make sure the editor is set up with the correct settings.

  • Go to Edit -> Project Settings -> Editor
  • Set Version Control Mode to Visible Meta Files
    • Meta files record how you want Unity to process something.
    • Always make sure that these are committed whenever you add new assets.
  • Set Asset Serialization Mode to Force Text
    • You can see how the data is stored: open up a prefab in a text editor!
    • This can be handy when two people have made small changes to the same thing.

3. Configure Your VCS

Configure your VCS to only upload what you need.

  • INCLUDE
    • Assets
      • Contains all of your code, art, prefabs, scenes... (i.e. the game)
    • ProjectSettings
      • Contains global settings, like Input axes, Editor config, tags, layers...
      • This may change between Unity versions, like when new services are added.
  • EXCLUDE
    • Library
      • Contains precached and auto-generated files used for running the game.
    • Temp
      • A staging location for temporary files, like the UnityLockFile.
        • 'UnityLockFile' shows that this project is currently open in an editor.
    • obj
      • Typically contains hot-reloading information for your project code.

4. Beware Repository Restrictions

GitHub has a max file size of 100MB per file, but no actual limitation on the overall repository size. Depending on your source control provider, there may be support for a Git extension that attempts to provides a way to store binary assets outside of the Git repository via symlinking or pointers. In the case of GitHub, Git-LFS is available for all users with a limitation of 1GB of storage and 1GB of bandwidth per month. This can be useful for unusually large files that exceed GitHub's regular file size limit.

5. Avoid Merge Conflicts with Binaries

Two people should not edit the same scene, prefab, or any other binary file or any other file format whose contents are not human-readable.

Scenes are basically blobs of data and should be considered unmergeable. If one person makes a change to a GameObject in the scene and someone else makes a change to the same GameObject, how does it resolve that? What if someone removes some of them and someone else adds something that references them?

The answer: it's fucked. I'm kidding: UnityYAMLMerge was released by Unity Technologies sometime this year, but I haven't heard of anyone using it. You'll need to hook it up as your merge tool for Unity projects.

Prefabs are basically mini-scenes; they store a lot of user-defined parameters and can be difficult to make heads or tails of once two people have made changes to them.

6. Accept FBX / OBJ and Reject MA/MB/BLEND

The FBX file format has a freely available SDK that developers (like Unity) can integrate to add FBX support. Since Unity natively supports FBX files, it will require the least amount of effort and asset preprocessing to use.

Using OBJ files is also an option, though I have had issues with the different ways that OBJ files are encoded. Unity has not failed to read any OBJ file I have given it, but I've had problems with other frameworks and engines. Best to avoid the hassle in the first place.

If you bring in a file used for authoring the content, such as Maya files or Blender files, then Unity will invoke the appropriate editor behind the scenes and convert it to FBX upon import. This would require anyone who wants to open the Unity project to have the appropriate tools installed, even if they would not normally make use of them in their workflow. This can be a hindrance if Maya is required especially since it is non-free.

One advantage that using the authoring format of either 3D modelling suite would be ease in iteration. Since Unity will automatically reload assets upon load, artists can simply edit, save, and open Unity to inspect the final result.

Remarks

Working with a team introduces so many concerns that it'd be a real doozy to try to list all of them here. I hope these serve as general guidelines or fill you in on a few gotchas before you learn about them the hard way.

If you have any questions, concerns, or suggestions for this, feel free to comment or let me know in any way.

Terry Nguyen
terreh@terrehbyte.com

@RaskoSmash
Copy link

How to Play Nice with Git♥

  1. Don't modify the same binary assets

If you can't open a file and understand its contents, it probably can't be merged.
That makes it difficult for two people to modify the same file without one person
losing their work when the merge happens. :(

This is true for...

  • scenes
  • prefabs
  • art assets
  1. Have descriptive commit messages (e.g. not "The Rapture")

Messages help you understand the history of the codebase and also facilitate
merges.

  1. Communicate with your comradz

In addition to having descriptive commit messages, talk to your teammates so
everyone knows what everyone else is working on. This makes it easier when you
merge other branches into your own project. (Descriptive commit messages also
help with this. ;D )

  1. Merge often

When you merge often, other people can see what you're up to as well as make sure
their code doesn't already do what yours or alternatively, conflict!

  1. .gitignore

Keep cruft out of the repo! This makes it harder to download and may conflict
with other people's systems. Things that can be automatically recreated on a
system are things that you can leave out. These are things like...

  • Build artefacts
  • Log files
  • Overly large library files
  1. Git Flow ♥♥♥
    devJ
    /
    master <- develop <-

    devB

    a. Work only on your dev branch!
    b. Push up your changes to your dev branch.
    c. Don't work directly on devMerge.
    d. Checkout develop and pull the latest changes.
    e. Merge develop INTO your dev branch.
    f. Push up your newly updated branch.
    g. Checkout develop.
    h. Merge your dev branch INTO develop.
    i. Resolve conflicts, if any.
    j. Push up develop branch.
    k. If your changes are stable, merge develop into master and push master up!
    l. Love Git♥.

Generally, the branches go like dis...

a. "master" is for stable code! People should be able to safely pull this down.
b. "develop" is your dev code. It's experimental, but should mostly work.
c. "devX" is where your work goes. Here be dragons. *BEWARE*
  1. Everything else: https://gist.github.com/terrehbyte/9614b70a21454c5761c7

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment