Code Base System: Screen Manager

I’ve been a busy recently working on Collow and some other stuff but I wanted to post about this since long time ago. After Fluff Eaters was released on iOS, I took a break and focused on re-thinking the core structure for the code to make it easier to use and as flexible as possible to save headaches in the future and avoid extra work.

What I’m going to explain now is the general idea of what I’m currently doing, I’ll add more documentation and improve the code as much as possible so in case there is someone who wants to use it and have any question about details, feel free to ask.

Basically so far the code is divided in many small systems of general purpose, all the code I create can be accessed in github , as you can see, I haven’t updated the readme file or licence stuff but, eventually, I will. Systems that are created so far and are working now:

• Screen Manager
• Graphic Manager
• UI
• Sound Manager
• Language Manager
• Helper (which is not a system, is a set of useful functions of general purpose)
• Animation
• Basic Structure

All these systems work independently. I decided to do this in case there is someone who wants to write their own systems and wants to use any of my systems, they could be included as part of their code easily and should not affect the rest of their code.

Let’s begin by talking about Screen Manager which is one of the core systems.

Screen Manager

As its name says, it’s in charge of managing screens, it handles transition between screens, can load or remove screens and allows the developer to separate the code for each section of the game in different parts. If you have experience working with XNA and remember how the Screen Manager system was built, this is very similar.

The set of classes that are part of this system are listed as follows:

Core classes:

This constitutes the core of the system, base classes.

• IGameScreen.hx

This is an interface that describes what should be implemented in any class that inherits it, if you want to implement your own GameScreen class, you can do it. This class has an Update function in which all the logic for the current screen is calculated; a HandleEvent function that handles all the GameEvent events; Draw function which is in charge of rendering sprites and animations finally, a Destroy function that handles all the work that has to be done before the screen is destroyed.

IGameScreen is the blueprint for GameScreen classes, the concrete class GameScreen has much more things

• GameScreen.hx

GameScreen is the core class of the system, this is what ScreenManager handles. There is always one screen active while the game is running. These screens can be a popup screen or a non-popup screen. Popup screens are loaded on top of the current screen (which could be any of these types), non-popup screens are loaded with no other screen below them.

Examples of non-popup screens are: a gameplay screen, main menu screen, etc. Examples of popup screens: pause menu, game over screen, etc.

This class handles all the logic and graphics for the work that it has to do, also it includes an event handler system that can be used independently of other screens.

To handle logic there is an Update function that is running all the time, which also has the current game time as a parameter. To handle graphics, a Tile Layer System that handles all the sprites efficiently, many layers are created and the z position on the screen can be decided depending on where each sprite is located.

Inputs such as Mouse or Keyboard are also handled in each GameScreen. In order to use them, they have to be added as events on the main screen of the game (I’ll talk about this in a future post).

This class basically exists to separate the game in many different screens and work in an organized way. It’s easy to focus only on the tasks that one screen has to handle instead of doing everything in one place.

• ScreenManager.hx

ScreenManager is the GameScreen handler. This class is in charge of managing all the screens on the game, including performing transitions between screens, cleaning graphics, freeing memory, etc.

This is modeled as a singleton, there is only one ScreenManager in the whole game so there is no need to create more than one instances of it.

Internal game events are handled here, loading screens, removing screens, etc. All this work is performed inside this class. In order to use it, access it as a static class or you can call events from wherever you want in the game.

Events

Events are used in the screen manager system and can be inherited and used in any part of your gameplay or subsystem. Feel free to include them as part of your own core.

• GameEvent.hx

Internal game events are represented usig this class. It’s a very simple class that includes what kind of event it is and any parameters what want to be passed from the caller to handlers.

• GameScreenEvent.hx

All the events related to the game screen system, loading, exiting, removing, etc.

• GameEvents.hx

This is a static class that contains names of the main events in the screen manager. Use these names to fire events from wherever you want.

Transitions

Transitions between screens, load and exit screens with animations.

• ITransition.hx

An interface that shows which functions should be implemented in order to create a Transition class. You can implement your own Transition class if you want.

• Transition.hx

This models a transition between screens. So far there is only implemented a fade effect, from now on I want to include many more things, graphically interesting that add more value to the interaction between screens.

• FadeTransition.hx

As I mention before, the fade effect is represented using this class. More effects will be added as soon as I have some time.

There are some other classes I pushed to the repository and a set of classed from “Console” but it will be moved to a DebugSystem in the near future so you can ignore them.

This is a brief explanation of what the Screen Manager system does and what systems are implemented so far. The plan is to keep improving current systems and adding new ones such as Debbuging, Effects, etc.

I’ll keep explaining the rest of the systems, not so deep, enough for someone curious to use and test them.

Feel free to ask questions, add some comments or suggestions.

Next post will be about Collow, progress and new features, stay tuned!

---