Update: some of the videos are no longer available, I found some of them on YouTube and added slides. If you know where these videos are now please post in comments.

Unity3D is great for indie developers. We have yet to build a large Unity project, but we’ve built a couple of small projects so far but during this process we did see Unity3D from the ugly side. It seems that the engine can do some things blazingly fast and easy but some other ones were clearly neglected during development. But that’s another post.

So, I’ve tried to find out how big teams work on large Unity projects if even we are struggling. But no luck.

Ones were mumbling about source control, separating control over scenes editing etc. That’s kind of obvious and shows that those people don’t have any experience at all.

But recently I watched all the videos from Unite 11 conference. I really wish I could visit it and talk to Unity gurus. But anyway, here are the videos I found useful. Videos where speakers share their experience on working in Unity3D as a team. The information which is practical and useful:

Unite 11: Scalable Game Development at Schell Games (PPT)

1. Unity tends to crash building a large project. That’s why they split the game into several projects: entry point project, assets projects, code project.
2. Entry point project is simple, contains minimum stuff to show loading screen or error screen. Loads asset bundles from asset projects and DLLs from code projects.
3. Content projects got their copy of DLLs, they are used to export assets to bundles and there are external tools to rebuild assets.
4. There’s no single source file in Unity projects.
5. That allows to build custom framework, use namespaces, custom compiler preprocessor and obfuscator (if needed).
6. But there are problems with this approach like some deeply derived from MonoBehavior classes not showing in Unity3D IDE, harder to debug, etc.
7. #if preprocessor instructions are used to exclude platform specific code.
8. Custom GUI with relative sizing and positioning of controls. Saved and loaded using ScriptableObjects.
9. A lot of external data handled by ScriptableObjects which are serializable, editable like Behaviors and not tied to a GameObject.

Unite 11: Postmortem – Smuggle Truck

1. ONE project to build for all platforms. I think the project is not large, so they don’t see Unity crash much.
2. There’s a Level Editor which was used by players to create levels which actually shipped with the release.
3. Asset Settings tool to configure assets importing parameters for every platform. For example, background textures could be half-size in iPhone builds to increase performance.
4. Platform Specific properties can be configured with special 1. Behaviors attached to objects. For example, you could specify object’s size depending on whether the project is compiled for iOS or PC.
5. Custom build process allows them to use the data from 3 and 4 to set needed properties and delete unused assets before the actual build. This ensures that assets from PC build will not go to iOS build increasing its size.
6. At the end of the presentation they advised to have 2 copies of the project for different build targets if you have a lot of assets. Because converting from PC formats to iOS formats takes a lot of time.

Update: recently they released Multiplatform Toolkit to the Asset Store.

Unite 11: Jagged Alliance Online Engineering for Large Web Player Game

1. Large games have different problems: automatic builds, light map baking which takes 4 days to complete.
2. Big monolithic project fails to build. (heh, been there done that)
3. The project is split in SEVERAL small projects: code libraries, asset project(s). This approach allows to share code between client and server. Unity3D .NET project uses 3.5 and can be referenced from 4.0 server code. Asset projects are compiled into assets bundles to be use with code.
4. Programmers don’t spend an hour a day waiting for assets to be imported.
5. Code projects are separate Visual Studio solutions kept outside of Unity3D Assets folder. It allows using namespaces (not for MonoBehaviors though). Also they use Unit Tests with modified SharpUnit framework. There are problems with built-in Unity3D classes.
6. Shared code between code projects and assets projects are separated in yet another project which is referenced by them as DLL libraries.
7. Separate VS projects are configured to build DLLs into Temp folder not to be loaded by Unity3D and causing names conflict with existing source files.
8. There’s an advanced automatic build system which executes light map baking and asset bundles exporting in parallel reducing average build time.

Unite 11: Creating a Browser-ready FPS MMO in Unity Slides

1. Yet again, nobody uses built-in Unity GUI system.
2. The game looks really cool q:
3. There’s a custom interface to build asset bundles.
4. They use ScriptableObjects which are saved to XML and later loaded from server.
5. Tools for artists is a key to success.

Unite 11: Intro to Editor Scripting, Unite 12: Advanced Editor Scripting, Unite 13: Advanced Editor Scripting — totally must see if you want to create your own editor tools. Describes how to create custom Behaviors inspectors, drawing dummies in 3D scene and even creating custom editor windows.

Unite 11: SHADOWGUN: Rendering Techniques and Optimization Challenges (PDF) — a lot of low-level details if you want to optimize your game for devices.

Conclusion

Now I have time to think what approach to use: single configurable project, many projects with source inside Unity3D Assets folder or many projects with DLLs in the final Unity3D project. At least this time I got the details.
If you want to improve your team workflow with Unity3D you must spend a day watching these videos one by one. There is a lot of interesting details and what to think about. There’s no silver bullet but there is real world experience which speakers gladly share with you.