Part 6: Taming XML

Let’s look at a typical XMLHttpRequest again.

If the request succeeds without error, then we can use the xmlhttp object to access the contents of the loaded XML file. To understand how to work with an XMLHttpRequest object, let’s relate it to something a little more familiar to Web coders: the Javascript Document object.

document.getElementsByName('across') will return an array containing all of the elements on your Web page whose name attribute is “across.” For example, <div name="across">.

xmlhttp.responseXML.getElementsByTagName('across') will return an array containing all of the “across” XML nodes. For example, <across>Data</across>.

Nodes can have both attributes and values. Review Figure 2.

getElementsByTagName will always return an array. In the example above there is only one a1 node, therefore there’s no reason to keep an array of a1 nodes. Instead, using the code below, we can save only the first returned node (since that’s all that exists).

Now that we’ve captured the a1 node specifically, we can access its c attribute using this simple code: var c = a1.getAttribute('c');.

Accessing node attributes is easy, but accessing node values is a little more confusing. Figure 4 demonstrates how to access the value of the editor node.

The firstChild method returns the first child of a node, duh. But the editor node does not appear to have any children. Well, it apparently (or not so apparently) does. When attempting to access the value of a node, imagine the value text as being a node itself. Access the nodeValue of the “text node” and you’ll get the result you’re looking for. Or, in more simple terms, always use .firstChild.nodeValue to access the value of a node.

In the above example, all of the across child nodes are named differently, so it would be cumbersome to getElementsByTagName each one separately. Instead, take advantage of the childNodes collection to return an array of the nodes.

There is more to learn about XMLHttpRequest, but by simply knowing how to use the getElementsByTagName, getAttribute, firstChild and nodeValue methods and the childNodes collection, you’ll have an easy time retrieving all types of data from XML documents.

Before I close this lengthy post, there is one more thing I’d like to mention with regards to XML files. It appears that you can not use Javascript to access local XML files using XMLHttpRequest, you can only access files found on a domain. I am completely perplexed as to why this is and if anyone has knowledge of the reason, or knows a workaround, I’d love to hear from you.

— Ryan

Part 5: Importing From XML

Most programs, including games, require data. More often than not this data must be updated regularly so as to sustain the usefulness of the application. This type of data is usually stored externally (out of the application’s main code) since it makes very little sense to require the application’s user to download a new version of the program every day in order to receive the latest and greatest data. Therefore, with respect to our game, it makes a great deal of sense to store the data for each crossword puzzle in an external XML file. This way each puzzle can easily be loaded individually by referencing a different XML file.

To import data from an XML file, we use the XMLHttpRequest Javascript object as follows.

We’ll talk more about reading from XML files in the next update.

—Ryan

This part of the tutorial is actually not going to explain proper procedures for preloading images. There are a number of methods available, all of which can be found by doing a simple Google search for “preload images”. This article will instead concentrate on ways to reduce the necessity of preloading altogether by means of self-contained data and CSS Sprites.

I’ll start off by briefing explaining the importance of CSS Sprites (since Part 4 below will explain how to use self-contained data). An in-depth discussion of CSS Sprites can be read on A List Apart. In a nutshell, a sprite map is a collection of smaller images mapped onto one large image. By combining images, you will reduce server requests and speed up download times. CSS Sprites especially come in handy when dealing with hovers.

Without sprites, displaying a different image for the hover state of an element requires making an extra call to the server for the new asset. This results in another download (at the time of mouseover), which can take time and create jerky mouseover experiences (especially in Internet Explorer). If a sprite map is used instead, the sprite can be setup to contain images for both the default state as well as the hover state. The sprite is downloaded as the page loads (if the element which will use the sprite is initially embedded on the page), and voilá, the hover state is downloaded with it and ready for use.

I’ve used sprites a couple of times on this site. To demonstrate how easy they are to use, let’s take a look at the “press” button at the bottom of the page.

Figure 1. Example sprite image
 

The sprite is illustrated above. The actual image is a PNG and contains elements which would be hard to decipher on a light grey background. The turquoise box was added to make things more viewable. Using an anchor tag as a button, we can crop out the backgrounds we need for the default and hover states using the following CSS.

Background, width and height styles: Because we are cropping the button to a width and height of 50 pixels, it is not necessary to specify a background position for the default state. Why? The default background appears at the top of our sprite. So as long as we assign a width and height that are the exact dimensions of the default background, the remainder of the background will extended past the boundaries of the button and will not be seen.

Display style: By default, anchor tags display inline, so in order to represent the anchor as a button (and specify things like width and height), we need to force the anchor to display as a block element.

Text-indent and overflow styles: If, in your markup, you include text within the anchor tag (for example: <a id="press" href="javascript:void(0)" onclick="dropBlock()">Press</a>), you can hide the text by assigning a negative text indent and hiding overflow.

The hover state: Now, all we need to do in order to fire up the hover state of the button is offset the top background position of the background enough so that the hover image is used instead of the default image. In this case, we need to offset by 50 pixels. When a sprite map only includes two image states, the offset can be either positive or negative. Both will achieve the same result. When dealing with sprites with three or more states, I recommend strictly using negative values. You’ll understand why as you experiment more with sprites.

And that’s CSS Sprites in a nutshell. Now on to the actual Part 4 update where I’ll discuss self-contained data.

Part 4: ‘Preloading’ Commonly Used Game Assets

If you’ve ever used Dreamweaver, you’re probably familiar with the code that’s used to preload images:

Look at the highlighted line. In Javascript you can create Image objects. By doing so, you can store images in the DOM’s (Document Object Model) memory and quickly access them later. But preloading images in this fashion still requires an HTTP call out to the image so that it can be downloaded. When designing games for the iPhone, we want to limit the number of HTTP requests as much as possible. There’s actually a way to embed some of your images in your Javascript file so that there’s no need to download them.

If you’ve ever tried to open a GIF or JPEG in a text editor you’ll notice that the guts of the image are a bunch of letters, numbers and symbols. There’s a free program online, called the URI Kitchen that will read an image and print out the letter/number/symbol/gremlin guts for you.

To use the program, go to URI Kitchen, upload a file and then copy the resulting data from the address bar. Here’s the data I get when feeding the program a graphic of the number 5 (one of the numbers used to mark the crossword grid):

Pretty, huh? Now, take that data, and use it as follows:

I can now access five anytime I want to load that image in my game, and since it’s embedded in the code there’s no need to run off to the Internet to fetch it. I can draw the image to the canvas (at coordinate 100, 50) like this: ctx.drawImage(questionMark, 100, 50).

Now, you won’t want to use this approach for every image in your game. You’ll still have to elegantly handle load times for large images. But this approach works great for smaller, commonly used images. What are the most commonly used assets in a crossword puzzle? The numbers used to label the grid, and the letters that will spell out each word. And those are the exact images that we’ll “preload” into Javascript using this method.

And this has officially been the longest blog post I’ve ever written. I hope you’ve enjoyed it!

—Ryan

Safari, Firefox, Dashboard, and all other WebKit-based applications, including Safari for the iPhone, support CSS Canvas. There’s even rumor that Internet Explorer 9 will use WebKit, allowing it access to CSS Canvas as well. So it really makes a lot of sense to start learning how to use CSS Canvas now, so that you can build really cool Web sites that take advantage of it later.

Part 3: Jumping Into Code

Let’s start programming this game. The canvas tag, supported by Firefox and Safari, is a really great way to draw to (or animate) a Web page. Since the iPhone does not yet support Flash, utilizing the canvas makes a lot of sense. Since more qualified people than ! have already written great tutorials on how to use the canvas, it may behoove you to read up a bit if you become confused with what follows.

Let’s code the grid. There are two ways we can display it. We can use the canvas to draw the grid. Or we can create 225 17×17 pixel div elements and float them all to the left within a 270×270 pixel parent div. The first option sounds easier, but we’re actually going to do a little of both.

Note: Yesterday’s illustration stated that the grid takes up 271×271 pixels, yet we mention here that the outer div that holds all of the inner squares is 270×270 pixels. This is because the inner squares do not include the outer stroke that surrounds the grid. The outer stroke (and all inner grid lines) are part of the background image. The inner squares have a 1px left margin to separate them from one another, so: (1+17)*15 = 270.

First we’ll use the canvas to draw the visual part of the grid. Here is some simplified code:

The code above will simply draw out 225 white squares, positioned exactly where we want them on the grid. It does not yet determine which squares should be black (the regions of the grid that are not part of the puzzle). We’re ultimately going to read from an XML file to understand which squares are white and which are black. We’ll get to that later.

The user will be interacting with the grid in order to read and solve clues, so we also need a separate clickable region for each of the 225 inner squares. Let’s add that logic to the for loop.

We’ve given each “touchable” div an id and name so that, when touched, we can figure out which clues they belong to. More on that later.

For today, that is all. Tomorrow I’ll provide a neat trick for embedding images directly into a Web page. It’s a great way to “preload” images. Very cool indeed.

—Ryan

I mention Flash because it would seem that the inclusion of the plug-in would open the door to many established and seasoned Flash developers who are not savvy with HTML/CSS/JavaScript or Objective-C (for SDK development). But with the introduction of CSS animation, which the iPhone (and now Safari 4 beta) already support, creating visually intriguing web user interfaces (for games or other web apps) is more plausible than ever before, even without Flash.

It may not seem realistic to create iPhone web app games anymore, since the release of the SDK over a year ago, but iPhone Web designers and developers can still strive to create visually impressive web experiences. And some of these tips may help towards that cause.

Part 2: Design Considerations

When designing web app games for the iPhone keep in mind that although the screen’s resolution is 320×480 pixels, some of the vertical pixels are lost to the status bar, address bar and lower toolbar… 64 pixels to be exact. So, if you want your entire game to display “above the fold,” design it to be 320×416 pixels. (Above the fold is a reference web designers throw around a lot to appear cool. It refers to the topmost part of a Web page. The area that is initially viewable. The content that shows up as you scroll down the page is “below the fold.”)

Figure 1. Crossword puzzle user interface components
 

If you look at a printed crossword puzzle you’ll notice that the game consists of two main parts: the grid, and the “across” and “down” clues. Both take up a lot of real estate. So how do we fit everything onto the iPhone screen?

First let’s discuss the grid (or board, whatever you’d like to call it). The squares that make up the grid need to be small enough so that a 15×15 matrix will fit within the design. They also need to be large enough so that even a person with “fat fingers” can press a single square. After mocking up a number of grid sizes I realized that although I could theoretically size each individual square at 19×19 pixels and still fit all 225 (15 rows x 15 columns) on the screen, I didn’t have much room for anything else. So I settled on 17×17. This means that we loose 271×271 pixels to the grid.

Since a title also accompanies each puzzle, very little room is left for the clues. It will be impossible to display them all at once, so instead let’s display relevant clues when the user clicks on a particular row/column. We’ll talk about how this is going to work later.

That’s all for today. We’ll start coding tomorrow.

—Ryan

This tutorial was originally written in February 2008 (pre iPhone SDK days) and was featured on a now defunct iPhone blog. I will repost the original articles along with update notes, where appropriate.

Part 1: Things to Keep In Mind

There are a couple of things to keep in mind when considering iPhone game development. The most important is that iPhone developers currently do not have access to many of the usability features that make the iPhone great. Things like pinch, expand, slide, drag, drop, etc. That may change when the SDK is announced later this month, but for now all we can respond to is a single touch (click). (March 2009 note: The SDK obviously now provides tools for developers to create amazing native apps, all of which include features like pinch, expand, slide, drag and drop, etc. But iPhone web apps are still limited to responding to only one action: a single touch of the screen.)

Additionally, all of the applications must be built in Safari. Don’t get me wrong, I for one am more than happy to use Safari as my development environment. After all, HTML/Javascript development is what I know. It’s what I’ve spent the last 10 years working with. So I know how to do really amazing things with that medium. Still, Safari on the iPhone is less responsive than it is on your Mac or PC. (March 2009 note: Apple just released Safari 4 (beta), which includes the “Nitro JavaScript Engine,” said to execute JavaScript up to 6 times faster than Internet Explorer 8 and up to 4 times faster than Firefox 3.1. There are no known plans to upgrade the iPhone version of Safari to 4.0, but the potential JavaScript speed increases would be extremely welcomed. For an actual unbiased JavaScript speed comparison test, check out this article on MacRumors. ) For instance, there is a lag between when you press something on the page and when you can press something else on the page. The lag is only about a second, but it should be kept in mind when you begin thinking about the type of game that you want to create. Because of the lag, slower-paced games make more sense. Therefore developing a puzzle game for this tutorial was a no brainer. After all, there’s not much need to race your way through a crossword puzzle.

Figure 1. Crossword puzzle design, along with dimensions
 

Besides the fact that a crossword puzzle was a slower-paced game, this type of game also provided some interesting usability dilemmas, but we’ll get into those with the next update (we’ll also discuss design considerations then). For now, take a look at the near-finished design above. Though I’ve started some of the development of this game, there is much yet to still do so things may change over the next two weeks. (March 2009 note: My original design never was edited later in development. So the design you see is final.)

Since I originally got the idea to create a crossword puzzle while reading a daily edition of USA Today, it made sense to literally try and repurpose the online version of their game in an iPhone format. Come back for tomorrow’s update when we’ll take a look at some design considerations.

—Ryan