Systems in the game are kept simple, bound to the game state.
The GameManager handles state updates and broadcasts changes.

public enum GameState { MainMenu, PreparingGame, GameReady, Playing, GameOver, } public static event Action<GameState> OnGameStateChanged; private GameState currentGameState = GameState.MainMenu; private void Start() => SetGameState(GameState.MainMenu); public void SetGameState(GameState newState) { currentGameState = newState; OnGameStateChanged?.Invoke(currentGameState); }

Numerous components in the project are designed to react to game state alterations. One of these components focuses on preparing the game initialization process. It contains references to scripts responsible for spawning core objects such as the player and the balls. These spawners are sequenced to avoid simultaneous occurrences. Once all necessary elements are spawned, it signals the GameManager to transition the game state to "Playing."

private void OnEnable() => GameManager.OnGameStateChanged += OnGameStateChanged; private void OnDisable() => GameManager.OnGameStateChanged -= OnGameStateChanged; private async void OnGameStateChanged(GameManager.GameState state) { if (state == GameManager.GameState.PreparingGame) await SpawnEntitiesSequentially(); } private async Task SpawnEntitiesSequentially() { await ballSpawner.GenerateBallsAsync(); await spawnGuardSpawner.GenerateSpawnGuardAsync(); await playerSpawner.GeneratePlayerAsync(); await Task.Delay(1000); GameManager.Instance.SetGameState(GameManager.GameState.Playing); }

In this project, the Player's Health Script serves as an independent module, managing the player's health logic. This script enables seamless interaction with other game components and handles all health-related operations. Additionally, when the player dies, a separate component listens for the OnPlayerDied event, and changes the game state.

public static event Action OnPlayerDamaged; public static event Action OnPlayerDied; private void Awake() => playerData.CurrentHealth = playerData.MaxHealth; public bool IsAlive() => playerData.CurrentHealth > 0; public int GetCurrentHealth() => playerData.CurrentHealth; public int GetMaxHealth() => playerData.MaxHealth; public void TakeDamage() { playerData.CurrentHealth -= 1; if (playerData.CurrentHealth <= 0) { Die(); return; } OnPlayerDamaged?.Invoke(); } public void Die() { playerData.CurrentHealth = -1; OnPlayerDied?.Invoke(); Destroy(gameObject); }

The GameManager oversees the player's death. Upon death, the game state transitions to "GameOver."

private void OnEnable() => PlayerHealth.OnPlayerDied += OnPlayerDied; private void OnDisable() => PlayerHealth.OnPlayerDied -= OnPlayerDied; private void OnPlayerDied() => SetGameState(GameState.GameOver);

The UI design aligns with the game state, simplifying UI management. Game object components with GameStateUI activate when the associated game state matches. This setup facilitates easy addition of a pause state and associated UI.

public class GameStateUI : MonoBehaviour { [SerializeField] protected GameManager.GameState associatedState; protected virtual void OnEnable() => GameManager.OnGameStateChanged += OnGameStateChanged; protected virtual void OnDisable() => GameManager.OnGameStateChanged -= OnGameStateChanged; protected virtual void OnGameStateChanged(GameManager.GameState state) { if (state == associatedState) EnableUI(); else DisableUI(); } protected virtual void EnableUI() => transform.GetChild(0).gameObject.SetActive(true); protected virtual void DisableUI() => transform.GetChild(0).gameObject.SetActive(false); }

There is many ways to implement Bootstrap logic, either having a Bootstrap scene or -script that handles project initialization. I chose to go with the code solution that loads a Bootstapper prefab from the Resources folder. The benefit of this is it doesn't matter which scene you are starting from, since the Bootstapper runs before scene load. This is a great way to have singletons and managers attached to a single bootstrap prefab that gets created when the game runs.

public static class Bootstrapper { private const string prefabName = "Bootstrap"; [RuntimeInitializeOnLoadMethod(RuntimeInitializeLoadType.BeforeSceneLoad)] public static void Execute() { GameObject existingPrefab = GameObject.Find(prefabName); if (existingPrefab == null) { GameObject bootstrapPrefab = Resources.Load(prefabName) as GameObject; if (bootstrapPrefab != null) { GameObject instantiatedPrefab = Object.Instantiate(bootstrapPrefab); Object.DontDestroyOnLoad(instantiatedPrefab); } else Debug.LogError($"Prefab '{prefabName}' not found in Resources folder."); } else Debug.LogWarning($"Prefab '{prefabName}' already exists in the scene. Not instantiating again."); } }

When projects get bigger there will be more systems and logic running at the same time. Using Unitys Debug.Log messaging can work as long as the console doesn't get bloatet with information. Sometimes when that happens I've used Debug.Error messages to find the logs I want to see. That's not how error logs are supposed to be used so that's when I decided to create this little logger.

Main points of this is to allow to have different loggers such as AudioLogger and InputLogger, which have their own color in the prefix when they log data. Having the option to disable some loggers is also nice, which makes debugging easier and console less bloatet with log messages.

[CreateAssetMenu(fileName = "Logger", menuName = "Logger/new Logger")] public class Logger : ScriptableObject { public enum LogType { Info = 0, Warning = 1, Error = 2, } [SerializeField] private bool showLogs = true; [SerializeField] private string prefix = ""; [SerializeField] private Color prefixColor = Color.green; public void Log(string msg, Object sender = null) => LogMessage(msg, sender, LogType.Info); public void Warning(string msg, Object sender = null) => LogMessage(msg, sender, LogType.Warning); public void Error(string msg, Object sender = null) => LogMessage(msg, sender, LogType.Error); private void LogMessage(string message, Object sender, LogType logType = LogType.Info) { if (!showLogs) return; string logMessage = $"[<color=#{ColorUtility.ToHtmlStringRGB(prefixColor)}>{prefix}</color>] {message}"; switch (logType) { case LogType.Info: Debug.Log(logMessage, sender); break; case LogType.Warning: Debug.LogWarning(logMessage, sender); break; case LogType.Error: Debug.LogError(logMessage, sender); break; default: Debug.Log(logMessage, sender); break; } } }

Another tool that makes development faster in the long run. When project gets bigger, some content will be moved over to their own scenes in Unity. Just to make life a little easier I made a scene switching tool way back. It gets all scene files from the project and displays them on a separate window and allowing scene switching to them.

public class SceneSwitchWindow : EditorWindow { [MenuItem("Tools/Scene Switch Window")] public static void Init() { SceneSwitchWindow window = GetWindow<SceneSwitchWindow>("Scene Switch Tool"); window.minSize = new Vector2(200f, 200f); } private void OnGUI() => ScenesToButtons(); void ScenesToButtons() { string[] sceneGuids = AssetDatabase.FindAssets("t:Scene"); List<string> scenePaths = new List<string>(); foreach (string guid in sceneGuids) { string path = AssetDatabase.GUIDToAssetPath(guid); scenePaths.Add(path); } for (int i = 0; i < scenePaths.Count; i++) { string scenePath = scenePaths[i]; string sceneName = Path.GetFileNameWithoutExtension(scenePath); bool pressed = GUILayout.Button($"{sceneName}", GUI.skin.button); if (pressed) SwitchToScene(scenePath); } } private void SwitchToScene(string scenePath) { if (EditorSceneManager.SaveCurrentModifiedScenesIfUserWantsTo()) EditorSceneManager.OpenScene(scenePath); } }