Down the rabbit hole

So armed with a vague sense of purpose and a half-baked plan, I went straight for the fun part: a game programming course on Udemy.

There are quite a few. I bought a couple while Udemy had some sales on and they seem to use some common programming ideas. I’m naming no names here as these courses are aimed at beginners. Bashing noobs round the head with complex design patterns would probably significantly reduce the course completion and satisfaction stats, but I simply can’t code in the way they describe while keeping a straight face.

Mainly they’re useful to me for learning how the Unity environment works. It’s a bit opaque on first opening, so a visual course for beginners really opens it up. Occasionally they even reveal a coding technique that’s useful

Things learned:

At its core, Unity uses a component base architecture. Many components come with the engine: collision detection, physics and the like are all implemented as components. You can write your own scripts, which are also components, or buy them in from the asset store.

Components are added to Game Objects. These represent some kind of entity, like a player character, an enemy, the camera, a wall… Or just a place to hang scripts and components. They exist within “scenes”, which are collections of game objects that maintain independence from each other.

GameObjects can be arranged in a hierarchy, and those with a visual component can be arranged using design tools built in to Unity.

Each scene is completely separate from the other scenes, so all GameObjects are destroyed when a scene changes. This includes any class instances you’ve attached to GameObjects in the scene, but you can set some objects to persist. Unfortunately, to avoid getting multiple copies of important objects on scene reload, you also have to make them into Singletons. (Waring bells might start going off at this point.)

You attach scripts to GameObjects, much as we used to do with Flash in the bad old days. Remember Flash? No? You’re lucky. The scripts can reference other game objects, which you can either drag into a slot in the object “Inspector” using the visual tools, or “find” at runtime from the pool of active objects. (Awooga! Awooga!)

A more interesting feature is “Prefabs,” which act as, I suppose, “prototypes” for game objects (or collections of game objects.) Pretty much everything in a scene can be made into a Prefab, just by dragging it into the assets folder. This includes UI elements, the camera, players, enemies, etc. Prefabs can be used like a template to create copies of elements within the scene, but you can override individual properties on selected copies. Their utility extends beyond that description, and it seems like a good idea to turn pretty much everything in your scene into a prefab.

The next couple of posts will describe some coding patterns I’ve seen in these courses, why I feel uncomfortable using them, and some alternatives I’ve researched and may try.