Unity for Software Engineers (an ongoing series)

If you’re trying to get into game development as a Software Engineer, finding learning materials with the right level of context can be challenging. You’ll likely face a choice between following materials introducing you to basic C# and OOP concepts while also describing Unity concepts, or starting with advanced tutorials and be left to figure out the core concepts deductively.

To fill that gap, I’m writing a series called Unity for Software Engineers.

I’ll update this thread with installments from that series so as not to clutter the rest of the forum.

Even if you’re already familiar with Unity: if parts of the engine or editor feel like a black box to you, learning about the first-principles can help you in your journey to apply them.

1 Like

I wrote something like that a while ago, about 4 pages long. I was imagining a trained programmer who hadn’t even seen a game engine. My high points from personal experience were:

o Sure, you can create objects manually with new GameObject() and addComponent, but using prefabs is so much simpler.

o The “Physics” system runs by itself and it’s often worth letting it. But you can and should manually tweak velocity and angularRotation as needed.

o It’s often better to put monobehaviours on gameObjects than it is to make a “normal” class with a link to the gameObject it contols. That’s because raycasts and collision handlers present you with a GameObject. It’s so nice to be able to ask the gameObject for the controlling/data monobehaviour class attached to it.

o Tags are a game designer concept. You won’t need them since classes are better. But you will use layermasks – several commands use them to ignore certain objects.

o Start and Update use reflection. All of the built-ins do. The missing “override” isn’t a typo. But of course, normal inheritance works everywhere else.

o Infinite loops permanently freeze the entire editor (unless you’re lucky and crash due to an overfull heap). Take extra care.

o Coroutines are Unity’s version of threads. They completely abuse iterators to get sleep commands. You can also have “real” threads, but coroutines work pretty well for many “do every so often” actions.

o Ignore references to UnityScript or javascript. Way back, and for good reasons, Unity used a homebrew language, but no more. It’s all C# now.

The whole thing is at taxesforcatses.com slash codeNotes/UforP.shtml if it gives you any ideas (I’m not actively doing anything with it).

1 Like

If unsure about the loop this might save your *** during testing phase.

while(true){

bool escape = false;
if(escape){ break;}

//some code here
}

When your debugger is attached you can breakpoint and set the “escape” to true. (possibly make the escape global);

Corutines and threads are nothing alike.
Also don’t use Coroutines.

I put if(notForever++>99999) break; in any suspicious loops, but the exact manner isn’t important. There’s a class of coders who will knock out a prototype and use run-time errors to shake out bugs. An infinite loop? Press ^C, glance at it for 2 seconds, and slap your forehead as you fix it. But not in Unity. I feel like those people could use a warning about such odd behavour.

The manual is full of coroutines. People will see them. If you don’t like them it might be nice to explain how Unity’s example with a coroutine dropping a rock every second is better done using Technique-X.

Ha-- that’s helpful! I also had a lot of discussion on this over at HackerNews and indeed the most common thread from Software Engineers who have previously tried to get into Unity is trying to do it all in code. I kind of tried to cover that in my second article, although the point might need some hammering by talking more explicitly about Prefabs, etc. as you suggested.

Unfortunately it is full because of simplicity of presentation, they were also using FindObjectOfType(string) in their examples as i remember.
You cannot control them, you cannot serialize them, you cannot get current coroutines.
They are stopped when GameObject is deactivated and you cannot change this behavior.
Generally quite risky.

So what is wrong with dropping rock every second using Update ?

Oh yeah. I had a short list of Unity API stuff which was only for non-programmers: GameObject.Find of course. SendMessage, transform.Translate (easier to modify position directly). AddForce (easier to modify velocity directly).

Destroy is a real surprise. The way g1=cat; Destroy(cat) sets g1 to null is seriously freaky if you know how references work. I was hand-setting everything to null before I read how Unity added an extra smart-pointer layer to GameObject and overloaded == to make Destroy work in that magical way.

Coroutine-wise, I was wanting in Unity to sometimes fork off “sleep(2000); do X; sleep(1000) do Y …”. Where’s the sleep command in Unity? Oh, it’s in coroutines.

Third part: Unity Input System and Movement, from Basic Principles. We go over the basic principles of input and movement, showing code examples of using Unity’s new Input System to move a player.

Two more parts to the series:

  • #4: A Brief Tour of the Unity Editor. Before digging deeper, we make sure Software Engineer beginners at Unity know how to make their way around the Editor.
  • #5: Understanding Unity Engine Objects. We’ve discussed Objects and Components as an architectural context. Now, we’ll dig deeper into their programmatic representation.

My hope after covering this ground is to be able to go into areas that Software Engineers might not be skilled at, but would need if they’re going down gamedev solo. Questions like “Whats the absolute minimum I need to know about rendering and lighting?”, etc. Architecture/best practices seem like another hot request.

Four more:

So what’s up with dropping stone each subsequent utilizing Update?