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

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.

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.

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.


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.

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" ?>
<SubTexture name="sprite1" x="0" y="100" width="50" height="50"></SubTexture>
<SubTexture name="sprite2" x="100" y="200" width="100" height=100></SubTexture>


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.

Play Button in the base system. Position: 640,480
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 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

Collow: First Trial

Collow was published on Google Play before Fluff Eaters. A very simple game about following colors, putting into practice your memory and attention. Each color has its own particular sound and every color is different from each other.

The main purpose of publishing such a simple game before the one that took a long time and effort to be made?, testing the whole process of publishing an Android game on the market and trying to fail less when Fluff Eaters was released.

Main Menu

Of course this was not the only reason to create Collow, I truly believe that the idea has great potential and regardless it was successful or not, I wanted to make it.

The idea of a very simple game with simple mechanics came to my mind when I was working on Fluff Eaters, then I thought it could be implemented in a very short time. The core mechanics of the game, graphics and the most basic mode were created and released in less than a week.

Basic Gameplay Screen

The feedback from the whole process of this game was incredibly useful to improve things on Fluff Eater, how to design a good marketing strategy (at least one that actually helped), what game sites should I write in the first place, what to include on the emails to the press, how much time does it take to appear on the market, etc.

Although searching on the Internet can be very helpful to find answers to these questions, taking into consideration it’s the first game I release, wanted to experience it by myself and it helped a lot.

Initial Screen

In addition, a version on Newgrounds was published to get feedback of as many people as possible and the results were very good (in my opinion), you can play it here.

During that week, a lot of ideas came to my mind, to improve the visuals of the game, new interesting modes, features, etc but the game was released without them, precisely to do it as quick and simple as possible to get opinions and ideas about the core mechanics of the game and test its most basic form.

Few months later, the visuals design was improved, adding more value to the game, better look and feel, a lot of new modes, multiplayer capabilities, integration with the mobile (Android and iOS) services, and this is the result of those changes:

Main Menu

A set of new modes that include different ways of playing based on the same initial mechanics, some new features added to the basic way of playing and new challenges that enrich the game somehow.

new modes
Board Type and Difficulty Screen

Three different boards with more colors to make it more difficult and three levels of speed were added too. The new update will include a multiplayer mode and better integration with Google Play and Game Center (hopefully the iOS version will come soon as well, lot of work to do).

New Board and Graphic Design

Everything is a work in progress, it has not been all implemented yet but (hopefully) soon will be all ready to test, starting with the visual improvements, mobile markets integration and some new modes.

Since it is not a final design, probably a lot of things will change until it’s actually updated.

As I mentioned in the previous post, I wanted to talk a little bit about Collow before starting to write about OpenFL. When I first planned this, I wanted to give an introduction to the platform but I think it’s maybe not necessary and I’m going to skip all the basics and focus on specific things.

I will start with something I tweeted few days ago because I consider it’s difficult to get it working right without the proper documentation (I’m still learning about it), so next post will be about Creating an Extension with OpenFL.

Let me know if you want me to post about something in particular or have any question.

In case you haven’t tried Collow yet or want to wait for the new update, get it here.

Collow: First Trial

Fluff Eaters: The Journey

As I mentioned in the previous post, I would like to talk about the creation of Fluff Eaters and Collow, my two first released games. I’m going to start with Fluff Eaters this time and, in the next post, something very short about Collow and then will be focused on OpenFL.

Before these two games, I worked in a couple of projects: Kamicats, Lost in Spice that will be added to the section of games soon. These were projects made for Dream Build Play, a contest sponsored by Microsoft to create games in XNA. Illustrations and part of the game design was made by Gabriel Balda. These projects were submitted to Dream Build Play, did not win and were not finished but I learned a lot from them.

KamiCats: DBP 2011
Lost in Spice: for DBP 2010

In addition, I worked on more projects that were not finished, one for a JavaFX contest and a couple of game jams too.

Hourglass: JavaFX Contest 2008
Pandamonium: Game Jam 2011
Caramelo: Ludum Dare 2011

All of them will be added to the games section later, if you have questions about the development of any, please let me know. All of them, except Caramelo, were drawn and animated by Gabriel.

The idea

After working on unfinished projects, in the end of 2011 I had an idea about making a new game, something I wanted to create and complete, promote and sell. Of course the market for mobile games was growing and everybody was making games for it so I decided to think about an interesting idea and give it a try.

Playing some games at that time, I thought that many of them were not intended to the platform they were running on, a lot of those games were just ports made different patforms to mobile, adding controllers to mimic gamepads and somehow (as a player) it didn’t feel “right”, something was missing, so I said: well, let’s think about something I like, that is designed for touchscreen devices.

I searched about traditional games in my country, things that were not tried before, things from my childhood and the idea of Jacks came to my mind. After thinking a lot about a possible gameplay for this, the core mechanics, etc, I started to search on the markets, to see if somebody did something similar before and, surprisingly, I found nothing.



The beginning of the next year I started working on prototypes for Fluff Eaters, the earliest version of the game looked like this:

[iframe src=”” width=”320″ height=”240″ frameborder=”0″ allowfullscreen]

I tested a lot of things with it, controllers, feedback, some simple levels, etc.

While I was working on this early prototype, I thought about the narrative and story behind the game as well. Since it’s a casual game, I wanted something simple, made different sketches, tested a lot of things and ended up with this:

Paws City
Early sketch of Paws City
Sand Land
Early sketch of Sand Land

Looks like ugly art but it was very helpful when I discussed about the art with the illustrators.

Pokki 2012 / HTML5

While I was working on these prototypes, a contest to launch a new platform that was based on HTML5 was promoted and with it, my decision to put more efforts on the idea. I decided to participate in this contest for two reasons: one, an “excuse” to work seriously on the game and two, to learn HTML5.

I contacted Tamara Hadeed (Miss Uh!) and Alejandro González (X2terra) to work on the graphics of the game (as freelancer illustrators). In addition, Stefano Merino (@stefmerino) accepted to work on the project as well, and composed original soundtracks for the gameplay, main theme and an additional theme (which will be used in the new mode).

Since the beginning of the project, Gabriel Balda contributed in a lot of aspects of the game, from graphic design decisions (although Tamara and Alejandro made the illustrations and animations, small things had to be fixed as well and of course changes through time, Gabriel helped a lot here), to the website of the game (which was completely designed and coded by him).

Pokki 2012

[iframe src=”” width=”320″ height=”240″ frameborder=”0″ allowfullscreen]

Dream Build Play 2012 / XNA

The game did not win the Pokki contest but was very useful to have a solid base on what the gameplay and all its features became later.

In the middle of the same year, Dream Build Play was launched one more time and I thought: well, if the game was really intended to mobiles in the first place, why not creating a Windows Phone Version and let’s try to submit something fot the contest this year.

In fact I made a new version of the game (crazy, I know) but as every other thing that could be called a mistake, for me was… a different way of learning and definetely I learned a lot of things from it.

The reason to not keep working on this version of the game? well, Microsoft decided to change the main language of its new Windows Phone at that time to C++ and, since the game was already written in C#, instead of looking for any way to port it easily to the new platform, I decided to put aside that version and started looking for a good framework to work on Android and iOS, which is the thing that I probaly should have done from the beginning.

It was true learning, I had the opportunity to playtest more and more, having the chance to see my mistakes in design and to think about the future of the game.

[iframe src=”” width=”320″ height=”240″ frameborder=”0″ allowfullscreen]


The game kept evolving and with it, more opportunities to show it to people from the industry. In spite of the early version of the game, I decided to send it to IndieCade and had the opportunity to get feedback from people that know a lot about games and got a chance to be part of the festival. This was the beginning of many awesome experiences, from sharing thoughts to other fellow developers, to making important contacts on the industry, including publishers, other developers and media.

In addition, being part of the festival, attending to talks, playing other people’s games, are experiences that definetely help you grow in this field. I recommend it 100% to anybody who is making games, it’s a great experience.

Using feedback from people of the IndieCade, the jurors and other developers, the game changed from what you saw in the previous iteration to the next one, new types of platforms, new elements, puzzles created to give another level of challenge to the game, etc. All these things really enriched the game in many different ways.


[iframe src=”″ width=”320″ height=”240″ frameborder=”0″ allowfullscreen]

Final Version

The “final” version of the game, as I already mentioned, was made in OpenFL which is a framework that allows you to create games in one language (Haxe) and export it to a variety of platforms, including the ones I was interested in for Fluff Eaters (Android and iOS).

I don’t want to talk about details here since I’m going to explain about the process of development in future posts and will be mainly focused on OpenFL. If you have any particular question regarding this topic, feel free to do it on the comments.

The framework is very good (although sometimes is a headache), its performance (which was one of the things that worried me the most) is good, if you know how things work and what to do to get the best of it, you can get good results.

Paws City
Paws City


Tokyo Game Show 2013 / GamExpo 2013

This is, of course, one of the most interesting things that have happened with the game since its creation, the Tokyo Game Show and GamExpo are two events where the game was presented to the public. A lot of people from different backgrounds, countries, ages, played the game and I had the possibility to see how they reacted to it, emotions, comments, feedback, something that is incredibly good to improve your work.

I wanted to mention this to point out the importance of promoting your game, no matter where, no matter how, it’s not important if the event is not the biggest one in the world, you have to get noticed somehow, see people’s reactions while they play, get them interested about what you are doing and the experience of getting contact with your players.

Besides players, you have a chance to see what others are making, play with their games, talk to them about the development and their experiences, talk about yours, meet publishers, media, people from the industry, etc.

If you have the opportunity, do not hesitate, do it, you will not regret it.

Tokyo Game Show 2013


The game was released in July, this year, you can get it from Google Play, the iOS version is still in development and new features will be added to both version of the game.

[iframe src=”” width=”320″ height=”240″ frameborder=”0″ allowfullscreen]

I was not planning to make such a long post but wanted to give you a good introduction to what the story behind the game was.

There are a lot of details that are not covered here, of course, if you have any particular interest on something related to any of the tools used or want me to talk about something specific in future posts, let me know.

Next post will cover very briefly the making of Collow and its future and the first post about OpenFL: basics, probably will be talking about sprites, sounds, etc, if there is anything you want to know, let me know.

Fluff Eaters: The Journey


Hello everybody!

This is the first post of (hopefully) a lot and I just want to give a simple brief about what this is about.

I finally created something oficially for Fiery Squirrel to showcase games I made or worked on and added a blog to start talking about my short experience on the game development field. I believe that this is a good way to learn and help others learn too.

The website will be constantly evolving, hopefully for better, I’m going to add more information, more games, and talk about what I’m doing and I did with Fluff Eaters and Collow. I will also talk a little bit about upcoming projects.

I don’t want to make promises here (about when I’m going to post), since the last time I did, I ended up posting nothing so what I’m going to do is try to save some time to write about specific things of the development of these two games and focus on the most difficult stuff (using OpenFL, designing the games, etc).

The site and the blog will be written in English because I think it’s a good way to reach a wider audience, however, it’s very clear that I’m not native so if there is anything that you don’t understand or i made any mistake, please let me know about it and I will happily fix it.

Feel free to write comments, start discussions or whatever you want.

Next post will be focused on the story behind Fluff Eaters and Collow, I will not go on any details of implementation or development, only how they were born, why, who were involved in those projects and maybe how will they keep growing with time.

The topics of development will cover OpenFL and Haxe, I will not make any tutorial since I don’t think I have enough knowdledge to do that but I do have a long list of things I struggled with.

I want to share some things related to promotion and maybe events as well, probably will be short but there some few things I consider are relevant in this area.

Anyway, I’m glad that finally was able to keep this running and maybe that was the most difficult part. If there is anything you want to know in particular, feel free to ask.