Barrels burning!
Hello. Hello indeed.

The white text over the barrels are the fuel.

The green to cyan to red to green is the temperature. Currently, the threshold for the barrels is set to 1500 fake degrees, so once it reaches 1500, it starts burning. When a barrel’s temperature is close to the threshold (about 75%), it starts radiating its heat to the nearby barrels, thus starting the chain reaction.

Still interested?

GameDev – Using Littera with Phaser

Littera, dudes.

This is one of those innocent looking webapps that blow my mind by their usefulness and ease of use (ease of usefulness?)

It all started when I needed a better font than Arial for my retro/pixel/end-of-80’s Roguelike game. At first I thought there would be a way to package the font with the game, CSS @font-face style, and be done with it, but this is different, since I’m using Phaser and displaying bitmap fonts.

It seems like the most popular option is to use webfonts in Phaser, but I really wanted to package the fonts and make the game playable offline.

I finally stumbled upon Littera, and my quality of life significantly increased. Continue reading “GameDev – Using Littera with Phaser”

GameDev – Entity Component System for Phaser.io, part 2

This is Part 2. Here’s Part 1 of the series.

The Magical World of Entities and Components

Hello and welcome back for the next iteration in this ECS adventure. You’ll learn about how I chose to make components, tied to the same entity, talk together. I believe this is the coolest part.

You’ll need:

  • Phaser.Signal
  • Your game.

Hah. That’s it.

And now, let’s dive into a…

Concrete Example

Let’s imagine we have a game where there are WOODEN CRATES, and WOODEN DOORS. That means we have two entities, the Crate entity, and the Door entity. Also, wood can break, and wood can burn. These are two components.

  • Wooden Crate
    • breakable
    • flammable
  • Wooden Door
    • breakable
    • flammable

It lends itself pretty well to our system. Let’s see what are our components’ outstanding traits:


- isBroken - bool
- healthPoints - number

- onBroken

- hurt(damage)
- break()


- isBurnt - bool
- isBurning - bool
- burnPoints - number (like health points, removed by burning)

- onBurnt

- burn()
- burnt()

This is totally BAREBONES, we could add a lot more properties and methods for the sake of making this even more interesting, but this is a bit out of the scope of this tutorial, and in time you’ll be able to do it yourself.

ALRIGHT! Remember our part 1 on Entity Component System? We’ll continue with what we learned on that tutorial. Let’s take a look at what our components look like in a file.

[snippet id=”83″ title=”ECS – part 2, Breakable” height=”0″ line_numbers=”true”]
[snippet id=”87″ title=”ECS – part 2, Flammable” height=”0″ line_numbers=”true”]

So do you see how the only thing in these components is just handling something VERY specific? They are ZERO aware of the door, and of any other components. They are blind.

But you ask…

[blockquote align=left]

“But wait!”


– you say, clearly flustered, your fists ready to fight –

[blockquote align=left]

“If the components are not aware of each other, how can the flames break the entity?”


Excellent question! The glue resides on the entity. BEHOLD!

[snippet id=”95″ title=”ECS – part 2, Door entity creation” height=”0″ line_numbers=”true”]

So as you can see, communication between components is as easy as
masterComponent.signal.add ( slaveComponent.method, this );

Now that we have our glue, our components and our entities, it’s easy to tie them all together. Here’s the complete file for a simple Door.

[snippet id=”91″ title=”ECS – part 2, Door entity” height=”0″ line_numbers=”true”]

Now, your Door only needs to catch fire to start its terrible non-zen journey into destruction.

[snippet id=”97″ title=”ECS – part 2, Door catching fire” height=”0″ line_numbers=”true”]

All of this with components 😀


Thank you for reading, and don’t hesitate to comment and share!

GameDev – Entity Component System for Phaser.io

This is Part 1. Here’s Part 2 of the series.

Entetey Compowhat?

So the other day I saw on invrse.co that there was interest in having an entity component system for JavaScript games, to which I self-fived myself and promptly tweeted how cool it was.

A couple of days earlier I had started looking into ECS, for a Phaser game I’m currently working on. I strongly suggest that you read invrse’s post up there, it’s super interesting and well written, and if you’re unfamiliar with ECS, I urge you to read it!

So hey, one little disclaimer before we move on: I am totally half-assing this. I’m pretty sure I’m miles away from the real way an ECS should be done, but bear with me, what’s coming is pretty cool!

Half-assing in all its glory

ALRIGHTY-O, let’s get started with a quick (half-assed) recap.

  • Entities are your “objects” or “actors”, such as the player, an NPC, an orc, a sword, a crate, a textfield…
  • Components are the additional properties and behaviors that you might want to add to your Entities. For example, a popular one would be a Physics component, so as to add gravity and collision to your entities.

We’re just adding behaviors and properties to an object.

With this information, let’s take a look at how components should behave:

  • Components should be parameterizable (pretty sure that’s how it’s spelled)
  • Components need to know on what they are applied (entity)
  • Components need to be updated every frame (game loop)
  • Components need to be added and removed at will (they’re optional)
  • Components sometimes need to talk to each other (event, signal, or callback system)

Ok, ok, that’s cool. Let’s take a look at a basic component without any behavior at all. Like I said before, some kind of physics component is usually used during game development, so we’ll create the Body component.

[snippet id=”41″ title=”ECS – Body component example, step 1″ height=”0″ line_numbers=”true”]

As you can see, there are is a name property, and an update() method.  These two things will make much more sense later, but for now let me explain quickly: the name property is used to identify which component we are dealing with. The update() method will be called by the Entity in its own update() method.

Now, the next step is to add the target, or simply put, the entity to which we are referring to, and the subject of the components behaviors.

[snippet id=”43″ title=”ECS – Body component example, step 2″ height=”0″ line_numbers=”true”]

Awesome. This is pretty much the basis for all our next components. You can copy paste and rename them to your liking. Personally, I like to give them adjectivized names, to quickly understand that they’re components, and what they do, for example FlammableDroppable, Throwable, you get the idea…

Now here comes the meat for our Body component.

[snippet id=”26″ title=”ECS – Body component example, step 3″ height=”0″ line_numbers=”true”]

So we’ve set some default properties (self.physicsEngine), and we’re enabling the object in the physics world of your game.

Ladies and gentlemen, we’ve just created our first component, and it is absolutely simple. Don’t be fooled by the apparent number of lines, there are many lines of comments and whitespace.


So we’ve created our first component. Now, how do we use it? Let’s imagine we have a Player class.

[snippet id=”58″ title=”ECS – Body component example, step 4″ height=”0″ line_numbers=”true”]

You need a this.components array. Storing the components you add to an entity makes them accessible, and you can then call the update method of ALL your components in easily:

[snippet id=”63″ title=”ECS – Body component example, step 5″ height=”0″ line_numbers=”true”]


Well, this wraps up the first Entity Component System post. I hope it made sense to you, and don’t hesitate to comment!

Now on to Part 2.