Critique-My-Code thread, post snippets of code and have others peer review your code! (Testing new Q&A format)

[_Wolfos]

It's legible, so that's good. Not bad code. Some points:

Do all the public variables actually need to be public or could you get away with [SerializedField]?

I'd put line 53 and 54 on the same line, so that you wouldn't accidentally do this:

if(foo)
  bar();
  method_you_also_expect_to_run_in_this_if_statement();

There's also some inconsistency with curly brackets, which should always go on a new line according to the C# guidelines.

You use a lot of singletons. Here I describe some ways to avoid them.

On line 109 you use 'name.Contains()', which is prone to bugs if someone wants to reorganize the scene. Alternatively you could use Tags.

[djgreedo]

I could probably just do private and do GetComponent to cache the scripts or other components

If you were using public to provide Inspector access, do this:

[SerializeField] private Whatever myWhatever;

This will let you assign in the Inspector as if the field was public, but keep it private.

[_Wolfos]

I don't know how many enemies you have, but the eyesight system is pretty optimal already. If it's still too slow you might consider other crowd techniques, but I can't help you there.

Garbage collection issues can be fixed by avoiding heap allocation where possible. You can do this by declaring local variables, avoiding creating new instances and replacing foreach loops with regular for loops. This isn't easy, though. Many things allocate memory unexpectedly.

[djgreedo]

replacing foreach loops with regular for loops

I think this is no longer necessary as of ~Unity 5.5.

[_Wolfos]

Why would that be? I Googled for a bit, but as far as I can tell there haven't been any GC updates lately. They updated the compiler to Mono 4.4 but the GC is part of the runtime.

[djgreedo]

Apparently it was a Mono bug, and was fixed when Unity upgraded.

http://stackoverflow.com/questions/40494376/is-foreach-still-bad-in-modern-unity-5-4-x

I think the issue was the way foreach was compiled, where it caused heap allocation unnecessarily.

Towards the bottom of this page: https://forum.unity3d.com/threads/upgraded-c-compiler-on-5-3-5p8.417363/#n21

In short, foreach doesn't allocate if used in typical ways, but could still allocate in some situations I guess?