Inkscape Parser for OpenFL (Haxe)

Last week I mentioned the small Inkscape parser I created for OpenFL and I said it was very helpful, not only to have it but also understanding how the Inkscape’s XML file is structured. This week I decided to briefly explain the code for that because it might be useful for someone working with OpenFL.

Editor XML (Shift + Ctrl + X)

This is the first cool thing about Inkscape I learned before writing the parser. Maybe you already know this but you can see an XML editor for the document you are seeing inside Inkscape if you press shift + ctrl + x. It basically shows a bunch of nodes that represent elements you have in your document.

In the XML you can find anything you add to the document, if we add a new element to the scene, it’s automatically added to the XML too and you can easily see it and its information when you select it in the document.

With these two things, we can easily write a very simple parser that maps positions from the XML document to our game. The following structure is the most basic one to get the elements inside layers in the document.

The Code

actionscript3

  1. //This code is written in Haxe but Wordpress does not highlight haxe so I just chose ActionScript3 :)
  2.  
  3. //This is what we use to load the Inkscape file (as it is)
  4.  
  5. var xml:Xml;
  6.  
  7. //You can use any variable you want but for this article I chose position, radius and id
  8.  
  9. var x, y, radius : Float;
  10. var id : String;
  11.  
  12. xml = LoadXML(YOUR_FILE_PATH + "name_of_your_file.svg");
  13.  
  14. try
  15. {
  16.    //Iterate over all the nodes of the file
  17.    for (e in xml.iterator())
  18.    {
  19.       if (e.nodeType == Xml.Element)
  20.       {
  21.          if (e.nodeType == Xml.Element)
  22.          {
  23.             //This is the layer's label (you can see the image above, it's called "Capa 1"
  24.             switch(e.get("inkscape:label"))
  25.             {
  26.                case "your_layer_name":
  27.                   id = e1.get("id");
  28.                   //The size of the Inkscape file should be the same in GraphicSystem here
  29.                   x = Std.parseFloat(e1.get("x"));
  30.                   y = Std.parseFloat(e1.get("y"));
  31.                   radius = Std.parseFloat(e1.get("r"));
  32.                   //This is only a sample, you can read whatever you want here
  33.             }
  34.          }
  35.       }
  36.    }
  37. }
  38. catch (e : String)
  39. {
  40.    trace(e); //Catch the exception beautifully
  41. }
  42.  
  43. //This function belongs to a bigger library I created as a helper for easily doing annoying stuff like this
  44. public static function LoadXML(path : String) : Xml
  45. {
  46.    var xml : Xml;
  47.    var str : String;
  48.    
  49.    str = Assets.getText(path);
  50.    xml = Xml.parse(str).firstElement();
  51.  
  52.    return xml;
  53. }

I believe the code is kind of self explanatory but I’ll comment a bit on it. Basically we load the XML file, put it in a variable and iterate over all of its nodes to see which one contains the data we need: layers. If you want to customize your parser and add whatever information you need from the document you can also do that. Once we find the layer we are looking for (it should be the same name in the XML file), we use the data, store it in variables and use it as we want.

There are some transformation involved, depending on what you want to do with the data you get from Inkscape but it totally depends on the purpose of your code, if you have any questions related to this, please let me know.

Custom Attributes

Something that I find very helpful from Inkscape, is the possibility to include custom attributes, which enables us to take the editor further and add specific information for our elements.

Let’s say you have a game object that has “speed”. You want to customize each game object in the editor for different speeds so your game object is different depending on its type or something like that.

In the image above you can see fields for each attribute in the element if you click on the element and then click on the attribute. If you write a new name in the field for name and assign a value to it, it will be automatically created after you click “Accept” (it’s “Aceptar” in Spanish in the image).

actionscript3

  1. switch(e.get("inkscape:label"))
  2. {
  3.    case "your_layer_name":
  4.       id = e1.get("id");
  5.       //The size of the Inkscape file should be the same in GraphicSystem here
  6.       x = Std.parseFloat(e1.get("x"));
  7.       y = Std.parseFloat(e1.get("y"));
  8.       radius = Std.parseFloat(e1.get("r"));
  9.      //New Attribute
  10.      speed = Std.parseFloat(e1.get("speed"));
  11. }

In the example above, you can see how we read the custom attribute using the same name we added in the XML editor.

I think that with these basic concepts you can easily write a whole map editor or if you prefer, a menu editor taking advantage of the Inkscape’s functionality. There are probably better or more general ways to do this but I wanted to discuss about the one I implemented.

Also, I want to clarify that an in-game editor would be much more helpful and comfortable to work with but either you need the time to make it or the money to buy it. This works for me and the simple games I’m creating, if you have advices or ideas, please let me know in the comments.

Inkscape Parser for OpenFL (Haxe)

Level Editor

 

I’ve been slowly working in a project for computer and console devices, a puzzle-action game based on a prototype I made for Ludum Dare back in 2013. The idea evolved quite a bit and I’m focused now on more puzzles and action, the idea actually changed a lot but the base is still the same.

 

Since last year I’ve been writing code for physics, gameplay, etc using OpenFL for this projects and after a while I decided to start working with Unity (I want to release the game for consoles as well and it seemed easier). The game involves big levels now and a lot of level creation, so I wanted to use a tool to create levels easy and simple, this really saves a lot of time when testing and changing features.

Inkscape

First I decided to use Inkscape as a level editor, the tool itself is very good and combined with its possibility of generating XML code from the elements you add to the document (graphically) it’s very handy. I wrote a small parser on Haxe for a small prototype I created last year, also used in the first version of this new project I’m currently working on.

It really worked very well when I was using OpenFL. After deciding to work with Unity, I also tried to do the same thing because I wanted to keep the levels separated from the game engine and also Inkscape itself runs faster and better when I’m focused on creating only levels. I wrote a parser in C# of the XML code that Inkscape generates and it worked well too.

Generally speaking, Inkscape is a really good tool for creating levels, it is lightweight and very flexible. Inkscape was also doing the basic functionality I needed from the editor but there was still work to do to really make it good enough for this project.

Unity and Custom editors

Since I’m still in the process of learning about Unity and all its features, I didn’t know you could customize the editor and include custom scripts to minimize the efforts when doing cumbersome or repetitive tasks.

This week while reviewing some code, I found out that you can actually create your own menus and customize a lot of things. So I decided to play a little bit with that and try to create a very small tile editor for this game.

After struggling a bit about understanding how to make everything work, I was able to put together the most basic functionality for the tile editor I wanted: adding tiles as fast as possible, having a grid that snapped tiles automatically to it, removing and moving tiles.

Having this functionality inside the editor while creating levels and the possibility of adding more stuff like rotation, layering, etc is really a great advantage if you want to save time and avoid doing repetitive tasks. I will keep improving what I have so far, keep posting about it and share it when it’s in a decent state for people to play with it.

Closing

Before writing this post I thought about detailed explaining how to write a parser for Inkscape and how to create a custom editor for Unity, however, I’m not really sure if it’s worth it. A lot of people have done this before and probably they explain it better than me.

If someone wants to know details about what I did, I’ll definitely explain everything step by step, meanwhile, you can check out the following links that helped me a lot understanding how to both processes work.

Once I clean up the code for the Unity editor I wrote and the Inkscape parser, I’ll upload them to my repository in Github.

Ah, in addition to the new project, Fiery Squirrel is also focused on this new mobile game: Kuon’s Saga, I’ll talk more about it soon!

Level Editor

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.

1280x720
Base reference in design. 1280×720 size used as a base for the game.

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.

1024x768
Graphic Manager system adapts the graphics automatically depending on the screen size. This screen is 1024×768, elements look very similar to how they look in the base design.

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.

spritesheet
Sample of a Spritesheet generated in the Sparrow format

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.

1280x720exp
Play Button in the base system. Position: 640,480
1024x768exp
Play button in the current screen, converted from the base screen to: 512,512

 

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.

 

Graphic Manager

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!

Code Base System: Screen Manager

Collow: Work in Progress

Hello,

This is a quick post to keep you informed about what is going on with the project at the moment.

Code

As you probably would guess, Fluff Eaters left a lot of horrible code with it once I finally launched it in both platforms, Android and iOS. After the release, with less pressure and more time to work, I decided to separate all the core modules of Fluff Eaters in different modules for Haxe/OpenFL. Basically this is, breaking the code, making it modular and with that, be able to share it with as many projects as I want without creating new code.

I’m planning to explain roughly what everything does and, of course, give a proper documentation to it in the near future.

So far I’m only uploading everything separated to github and will keep updating it while I make progress.

If you are interested, here is the github link.

Media

These things are time consuming and there is no one else to do them but they have to be done anyway.

I updated the Collor’s website to something very simple with more information and the new design. Of course this is very basic but probably in the future it will get better depending on how things go.

I still have to fix it for mobile platforms but you can check it out here.

In addition, I updated the press kit for Fiery Squirrel and both games. For Collow it will get more stuff when the new trailer with new modes and stuff are done, you can visit it here.

screenshot4

New Stuff

There are a lot of new things in the game, at least a lot of new things to try, I haven’t implemented them all yet but for sure I will and, in case you are interested in being part of those tests, I’ll announce them when they are ready.

CHM6cJdUwAAvcNN
Brainstorming

Along with the Collow’s brainstorming, a lot of new ideas came up as well, ideas for new games, simple and easy to implement. When I finish separating everything (the code) in modules and it’s stable, I’ll probably try to prototype some ideas and share them here.

Let me know if there is anything in particular you want to know.

 

Collow: Work in Progress