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


  1. //This code is written in Haxe but Wordpress does not highlight haxe so I just chose ActionScript3 :)
  3. //This is what we use to load the Inkscape file (as it is)
  5. var xml:Xml;
  7. //You can use any variable you want but for this article I chose position, radius and id
  9. var x, y, radius : Float;
  10. var id : String;
  12. xml = LoadXML(YOUR_FILE_PATH + "name_of_your_file.svg");
  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. }
  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;
  49.    str = Assets.getText(path);
  50.    xml = Xml.parse(str).firstElement();
  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).


  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.


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.


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

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 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 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


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


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.


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.


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.


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

See you later Bouncy!

Well, June is here and I finally have some time to make a new post.

Mainly I would like to share some final thoughts about Fluff Eaters, including downloads and sales in both platforms iOS and Android, the next project, prototype and future work.

Fluff Eaters

Keeping it simple and short, I will start with Fluff Eaters. We launched the iOS version a couple of weeks ago and we have some results now I would like to share. More from the experience than charts or numbers, I think it will be helpful.


Let’s start with Android to compare. The Android version came in July last year, after presenting on Tokyo Game Show and GamExpo, the game was in development for enough time and was time to be released.

The expectations were not so high, first game we actually release, many things to experience and understand. From the promotion point of view and the overall attention it got, considering Fiery Squirrel is a tiny team, the results were very nice, some of them in Venezuela, and the rest in game review sites around the world. Generally speaking it was a good result.

From the economic point of view, the numbers are very low. For the paid version of the game, there are around 50 downloads, for the free version (which is not available anymore) with ads,  around 500 downloads, the free version generated almost zero profits.

Of course Fluff Eaters was not initially designed to be free, the free version was available for some time to test, basically.


First of all, I understand clearly that if a game is not properly promoted (featured on the App Store, has a good review in a big site, whatever gives it exposure), the game will not sell, Fluff Eaters was not featured on the App Store (at least not yet ;)), didn’t have much attention from the press but a couple of small mentions in Pocket Gamer and TouchArcade made the difference to get some downloads on the release date. Maybe for people used to release a lot of games, that’s a normal thing but since this is the first experience of this type, was quite good for us.

There were a couple of surprises on iOS, first, the game was featured on many Chinese sites, which was completely unexpected. In addition, the game was pirated a lot of times, we know that because we have Apple’s stats and some inner stats we created for ourselves plus the game center which gives us how many people are playing.

All of this translates into more than 350 people playing in less than three weeks, from which around 48 of them were actually bought and given away (promotional codes). I think that considering the game was not actually featured in the App Store, the promotion was not that big, the results are good, at least I’m happy with many people playing.

Thoughts about the results and how could they help?

  • Results from Google Play are clearly different from the ones from the App Store. In less than three weeks downloads in the App Store (for the paid version) were three times the downloads for Google Play
  • The promotion on the Chinese side was a big surprise, if I knew about that before, of course the strategy would have been different
  • Feature is everything in the market? I would say yes, if you wanna have a “successful game” whatever that sells, needs a very good exposure
  • Even though being featured is what brings you “success”, choosing the right strategy is very important. For example, from those 350 downloads, pirated, paid, gifts, whatever, if the game was free, people would be able to download it legally and review it, which I think is important… yes, I didn’t know that you could not review games that you downloaded using promotional codes (makes a lot of sense but didn’t consider it)
  • I personally like games you paid once with no in-app purchases, no ads. Clearly making a game like this now is not so easy to sell, so… different strategies will be tested for the upcoming projects and will share results too


Upcoming Projects

Fluff Eaters is finally done (for a while at least :)), the next project should be Collow which has solid prototype of core mechanics here and you can test it. The plan is to expand it, test different ideas that are on paper yet and see how it goes. The strategy for this will be different, less develop, smaller scale projects and a business model different as well. Please stay tuned if you are interested on how it progresses.



There is a new idea about a very simple game, whose prototype will be probably done in one of the following weekends, once it’s done, it will be shared on twitter or something.

Feel free to ask questions.

See you later Bouncy!

How to Create an Extension for Lime/Haxelib

Update: People that work on OpenFL explained how to create an extension here it’s better if you read that instead.

Basically I wanted to write about what I did with Fluff Eaters and Collow here because sometimes it’s difficult to understand how things work, even if you google a lot, sometimes there is nothing or documentation is very scarse.

OpenFL is a great library, I think it’s what I wanted to use when I decided to create 2D games for mobile (and many other platforms) but if you don’t have experience working with it or with AS3/Flash (which I did not have), it’s difficult to understand sometimes.

So I want to start my posts about OpenFL/Haxe/Gamedev with something I accomplished recently: How to create an extension for Lime/Haxelib, specifically for using OpenFL but I guess you can use it with anything else if you want.

This particular topic is something you probably won’t need but if you want to make a library for your game, an extension, something that could be reusable for different projects, it’s important to understand how to do it.

First of all, open the console and go to the folder you want the extension to be in. Once you are there, type the following command:

haxelib create extension <name of your extension>

Note: Andy Li (@andy_li) noticed I made a mistake writing the command here and he kindly pointed it out, it should be:


lime create extension <name of your extension>

Where, <name of your extension> is the name you want to give to your new extension.

Once you do this, haxelib lime will automatically create a folder with the name you put there and it contains the whole structure to make your library work. It will create:

  • A file <name of your extension>.hx which you can use to link to native code or create whatever you want to create
  • A folder of dependencies called “dependencies” which contains native code for your extension, in my case, I created an extension that will be used on Android and probably iOS too (haven’t tried this yet) that will be located on that folder too
  • An “include.xml” file which will tell Haxe about your extension, where the dependencies are located their name.
  • Other folders and files I will not explain here

You can check an old NME post about how to create an extension in case you want to understand it better. I believe that the proper way (currently) to do it is to use the haxelib lime create extension command because it automatically creates all the proper templates for you and you won’t have to worry about that but you always can do it manually.

While you are working on your extension you probably will want to test it on a a different project or probably publish it somewhere. I’m not sure if this is the proper way to do what I’m going to explain but for me makes sense so I’m going to explain it and explain why, if you have a better way, please let me know.

I have one project called “my-game” and an extension I’m creating “my-extension”, in order to include my-extension in “my-game”, you will do it as you include any other extension, you go to your project “my-game”, search for “application.xml” and add the following line:

<haxelib name=”my-extension” />

Of course haxelib doesn’t know yet that your extension is there, so you have to link it somehow. To do that, if you are working locally, go to the console and type this:

haxelib dev <name of your extension> <path to your extension>

In the case for our example, it would be:

haxelib dev my-extension whatever-path-you-created-your-extension

If you want to test if the extesion was properly installed, type this:

haxelib list

And you should see your extension there, pointing to the path you added.

If you want your extension from a git repository (which is useful for sharing and keeping proper track of your code and good practice, etc, etc), do this:

haxelib git <name of your extension> <git repository url>

If everything went well, you can compile “my-game” and it should compile without errors. Now, all the methods you create for your extension will be available to use from your project.

The sample that haxelib lime creates automatically contains some code for adding native Android code (in Java), if you want to create an extension that uses Android, you can use that, maybe, if somebody is interested, I will explain how I made the extension for Google Play, which is not complete yet but finally it’s working as expected.

Finally if you need extra documentation on the haxelib commands:

haxelib help

To understand all this I searched a lot on the internet, I want you to take a look at the sources that helped me with this:

This guy here has a good approach on making libraries that use Google Play library as their base, I’m actually basing my own Google Play Game Services extension on his approach because I believe is good. However, it wasn’t easy to understand what he did without wasting a lot of time reading code and analysing it, once the extension is complete maybe I’ll talk about this.

Here another interesting repository that has different extesnions and their code, some of them are outdated and that’s one of the reasons I decided to create a new one.

Haxe->Haxelib website:

I did not decided to make a new Google Play Services extension because I like re-making things, before that I searched a lot to find a good extension, I did find those two I mentioned before but, one of them is outdated and the other one does not work properly with the admob’s extension I wanted to use.

I got many good things from this:

  1. A library that is working
  2. A library up to date
  3. Understanding about making new libraries
  4. The opportunity to create better and new libraries
  5. Create some documentation and share with others


So I think this is it, if there is anything that was not clear, you have a better way to do it or you have questions, feel free to ask me.

How to Create an Extension for Lime/Haxelib