The Unity scripting system is very easy to use once you get a “feel” for it – which might take a while. There are a few libraries to get familiar with, and some critical components to be aware of (things like Time, Transform, Mathf, and Camera are pretty critical off the bat). But at it’s core, Unity deals with GameObjects – a base class for all objects – which are object-oriented containers for components – behaviors and characteristics.
In practice, it’s pretty straightforward. You have an object. Want to make it player controlled? Link in a player control component. Want to make it visible? Link in a mesh renderer using whatever player mesh you want. Want it to leave a trail behind it? Link in a trail component. For more complex objects, your game object can have a number of “children” objects, all with their own components. It’s powerful and elegant. And of course, much of your job as a programmer is creating these components.
Once I got into the swing of things, I quickly found that a lot of the way things were designed pretty consistently – which means to me that I could predict with decent accuracy how I expect Unity to handle things I needed to do. I felt like it was designed the way I would have designed it. This makes navigating the system much easier – when I’m trying to figure out how to do something, I simply think of how I, as a programmer, would have set it up, and go hunting for a function that sounds right. Four out of five times, I nail it. This is perhaps a subjective aspect of Unity, but it makes things a lot easier and more fun for me. It just makes sense and feels right.
