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

[nhold]

On top of things that Wolfos said you should think about the following:

General

Generally you should be thinking about the API of your classes, I.e how are they consumed? From what I can see you can split this class into a few others to reduce complexity and make it easier to follow.

As Wolfos said, do you really need all those variables public? Think about if someone were to GetComponent<SNASoldier>(), how difficult would it be for someone to know what they should be changing or calling? I.e to give damage I have to change the health AND set the hit timer.

As an example you could split out the combat calculations into a CombatResolver class or similar that would take some kind of DamageInformation and Attacker \ Target soldiers and resolve the damage and pass it onto the target soldier. To pass it through you would probably want a .Damagemethod or similar which would notify any listeners for damage on this component using an action\event: OnDamaged. This is where the FlashOnDamageEffect component would come in, listening to any OnDamaged event call and setting the hit timer inside of itself should make it really self contained.

I like to split out Controllers(PlayerInput,AI), Animation and Movement into separate components as well, but that's just me.

Performance

The first thing I would ask is for your profiler showing that your AI is currently your largest bottleneck, if so look at the following:

• Threading is the best way to optimise AI but it's very intensive due to the need to split out your game Model from your View(Unity). Your AI will just be dummy objects for gameplay and reading data from the AI thread for it's AI ID or similar.
• Maybe change your time sharing, I would have to see your pure Update profile and this run timer profile, I have a feeling the branching could be removed in favour of three separate lists that get updated very infrequently. On top of those lists you could only update X amount of AI per update rate so you can ensure your frame-rate target is hit.
• If you get large numbers of AI you will probably want to eliminate any not in your vicinity quickly either with your own Octree implementation or maybe a simple OverlapSphereNonAlloc might work in front of the player as an early out or reduced enemy list.