Search Unity

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.

21 コメント

コメントの配信登録

コメント受付を終了しました。

  1. Alan Mattano

    8月 30, 2017 4:52 pm

    PROBLEM: There are a lot of problems making “Package” because try to include more script that it should and the interface dialog is confusing. We need to include dependencies first and then, later the interface has a boolean with an incoherent text “include dependencies” that we often turn off. Probably if this boolean is disable by default it can help to prevent the idea of “Package” creates problems. Also to change the boolean name to more appropriate one “show more scripts”. Also, we need to select dependencies before exporting and it is not nice. SOLUTION IDEA: It can be more useful, a new line button in the context menu “Select dependencies & Make Package” that select dependencies automatically, show you the package window and by default, the boolean is set to false, with the boolean name “include more script” that shows you all the scripts not included.

  2. The Unity team should take a look a Projeny https://forum.unity3d.com/threads/released-for-free-projeny-unity-project-and-package-manager.378544/

    It makes the handling of project assets much more manageable by allowing you to specify packages for inclusion into a project using symbolic links. You can even set up your own directories of assets for inclusion. This makes it easier to have multiple versions of assets for managing updates.

    It’s kind of hacked together using python and OSX support is non-existent, but if it was built into Unity it’d make the lives of developers and plugin developers easier.

  3. I’d contend that Unity -really- needs a proper separation between Editor-extending assets and regular Project assets. The former really need to be able to be added ‘permanently’ to the Editor as per every plugin-spporting IDE out there, with simple enable/disable style management; installed to the Editor not each and every Project individually, and separated explicitly from the Project compile cycle.
    Do that, and Project folder management becomes a lot saner.

    (Oh yeah, and that the Editor menu table generated by MenuItem attributes needs to be customisable somehow)

  4. John Vanderbeck

    8月 16, 2017 9:15 pm

    > 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.

    Can you explain what you mean by “adding the version of Unity you use” in this context? Do you mean next to the project folder, create a text file that just indicates the version of Unity or did you mean something else entirely?

  5. engrishfurlong

    8月 14, 2017 7:45 am

    Can you expand on “turn on gfx job and gpu skinning early on to ensure compatible asset”? What make an asset compatible with either? zero doc on that, info much appreciated.

  6. Joe Delekto

    8月 12, 2017 3:00 am

    I am dabbling with some development in VR using SteamVR –do all of these same hints apply or should there be other hints ahead of time one needs to think about as well?

    I really like that they released the VR Editor with one of the experimental Unity builds; however, are they planning on updating the editor for newer versions of Unity?

    I’m looking forward to the tools you will be sharing for customizing Unity and I think one of Unity’s greatest features is being able to augment the editor. On that note, is there a way to exclude tools created for extending the editor in one’s project from the actual project itself easily?

  7. What I is that I have a folder called 3rd party and put everything I got from somewhere else in it. My scenes folder is preceded by a “_” but the rest is normal.

  8. With respect to moving Asset Store Assets:

    [QUOTE]
    ・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
    [/QUOTE]

    This is really dangerous for certain assets and will cause them to simply break. It’s not just hard-coded paths, but certain Editor features that require assets to be in specific Special Folders. See this forum post for a description of some of the most important folder structures (e.g.

    and

    .

    Suggesting that users “reorganize Asset Store assets” is a fundamentally broken approach. It may work for a majority of art assets, but more complex Editor Extensions may make use of certain Unity features that can only be used by following a Unity-prescribed folder structure. Please take time to understand why some assets are broken up as they are before suggesting that users roll up their sleeves and get themselves into trouble.

    I’ve heard tell that this requirement will change in the future. Unfortunately, suggesting this to users now will cause lots of headaches for Asset Store Publishers who are actually following today’s rules. Rather than suggest users mire themselves in these issues, why not write a blog entry about the purpose and utility of the Special Folders – educate users to recognize them and learn about the benefits that they bring to their projects?

  9. Here’s the project layout I use. http://i.imgur.com/klt9WXe.jpg

    "Fixed Timestep"
    Did you mean set it to 1 if you’re not using rigidbodies/etc? Setting it to 1/60 would get worse performance if not using it.

    1. I think what they meant is;
      if your game isn’t very physics-heavy, you can afford to make your physics update rate faster so that everything is smoother and more responsive.

      So if I make an ultra-fast-paced arena shooter that people will want to play at 144 fps and I want my physics to be absolutely flawless and all my movements perfectly smooth without interpolation, I can set my physics rate to 150 fps (because my game doesn’t use a lot of physics, so the performance hit won’t be too much)

      1. (continued)

        I’ve actually found that in certain cases, setting your fixed timestep to match your maximum target framerate (and removing all interpolation) can actually give you better performances than keeping a 50fps fixed timestep but relying on interpolation for smoothness of movement.

        It’s a question of how many interpolated rigidbodies you have, and what is your maximum framerate.

        1. At first I thought “dubious” but then I think I found some sense to it: when you shorten the time step, each physics step needs less iterations than when it needs to solve large deltas.

        2. The performance gain is simply due to not having to calculate interpolation.

          Say you lock your framerate and fixedFramerate at 60 and remove interpolation for a scene with 2000 physics objects, it’ll be less costly than having your fixedFramerate at the default 50 and calculating interpolation for all those objects

  10. Have you considered a Library feature where people can park assets or packages they have made themselves and drop them into a new project more quickly.

    Also what if we could have preconfigured starting templates, e.g. my 2D platformer starter pack?

  11. >> Put everything you get from the Asset Store in an AssetStore sub-folder. You will need to fix up anything that uses hardcoded paths.
    Worst solution – you will have pain on each update. Better to keep all external assets “as is” and create “Client” or “Project” folder for current project / game data (code, assets, prefabs, etc). You can even create editor “folder generator” like this for decrease pain on it.

  12. It’s better to consider to put assets from Assets Store into Plugins folder. It’ll cause them to compile into separate dll thus wont affect compile time of your own scripts.

    And floating folders seemed to me as a bad decision, at least you may put Scenes folder to Favorites in project view and it’ll alvays be on top.

    And with purchased assets what was a good descision for me is to put text file to every Asset folder, and this file named “_vXXX” where XXX is asset version. It’s generic way to see what version of asset is imported

  13. Question regarding:
    “…you should set this to match your target time per frame”

    PC games often feature a vertical synchronization setting. How would I set the target time per frame in this case? For example, if v-sync is turned on, I’d like to set this to 1/60. If v-sync is turned off, I’d go with something different.

    It seems this setting is not exposed to the UnityEngine API?! Is there a way to modify this setting during runtime?

    1. You can’t set what Vsync is. If you put it on it’s supposed to set itself to the monitor’s refresh rate.

      You can turn it off, then use https://docs.unity3d.com/ScriptReference/Application-targetFrameRate.html

      1. You’re right, I used a wrong word. This is what I wanted to ask:

        Question regarding:
        “…you should set this to match your target time per frame”

        PC games often feature a vertical synchronization setting. How would I set the “Fixed Timestep” in this case? For example, if v-sync is turned on, I’d like to set “Fixed Timestep” to 1/60. If v-sync is turned off, I’d go with something different for “Fixed Timestep”.

        It seems the “Fixed Timestep” setting is not exposed to the UnityEngine API?! Is there a way to modify the “Fixed Timestep” setting during runtime?

        1. Two ways:
          – In Edit > Project Settings > Time window
          – Through code, by setting Time.fixedDeltaTime directly