BrowserQuest’s Event Handling

This time I want to look at how BrowserQuest handles event happening and how reactions are triggered.

(Last time, I did a quick write up on animation in BrowserQuest.)

Just from playing through the game, you can see that a few things happen when you die: the you explode in a puff of smoke, and the ‘revive’ screen pops up. Lets see how they’re throwing that event.

You are dead.
You are dead.

The die method in the Character object is the one that handles our player dieing, and it’s pretty simple: stop trying to attack whatever we were attacking, and mark us as dead. The bit we’re interested in this post though is the callback.

die: function() {
    this.isDead = true;

    if(this.death_callback) {

this.death_callback is a variable which is set in the onDeath method. I’m not all that sure why this is a public variable, but public variables seem to be the common way of storing data throughout the project. BrowserQuest was never intended to be an example of clean coding standards, so I won’t hold it against them. But this is a problem since those public properties could be relied upon existing by other developers (either in or outside of the dev team). This makes refactoring later on really hard if you don’t want to risk having unintended side affects of changing these properties.

Calling the event onDeath is something I hadn’t thought of doing. The events is like any other that we come across in JavaScript: onClick, onFocus, and the like. So it makes a lot of sense for it to start with the ‘on’ prefix.

Something that limits this feature is that there can only be one callback. That’s very different to how we think of other events. Usually you can bind as many actions as you like to onClick so you’d expect the same here, but it seems that you can only have one callback per event in this system. It’s possible that this feature was never added because they didn’t think they needed it. You can see that they don’t need it by running a grep on “onDeath” and there’s only one place it’s used. (For the Character object at least.) Why waste time on implementing a fancy event system with multiple callbacks when you just need one?

Strangely though, there is another onDeath-like event which gets thrown but is handled by the game class, rather than the character. When the character dies, if you have the credits open, they should be replaced with with “revive” screen. (Code here.) I’m not sure why you wouldn’t want to just bind that code to your already existing event.

In my demo code, I made an array of elements who wanted to listen to a certain event, like ‘onKeyDown’ and then passed the event to each of those objects via their own onKeyDown method. I haven’t stress tested this at all, since there wasn’t any complicated code to be processing. I don’t think that there will be much of a difference in performance by storing an array of callbacks though.

It’s becoming clear that drawing from BrowserQuest alone for ideas of architecture won’t be enough, so I’m going to be looking at other games where the source is available in the near future to look into other ways.

Leave a Reply

Your email address will not be published.