Is it best practice to not attach a pause script (or others) to a GameObject?

Questions & Answers
1

I want to add pause functionality to my game, and have the start of the following script:

public class Pause{

// Update is called once per frame
void Update () {
	if(Input.GetKeyDown(KeyCode.Escape)){
		//pause game
	}

}

I was thinking it would be best practice to not have this attached to a game object like “player” etc, as sometimes this object is destroyed. i’ve heard of people using utility scripts that aren’t attached to game objects to do calculations and was wondering if it is possible to make a similar utility script that waits for the user to press escape and pauses the game, or does this script have to be attached to a game object?
Thanks.

2

Hi @cpcrox1, your question is really depending on what type of game/application you are developing, even which is your architectural approach.

I’m not going to deep in all the architecture types, but can give a simple answer.

Simplifying things a lot, I like to have at least one “SceneController” object that rules all the components of the scene. One of those components can be a “PauseManager” in charge of all the pausing stuff. This can be achieved with a static class, a singleton, a WorldInfo+GameMode combination… What It’s definitively not a “best practice” is to give to a player object the responsibility of pausing the game.

Extra tip: I hate MonoBehaviour.Update(), and you need to get rid of updates as much as you can. Querying Input.GetKeyDown(); on every single script you need Input feedback is a thing you must avoid. You can always create a custom InputManager that registers callbacks for Key events. I’m sure that there are a lot of good tutorial/examples out there.