sigtrap

This is a series of posts prompted by an observation – the vast majority of Unity tutorials and articles (official and third-party) teach how to use Unity, not how to design software.

It’s easy to find, for example, specific help on “how to make a hitscan weapon in Unity”. And there’s plenty of abstract software design stuff floating around the internet, but little on how to relate it back to Unity development. The result is that, for those without an existing background in programming, the “natural” way to learn Unity is like a jigsaw puzzle, putting together pieces. But it’s harder to learn general software design, with Unity as a framework. This can easily result in a mishmash of spaghetti code with little large-scale coherence.

Most tutorials teach how to use Unity, not how to design software

So hopefully this series can give some high-level – but practical – advice on creating games in Unity with better planned, more maintainable, more solid programming.

Some Caveats

Firstly – I’m just a guy. I don’t represent a hive mind consensus on software engineering. I’m writing from my experience, but my opinions (because that’s what they are) may be controversial, unconventional, or wrong. And I don’t have all the answers.

Secondly – there are no right answers anyway. Software engineering is not a solved problem. In many cases, there aren’t even widely-accepted best practices. I’ll say these many times throughout the series:

No single technique or pattern will solve all your problems.
Every tool has jobs it’s good at, and others it’s not.
All techniques can be used or mis-used.

The important thing is to have a broad understanding and not be dogmatic. And given the choice, get stuff done rather than agonise endlessly about how. But a little planning (and a lot of flexibility) can go a long way.

Thirdly – my examples will usually be trivially simple. They’ll be easily solved a dozen ways, often including ways I’m telling you to be wary of. They’re just there to illustrate a basic point as clearly as possible; in most cases my advice will only really help when a project gets more complex. But mark my words – real-life code always does.

Finally – these aren’t tutorials. These are introductions to techniques, warnings about common mistakes, and musings on the more abstract structure of code. How-to guides would defeat the point, and I’m too lazy anyway.

I’m generally aiming at a post every two weeks, on Tuesdays to line up with the #UnityTips hashtag on Twitter. You can see all the posts here.

-Luke