I’ve been using Unity since it’s version 2.x (around 2008 or so), and I’ve seen it grow year after year. Along with the engine, the projects done with it grew as well.
One thing I’ve noticed is the general mis-understanding (from my point of view) on how capable Unity is handling large projects, and how to do so. I see a huge misconception on what Unity is, and how one should use it.
If I can explain these tips, you’ll never fall back on using Unity like before.
Throughout years of experience, research, and forehead slaps, I’ve come up with a set of rules I implement here at Indelve. I’m sure this is not the only way to handle large projects on Unity, but it has helped us greatly and worked wonderfully in small teams like in our mobile division, and in large teams like in our current large game Initiative: Red Daw.
You’ll notice some of them are not exclusive to Unity and more general to programming, but since they are part of my mantra, I’ll share them as well.
1- Keep it sharp
First, most libraries you’ll find are written in C# (such as Facebook’s or other major SDKs).
Second, UnityScript and C# in Unity have different compiling time. This means they are not compiled together. Hence, if you want a UnityScript to access a C# script, you have to follow specific folder guidelines to achieve that. I’ve found myself in a hybrid nightmare of C# and UnityScript scripts that didn’t see each other, so I had to arrange some on the Assets folder, some on Standard Assets, some on Plugins, etc. to be able to achieve what I wanted. Since then, I chosen to use C# for everything.
2- The point of no return
When working on large projects, there’s a point of no return (usually pretty early) where you must commit and stick to an engine version (strictly speaking, to a specific version of every library you use). This is true not only to Unity. Although Unity still lacks a good version management like Unreal Engine has.
Also, under no circumstance you should depend on a future feature Unity says they will provide (i.e.: Nested Prefabs have been in the roadmap as the next feature since 2013 and still at the end of 2016, no nested prefabs). If you need a feature, either code it yourself or get a plugin from the Asset store. If you plan the latter, check below on #5.
3- Make your own DLLs
When working with multiple programmers and designers it becomes imperative to protect the code from accidental edits. And if you are working with freelancers, you’re also protecting your source code.
You can create one or multiple DLLs if you want. Here are a couple of uses we have for DLLs:
– Prevents accidental edits
– Protects source code
– Easier version tracking (easier to know all developers are working on the same library version)
– Easier update: you simply send the new DLL instead of the source code script or worse, the full Unity project. This is specially useful if you work with programmers off site
– Easier propagation: you can setup your environment to automatically copy linked DLLs to a master server from which others will update automatically
You can make .NET DLLs in Windows and in Mac as well using Mono. Unity uses Mono so you’re not loosing any special features. Send me a buzz if you need some guidelines as to how to create such DLLs.
4- Unity for Unity
One of the biggest mistakes I find online is wanting to have Unity solve every single need we may have.
As a general rule, I put no game logic on Unity. I use Unity simply as a visual front-end of the game. For example, on Initiative: Red Dawn can be played fully from a linux console. Unity is just a visual representation of that.
Remember, just because Unity has certain functionality does not mean you need to adapt your code to use it.
Use Unity stuff (i.e.: MonoBehaviours) only for Unity-specific visual stuff. If a class has no visual representation on the game world, then it makes no sense to make it a Monobehaviour or even have it inside Unity.
Don’t use Monobehaviours just for the Start/Update/etc. Use Dirty updates instead.
We have a single MonoBehaviour performing the update to the DLL, and everything else is handled through a dirty update from there, even Unity stuff.
If it has a visual representation, use Unity. If not, goes into the DLL.
5- Asset Store plugins
If you want/need to use asset store plugins, there are a few caveats we always check:
– Make sure the plugin is actively maintained by the developer: you can check the forums, their webpage and comments on the Asset Store itself.
– Always have an empty project to import the plugin, run the demo scenes, and make sure it works. Then, delete all unwanted content (demo content mostly), and create your own UnityPackage to use. Never have developers download the asset from the store, always share your version of it (also check the licensing to see how many seats you need when sharing)
– Just like Unity, you need to stick to a version of the plugin and be very cautious when upgrading
– If the plugin comes with source code and the license allows it, embed such code in your DLL and use it from there. If the plugin does not come with source code, I simply don’t use it. We already have to live with Unity’s lack of source code to add yet another black box middleware.
6- Scene usage
Don’t. Just don’t use or relay on scenes for your end-game. Use prefabs for everything (I mean, everything). If its a GameObject, then it is a prefab, no matter how simple it is.
You can use scenes during development to test specific elements of the game if you must. If you do, plan ahead and make sure each scene is fully playable without the need to go through several other scenes to test a single feature.
In our case, we use different Unity projects for each section of the game: the base on Earth is one project (not a scene, a separate project), the technology tree is another project, etc.
All projects have a shared library containing the DLLs and all shared assets (icons, logos, images, sounds).
Also, since we are not using scenes, we can have multiple programmers working on the same part of the game and it’s just like a script file edit.
If they are changing visual elements (models, animations, etc.), it’s just updating a prefab.
Well! I hope I did a fair job explaining our method. Remember, I’m not stating this is by far the best method there is, but it sure worked for me in the past and is working wonderfully now.
Game developing consumes an immense amount of time, which unless you’re doing it fully as a hobby, translates into money which, for most of us, it’s very limited and heavily guarded by our CFOs and alike. So, ensuring you use a cleaner and smoother workflow saves plenty of time in the end.
As always, let me know if you find any issues, typos, or if you want me to go deeper into any topic explained here.
Thanks for reading!
You can follow me on Twitter at