Progress, Level Edition and Game Jam’s Feedback

This week I would like to talk about three different topics, the progress I’ve been making on the games I’m creating, the status of the Unity Level Editor and some thoughts on the past Ludum Dare 38 experience.


Fiery Squirrel is currently working on a couple of games. One of them is (tentatively) called Zin, which is the game that is benefiting from the new tile editor. There is also another game I mentioned in previous posts, Kuon’s Saga, developed in collaboration with Gabriel Uguet, illustrator and creator of Serpentarius, an online comic.


Zin is a action-puzzle game that narrates the story of a little creature unable to move by itself due to a magic curse. The creature needs to recover its powers and escape from its captors. This is a very simple game for computer and consoles that involves mastering different kinds of abilities and gameplay mechanics.

The game is still in very early stage of development, I’m currently focused on designing and testing the first level, including concept art, sounds, etc. The game is divided in four different chapters, each one with four levels.

In case you are curious, you can play a very early prototype made for Ludum Dare some time ago in Newgrounds. The game now includes many more things and it’s bigger but the essence is still the same.

For this week, the focus was to create and test levels with the new editor, which is really helping a lot with the new tiles and perspective of the art. I hope next will show some new screenshots and progress.

Kuon’s Saga

This is a game that has been in development for some time, despite its simplicity and its casual nature, we created different versions of the game and tested too many things on a very slow development pace.

The game is planned to be released for free at some point next month and will include one level with 24 waves for players to enjoy. Progressively, depending on players’ feedback and reactions, we will keep adding new content with new levels and challeneges. This will be available for Android and iOS.

This week has been basically working on completing all the final elements for the gameplay, including graphical stuff and level design. By next week we will have a very solid demo to show.

Level Edition

I have good news about the Unity Tile Editor. All the basic functionality is already working properly and we submitted it for approval to the Unity Asset Store. The editor will be free and available for people to download.

This first version is a beta that will be expanded in the upcoming weeks, there are a lot of things to improve, from the functionality side of the editor to the usability, we plan to add new stuff to help automatize cumbersome tasks and create levels faster and easier.

For all of you that are interested in the details on how was the editor created, I’ll be posting details about the code in future articles. If you have specific questions, please let me know.

The video shows all the current features that will be available for people when the asset is approved on the Asset Store.

Game Jam’s Feedback

As I mentioned in a previous post, I was part of the Ludum Dare 38 three weeks ago. After playing a lot of different games and receiving feedback from people on the game I made, I have some thoughts that might be useful for people making games out there.

First of all I want to thank people for their observations, getting feedback is really nice and one of the reasons I like participating in this event. Comments from people really help improving our work, they show us a perspective that we probably do not have or just different ideas that enrich our way of thinking.


When I talk about feedback, it’s not only players’ comments, ideas and bug reports. Feedback is also related to that concept of making your game react to the player’s input and be able to clearly show in the screen or  through speakers what is going on in your game.

I decided to talk a little about this because my most recurrent comment on other people’s games was exactly that: “it would improve a lot if it had more feedback”.

And this is something that I really think developers can easiy do. Feedback does not really require super high art making skills or 3D modeling years of experience, this is all about the feeling of the game, this is related to showing the status of the game in a very clear way.

In SORLD for example, although I know there is a lot to improve and much more feedback to add, the basic actions have clear feedback and they were implemented in very few time. Shooting, being hit, recovering, dying and making progress are some of the basic actions that this game includes and they were represented with particles, screen shake, sprite rotation, sound effects, etc.

Seriously, with few changes on the feedback side, adding particles, sound effects, changing the rotation a little, zooming in and out, in most of the cases make the game feel much better and meaninful and it’s not really a difficult thing to do.

Jan Willem Nijman from Vlambeer has more experience than me on this topic and he gave a nice talk about “Game Feel” which is related to what I mentioned here. Enjoy the talk if you haven’t already and hope this helps you make better games!

This was basically it for this week. A lot of things going on, I’m trying to keep people up to date about what we are doing here and get some comments on what would be interesting to talk about for future post.

Have a great weekend!

Progress, Level Edition and Game Jam’s Feedback

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

SORLD: Ludum Dare 38

This will be a short post about the result of a game I made for Ludum Dare 38 last weekend. I will basically cover why did I decide to participate and how did I come up with the idea.


Recently I’ve been very busy working on other projects that are planned to be released this year. However, after the theme was unvelied, I decided that if could find something that had a message I could transmit somehow (I want to make a full educational game in the future), I was going to participate.

In this case, I focused the brainstorming in two topics: what’s going on in Venezuela (my country) now  and global warming. I decided to go with the first topic because this is how I feel can contribute to what’s going on there, we can all contribute to a cause from different perspectives and my perspective is from the game development side.


The Jam lasts only two days and there was not a lot of time to decide what to do. As always I try to keep things as simple as possible and concentrate on a small idea.

important points for the game

  • Choose a message
  • Communicate the message clearly
  • Make something dynamic
  • Try as hard as possible make it fun
  • Polish as much as possible until the Jam is over


As message, I just wanted people to be aware of what’s going on in other countries, make people think about what’s happening in other parts of the world. I wanted people to understand that despite the fact that we have different cultures, live in different places and have different ways of thinking, we all belong to the same planet and should care about each other.

I said earlier that I wanted to focus on what is happening in Venezuela and it’s true, however I also think it’s important to take a look at other countries because people are suffering everywhere.


The message is communicated not only in an explicit way in the end of the game but also the whole mechanics are based on the idea of caring about others, helping and cooperating.

The rules of the game are:

  • Beat the aliens: To beat the aliens, members have to combine the power of their colors to attack
  • Stay alive: You need at least one house in your territory to respawn
  • You can attack any alien
  • You can give one of your houses away
  • You can repair your or someone else’s house

The game is made in a way that these rules are not explicitly taught. From the game you know you can move, grab and place houses, you can shoot and you can repair houses, but I don’t tell the player “to beat the aliens you need to cooperate”. The idea was that the player understood the rules by looking at the NPC or just using common sense.

The NPCs have different behaviors:

  • Attack an alien in my territory
  • If someone helps me, I’ll help too
  • Stay alive
  • Give the player a house if he is out of them

Since I didn’t have enough time to make things smoother, I included a condition to randomly decide to help someone sometimes, so the player could understand easier what to do.


The game is really simple. Since the theme of the jam was a small world, I just decided to make everything in a very small world created from four different parts. To add a fast pace, the aliens attack non-stop in a random way. In addition, all the NPCs work very hard to attack the aliens and try to stay alive too.

The focus here was trying to stay concentrated on the main message and make something enjoyable.


After all the basic elements were complete, I just focus on trying to add things that improved the experience of players.

I think that when time is very limited like in a game jam, one should focus first on adding important feedback after finishing the basic mechanichs of the game. Shooting, receiving damage, reparing a house and subtle details to explain how to play were the core of this part.

Also the planet reacts to what is happening in the game, if it’s attacked, everything shakes and when something good happens (like defeating an alien), it winks.

These things are very small but they improve the experience of the game as a whole. I really wanted to put more efforts here but… not enough time.

Wrapping up

This is it, I wanted to make a small post and I feel it’s very long already, so to wrap up, this jam for me was different and interesting for the following reasons:

  • First time I base everything on communicating a message
  • First experience using Unity for a game jam
  • I tried to make simple but pretty graphics with a different palette of what I use to
  • Programming the NPC was a challenge but really fun

So if you have any questions, let me know.

You can visit the Ludum Dare 38 entry here and play the game online or download it in your computer.

By the way, I’ll still think about the idea for the global warming game, I think it’s an important issue.


SORLD: Ludum Dare 38

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

7 Tips to Improve Your Experience at Ludum Dare

Since Ludum Dare is going to happen this weekend, I decided to put together few ideas of things I’ve learnt participating in LD and some other game jams. I believe this could be helpful, specially for  people that are participating for the first time.

1. Set a Goal

I think it’s good to set a goal before you start your jam, regardless what you want to do, it helps you stay on track all the time and in the end will be easier to achieve that goal if it’s very clear for you.

By setting a goal I mean what you want to accomplish with the jam and is not necessarily making the game. For example, you could decide to learn a new tool or improve the art of your previous game.

In the global game jam of 2012, learning HTML5 was one of my particular goals of the jam. We managed to create a very simple game: Serpens Ruby. Since we didn’t know how to use HTML5 that well, we struggled a lot but the experience we got those two days helped a lot to create Fluff Eaters in HTML5 later the same year, which turned into a commercial project in the end.

Another example, my last Ludum Dare in 2014, I wanted to improve the art of my games with KIWI, the overall game is not that cool but I managed to accomplish what I wanted, compared to the previous jam, the art was much better.

Watercolor: Game made for Ludum Dare in December 2013
Kiwi: Game made for Ludum Dare in December 2014


2. Choose the right tool

If the goal of your game is not learning a new tool then choose the best tool you can use. A lot of people use big engines like Unity, others prefer work without engines, it really doesn’t matter what you use, if the tool you use suits you well, that’s enough. Focus on whatever language or tool that helps you turn your awesome idea into a playable game, something that fits well the idea you want to communicate.

For my first LD I used one of the few tools I knew how to use at that time: XNA, which now I think is not the best tool to work with for a game jam but at that time it helped me create a fully playable game.

Since my second submission to the jam, I’ve been using OpenFL which is the one I use for commercial projects as well.

Caramelo: Simple runner made with XNA for the Ludum Dare in August 2011

3. Think about your schedule

Two days is a very short time to create something that is good but it’s possible. Before starting, think about general steps in the process of creating a game, what you have to do in order to start with an idea and end with a fully playable prototype and set time limits for each task. I’ll give you an example of what I usually do:

First eight hours:
  • Brainstorming – around 3 hours, maybe more –
  • Proof of concept – 4 hours –
  • Test – 1hour –
Next fourteen hours:
  • Programming (focused on the core) – 7.5 hours –
  • Art (focused on the concept) – 5.5 hours –
  • Test – 1 hour –
Last fourteen hours:
  • Programming (use feedback to improve, juice) – 7 hours –
  • Art (use feedback to improve, add details) – 4 hours –
  • Sound – 3 hours –

Depending on how you progress following the schedule (which is only a guideline), you’ll be able to evaluate whether you have to make changes to it or not, you’ll iterate depending on how everything goes.

4. From the core to the edge

Identify the core features of your project, what is the most important part of it? usually for most games mechanics are the core. Once you decide what the core of your game is, give priority to the rest of tasks you have to complete.

Focus on the core until it’s working as you expected, after that use the priority list to keep working on each task until you complete all of them or until time is up.

The advantage of working in this way is that if in the end you cannot finish what you expected, you at least will have the most important part of your idea done to show to other people.

The way I usually decide the priority list is described as follows:

  • Player controllers
  • Goal (winning condition if there is any)
  • Challenge (losing condition)
  • Enemy behaviours
  • Level design
  • Items
  • Extra (effects, better graphics, better sounds, etc)

Of course depending on the game, some of the elements in the previous list won’t be necessary or will change, just identify how this strategy works for you and apply it.

Gameplay screen
ZIN: Game made for Ludum Dare in April 2013

5. create for the Web

If you can choose a tool that has a capability to export to web (preferably HTML5), then use that one. The main reason for this is that you want people to play your game, after the two days of hard work, the game you make will be played and rated; the more comments, feedback, rating you get, the better. Not everybody has Windows, not everybody wants to click 3 times to download and play your game, the sooner they get to it, the happier they will be.

6. Juice

After finishing the core idea of your game, when you have a playable prototype that is strong enough to communicate what you wanted to make, you can focus on adding – juice -, which I really believe will make a difference and will make your creation stand out from the rest.

Adding little details that make the game feel better is something that any programmer can do, feedback is a very important part of what makes games feel – right – and you will appreciate it.

If you haven’t watched it yet, take a look at the following talk about juice, it will give you ideas to improve your creation.

7. Sleep

Finally, everybody says this but sometimes we forget how important it is. You have to sleep, if your body is not in optimal contidions to work, you’ll very likely make a lot of mistakes, that you’ll have to fix and possibly will lead to failure. If you read tip number 5 you’ll notice that the schedule I showed as an example includes only 34 hours, the other 14 are ideally for resting.

If you have questions, comments, suggestions, whatever you want just let me know on the comments, good luck with the jam and have fun!

7 Tips to Improve Your Experience at Ludum Dare

New Projects and Future Work

Hi there!

From now on, I want to write a post every week so I keep you updated about what we are doing and share some thoughts on different things that have happened since the last post I wrote.

I would like to summarize all the significant things that Fiery Squirrel has been through last months, will try to keep the post short and simple. It will basically cover status about each project the Squirrel has been working on and few tips that might help other developers.

Fluff Eaters

So let’s start with Fluff Eaters, game that I mentioned in a previous post that I was going to take a break and stop working on it for a while.

Last year in October, Fiery Squirrel partnered with a new publisher called Apartment 507 to promote and market the game as it was in order to improve sales, downloads, etc. Our agreement basically said that for one year we were going to work together to improve the game and create a better experience for players. We have tried different things with the game and I would like to mention few of them here.


The first big thing we tried was create a Holidays vesion of the game with new content, new levels, new mechanics, etc. You can check the final update here and very likely we will make it available again this year.

As you might notice, the art style is slightly different, Fiery Squirrel is working with Gabriel Uguet, who is a very good illustrator and graphic designer, I’m also working with him in a completely different project that I probably will talk about later. In addition, the theme of the new world was composed by Stefano Merino, original musician of the game.

Holidays Update

With this new update, our players could enjoy new mechanics and also we were able to include new features in the game, a bunch of new players, existent and new players interacting more with the game, etc. In general it was a good experience.

But not everything was easy, we also faced different issues. The cycle of work we had, time constraints and all the work we needed to complete was enough to keep us very busy every day and night for one whole month. From the brainstorming, mechanics design, elements, characters, art, sounds, etc, was a lot of work and the worst part of that, even though we managed to finish everything on time, we didn’t consider that the iOS build was going to have issues when we uploaded to the AppStore, it was seriously something not only unexpected but very weird.

Before uploading the game we tested a lot in different devices, it worked well, we uploaded, Apple said there was an issue with the build, we tested a lot again, didn’t find anything weird, compiled again and upload again and it worked (we still don’t know what happened), the bad part of this was that we missed our deadline (on the marketing and promotion side was very important) but I guess we learned a lot.

Holidays Version Level Design

Try to include everything related from the brainstorming to the release on the market in your schedule, every possible step that you have to take in order to see the game in the market from your device, whatever it is, PC, mobile, the last step always will take a lot of time too and, if (like us) you are small team, it matters.

Pax South 2016

The second big thing I want to talk about is Pax South 2016. We had the opportunity to be at the event this year, it was a very nice experience, we met other developers there ( including Rami Ismail who talked to us about his experience at Pax and other events), were able to test new features, see how a different group of players reacted to the game,  promoted the game with different types of promotional material for the first time, etc.

Promotional Material for Pax South 2016

Fluff Eaters was presented at different events in the past and all of them have been a great and unique experience but Pax South was particularly interesting. The main reason is the type of player that played the game at the event, the core mechanics of Fluff Eaters are based on Jacks, which is a game that a lot of people from the U.S. are familiar with, so many of them understood and seemed to enjoyed it very much. Besides this, the response of people was really amazing, a lot of them downloaded the game and played it.

This is something I’ve said before but going to this type of events is very positive for developers in different ways. You might be interested on a post that Apartment 507 wrote about the details of the event, expenses, promotional material etc, you can read the full article here.


These caps were not part of the promotional material that we gave away but were an amazing present from my brother (also part of the team). Depending on how things go (if people are interested), we might sell them in the future.

I guess I could keep giving details of what we have done with Fluff Eaters so far but I also think I spent a lot talking about this game before. In few months the contract with the publisher will come to an end and we will spend the remaining time to keep testing things and trying to improve as much as we can, if you have specific questions please let us know.



Collow is the second project I want to talk about and I’ll do it in a very short way. This idea started long time ago but has been put on hold some times, however, the project will be released for sure this year, the thing is I haven’t have enough time to finish the code for this. We are also accepting playtesters (this is the next step we are going to take) so you can sign up here if you want.



This is a game made for Venezuela Duel Jam 2015 and was the lastest jam Fiery Squirrel has participated in, you can play it here. I know it’s old information but since didn’t mention it before, I would like to at least show it to you. It started as a very simple idea around the theme and I ended up liking it a lot so it will for sure be fully developed (don’t know when) and released as a mobile game.

Chicks: Very simple game

With this game I wanted to achieve few things:

  • Focus on the aesthetics more than usual: In previous game jams aesthetics were not focal point, Chicks does not have awesome graphics but at least they are better than previous games
  • Simplicity: Easy to understand, easy to grasp, challenging and entertaining
  • Mobile: Something that could become a commercial title for mobile devices
  • Complete: A fully playable game

In the end, the game ranked first in the event and more important than that, the feedback from other developers was really good, comments, advices, etc, which will for sure be a key factor when developing the full game.



The last project I’m going to talk about for now. If you follow us on twitter you probably know what this is about. This is the project currently developed by Fiery Squirrel, it’s a very simple and short idea that emerged from the fact that there is a lack of popular and good games that involve the idea of the Sakura (Cherry Blossom) from Japan, in addition to this, I wanted to start getting involved in the artistic part of the games I make and tried to design something aesthetically appealing.

Testing crows behavior and colors

The game is not ready yet. Despite the fact that the idea is very simple, I haven’t had enough time recently, these last months have been busy, however there is significant progress on it and we will playtest it very soon.

The plan is to complete the first chapter of the game which includes 4 different trees, each tree has 4 levels on it, a bonus level and a boss in the end. Depending on how people react to the game, the response we get after playtest and release, it will be decided whether the rest of the chapters (3 more) will be added or not.

This post is longer than I expected, just wanted to summarize what Fiery Squirrel has been doing since the last post. For all of you that are using OpenFL, I still update the repositories in git, I would like to focus more on the implementation of new things and what is there at the moment, there is a lot of uncommented code that might be helpful for someone so, I’ll try to document it as soon as possible and focus future posts on it.

Please feel free to ask questions, if you are a developer, I can talk more about the design or programming of any project you see here, whatever you are curious about just write it on the comments.


New Projects and Future Work

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