Daniel Janus – JavaScript

2048: A close look at the source

2014-04-02T00:00:00Z

Dust has now mostly settled down on 2048. Yet, in all the deluge of variants and clones that has swept through Hacker News, little has been written about the experience of modifying the game. As I too have jumped on the 2048-modding bandwagon, it’s time to fill that gap, because, as we shall see, the code more than deserves a close look.

I’ll start with briefly describing my variant. It’s called “words oh so great” (a rather miserable attempt at a pun on “two-oh-four-eight”) and is a consequence of a thought I had, being an avid Scrabble player, after seeing the 3D and 4D versions: “what if we mashed 2048 and Scrabble together?” The answer just lended itself automatically.

Letters instead of number tiles, that was obvious. And you use them to form words. It is unclear how merging tiles should work: merging two identical tiles, as in the original, just wouldn’t make sense here, so drop the concept of merging and make the tiles disappear instead when you form a word. In Scrabble, the minimum length of a word is two, but allowing two-letter words here would mean too many words formed accidentally, so make it at least three. And 16 squares sounds like too tight a space, so increase it to 5x5. And there you have the modified rules.

I cloned the Git repo, downloaded an English word list (EOWL), and set out to work. It took me just over three hours from the initial idea to putting the modified version online and submitting a link to HN. I think three hours is not bad, considering that I’ve significantly changed the game mechanics. And, in my opinion, this is a testimony to the quality of Gabriele Cirulli’s code.

The code follows the MVC pattern, despite not relying on any frameworks or libraries. The model is comprised of the Tile and Grid classes, laying out the universe for the game as well as some basic rules governing it, and the GameManager that implements the game mechanics: how tiles move around, when they can merge together, when the game ends, and so on. It also uses a helper class called LocalStorageManager to keep the score and save it in the browser’s local storage.

The view part is called an “actuator” in 2048 parlance. The HTMLActuator takes the game state and updates the DOM tree accordingly. It also uses a micro-framework for animations. The controller takes the form of a KeyboardInputManager, whose job is to receive keyboard events and translate them to changes of the model.

The GameManager also contains some code to tie it all together — not really a part of the model as in MVC. Despite this slight inconsistency, the separation of concerns is very neatly executed in 2048’s code; I would even go so far as to say that it could be used as a demonstration in teaching MVC to people.

The only gripe I had with the code is that it violates the DRY principle in several places. Specifically, to change the board size to 5x5, I had to modify as many as three places: the HTML (it contains the initial definition for the DOM, including 16 empty divs making up the grid, which is unfortunate — I’d change it to set up the DOM at runtime during initialization); the model (instantiation of GameManager); and the .scss file from which the CSS is generated.

While on this topic, let me add that 2048’s usage of SASS is a prime example of its capabilities. It is very instructive to see how the sizing and positioning of the grid, and also styling for the tiles down to the glow, is done programmatically. I was aware of the existence of SASS before, but never got around to explore it. Now, I’m sold on it.

To sum up: 2048 rocks. And it’s fun to modify. Go try it.

Meet my little friend createTree

2011-07-08T00:00:00Z

I’ve recently been developing an iPhone application in my spare time. I’m not going to tell you what it is just yet (I will post a separate entry once I manage to get it into the App Store); for now, let me just say that I’m writing it in JavaScript and HTML5, using [PhoneGap][1] and [jQTouch][2] to give it a native touch.

After having written some of code, I began testing it on a real device and encountered a nasty issue. It turned out that some of the screens of my app, containing a dynamically-generated content, sometimes would not show up. I tried to chase the problem down, but it seemed totally random. Finally, I googled up [this blog post][3] that gave me a clue.

My code was using jQuery’s .html() method (and hence innerHTML under the hood) to display the dynamic content. It turns out that, on Mobile Safari, using innerHTML is highly unreliable (at least on iOS 4.3, but this seems to be a long-standing bug). Sometimes, the change just does not happen. I changed one of my screens, to build and insert DOM objects explicitly, and sure enough, it started to work predictably well.

So I had to remove all usages of .html() from my app. The downside to it was that explicit DOM-building code is much more verbose than the version that constructs HTML and then sets it up. It’s tedious to write and contains much boilerplate.

To not be forced to change code, the above-quoted article advocates using a pure-JavaScript HTML parser outputting DOM to replace jQuery’s .html() method. I considered this for a while, but finally decided against it — I didn’t want to include another big, complex dependency that potentially could misbehave at times (writing HTML parsers is hard).

Instead, I came up with this:

function createTree(tree) {
    if (typeof tree === 'string' || typeof tree === 'number')
        return document.createTextNode(tree);
    var tag = tree[0], attrs = tree[1], res = document.createElement(tag);
    for (var attr in attrs) {
        val = attrs[attr];
        if (attr === 'class')
            res.className = val;
        else
            $(res).attr(attr, val);
    }
     for (var i = 2; i < tree.length; i++)
        res.appendChild(createTree(tree[i]));
    return res;
}

This is very similar in spirit to .html(), except that instead of passing HTML, you give it a data structure representing the DOM tree to construct. It can either be a string (which yields a text node), or a list consisting of the HTML tag name, an object mapping attributes to their values, and zero or more subtrees of the same form. Compare:

Using .html():

var html = '<p>This is an <span class="red">example.</span></p>';
$('#myDiv').html(html);

Using createTree:

var tree = ['p', {},
            'This is an ',
            ['span', {'class': 'red'}, 'example.']];
$('#myDiv').empty().append(createTree(tree));

A side benefit is that it is just as easy to build up a tree dynamically as it is to create HTML, and the code often gets clearer. Note how the createTree version above does not mix single and double quotes which is easy to mess up in the .html() version.

A quirk with JavaScript closures

2011-05-15T00:00:00Z

I keep running into this obstacle every now and then. Consider this example:

> q = []
[]
> for (var i = 0; i < 3; i++)
    q.push(function() { console.log(i); });
> q[0]()
3

I wanted an array of three closures, each printing a different number to the console when called. Instead, each prints 3 (or, rather, whatever the value of the variable i happens to be).

I am not exactly sure about the reason, but presumably this happens because the i in each lambda refers to the variable i itself, not to its binding from the creation time of the function.

One solution is to enforce the bindings explicitly on each iteration, like this:

for (var i = 0; i < 3; i++)
  (function(v) {
    q.push(function() { console.log(v); });
  })(i);

Or use Underscore.js, which is what I actually do:

_([1,2,3]).each(function(i) {
  q.push(function() { console.log(i); });
});