This page covers the various managers included in the Corgi Engine and how to tweak them to your needs.

Introduction

The Corgi Engine uses managers as central reference points for a lot of classes and components. These managers, always present in your scene, will remember the current points count, the sounds that are playing, or where to spawn the character.

There are a few of them, and in most scenes you’ll have a Game, Level, Input and Sound managers present at all time. Usually you’ll want to place them on empty gameobjects. Their position in your scene doesn’t matter, they’re invisible anyway. It’s good practice to put them out of the way of your level so you don’t delete them by accident.

Game Manager

The Game Manager is a high level manager that is responsible for setting the target frame rate, storing the points, handling the timescale, and remembering where on the level map the player was last time. It can also optionnally handle the lives system, defining how many lives the player can have, and how many it has right now. In this case you’ll have to specify a game over screen to redirect the player to in case all lives are lost. In most cases you won’t have to interact with it, but make sure there’s one in your levels. The API documentation is a good place to go to if you want more information about it.

Level Manager

The Level Manager is a reference point for a lot of the engine’s scripts. It maintains a list of player characters in the game (usually one but you could have more if you want). It’s also in charge of spawn and respawn, and checkpoint management.

Note that there’s also a Multiplayer Level Manager, which does pretty much the same thing, but for multiplayer levels.

The LevelManager's inspector from the FeaturesPlatforms demo scene
The LevelManager's inspector from the FeaturesPlatforms demo scene

In most cases you’ll want a LevelManager in each of your levels. It needs to be on its own gameobject. From its inspector you can (and should) set what prefab to use as the player. To do so, unfold the PlayerPrefabs dropdown if it’s folded, and just drag a prefab from your project view into the Element0 field. If you’re in a multiplayer level, set the size of the PlayerPrefabs array to more than 1 and repeat the process. For more information about the “Auto Attribute Player ID” checkbox, check out the Input page.

You can also define a debug spawn (drag one from the scene view, or click on the little dot at the right of the field and select one from the popup window that will open). This debug spawn will be where your player will spawn while in editor mode (useful to tweak the end of a level for example).

The level manager’s inspector is also where you’ll be able to set the level bounds. They’re the limits of your level, your camera won’t go beyond that, and in most cases neither will your character. To set that up, just set the center’s position, and change the extends of the bounding box. You should see the bounding box in yellow in the scene view.

The Level Manager will also allow you to setup your level as a One Way Level. One Way Levels are levels where you can’t go back where you come from (think early Mario levels for example). To do so, from the LevelManager’s inspector, just select any One Way Level Mode other than “none”. You can chose between Left, Right, Top or Bottom. These are the directions the player won’t be able to go back to. What this will do is add, when the level starts, an invisible collider that will follow your player and prevent it to go back. In addition to that, the camera will also be constrained by this collider, as if it was the Level Bounds. From the inspector you can also set the distance that collider should be from the player, its size (make it bigger than your character), and whether or not it should kill the player when it collides with it.

Input Manager

The Input Manager handles the inputs and sends commands to the player. It’s described in more details on the Input page.

:warning: This script’s Execution Order MUST be -100, to make sure it always runs first on each Update(), and avoid weird side effects, especially at low framerates. If you’ve imported the engine into a blank project that should already be the case. You can define a script’s execution order by clicking on the script’s file and then clicking on the Execution Order button at the bottom right of the script’s inspector. See this page for more details.

Sound Manager

As its name implies, the Sound Manager is in charge of playing sounds in the Corgi Engine. Of course you can play them directly in your code using Unity’s native APIs, but using the Sound Manager will ensure that it’s played using the same volume settings as other sounds, that they won’t be played if sound has been disabled, etc. It’s usually found on the same prefab as the GameManager script. From its inspector (or from your code), you’ll be able to set the music and sound effects (Sfx) volume, and whether or not each is active. You can have a look at the API documentation for details, but mostly you’ll be using the following methods :

To play a background music (will replace any previously playing background music) :

PlayBackgroundMusic(AudioSource Music);

To play a sound effect - you can specify its position in space, and whether or not it should loop (make sure you stop it in this case) :

PlaySound(AudioClip sfx, Vector3 location, bool loop=false);

Loading Scene Manager

With Unity, usually when you want to go to another scene (in a menu, or to go from one level to the next for example), you’d use the SceneManager API, and probably the SceneManager.LoadScene() method. The engine comes with its own scene change API, that you’re completely free not to use if you don’t like it. Personnally I think that this method doesn’t provide visual feedback to the player, and scene loading on mobile for example can be a few seconds long, so just having a black screen there isn’t really good looking.

The LoadingScene in scene view
The LoadingScene in scene view

If you want to provide a better experience to your player, you can use the Loading Scene Manager :

  • it can be called from anywhere, you don’t have to have a LoadingSceneManager in your scene
  • it handles loading (as the name implies), showing an animation and a progress bar
  • it’s completely customizable, just edit the Common/LoadingScene scene’s contents. You can easily add your own logo, change the look of the progress bar, what animation is playing, etc.
  • it’s pretty simple to use

To use the LoadingSceneManager API, when you want to change level, just call the LoadingSceneManager.LoadScene (string sceneToLoad) method. The string parameter you pass must of course match the name of the scene you’re trying to load. So if you were to load the minimal demo multiplayer level for example, you’d use :

LoadingSceneManager.LoadScene ("Minimal4Players");

And the engine will take care of the rest :rocket:

Progress manager

While all the other managers mentioned on this page are generic, there is no generic Progress Manager. You’ll find an example of it in the RetroAdventure folder. The progress manager is responsible for saving and loading progress across levels. The reason why there’s no generic one is that it wouldn’t make much sense, as all games will by nature have different needs when it comes to saving stuff.

You can either copy this one into your own progress manager, or extend it if your needs are close enough. The Retro Adventure Progress Manager uses serializable classes to save data to file and read it later. It waits for LevelComplete events, and when it gets one, it saves what level’s been saved, which ones are unlocked, how many lives are left to the player, and how many stars (and which ones) were collected. When combined with the inventory and achievements systems (which handle their own save/load mechanisms), you’ve got a complete solution to save all progress in your game.

Extending a manager

If for some reason you want to modify a manager’s behaviour, the best way to do so is to extend it. That way, you won’t lose your changes if you update the asset. Extending a manager is fairly easy. All you have to do is create a new class, that inherits from the manager whose behaviour you want to change, like so :

using UnityEngine;
using System.Collections;
using MoreMountains.Tools;
using System.Collections.Generic;


namespace MoreMountains.CorgiEngine
{
	public class NewGameManager : GameManager
	{
		protected override void Start()
	    {
			base.Start();
			MMDebug.DebugLogTime("new game manager");
	    }

		public override void Pause()
		{
			base.Pause();
			MMDebug.DebugLogTime("new game manager pause");
		}

		public override void AddPoints(int pointsToAdd)
		{
			base.AddPoints(pointsToAdd);
			MMDebug.DebugLogTime("new game manager add points");
		}
	}
}

In this example, a new GameManager is created, and a few of its methods are overridden. They don’t do much, they just do what the base class does, and then output a debug message. Of course, you could have them do much more. All you have to do then is to place that new manager in your scene on an object, and remove the base one.