game jam

When I first read the theme “Small World” at the theme voting, I thought in making a circular world again (just like my last LD game). However, everybody is gonna do that! So, after a 2-hours brainstorming, the 2 first hours of the competition, I came back with the game idea.

I love the aesthetics of Besieged. All levels show a small village or a small campsite merged into a white-ish background, creating a very cool mix of white emptiness and green alive. With this mixture, you have the feeling that the whole world is just that small portion of green you are seeing. I love that, and I would like to try something alike.

After deciding the aesthetics, I had the feeling that a board game would fit well in this style, where the tiles kind of merge to the background. With a board game in mind, I decided the base rules, which are based on Zombicide: multiple missions, swarm of enemies, climax during the gameplay, varying missions, etc.

All set. A board game inspired by Zombicide and Besieged.

And as usual, even before the theme voting phase, I decided that this game would have something technical that I haven’t developed before. LD#30 was behavior trees, LD#31 was flocking algorithm, LD#32 was circular world and complex behavior trees, and, finally, for this LD#38 I wanted to give more time to animations – not the animation like in sprite sheets, but the animation effects like moving a piece, spawning an enemy, changing scenes, etc…

What went right?

  1. Although the game is not very good, I could finish it, and that was the biggest achievement this time. Sure, other Ludum Dares I worked as hard as this one, but this time the schedule was very, very tight – 3 hours to end the competition I was considering giving up because it missed so many things – but I could complete the base project scope that I have decided at the beginning.
  2. There were, impressively, very few bugs during the development, even the A star algorithm I could code in minutes without any problem. Most bugs I could fix in the last hour.
  3. I could do some cool animations and developed a nice animation scheduling (see below for more details). The animations are not perfect, but they were fun to implement, in special the enemy spawn and enemy movement are very cool!

What went bad?

  1. Very, very tight schedule so that I could barely finish the base of the game. Everything went as I expected, but who wants to barely finish something?
  2. Unbalanced and not fun, again. This is the problem I find in most of my games. I dedicate so much time on the mechanics (usually a bit complex) and the visual that I don’t the time to make it good. I should probably focus that on the next game.
  3. The game provides a few visual feedbacks only, but the player don’t have much idea of what is happening within the combat, or the player can’t even track the pawn actions properly.
  4. No music or sound, but that has always been my Achilles heel.
  5. I implemented a great customization system in which I can add new pawns, enemies, tiles, maps, or event different goals very easily to the game, but I only had time to create one map. If a jam game have lots of customization and lack of content, the customization was just wast of time.
  6. Developing a board game is really hard. I expected it to be complex and take a lot of time to code the game rules, but it is really hard to change and tweak how the rules work and interact during the development. If I will ever implement a board game for a Ludum Dare again, I will keep the rules very very very very simple.

Technical details

Some details of implementation:

The board game logic is completely independent from the visual and the user interaction, which made things really easy later. When the user select an action, the game (visual) asks the board (logic) for more information and render things. When the user perform an action, the game sends it to the board, the board perform and compute everything internally and returns a list of events that occurred internally. For instance, if the user attacks an enemy, the board returns the events pawn attack, enemy defense, enemy damaged, enemy killed, etc…

This messaging system is really great for board games, in special because I wanted to animate all actions, one by one, sequentially. Each message have a different payload, which is used to update the visual object properly. You may see the messages while playing the game if the developer tools is open.

Animations are trick to do. The problem with animations is that you must wait it to finish in order to continuing the operation of the game, thus, making its operation asynchronous. However, as any asynchronous system, other things are happening while the animations are working, such as the user clicking and moving the mouse everywhere (which causes a bug on buttons, don’t know how to solve that yet). To create this system, I added a job function attached to the scene, which can create multiple jobs and run that in parallel.

The job functions receives the duration of the job, the delay to start it, an update function which will perform the animation, and a complete function which is called when the job finished. Moreover, the programmer may stop every job at any time.

At last, I just want to recommend the Affinity Designer, it is a wonderful software for vector drawing, and it save a lot of time with the automatic exporting. I used it together with the Texture Packer and a small script to make the sprite sheet. It was really efficient: I save the document; the Affinity Designer export everything to a specific folder; then I just click export sprite sheet on Texture Packer (I only have to add new sprites if I create new ones); and run the script (I have a console ready to execute it), and done.



Read more

So, I finally decided what to do for this ludum dare, which has the theme “unconventional weapon“. My weapon of choice is “Democracy“, a humble tribute to Heinlein’s novel – and, of course, the Verhoeven’s movie – Starship Troopers.

Player controls an invasion operation at a distant planet, inhabited by big insects , in order to spread “democracy” through the galaxy. The player must exterminate the insects and collect the planet resources to win.

This is what looks like for now:


Read more

Just for the record, I hate the theme of LD 32, “unconventional weapon”. There were a bunch of good themes on the final voting round, like “grow”, “companion” and “abandoned”, but they have lost for “unconventional weapon”, gosh…

Well, we have to do what we have to do. The theme is what it is and now I have to use it. Unfortunately, I’m writing these after 2:30 hours of brainstorming and I still have no clue of what to do.

I really want to use AI, so I trying to add some agents (enemies, allies, creatures, companions, whatever), and giving my artistic and resource limitation, I thinking in use tile maps. That’s all I got for now and it may be useless tomorrow.

I’ll keep you updated.

Read more


Finally I finished my entry for this Ludum Dare (LD31, the theme is The Entire Game on One Screen). This time, I am so exhausted that I couldn’t do any progress report during the weekend, but, on the other hand, I could finish the game, including the mechanics, graphics and sounds.

My idea was creating something with artificial intelligence (again) and for some reason, after the theme announcement, I remembered that I never touched at a flocking algorithm and this would be a good opportunity for it. The game idea is to take some sheeps from one point and bring them to another, without letting them to leave the map or to be killed. The player uses the mouse to herd the sheeps, which will behave accordingly to their neighbor mates and some tiles in the environment.

As tradition, I writing here a summary of the competition:

What was good:

  • Could finish the game!
  • Cute sheeps with nice behavior;
  • I could follow the schedule without any change;
  • I could do some music and sound effects;
  • I drawn my first tileset!

What wasn’t good:

  • Lot of problems with collisions ;/
  • Spend a lot of time with rotation math (shame on me);
  • The sound effects are pretty limited and the music is too simple;
  • The graphics are cool but some things I’m hating, such as the windmill;
  • I had to redraw the tileset 2 times!

Which technologies and techniques I used:

  • The sheeps are controlled by a flocking algorithm, (or boid algorithm) as described here and here;
  • The graphics were made in Inkscape;
  • The map were built in Tiled, using a 32×32 tileset;
  • I recorded the audio for the sound effects in Audacity;
  • The music were made in Guitar Pro and converted in audacity;
  • CreateJS and Creatine were used as programming base;



Read more


Ludum Dare 30 ended some days ago, but unfortunately I couldn’t post this before, so much work to do, so many projects! Anyway, In this post I will tell my experience within this last Ludum Dare, my third one.

Before the announcement of the theme, I was making some plans:

  • I wanted to do something with Behavior Trees. As commented on the last posts here, BT is part of my research in the doctorate program, and LD is a good event to have some real practical experience with it;
  • I wanted to use AI for several agents. A lot of trouble implementing a behavior trees for this compo and then using it in a single NPC? It seems a waste;
  • I wanted to make a game not literally connected to the theme. The thing is, most people take the theme literally and make the default game option, specially the composed words such as “lost in space”, “connected worlds” or anything involving dead things (which means you are going to have zombies).

On Friday night the theme came out: Connected Worlds. At first I hate it, I was expecting something like “you are already dead” or “no one can see you” (I have a cool idea to make something related to these themes), but was Connected Worlds. Then, still on Friday, I made some brainstorm and came out with:

  • A game that uses the theme metaphorically: each person is an independent individual, with its life, with its own world. Thus, connecting worlds refers to connecting people. Therefore, a relationship game in which the player must help the agents (which I call chibis) to connect themselves and to fall in love.
  • Following the idea of using behavior trees on this game, I planned to each chibi be autonomous, controlled by the behavior trees, i.e., they move and talk by themselves, without the command of the player.
  • I predicted that I would spend a lot of time with the behavior trees, thus, the game mechanics needed to be simple: drag and drop! maybe a reflex game! Finally I came up with the following: the player must let the chibis talk with each other in order to make couples; he or she also must drag problems away. Problems are: meddler chibis (which interrupt talks); birds (which poop on chibis); and rains (which wet the chibis).


After the planning I slept (bad night, unfortunately ;/), and Saturday I started the development.

Tools Used

Same as always:

  • createjs for canvas drawing, preloading, tweening and sound control;
  • creatine for the game structures (such as scenes and layouts);
  • inkscape and gimp for graphics;
  • sxfr or similar, guitapro and audacity for sound and music;



First thing I’ve implemented, a simple drag and drop mechanics with trivial gravity implementation. I’ve spent some time on this to organize the game architecture and some more time later to fix all bugs after the BT implementation.

I think I’ve spent about 10 hours on this.


Graphics needed to be simple, I couldn’t lose much time on this because I was already late on my schedule (BT implementation at this point were very buggy). I also wanted that they would be cute. Then simple + cute = chibis!


Example of cute little Chibis


My Chibis

I also needed a feedback to the conversation, showing to the player that the chibis are talking to each other. I remembered that The Sims do that brightly with the conversation balloons. Thus I also drew something similar.


Some conversation Balloons, inspired on The Sims

To differentiate the static objects to the draggable ones, I tried to draw white borders on draggables and no border for the statics, but at the end I think this made no difference to the player.

I spent about 6 hours on this.



This was the tough part. I was risking the whole game when I decided to base the gameplay on this, but I tried anyway. My idea was – using behavior trees to control all actions of the chibis – but I had to implement the BT from scratch! Of course, I’ve looked for BT implementation in javascript, but all frameworks I found seemed very poor to me. Thus, I started the development based on the paper [Marzinotto, 2013], which have a formal description of the model.

And of course, implementing a fully functional behavior tree in few hours basing it on some paper is completely insane. There was a lot of bugs, man, A LOT. This forced me to learn that debugging BTs without a visual help is VERY, VERY, VERY HARD.

I used the following structure for my behavior tree library:

  • AIBehaviorTree: is the tree class, it only have the root node and a function to propagate the tick signal. This function receive the “target” object, which, in this case, was the Chibi object;
  • AIBaseNode: all nodes inherit this one. It doesn’t have much code, just a wrapper to help me debug the model;
  • AIInternalNode: nothing special;
  • AILeafNode: nothing special too;
  • AIDecorator: nothing special tooo;

and with this I’ve implemented the base internal nodes:

  • AISequence: the sequence composite node (similar to the AND operator);
  • AIPriority: the priority composite node (similar to the OR operator);
  • AIMemSequence: similar to the sequence node, but it remembers which child returned the RUNNING state at the last tick, and doesn’t execute the children before this node, i.e., The Mem Sequence execute directly the last RUNNING node, skipping previous children. To know more about this consult the reference.
  • AIMemPriority: similar to the AIMemSequence.
  • AIMemRandom: similar to the Mem nodes, but it choose its children randomly.

With all this implemented, I had my little improvised and buggy BT framework. Notice that, all this code have ugly hacks. I NEEDED THIS WORKING!

Other important detail. Nodes on the BT does not store any control variable on the tree structure, this allowed me to use a single BT to all chibis. To make this work, each chibi object have a “memory” variable (an empty javascript object) in which the tree nodes can write and read information. For example, a “Wait” action write how much chibi is waiting on this memory, e.g., target.memory.tree.node[id].timeWaiting += fdelta .

Other problem related to developing a game based on behavior trees it that, modeling the agent behaviors without a visual tool is also pretty hard!

Firstly, it is not trivial to decide which behaviors an agent will have, and how to implement them to coordinate with each other. After too many hours I had 21 unique actions, 15 unique conditions, and 2 unique decorators; resulting in 92 nodes to model the chibis. With this, I’ve also learned that modeling this kind of thing is pretty hard programmatically, you need a visual tool to understand what is really happening to the model.

I spent more than 20 hours on this!!!!!

Fluffy Things

In the last 4 hours I had to fix some minor bugs and to make things more beautiful (or, at least, not totally crap). Than I made the visual to all screens (menu, credits, …), including deciding the name of the game and the logo. In the last 2 hours I also could create a tutorial and 4 different levels to the game (which is not that cool because there is no real variation on the levels neither they are challenging).

So, 4 hours on this.


Sounds and Musics

Unfortunately, I couldn’t manage to create sound effects nor music. I don’t have much experience on this and probably would take more than 4 hours to make something reasonable.



  • First Ludum Dare that I didn’t change the plan in the half of the compo!
  • Behavior Tree worked very well and there were no relevant bug at the final version of the game;
  • Despite the time I spent on it, the visual of the game is pretty good;
  • There are very few games on Ludum Dare that uses AI as this one, I’m very proud of it;


  • Constant fear of failing to finish it;
  • Very hard to model behavior trees programatically;
  • VERY hard to debug behavior trees without visual helper;
  • Mechanics is incredible boring and repetitive;
  • I couldn’t finish several aspects of the game, but the worse was the sound and not fixing the crap mechanics;




Read more