These slides are already online .

feel free to ask questions during the talk.

Also, lets keep it informal

processes I use when I'm writing code in unity.

It's just the mistakes I've made and some of the

definitive "how you should use unity".

This talk isn't by any means the

But lets just focus on the big ones

But lets just focus on the big ones

Like most people, I made a lot of mistakes.

Like most people, I made a lot of mistakes.

for using the engine.

"best practice" for using the engine.

At that time there wasn't any considered

Your project becomes a nightmare made from "order of Update/Awake" bugs.

The inspector gets filled with parameters that don't relate to the object you're working on.

Your "clean" and "modular" code instantly goes to hell as you try to cover all the edge cases needed by every object in your game.

collections of them in the editor.

every object in your game out of "reusable"

It's very tempting to think you can create

Making everything out of "generic" components.

Short version. I only use these features when I have to, and even then I do so very sparingly.

And editor logic and visual scripting tools are great until a point, after which they become complex, impossible to debug... and completely indecipherable to anyone but the person who set them up.

And editor logic and visual scripting tools are great until a point, after which they become complex, impossible to debug... and completely indecipherable to anyone but the person who set them up.

SendMessage is great in theory, but a pain to debug and work with. I've had problems where it wouldn't appear in callstacks, it misreads null as "no parameter".

Editor logic also seems like a great idea, you have a button in your level or in the user interface. Instead of linking them by code you put a UnityEvent or EventDelegate in the inspector.

On the surface, SendMessage doesn't seem like a bad idea. You SendMessage an "event name" and if any component on that object has a method with the same name, it gets called.

to be writing tests than fixing bugs.

I'm a firm believer that it's more fun

Automated testing = you spend your time making game, instead of spending time figuring out why it's not working.

Unity even has one on the asset store that is deeply integrated with the engine.

There are awesome testing frameworks around. Unity even has one on the asset store that is deeply integrated with the engine.

Like nearly everyone in the games industry,

(or anyone else) can pick it up and actually get on with things.

From now on all my code is written so that future Kieran

Without fail I will always forget this stuff.

an object so that it works as intended.

remember what components I need to manually put onto

Assuming that in 24 months time I would

I have a process for writing programming objects in unity.

I have a process for writing programming objects in unity.

After all, we're making games here,

and hacked up as it needs to be.

t can be as dirty, over-specific

I t can be as dirty, over-specific

This component is the place for

your actor will have that component.

and prevent users from manually removing it using the inspector.

It will add the required component automagically

It's an attribute that you attach to a monobehaviour class .

One of the rules for Actor components is that I never manually add non-actor components in the inspector.

while writing another actor component. I refactor the functionality into a shared component.

If I later find that the same functionality would be needed

I start out by writing all functionality

parameters

The way you expose parameters to the inspector can make all the difference for your programming and design workflows.

A good parameter is...

Public only if it needs to be.

Only accepts the types of object it can use.

It's something you ACTUALLY

need to tweak in the inspector.





Public and [SerializeField] Parameters

There are two ways to put a variable in the inspector

Prefix it with public - OR - Prefix it with [SerializeField]

There's an important difference!

PUBLIC AND [SERIALIZEFIELD] PARAMETERS

[SerializeField] members appear in the inspector but are NOT accessible from other classes/components.



Public members also appear in the inspector but CAN be accessed from the code of other classes & components.

General rule, make all parameters as [SerializeField] you can convert them to public if you need to later.



Why?

Unnecessary public members cause problems:



They clog up your code auto-complete windows with variables you're not interested in.



They require more work & testing as they need to be able to be changed at any time without breaking anything.

USE Specific parameter types

Object parameters in the inspector can accept a component/asset/object of that type... or any object derived from it.

A very common practice is to reference just about every asset/prefab/object as GameObject.

This tragedy has to stop.

NOT USING SPECIFIC TYPES Common example; I have a cannon.

The cannon has a parameter for the prefab for the object it will create when it fires.

Whatever, lets make it a GameObject so it could fire "anything"

So the code creates it then... and immediately has to check if it has a bunch of components, rigidbody, damage type, bullet owner. That's a lot of assumptions.

USING SPECIFIC TYPES So instead, you make the parameter ActorCannonShot.

It's an actor component.

It already has all the components garunteed cached, no calls to GetComponent needed.

Hell, lets just give ActorCannonShot a FireMe() method. Firing your cannon just became a 2 line job.

You can even change the parameter to be a base class for various CannonShot components and it'll still be like this!

DO I really need aN INSPECTOR parameter for this?

If you're a programmer there are two places you can put variables to make them tweakable.

In your code as constants. - OR - As inspector parameters.

Try to only use inspector parameters for values that need them. Otherwise your inspector window can get a mile long.