0
\$\begingroup\$

I have three scenes: SceneTitle, SceneMenu, SceneLoad.

(The difference between the title scene and the menu scene is that the title scene is what you see when you first turn on the game, and the menu scene is what you can access during the game. During the game, meaning, after you've hit "play!" in the title scene.)

I provide the ability to save progress and consequently load a particular game. An issue that I've run into is being able to easily keep track of the previous scene. For example, if you enter the load scene and then decide to change your mind, the game needs to go back to where you were before; this isn't something that can be hardcoded.

Now, an easy solution off the top of my head is to simply maintain a scene stack, which basically keeps track of history for me. A simple transaction would be as follows

  1. I'm currently in the menu scene, so the top of the stack is SceneMenu
  2. I go to the load scene, so the game pushes SceneLoad onto the stack.
  3. When I return from the load scene, the game pops SceneLoad off the stack and initializes the scene that's currently at the top, which is SceneMenu

I'm coding in Java, so I can't simply pass around Classes as if they were objects, so I've decided implemented as enum for eac scene and put that on the stack and then have my scene managing class go through a list of if conditions to return the appropriate instance of the class.

How can I implement my scene stack without having to do too much work maintaining it?

\$\endgroup\$
1
\$\begingroup\$

Your idea seems fine. A short stack of screens would let you transition into and back out of a menu without any problem. But the way you've described your problem is really odd. You plan to create a new screen instance while popping off your stack? That would defeat the purpose have having a stack of screen instances. You only need new instances when adding to the stack, not when moving back down.

While moving into new screen, i.e. pushing onto the stack, you do need to create new instances of screens. But since that process will happen only as a result of interaction with any given screen, you can simply define code paths that instantiate the correct screen type. For example, selecting load from the menu executes a specific function. That function's purpose is solely to initialize a loadscreen instance and push it onto the stack. This screen instance's type is defined in the code, so no reflection or enumeration/switch required.

When you do that, the menu screen is put on hold (however that works for your project), but it isn't destroyed. It remains on the stack, and can be reactivated. So your dilemma of needing to pass around class definitions seems moot. When moving backward through screens, pop off the current screen (probably destroy it), and activate the screen below it. Perhaps you need to define some reset logic for reactivation, but that is better than creating a new instance in the manner you described.

| improve this answer | |
\$\endgroup\$
  • \$\begingroup\$ The way I thought of the problem was that when you move from one scene to another, the previous scene may be disposed of, so when you want to come back to it, you'd have to re-create it again. But now that you mention it if I simply paused it and then resumed it, that may be easier (and better, since assets don't need to be disposed and then reloaded later) \$\endgroup\$ – MxLDevs Apr 6 '14 at 23:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.