On the Spotlight Team, we work with the most ambitious Unity developers to try to push the boundary of what a Unity game can be. We see all sorts of innovative and brilliant solutions for complex graphics, performance, and design problems. We also see the same set of issues and solutions coming up again and again.

This blog series looks at some of the most frequent problems we encounter while working with our clients. These are lessons hard won by the teams we have worked with, and we are proud to be able to share their wisdom with all our users.

Many of these problems only become obvious once you are working on a console or a phone, or are dealing with huge amounts of game content. If you take these lessons into consideration earlier in the development cycle, you can make your life easier and your game much more ambitious.

Folder structure

Before you add your first camera, map out your first town, or even get a cube spinning, take a moment to think about the folder structure of your project. While the project view does a very admirable job of making your game data easily searchable, searching isn’t always practical. Ideally, you want a folder structure that guides your teammates to the correct place even when they have no idea what to search for.

There are lots of ways to do this, and I will give some examples of things we have seen work well. But, really, use whatever works for you. If your project layout has good answers for the following questions, it is probably a pretty good layout.

Who made this? Is this something your team made, or something you bought?

What type of thing is this? Script, Audio, Art, Design? You want to be able to see a problem in game and track down the data.

What area of the game does this cover? Is it in a specific level, all over the place, or only used in the launch screen? This makes it easy to know how expensive a given asset should be, and how much other data you might need to touch if you change it.

Is data coherent? Is a prefab or a character near the model that it comes from or the animation clips that go with it?

Some examples:

Floating folders

Prepend all folder names for your own assets with an _. This causes them to sort on top of anything else. Personally, I like my Scene folder on top, so it gets two (i.e. __Scenes).

Anything you get from the Asset Store just installs wherever it would like.

If you majorly change an Asset Store purchase, stick the _ on the folder names and you will know not to overwrite with a newer version.

Divide and conquer

Put everything you get from the Asset Store in an AssetStore sub-folder.

You will need to fix up anything that uses hardcoded paths.

This keeps your Asset Folder under your control, and keeps things as neat as possible

Per-discipline top level folders

Every work group gets its own folder. Level Design. System Design. Environment Art. Character Art.

Good for large teams.

Keeps content you produced in easily recognized folders.

Locally coherent data. Things should live near where they are referenced.

Living with Asset Store packages

For larger teams with longer projects it is very easy to have assets from the Asset Store start to bloat a project. The brilliant developers who put tools up on the Asset Store try very hard to make their tools easy to learn. This often means including large tutorial and sample projects with the assets to support them.

The easiest way to handle Asset Store bloat that we have found, is to avoid importing large asset store packages directly into your project. Rather, import your large packages into a new project. You can then delete any heavy content you don’t need before moving what you need over to your project. You can clean up any assets you don’t need, organize the asset package how you would like it, and then package this up in a new package using the “Assets->Export Package…” dialog.

Make sure that you check both the original version and your modified version into whatever source control you use, just in case you need to later update your Asset Store purchase or if anything goes wrong.

Unity Versions

The image below is my current desktop. Given the number of client projects I work on, I always have 5+ versions of Unity installed, not counting the 1-3 I have recently built from source code.

If you use external source control — git, hg, perforce, etc. — I strongly recommend adding the version of Unity you use. Ideally, every branch of your game contains the project folder and, next to it, the version of Unity used to work on that project. As your team grows this will streamline onboarding, ease the Unity upgrade process, and make me very happy if you ever end up working with the Spotlight Team.

Initial Project Settings

There are quite a few project settings that are easy to overlook when you are just starting up a new project. Tucked away in their own menu, generally far from whatever problem you are trying to solve, it is very easy to forget all about the myriad controls we give over your project. So, here is a quick lightning bonus round of the most commonly overlooked settings, in menu order.

Audio

Disable Unity Audio – If you aren’t planning on using Unity’s built-in audio, disable it here. This will remove some overhead with no cost.

Time

Fixed Timestep – If you are not making heavy use of Joints or stacking RigidBodies, you should set this to match your target time per frame, or 1 / target framerate.

Maximum Allowed Timestep – This is the largest number that will ever be passed into deltaTime. I generally set this at around 0.1f, or 10 fps. If your game is running lower than 10 fps, generally speaking, it is better to go into slow motion until you recover. This will help you out when your game gets big if you start having one frame lag spikes, especially while loading in the editor.

Player

Other Settings -> Rendering Color Space – You want this to be Linear in almost all cases. It works with a wider array of Post Effects. GPU Skinning and Graphics Jobs – Set both of these to true. These settings both improve performance at the cost of some compatibility. By starting with these settings on, you can make sure each piece of content is compatible with them. Many projects run into issues trying to enable these to save performance late in development, when the cost for fixing data issues is high.



Physics

Default Solver Iterations – Like Fixed Timestep above, this improves the stability of complex physics systems. If you are not planning on using a lot of Rigidbodies, you can set this value to 1.

Quality

Anti Aliasing – If you intend to use an anti aliasing solution from the Asset Store, or any of the ones included in our post processing stack, you will want to disable the default multi sampling anti aliasing.

V Sync Count – If your target framerate is 30, you should set this to Every Second V Blank. If you are having issues with your framerate falling lower than 30 during development, you should set this to Don’t Sync.

Editor

Version Control – Set this to match your source control. If you are not using source control, I still recommend using Visible Meta Files so you can inspect them if necessary.

Asset Serialization – Set this to force text. It increases the overall size of your project, but allows you to diff changes, inspect assets, and gives more control over what Unity is doing. It does not affect build times or the final built executable in any way.

If your plan is to grow your game into something truly ambitious, taking a moment to set up your project correctly from the word go will save you a ton of time down the road. Our next blog will be a little bit different. We will be sharing several small editor tools written in-house that will hopefully improve your productivity and show you how to customize Unity yourself.