How to Start Unity Development, Even if You’re Not a Gamer

Unity is a favored development platform of the game-making community. It allows the developer to work with rich 2D or 3D graphics and animation. It has also, over time, absorbed some of the tools and practices needed for successful teamwork. While the recently released rival platform Unreal Engine 5 focuses on top-end cinematic visuals, Unity remains more concerned with keeping its growing module empire manageable.

You may be looking wistfully at a platform designed to produce games because you want to investigate game development, but what is under-appreciated by mainstream developers is how well Unity targets most popular computing platforms (PC, Mac, mobile, and web) with C# and the .NET Standard profile. It’s also a very sensible way to do cross-machine development. Of course, you may just need to create an application with a high level of audio-visual presentation and user interaction. With Unity, you don’t have to lose source control, pipelines, integration testing or LTM releases.

Talking about a game development platform would have seemed like crossing the Rubicon in the past, because mainstream developers looked at games as Another Country. Over the years, however, the two nations have gotten closer. That terrible term “gamification” now just implies that users like spending time on apps with good UI and good feedback. And whatever we think of the possibilities of a metaverse, at least we have the tools to populate it.

In this article, I’ll try to show you that while Unity is far from simple, you should consider it as a valid way to work, even if you are not a Rockstar. In a future article, I’ll do something a little more complex, but for now, let’s just consider how it achieves the basics.

Unity Development: The Basics

Unity development is in no way finished, and incoming offerings sometimes clash in a contradictory fashion. However, it does have a fairly consistent way of dealing with additions and preview components, with its package management system. This demo uses only built-in packages.

The first big blocker for most developers new to the system is that you cannot do everything programmatically. You do need to work with the Unity frontend as well as with your code editor. In general, the code does the manipulation, but Unity handles the relationships between objects. Like other opinionated platforms, it has a specific way of doing things, and working against the grain is unwise until you know the ropes.

So what do we actually need to get a simple app on the screen? You need the following:

• A version of Unity.
• Visual Studio, and a comfortable knowledge of C#.
• A willingness to work in a slightly different style.

Unity recognizes a GameObject as its basic unit. These are containers for different components. You can build up a Scene via a hierarchy of GameObjects.

Building a Unity Program

For this tutorial, we will stick to something simple. Let’s examine a project that just places text onto a button after it is pressed.

OK, this obviously isn’t about showing off the myriad capabilities of Unity. Responding to a button press is the equivalent of “Hello World” for anything with UI. But it does give a glimpse into the design constraints of Unity.

Before we stare at the Unity application in all its glory, let us just note one preference:

👁 Image

Unity has a direct relationship with your Visual Studio. This is important, as it can create the right style of C# solution without much intervention.

Anyway, back to the main event. The Unity application:

👁 Image

Obviously, the window panels can be re-arranged, but this is a typical setup. The Hierarchy panel on the left shows what I built from simple menu clicks for this demo scene. We have a Canvas GameObject (i.e. an object in Unity parlance named Canvas), that contains a Button GameObject, which contains a Text GameObject. The button can be seen visually represented on the screen in the center. Note that we are in the “Game” tab. The Inspector panel on the right shows that our Button GameObject seems to have various components within it.

A Canvas represents the background GameObject that the button sits on. Unity makes some simplifications for 2D applications. However, you can see that we could also play with a camera, or the image and styling of the button — none of which we want to do right now.

Let us look further down the component list to the Button component itself:

👁 Image

There are two things that concern us here at the bottom. First, there is mention of a script called “ButtonHandler.” A script maps to a class in C#. When I ask for Unity to create a script, it first creates the appropriate Solution within Visual Studio, then starts a template from which I wrote the following:

using System.Collections;
using System.Collections.Generic;
using UnityEngine;
using UnityEngine.UI;

public class ButtonHandler : MonoBehaviour
{
 public void SetText(string newText)
 {
 Text txtComponent = GetComponentInChildren<Text>();
 txtComponent.text = newText;
 }
}

There is precious little here to think about. First of all, the ButtonHandler class extends MonoBehavior — this is what allows it to participate with Unity code. There is one method called SetText, which has one string argument. I find the Text component, then set the text.

Note that I use the hierarchy of components to find the Text component. This script itself is treated as a component of the Button GameObject. And we know that there is a child GameObject called “Text”, which contains a Text component. (The Inspector confirms this). As there is only one Text component, we successfully find it.

Now, look back at the Button component above in Unity. It advertises one event, OnClick, that I subscribed to. I selected the Button object itself (you can literally drag it in) and Unity asked which method I wanted to call, and with what parameter. As you can see, I called SetText with the string “The New Stack.”

Running the Program

Before we run this, let’s just check what we know:

• A Unity Scene is the virtual place we work in.
• A GameObject is a general container for components.
• We put a button on a canvas. The button contains text.
• The code class extends MonoBehavior. This lets it work with Unity objects. The code itself is a script component.
• The familiar listener pattern is used, with an OnClick trigger.
• The organization of the GameObjects is managed by Unity, while the code deals with responding to the button press.

Here is the exciting outcome of running the program and clicking the button:

👁 Image

Note that we have pressed the “play” button and remain within the Game view tab. I clicked the button, then captured the above image.

We could then go on to build the application and produce an executable, but our aim was just to go over the basics of working in Unity. The takeaway is to understand the interplay between what lives in Unity, and what lives in code. There are several ways I could have achieved the same goal, but they would all involve a similar relationship.

Next time, I’ll demonstrate a recent Unity UI module that looks very much like HTML and CSS. Meanwhile, see if you can have some fun with Unity.