In addition to me explaining the history behind some of the projects I’ve been tinkering with over the years, I want this blog to serve as an educational tool for aspiring designers and developers. And so, without further ado, the first of (hopefully) many tutorials.

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.)

continue reading »

Alright, so I’m a donkey. (That’s right a donkey. That’s Scott Allen’s “nice” way of calling someone an ass.) I waited a full ten days before taking the time to check this blog on a PC, in Internet Explorer… only to learn that it was broken in PC Firefox. And I’m not sure for how long. So, sorry to all you PCers out there. I’ve fixed the Firefox issues, and will QA the site regularly on a PC every time I add something new to one of the sidebars and whatnot.

Furthermore, the site is now 100% accessible by Internet Explorer 7* users. When I finally checked the site in IE there was only minimal damage. Which took me all of about an hour to fix.

I promised to write an article about Internet Explorer, and common problems you should beware of when building cross-browser compatible sites. I hope to write that article soon.

—Ryan

* As of this writing, the site is still inaccessible to anyone who is unfortunate enough to browse using Internet Explorer 6. Maybe I’ll get to troubleshooting for that browser in another 10 days.

Have you ever viewed the source of someone else’s webpage and seen gibberish like this:

Looks crazy. When I first ran across it, I assumed it was a random comment left by a developer (meaningful only to him or her). But there’s actually a really good reason why you’ll want to use this code.

When you validate a page using the W3C Markup Validation Service, the < and > characters are important. As a document is parsed, the validator relies on these characters to let it know when it has reached a tag in your HTML code. The parser uses a page’s tag hierarchy to understand the structure of your page and to determine if anything is invalid.

So, when it stumbles upon a random < or > in embedded JavaScript, the parser will get angry and return an error. (Note: Inline, or embedded, JavaScript is any script that is included directly in your HTML. It’s always a better practice to use external JavaScript files, but in the cases where inline scripts are unavoidable, continue reading.) The parser thinks it is encountering the beginning or ending of a tag, when in actuality it may have found a logical greater or lesser symbol instead.

continue reading »

Parsec was a simple game. A traditional side-scrolling space shooter. Enemies entered the screen from the right and if you didn’t kill them before they reached the left side of the screen, they would double back and attack from behind. There were only a handful of enemies and three “mini-bosses” (called cruisers) per level. The beauty of the game was that each level was exactly the same, save for a varied background color and slightly faster gameplay, which made each level progressively more difficult. The simplicity of the game made it both easy to pick up, and extremely addictive.

In addition to enemy battle, you also were required to navigate tricky fueling tunnels riddled with stalactites and stalagmites. Powering down your ship into a lower “lift” speed would decrease the sensitivity of its vertical lift, making refueling expeditions much less dangerous.

Parsec seemed simple enough to recreate.

continue reading »

All of the sites I code nowadays conform to the XHTML 1.0 Strict doctype declaration (or DTD). Except this site since, by default, WordPress uses the XHTML 1.0 Transitional DTD. In olden days people would quite regularly use target="_blank" in their anchor tags to launch a URL in a new window. Sadly, the “target” attribute is no longer supported under the strict XHTML 1.0 doctype and will throw an error when attempting to validate your page.

Googling for a standards-compliant alternative results in far too many options. Here’s the easiest and cleanest solution I’ve found:

Extremely compact and efficient.

While we’re on the topic, don’t validate this blog. It has 32 errors and 11 warnings, according to the W3C. No, this isn’t one of those “do as I say, not as I do” copouts. I plan to try and eliminate all errors and will even write a post about the process since, IMHO, validating your site is one of the most important things you should do before launching it.