Background

Phoenix Rising is a JavaScript/HTML5-based puzzle game that I wrote for the second iteration of the Game Prototype Challenge, a week-long game jam. Organized by former colleague Jason Kaplan, the purpose of the challenge was to motivate game developers. And motivate me it did; I saw it as a good opportunity to try my hand at game development.

Idea

This was my first ever attempt at writing a game, so I wanted to keep things simple. Basically, this meant that I couldn’t do anything that required complex mechanics. I was also working that week and had a couple of events to attend so time was definitely an issue.

I chose to write the game in JavaScript, making use of the canvas element introduced in the HTML5 specifications. There are a couple of reasons for this. One: I’m already quite experienced when it comes to web development so I wanted to take full advantage of that knowledge. Two: I haven’t actually worked with canvas before even though I’ve seen all sorts of cool demos that others have written. This was a good way for me to get my feet wet on both fronts.

It took me a few hours to come up with a workable concept once the themes for the challenge (immortality and thin ice) were announced (I was actually up ’till 4 AM thinking while reading up on basic game development). One of the first things that came to mind was the notion of cracking tiles that would deteriorate into holes once you’ve stepped on it a couple of times; a set of such tiles would essentially be a puzzle that has to be navigated carefully. This was one of the mini-obstacles in Golden Sun, a RPG that I hold in the highest regards. In the end, it turns out that I would do something similar – a set of ice tiles that melt into a trail of impassible water. I wasn’t entirely sure how to fit immortality in at first (early ideas included obtaining an elixir of life, spiritual ascendancy, etc.), but then it hit me. Why not do something featuring one of my favourite creatures of all time, the phoenix? Everything came into place once I wrapped my head around that thought, including the melting ice (a phoenix is made of fire after all), the collection of twigs to build a nest, the mini-story…

Development

Although I fleshed out the game concept fairly early in the week, I didn’t actually start coding seriously until Thursday. In hindsight I should have started sooner, but there was a lot of material for me to read up first (as stated, I haven’t done game development before). JavaScript is pretty quirky as a language too which didn’t help much (I typically use jQuery syntax for the things that I need in the average web development project).

I started with a simple game loop using setInterval() that is first called when the DOM is ready. For this particular project, a continuous game loop was probably overkill; something based on player input would have been far more efficient. I wanted the flexibility though, in case I felt like implementing AI for enemies and whatnot. It turns out this was a rather bad decision as I overestimated the performance of JavaScript in certain browsers; FF 3.6 was quite laggy although FF 4 and Chrome 8 ran the game alright.

All of the level data is stored in separate XML files which are parsed into game objects as needed. This allowed me the flexibility of adding new levels on-the-fly as well as giving an easy way for others to create their own custom maps (in the future?). The jQuery framework makes the parsing process painless, only requiring an AJAX request and a callback function. I’m actually pretty sure it’s standard practice to store this data separately, although it was more out of intuition for me.

It turns out that drawing on the HTML5 canvas is rather simple, though you are more-or-less limited to primitive objects. I made extensive use of drawImage() since most of what I had was stored externally. The visual part of the game consists of a bunch of images hastily drawn using my trusty Wacom Bamboo tablet. It was actually slightly challenging drawing things that would tile correctly (mainly the wall) and writing code to display the right image wasn’t a walk in the park either. I probably messed up here; there was likely a much better way of doing things (i.e. not having separate cases for everything).

Everything else is rather straightforward; I used a 2-dimensional array to store the current game state and had various checks in place for “special” events. Arkayle’s abilities were actually a last minute add-on that I felt added a lot more depth to the game (I knew something similar had to be added eventually – there is only so much you can do with a puzzle where you couldn’t normally retrace your steps). Unfortunately since I was crunched for time, I couldn’t really do too much level design. The result is a three-level game where only the last level is slightly challenging.

Lessons Learned

There were a few major issues that I ran into. I found that drawing on the canvas is pretty damn slow especially when the dimensions are large (e.g. 1000px x 500px). Especially for a game like this, it was probably a much better idea to redraw when something actually happened (e.g. player input), rather than at a constant interval. An alternative would have been to not use canvas: DOM manipulation is another path that I could have taken.

A second major issue that I found was when I was trying to import my “art” assets into the game. There is an issue with drawImage() which tries to render an image onto the canvas even if it hasn’t been loaded yet. I’m not sure if this is a bug or by design (if it is by design, I’d like to know why). One of the ways to resolve this issue was to use drawImage() on image load:

1
2
3
4
5

var img = new Image();
img.onLoad = function() {
    canvasContext.drawImage(img, xStartingCoordinates, yStartingCoordinates);
}
img.src = "path/to/image.png";

Unfortunately, this caused a whole bunch of flickering due to my game loop (at least in Firefox 3.6) so I opted to preload all of my images instead.

1
2
3
4
5
6
7
8

$(document).ready(function() {
    var images = ["image1.png", "image2.png", ...];
    var img = [];
    for (var i = 0; i < images.length; i++) {
        img[i] = new Image();
        img[i].src = images[i];
    }
});

Turns out that this works quite well. The smart way of dealing with so many images (20 at my last count) would have been to use sprite maps to minimize the number of HTTP requests, but I didn’t want to deal with the hassle at the time (as mentioned, crunch period!).

There were a few more kinks along the way (e.g. dealing with JavaScript’s prototypical – rather than classical – inheritance), but they were pretty minor. My code base is pretty messy, though that was to be expected writing something I didn’t know how to write, using tools that I didn’t know how to use. In hindsight, I should have introduced a lot more separation between the engine and game logic. I also should have found a way to reuse code more effectively (see the Entity object). As for the game itself, I should have added in a few more abilities for Arkayle to use, as well as more levels (right now it doesn’t seem much like a game). Ah well…

All in all, I had a great time working on this prototype. I felt like I learned a lot from the process and I hope to apply that in future projects.

There are many different ways to build a web scraper. A server-side language such as PHP will have a much easier time as there are less limitations and existing libraries (such as cURL) to accomplish the task. I’ll be using JavaScript (with the jQuery library), however, as I want a standalone client independent of server technology.

Let’s start with a random snippet of code:

1
2
3
4
5
6
7
8
9
10
11
12

function fetchPage(url) {
    $.ajax({
        type: "GET",
        url: url,
        error: function(request, status) {
            alert('Error fetching ' + url);
        },
        success: function(data) {
            parse(data.responseText);
        }
    });
}

The above function attempts to make an AJAX call to a specified web page, fetch the HTML of said page and pass it to a parsing function. Simple enough, right?

Unfortunately there’s a little problem with this. Client-side programming languages have to deal with something called the same origin policy which basically restricts scripts from accessing external domains. From a security standpoint this is obviously a good thing; however it can be a headache for web app. developers (indeed, there are ideas such as the origin HTTP header to solve this). (The following bit can be ignored if the scraper is on the same domain as the data source – but in such a case why is said scraper even necessary?)

In this case, there are a couple of solutions (that I can think of). Both of them take advantage of the fact that JavaScript can read JSON even if it is located on a different domain.

• The first one is writing a complementary server-side script that takes a few arguments (such as the target URL), makes the call, parses the result into JSON format and passes it back to the calling function. It’s a simple idea, but I never really liked it because it introduced a major dependency (which, in my case, can be a pain to deal with). However, it’s definitely a viable solution which works extremely well.
• The second is using an existing system such as Yahoo’s YQL to fetch the required data and return it in a structured form. This is the method that I’ll be using.

YQL is an interesting little beast. From their site:

The Yahoo! Query Language is an expressive SQL-like language that lets you query, filter, and join data across Web services. With YQL, apps run faster with fewer lines of code and a smaller network footprint.

I haven’t had too much time to look into it so I do what all programmers do: Google the living crap out of a problem to find a solution. In this case, Chris Heilmann has a great post on how to load external content via. various methods including YQL. To simplify things, James Padolsey wrote a plugin that detects an external AJAX call and passes it to YQL automatically.

Anyway, that solves the problem of fetching data from an external source. All that’s left is extracting the relevant pieces for whatever application is being built. Consider the following example:

1
2
3

function parse(data) {
    alert($(data).find("h1").text());
}

The parse() function takes the responseText data from the earlier fetchPage() function and then proceeds to pick at it slowly and painfully. What’s really cool about it is that pretty much all of jQuery’s selectors can be used to select relevant data. In the above case, I’m trying to extract text inside the first <h1> tag found on a page and outputting it as an alert to the browser. Obviously there are more complex uses for this but they are outside the scope of this post.

And…that’s it! Those two code blocks combined pretty much handles all of the grunt-work in extracting data from external sources. Again, this is a rather fragile solution – it can break if the target page’s HTML changes (one possible solution is to pick unique identifiers or classes). In addition, some sites may have restrictions on their data – but I’m sure everyone reads those long-winded documents.

1
2
3
4
5
6
7
8
9
10
11
12
13
14

function blah() {
    var pagedata;
    $.ajax({
        type: "GET",
        url: "test.php",
        error: function(request, error) {
            alert("Error: " + error);
        },
        success: function(data) {
            pagedata = data;
        }
    });
    return pagedata;
}

Looks reasonable enough. The purpose of the function is to make a GET request to some page (“test.php” in this case), store the result in a temporary variable and return said variable (of type string).

However, it turns out that this doesn’t work too well. When the function is called, chances are pretty good that the returned string is empty. Why? At first I thought it was because of some weird variable scoping rules in JavaScript, but that didn’t really make too much sense.

It turns out that I forgot about the “A” in “AJAX” (i.e. Asynchronous JavaScript and XML). The function above doesn’t execute in a top-bottom manner; the $.ajax() call is made in parallel with the rest of the script. Generally this isn’t too much of a problem (indeed, it’s a valued property by those making web applications) but in this case it isn’t what I want.

Anyway, there’s a simple solution to this. What I want to do is make the call synchronous with the rest of the script. Fortunately, jQuery makes this extremely easy in the $.ajax() method by providing an option (async: false) to turn this off. Thus:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

function blah() {
    var pagedata;
    $.ajax({
        async: false,
        type: "GET",
        url: "test.php",
        error: function(request, error) {
            alert("Error: " + error);
        },
        success: function(data) {
            pagedata = data;
        }
    });
    return pagedata;
}

This locks up the browser while the call is being made so it’s probably not the best solution. It shouldn’t matter too much with small requests though (or requests made with the user’s consent via. the UI or something).