Graphic Manager

In a previous post, I introduced the structure I’m using to create games with OpenFL, also explained about the purpose of the Screen Manager and a brief explanation on how it works. This time I would like to explain the Graphic Manager, which is also a very important part of the small system I’m using.

The Graphic Manager is a unique and centralized system that handles all the operations related to the screen, including coordinates system conversion, bitmap loading, spritesheets loading, etc, they all work as helpers to make recurrent operations easier for the programmer when creating a game.

The repository for this system is located here in case you want to see the code. Please consider that it’s still being improved and needs more documentation.

Fixed width and height

Fixed width and fixed height are base parameters decided by the designer when creating the game. For example, let’s say I’m making a landscape game and the base reference size that I’m using in design is 1280×720, this is the size of the screen I am using to position all the elements, the base size and base positions of all elements.

Once we have the fixed width and height decided, we pass those two values as parameters to the Graphic Manager and the system adjusts all the elements to make them look as in the base design regardless the screen size.

Sprites and backgrounds paths

We also pass as parameters to the Graphic Manager the sprites and backgrounds paths, this way it’s easier and cleaner to deal with sprites in the whole game and screens from the Screen manager.

Spritesheets

In order to create 2D animations and make them work, we need spritesheets and a good system to use them. I’m not going to talk about the specific of animations in this post, only an easy way to load spritesheets.

The Graphic Manager system uses a TileLayer extension of OpenFL that can be downloaded here. This subsystem is used to render sprites efficiently on the screen and manage spritesheet elements in a  convenient way.

The TileLayer extension includes a Sparrow parser implementation, which needs the spritesheet itself and a data file that helps mapping and indexing all the sprites in the spritesheet.

This is an example of a data file that helps mapping sprites and data:

<?xml version="1.0" encoding="utf-8" ?>
<TextureAtlas>
<SubTexture name="sprite1" x="0" y="100" width="50" height="50"></SubTexture>
<SubTexture name="sprite2" x="100" y="200" width="100" height=100></SubTexture>
</TextureAtlas>

 

In the Graphic Manager system there are helpers to create, load and use these spritesheets very easily, the only thing that we need to do is to put spritesheets and data on the same folder with the same file name, with LoadTileLayer we can get all the necessary data to work.

If you are curious about what tool is used to create the spritesheets and data, it’s called Sprite Sheet Packer, you can adjust the data format as you wish, it was adapted to fit the Sparrow format in the Graphic Manager system.

Fix functions

As I mentioned in the beginning of the post, all the elements are adapted depending on the current size of the screen and the fixed size set when instantiating the Graphic Manager system. In order to make all the calculations work, there are a lot of different helpers to convert values to the current size of the screen depending on what we need.

For example, in the previous two images where the base size of the screen is 1280×720 and the current size of the screen is 1024×768, we can see in the following two images how the “Play” button position is converter from one coordinates system to another. To achieve this we use the helper functions that Graphic Manager contains.

 

The work that the Graphic Manager system does is not complicated at all but is really helpful to save time when coding. The class is a singleton that can be accesed from any part of your code (in any project if you import the extension) without being imported in every class, which saves a lot of headaches and time.

This is basically what I wanted to show today, a very simple way to handle common operations without too much trouble and code.

If you have questions, feel free to ask, I’ll probably talk about Animation in my next post.

 

---