Scene Management

SCENE MANAGEMENT

“The Scene System.” divide the game up into scenes, where a scene is (usually) defined by a change in the background image. This means that the main menu screen is a scene, the map screen is a scene, the normal gameplay is a scene, etc. Why divide them up this way? Because in our current platform, background images take a noticeable amount of time to load (at least enough to cause the cursor to flinch). The idea is that if you only load a new background between scenes when the entire screen is black, the user won’t notice any delay from loading.

This means that each scene should have a natural way to transition in and transition out, and the unloading/loading takes place after the transition out of one scene and before the transition in of the next. In Primate Panic, you see the end of a scene when the screen fades to black. This is when the next scene is being loaded, but on most computers it is fast enough that you don’t notice any load time.

There is also a class that manages the scenes, and tells the current scene to update its game logic and redraw everything each frame.

How Does It Work In Code?

In Java or Slag, you have a SceneManager class (which is a singleton for ease of use). This class contains a static reference to the only instance of Scene Manager, and a reference to the currently running scene. It needs this scene reference to update and redraw the current scene, as well as change it. Here is a quick Java example of the idea:

class SceneManager
{
private static SceneManager instance;
Scene currScene;

public static SceneManager getInstance()
{
if (instance == null) instance = SceneManager()
return instance
}

public void update() {currScene.update()}
public void redraw() {currScene.redraw()}

// A simplified way of loading and unloading scenes
// Notice that the method is static so that anyone can call it.
public static void changeScene(Scene newScene)
{
if (instance.currScene != null) instance.currScene.unload()
instance.newScene.load()
instance.currScene = newScene
}
}

The Scene class is abstract and has four abstract methods that each scene must implement. Overriding these abstract methods is what keeps your scene code clean and avoids those nasty switches. Scenes can of course have plenty of other methods that you override as well, but these are the essentials.

abstract class Scene
{
abstract void update(); // update logic for this scene
abstract void redraw(); // redraw everything on screen
abstract void load(); // load all of the data and graphics that this scene needs to function.
abstract void unload(); // unload everything that the garbage collector won’t unload, itself, including graphics
}

Internally, our Scene implementations also have a transitionIn() and a transitionOut() procedure. This is where the screen fades happen in Primate Panic.

Automating Scene transitions

In the CoherenceBridge inspector you will find all the options related to handling Scene transitions. First thing to know is that Client Connections must be enabled for this feature to work.

These are the options related to Scene transitions:

Main Bridge: This CoherenceBridge instance will be saved as DontDestroyOnLoad and its connection to the Replication Server will be kept alive between Scene changes. All other CoherenceBridge components that are instantiated from this point forward will update the target Scene of the Main Bridge, and destroy themselves afterwards.

Use Build Index as Scene Id: Every Scene needs a unique identifier over the network. This option will automate the creation of this ID by using the Scene Build Index (from the Build Settings window).

Scene Identifier: If the previous option is unchecked, then you will be able to manually set a Scene Identifier of your own (restricted to unsigned integers).

References:

https://rivermanmedia.com/object-oriented-game-programming-the-scene-system/
https://docs.coherence.io/manual/scenes

arcade