Working in Unity

The gist

  • Why Unity?
  • Key concepts

Why Unity?

Unity is a strange beast. It provides a lot of great tooling to speed up workflows that are typically very tedious when you have to do it yourself, but at the cost of adhering to their design choices, some of which where made a very long time ago. Overall, the ability to get shit done most definitely outweighs most downsides, but after a few weeks of stumbling around, here’s what I’ve discovered and is worth sharing to others unfamiliar with it.

One of the key reasons I went with Unity is that they support C# as a scripting language. They support others (like javascript), but I can not fathom a good reason to use any other than C#. The only argument you could make to use js might be because you are familiar with it (since you know how to code the webz), but that is not a great argument since you can, uh… learn C#. If you are willing to put the time into writing a game, the time investment to pick up C# is well worth it. If you know Typescript, you’re 80% of the way there anyway. Just do it.

Additionally, Microsoft fully embraces Unity. When installing Visual Studio, you can actually opt to install Unity and associated support tooling. That is awesome.

If you already know C++, or you are making a game in 1998, then perhaps a C++ workflow is right for you. Joking aside, there are good reasons to go that route, but none of them apply to my own projects, so this will hopefully the last time C++ comes up.

Key Concepts

Unity still surprises me on occasion, but here’s the best way I can describe how it works:

The Editor

The interesting bits are the scene hierarchy, the project view, the scene view, the game view, and the inspector.

This is mainly just to show what I am talking about, Unity has plenty of tutorials and API documentation on all of this. Understanding how to think about this stuff is more interesting. Here’s my take on it:

The stuff you work with

When your game starts, you are always operating within a Scene. You can load or unload scenes as you play the game. Scenes can be used as separate levels for example.

In the Scene live GameObjects. These are represented by the white / gray / blue cube icons in the hierarchy. Any object that you can interact with in a scene (balls, cameras, UI elements, whatever) is a GameObject.

How a GameObject behaves is dictated by MonoBehaviors. Monobehaviors are actual scripts (usually C#) that define what the GameObject does.The easiest way to assign a MonoBehavior to a GameObject is to select the GO in the hierarchy (Game in the above picture) and drag and drop a script from the project view onto the object itself, or into the inspector. The inspector shows all scripts attached to the selected GO.

Here are a few concepts it took me a while to get my head around and fully understand.

  • A GameObject is an instantiation of an object – not a definition (more on prefabs later).
  • Although the UI indicates otherwise, you should think of GameObjects in an ‘is a’ relationship with MonoBehaviors (it looks like a ‘has a’).

The last point was non-obvious to me at first. In the picture above, it looks like a Game has a Score Manager, and has a Save Manager. This is the wrong way to think about it. Instead, a Game is a Score Manager and is a SaveManager. MonoBehaviors are not like C# interfaces, which I’ve found serve a different purpose in Unity, but now that I think about it, it’s sort of a way to accomplish multi-inheritance behavior (which C# does not allow). I’ll get into that more in a later post.

As I go through how I implemented my game in later posts, this stuff will make sense. Not understanding some of these basic ideas led to some strange or incorrect ways of manipulating the objects in my world.

Play vs Edit Mode

The other concept that has major implications on how you design and test your game is the difference between Play and Edit mode.

Edit mode is for working on your project, and Play mode is for testing

Unity Basic Tutorial #1

When you start your game from Unity, the influence of the IDE does not end there. While the game is running, you can continue to manipulate GameObjects and values in MonoBehaviors. This makes game testing incredibly convenient. If you have a run speed for your character set to some value, you can double it on the spot to see how it looks if he runs twice as fast. The Editor view can actually render debug information related to a particular GameObject alongside it in the scene itself.

In order to achieve this experience, however, you must sometimes do things a certain way to facilitate it. This is a constant push and pull for myself personally, because doing things in a way the Editor likes is sometimes a questionable design decision in any other application.

Again, be sure to stop and check out their tuts for the real meat on the subject before moving forward. Glossing over this distinction initially caused me more than a few headaches down the road. I’ll share my experience with specific examples in later posts.


Leave a Reply

Your email address will not be published. Required fields are marked *