As an iPhone developer, I am giddy with anticipation over tomorrow’s supposed unveiling of Apple’s upcoming tablet. Specifically, my interest in multiplayer gaming as it relates to the iPhone and iPod Touch, and now iPad (if that’s what the tablet is to be called), has peaked recently as I begin development of a couple of new mobile games of my own.

Yesterday a number of friends forwarded me a New York Times article entitled A Playland for Apps in a Tablet World. I actually didn’t make it through the entire article because I stopped dead in my tracks by the fourth paragraph which reads:

But the larger screen — most likely 10 inches diagonally — and other features of the tablet could inspire developers to create new twists on apps, like games that two or more people can easily play at once on the same device.

The concept of a device large enough for two people to play simultaneously is not news in its own right, or cause for mass hysteria. Yes, a 10” tablet would definitely be large enough to support a multitude of simultaneous finger/toe touches. The same article quotes Smule co-founder, Ge Wang, as saying:

“On the iPhone, there are five touch points max,” Mr. Wang said. “You don’t need much more than that because that’s about all you can fit on that screen.”

A tablet with a bigger and better multitouch screen, he said, “could mean entirely new user interfaces, screen layouts, instruments, contraptions and games.”

But how the tablet would distinguish one player’s touch from another player’s, that’s what’s got my mind twerking. Will the tablet be sophisticated enough to differentiate one player’s fingerprints from the other player’s?

Surprisingly, this concept may not be that far fetched. Let’s look at the facts.

Apple filed a patent as early as June 2004 that involved “many tiny image sensors wedged between LCD cells, and software to stitch together all of the smaller pieces.” Later, in July 2007, a new filing detailed plans for a camera mounted behind a display that could capture an image “while the display elements are in an inactive state (in which the display elements are darkened and at least partially transparent).”

At that time, technologies like these was envisioned to be used on desktop or laptop displays, but why couldn’t a technique like this be used on a touch screen? And could the camera images be detailed enough for the computer to decipher fingerprints?

While digging further for information to support fingerprint-awareness, I found this article which brings the idea well into the realm of plausibility. In July 2009, Macrumors, along with a number of other news sites, published the findings of another Apple patent entitled Fingerprint Identification as an Input Method. The patent involves the use of fingerprint patterns to actually identify distinct fingers and suggests that the technique could be used to produce specific functions depending on which finger is being used. For instance, an index finger press might perform one action (PLAY/STOP) while a middle finger press could fast forward. If this patented technique is sophisticated enough to distinguish an individual’s index finger from their middle finger, surely it could be used to distinguish two (or more) completely separate sets of fingerprints?

And honestly, how else can “games that two or more people can easily play at once on the same device” be possible without fingerprint recognition?

There’s no indication that any of these patented technologies are accessible enough to include in affordable consumer devices, but we can dream can’t we? Steve Jobs has been quoted as saying the tablet “will be the most important thing [he's] ever done.” Based on that, I’m expecting a lot of surprises. What do you all think?

— Ryan

Well now I have the proof! A couple of weeks ago I was followed on Twitter by @canvasdemos. The Canvas Demos blog dedicates its time to tracking down and showcasing demos and tutorials for the HTML canvas element. Some of the examples they’ve uncovered are truly amazing and include games, 3D tests, music visualizers, etc. If you’re at all intrigued by the power of CSS Canvas, and are wondering how you can use it on your own site (or Web app), don’t hesitate to give their site a look!.

The image above is from Jacob Seidelin’s music visualizer. The demo creates an image of Thom Yorke to the music of Radiohead’s Idioteque. It’s worth checking out.

— Ryan

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

For years now I’ve admired the works of many of today’s top visual designers. Through regular visits to the Iconfactory, an icon design house, I’ve come to appreciate the illustrative styles of a select group of visual designers. David Lanham is one of these incredible designers. Lanham’s designs are remarkably otherworldy. Though his creations are born from fantasy and bewilderment, his attention to detail is uncompromised. David’s contributions to the Iconfactory can most publicly be seen in icon and title art he created for the Frenzic iPhone/Mac game and the Twitterrific application.

I’ve included one of his vector pieces, Samurai Monkey, above. On his site Lanham writes, “Most of my work is made to be fun and enjoyable, which works out well since I have a really good time creating it.” And that simply is what good design is all about. Making magic and having a fun time doing it!

To view more of David Lanham’s art, visit his Web site at www.dlanham.com. You can also follow him on Twitter at dlanham.

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

Pretty, isn’t it? Did you know that Microsoft pioneered favicons in the release of Internet Explorer 5 as a way to spice up dreary bookmark menus? This was back when Microsoft actually contributed to the forward momentum of positive Internet change instead of holding it back. It wasn’t until later that favicons were incorporated into browsers’ address bars.

Most people know the purpose of a favicon and even understand how to implement one. Still, there are some unique things to keep in mind when generating the image itself.

A favicon should be appropriately sized at 16×16 pixels. You can design them to be larger, but most Web browsers are going to scale them back down to 16×16 (or smaller), so test your image to ensure it will still appear acceptably if scaled.

When originally introduced, Web designers were required to name their icon favicon.ico (thus the name) and place it in the root directory of their Web site. Internet Explorer 5 would then instinctually find the icon and use the image. Today’s browsers provided a little more flexibility by allowing you to specify a path for the file and an image format. Simply place a <link rel="icon" type="image/png" href="/path/image.png" /> tag in the <head> of your page.

However, later versions of Microsoft Internet Explorer only truly support icons that have a legitimate .ico extension and that are exported in the icon file format. Many designers have changed their preferred image’s extension to .ico without first actually converting them to Microsoft Icon Files. This creates a conflict that Microsoft Internet Explorer cannot resolve; such icon images will not be displayed.

So how do you create an .ico file? Well, I used favicon.cc. Go to the site, upload your image, generate a favicon.ico file and upload it to the root directory of your Web site. Easy as pie. The site even provides a preview of what the image will look like in an address bar, which is very convenient indeed.

—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

Also, if you use Twitter and would like to be updated whenever I post something new, please follow designment. I wanted “sinceriously,” but it was taken… by someone who doesn’t even use it. Hate. Anyway, happy Friday!

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