Behaviours

• Attached to a GO. Many GOs may have this script.
• A MonoBehaviour.
• Can be used multiple times in a scene.
• Can implement interfaces.
• Great for enemy behaviour, trigger & door logic, reacting to OnTrigger events.

Controllers

• Attached to a GO like a Behaviour
• Single instance of this may exist in a scene at once.
• Do not register as a Singleton. Instead use a Service Locator.
• Can reference the Service Locator.
• Can reference other Controllers (careful!)
• Can implement interfaces.
• Typically, these aren't shared between projects and are highly coupled with other scripts.
• Great for puzzles, menus, player movement, overall gameplay logic, timer logic, sfx repo & playback.

Services

• Like a Controller, but more portable.
• Shouldn't have references to other controllers.
• Shouldn't have a reference to the Service Locator.
• Can register self as singleton, use Service Locator, or force other scripts to use GameObject.FindObjectOfType<ServiceName>().
• Can implement interfaces.
• Great for Input logic, Data logic, high level scripting

Interfaces

• Used to define functionality for any class.
• Other classes can expect your class that implements the interface to have that functionality.
• Great for working with services that are generic that have to interface with specific controllers, behaviours or utilities.
• For example a ITakeDamage, IReactToPlayerInteractions, IHurtPlayer.

Utilities

• Static functionality bundled together in a static class.
• Doesn't need to be instantiated or attached to any GameObject.
• As long as it is in the Assets folder, you will be able to access it.
• Can implement interfaces.
• Great for highly portable, static code. Anytime you find yourself copy/pasting code, consider making it static and throwing it in a Utility class.
• For example ScreenResolutionUtility, InputUtility.

The Service Locator

• Used to couple controllers to each other and other services.
• Has Controllers and Services as members.
• Controllers can reference the Service Locator, but Services cannot.
• Define one for each mode of your game. (Main Menu, Game Play, Mini Games, etc.)
• Don't overuse. Try to make things as portable as possible.
• Great for connecting Controllers to portable Services

Example

The MainMenuServiceLocator references the MainMenuController, the InputService and the UIService. The MainMenuController references the MainMenuServiceLocator, but the InputService has no reference to the MainMenuServiceLocator. The InputService may have an event to subscribe to. The MainMenuServiceController can access the InputService from the MainMenuServiceLocator and register itself. The MainMenuGameObject needs to have all of the components attached MainMenuServiceLocator, MainMenuController, InputService and the UIService. If there is a UIUtility in your project, as long as it is in the Assets folder, it doesn't need to be attached to the MainMenuGameObject.

Persistent Class (Persistent Service, Persistent Controller, etc)

• Are not destroyed when a scene is unloaded.
• A class that persists between scenes.
• Uses DontDestroyOnLoad(this.gameObject);
• Must destroy itself when it's done. May not be destroyed if it is always needed.
• Other classes shouldn't store a reference to it. Instead should look it up when needed.
• Shouldn't be listed in the Service Locator.
• Good for managing data, making server calls, and managing game state.