This is more a question about architecture. Not sure if there's a right or wrong:

Let's assume I have some gameobjects:

  • GUI: A menu containing some elements like "Go to position". It's opened when right clicking in the game
  • Main Camera
  • Characters: Characters in the game which can be controlled by the player

Now I was thinking about the following scenarios:

  1. A character is clicked. It's highlighted yellow. This should definitely be done in the script of the character.
  2. When a character is highlighted (or selected) and the right mouse button is clicked, the GUI will be shown. Where does this have to be implemented when talking about clean code? In the character? But then the character has to know about the GUI. I'm not sure if this is clean. In the GUI? Then then the GUI has to know if a character was highlighted (or selected). Doesn't feel clean too.
  • \$\begingroup\$ For 1, you could have a SelectionManager, this will managed all currently selected characters. For 2, you could use a CharactersCoordinator, in which the GUI will notify that user has requested a "Go to position". The CharactersCoordinator would then use the SelectionManager to move the currently selected characters. \$\endgroup\$ Oct 19, 2015 at 13:35
  • \$\begingroup\$ For 1 ... how can the SelectionManager be informed by the character that it was selected/highlighted? \$\endgroup\$
    – mosquito87
    Oct 19, 2015 at 14:03

2 Answers 2


Have you considered implementing the observer pattern? http://gameprogrammingpatterns.com/observer.html


In your case I'd add an "Input Watcher" component to the Main Camera (or similar Game Object).

To me the Input Watcher component is in charge of watching every player input and react accordingly. In your case, the Character component would inherit from, let's say, iSelectableObject (an interface that allows you to select the Character with the mouse or any input).

Once you click on the Character the Input Watcher component would know what you're trying to do and select the Character because it inherits from iSelectableObject (the Select() method of the Character would be called and the Character would display the yellow border you want it to show). Input Watcher now knows that an iSelectableObject object is selected and can now display the right GUI according to the type of the object. In your case it would be the button "Go to position".

To avoid having a gigantic list of if/else I usually use a state machine in the Input Watcher component to call and update the right state at the right time.

  • \$\begingroup\$ One minor quibble: since Unity encourages composition over inheritance, it may work smoother to add a "SelectableObject" component to each character, rather than implementing a selection interface in the character/other selectable entity classes. This keeps the behaviours a bit more modular, which supports iteration over the course of the project. It also means designers can make new content selectable (eg. A one-off prop in a certain level) through the editor by just dropping a component on it, without changing any code. \$\endgroup\$
    – DMGregory
    Oct 21, 2015 at 19:57

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .