Getting Started With Unity3D: The Basics

Best practices for getting your project off the ground

Michael Apfelbeck
Slalom Build
5 min readJul 18, 2023

--

When you think of Unity, your first thought is likely “game development.” And while this is the most well-known function of Unity, it has many other interesting use cases. The Unity Engine can power VR/AR training software, power digital twins, and prototype industrial processes and factory layout.

The video below is an excellent example of Unity in a maritime application. It combines a 2D canvas UI, a 3D container holding a map projection, multiple video streams, and even AI-generated annotations overlayed on top of the video.

JRCS Command

Now for the good stuff

Our annual hackathon at Slalom this year was a game jam, where I worked with a team of experienced software engineers and design professionals on a colony sim game. Most of my team had no or very little game development or Unity experience. I was inspired to make this guide after ramping the team up on Unity. Here are some tips to get you started on the right track.

Over the years, I’ve used Unity as a solo developer and on teams with a wide range of experience levels, and I‘ve learned what it means to create a successful application using Unity with best practices in mind. Now, I’m not claiming to be an expert in the field, however I hope you can take something away from this article that will either inspire you or simply add a new tool to your belt.

Setting up your project

#1: Plan ahead

This probably sounds like common sense, but it’s worth addressing.

The Unity ecosystem encourages you to use both free and commercial frameworks and tools to build your project. Make sure you understand any license restrictions, workflow requirements, platform restrictions, and performance impacts that a new package has before you commit to it. You can, for example, build a small demo project around the new package to get used to it and validate its capabilities.

If you plan to localize, do it right from the start. If you localize late in the project life cycle, you’ll end up doing a large amount of tedious and expensive string hunting. You’ll have to re-create assets that have text baked into them and be stuck tracking down far too many strings cobbled together by programmers at run time.

The need to plan ahead applies to all elements of your application’s design. Multiplayer, for example, is much harder to add in later than to build in from the beginning. Whether you’re using Unity Netcode, a third-party framework, or rolling a custom solution, you will want to pick an approach before you get too far into building the app.

#2: Use an LTS version and stick with it

Unity has two related release cycles.

  1. LTS or Long Term Support contains annual releases and non-breaking patch updates for projects that require a stable environment.
  2. Tech Stream provides a rapid release cadence, includes in-development features, and occasionally contains breaking changes.

The more stable LTS version of Unity is almost always the right choice for any project that doesn’t explicitly need the latest features added in the Unity Tech Stream releases. LTS versions of Unity are guaranteed two years of update support and no breaking API changes. This is what you want to base any sort of serious project on.

#3: Select a VCS (Version Control System)

Unity has two main integrations with version control systems: Perforce and Plastic SCM.

A Unity project usually has at least some, and possibly many, large (greater than 100MB) files in the repo. These are typically not very compressible, hard to diff, and not mergeable at all. If you’re using another source control system like Mercurial or Git, make sure you set up its corresponding large file extension. For Git this is LFS and for Mercurial this is the LargeFiles extension.

#4: Smart Merge is your friend

The Unity Smart Merge tool removes the headaches caused by merging changes in scene and prefab files. It’s compatible with just about every source control system out there too.

You will create a lot of scene and prefab files in a Unity project. These are stored as YAML files which regular diff tools can merge as regular text, but this may not be very successful when you have non-trivial changes. The Smart Merge tool understands how the Unity editor works with these files and can merge complex changes much more easily.

#5: Deploy to your target platforms(s) early and often

Platform-specific features, quirks, and incompatibilities are a reality of life for an engine that supports as many platforms as Unity does. Catch these problems early by setting up your build for your target platform early on, even if it’s just a ‘hello world’ scene at first. Your CI/CD pipeline should also be building to each environment when you merge code. (You have one of these right?!)

It’s also a good idea to at least build to potential future platforms you may support later on, even if you don’t do full build verification tests (BVT) on them.

Similarly, it’s very tempting to test your new features and content by just entering play mode and trying things out. This is great for testing in-progress features and debugging code, but always test in your target environment as well to ensure compatibility.

#5: Setup assembly definitions

Unity uses assembly definitions to create logically separate code libraries.

When you add a script to a Unity project, you don’t have to add a namespace to it in order for it to work. However, it is good practice to use namespaces and create assembly definitions for a few different reasons, namely it:

  • assists you in logically separating your code.
  • reduces the number of code files Unity recompiles when code changes.
  • helps isolate any editor or test code that you don’t want built into the final product.

#6 Build effective tests and keep them up to date

Unity embeds the NUnit framework directly inside the editor. You can easily use it to build out unit and integration tests for both your application code and any editor extension you write. It’s also very easy to deploy these tests to phones and tablets for on device testing.

Testing is a big topic. Luckily, test strategies are the subject of the next article in this series.

Additional resources

Unity is a large ecosystem and there’s a lot to learn. Here are a few additional resources you can use to branch off into specific subjects in different formats to best suit your requirements and learning style.

  • Unity Learn — Beginner to advanced lessons on a variety of topics
  • Unity official Youtube — Everything from new feature demos to recordings of live training events. The recorded Unity Unite conference videos are particularly good
  • Unity official docs — If you can’t find what you need somewhere else, it’s probably here

Now it’s time to go build something!

No matter how much you read about something, it’s no substitute for hands-on experience. The best way to learn is by building a small project for yourself or your company—starting with projects small in scope and scaling from there.

I’ll be writing more articles on scaling Unity projects up, building good tests, and measuring and tuning performance in the coming weeks, so stay tuned!

--

--