Game Career Guide is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Get the latest Education e-news
  • Top 3 Tips For Starting A New Unity Project

    - Charles Hinshaw
  • I've been using the Unity game engine nearly daily for around a dozen years (with five of those years as an early employee of Unity Technologies.) With all this time spent using Unity, I've seen a lot of projects in various states of chaos and have been responsible for a making a mess or two.

    After a recent "best practices" consulting gig at a local game studio, I've been thinking about what advice I would include in my top three tips for anyone starting a new project in Unity.

    #1: Plan a Sane Project Structure

    The battle against entropy begins the moment you select File/New Project...and the choices you make now will directly impact the amount of joy or pain you experience every day while working on your game. Since I firmly believe that creating should be a joyful experience, my top piece of advice for anyone starting a new project is to spend time planning a sane project structure.

    I have personal preferences when it comes to "the best way" to organize a project, but regardless of how you choose to organize things, I think all good structures are built around a principle like this:

    • Anyone looking at the project should be able to quickly understand how your project is structured; so that

    • Everyone using the project can determine precisely (without ambiguity) where any new asset should go; so that

    • Anyone with access to the project can quickly find any file.

    All of this starts with you really thinking things through - you can't hope for other people to understand how things are organized and maintain a project if you don't understand it yourself.

    Ok, that is pretty high-level/big picture. Let's consider some concrete advice:

    Communicate Your Structure

    Your structure isn't as "obvious" as you believe and you need to actively consider how it is communicated to new team members. Part of this is about carefully considering how you name your folders, but I like going one step further and having the communication right there in the Project Window in the form of notes on folders that say exactly what is inside (like having "Plugins - Extensions to Unity functionality. Special folder offering phase-one compilation" right there in the inspector when the Plugins folder is selected.)

    How do I do this? In Unity, the type DefaultAsset is used for assets that do not have any specific type... like folders. Like all Assets, DefaultAssets have an AssetImporter and can have a custom Editor to get a custom inspector. I like to store a description of a folder in the AssetImporter's userData and use the custom Editor for DefaultAssets to display userData strings.

    Enforce Your Structure

    Planning and communicating will only get you so far. At some point, you need to think about how you are going to enforce the discipline necessary to maintain your project's organization. As a first line of defense, I recommend ensuring that only files of certain types are allowed into specific folders.

    Again, use the userData in a folder's AssetImporter. But in addition to descriptive text, include the allowed file extensions. Technically, I recommend storing the GUID to a ScriptableObject that contains that list so that when you realize that "Code Only" folders need to store not only .cs files but also .asmdef files, you can update that globally.

    With that in place, you can use AssetPostProcessors to ensure that an asset is allowed to be where it is on import and warn the user if they place a file someplace where it doesn't belong. You could even take this a step further and hook it up to your VCS to reject commits until the user gets that prefab out out the scripts folder.

    Firewall What You Won't Ship

    Your project contains some stuff that isn't really part of the game: things like reference implementations and prototype environments. Invariably, whether through mis-clicking or misunderstanding, these things creep into production scenes or are referenced in ways that pull them along into your build.

    I like to keep these things separated at the top level of the project in a "Prototypes" folder and to have a hard rule that says that nothing from outside this folder should ever reference anything inside this folder.

    Fortunately, it is pretty easy to detect when this rule is violated-we can make a simple editor tool that walks through the SerializedObjects in our project and ensures that none of them have a SerializedProperty that is a PPtr to an asset in /Prototypes. As your project grows, this can start to take a little time to process everything, so this step is perhaps best done as part of your Continuous Integration setup.


comments powered by Disqus