Ever wonder why links you find via Twitter don’t show up in your browser history and aren’t suggested by autocomplete in the url bar? The t.co link shortener serves known browser user agents an HTML page containing a JavaScript or meta refresh redirect (instead of the standard Location header) so that Twitter can stake itself out as the referrer when coming from third-party clients. This confuses Safari.

Stats are cool and all but only when they don’t break the experience for your users.

Download Detox.

(Zackary Corbett made a Chrome version too, which may or may not be necessary. Firefox and Opera also appear to be unaffected.)

Detox 1.1

Now when you hit a t.co redirect page (from a native client or a direct message from Mail.app) the destination url is added to the document title making the destination url appear in your history and url autocomplete suggestions.

• The Last Rocket Though not released until mid-August I started work on what I consider to be my first proper game in early January. The development of this game, more than anything else, shaped the past year. It was critically well received, responsible for a quarter of the year’s income, and even made Edge, Touch Arcade and iPhone Alley’s year end lists.
• Unplayed I’d been privately maintaining a list of games I’ve played or want to play since getting a DS Lite in June of 2006. After briefly dabbling with a Tumblr to maintain the list I wrote this trifle of a web app.
• Breathing Room My first Ludum Dare. Also, an early study from my thinking about level design.
• CSSFrag A Safari extension for targeting specific DOM elements by url. Passed the torch to Pinpoint.
• Reply Reach & Past @s Two little JavaScript bookmarklets for use on Twitter.com.
• Data Entry Sentry My second Ludum Dare and my first attempts at a JavaScript/Canvas game. The genesis of the JavaScript port of the Objective-C framework I use for all of my iOS games, SI2d.
• Day-O A simple menubar calendar replacement for OS X.
• Chunks A native iOS port of my second Ludum Dare game, Data Entry Sentry. I didn’t promote this as much as I probably should have but a more vocal release might have set expectations too high for this modest little falling block game.
• Sinkhole My third Ludum Dare. A tense little exploration game that I’m still actively developing. SI2d.js was updated significantly for this game. I even ported it from Canvas to DOM sprites to compare performance (pretty much head to head by the numbers but the Canvas version feels smoother in play and is easier to extend).
• The Last Rocket Suite The soundtrack from The Last Rocket did pretty well too so I released this string quartet version of three themes from the game.

In addition to these wholly new things, I also released a bunch of updates to Mint and its Pepper, Fever, Shortwave, Lessn and NoiseES. I’m also about a month or two into another all new 8-bit iOS game, inspired as much by Metroid and Super Mario Bros 2/Doki Doki Panic as it is by Studio Ghibli’s films.

All in all, a very productive year.

This past weekend I participated in my third Ludum Dare. I created an HTML5 game called Sinkhole from scratch in 48 hours. It was an awesome experience and the game didn’t turn out half bad either. Last time I had just launched The Last Rocket. This time I had just launched Chunks, a native port of my previous Ludum Dare creation.

The theme this time around was Alone. Unlike the previous two Dares where I came up with three ideas and then slept on them before starting, this time I had an idea I was really excited about and after only half an hour set to work.

The first three lines of my notes from that first night read:

• top-down
• exploration by flashlight
• something moving in the darkness

I wanted there to be an urgency to the exploration. I wanted the antagonists, the stalkers, to be unseen. Let the players’ imagination do the heavy lifting.

I also knew I didn’t want to have to worry about level design so after bootstrapping the JavaScript framework I cobbled together for the last Ludum Dare I started researching cellular automata and pathfinding so I could dynamically generate solvable maps to use. I managed to get the skeleton of a solution working (ported from C to JavaScript) before bed the first night.

While falling asleep I started imagining the stalkers’ behavior. After a short delay a stalker appears and attempts to sneak up behind the player. Facing the stalker causes them to freeze. Shining a light on them causes them to flee. But every time one flees another, slightly faster, stalker spawns. The player solves their current problem at the cost of future safety. More impetus to find the exit quickly.

In addition to the unseen threat of the stalkers, the player’s defensive and discovery tool, light, is limited. The flashlight’s batteries drain in one minute. Matches burn out after 3 seconds. It takes time to load a new battery or strike a match. During that time visibility is nil. Or rather, you can see the stalkers approach but not the player or the walls of the level. Once the player runs out of light sources and their eyes adjust only slivers of walls are visible on the periphery of their limited cone of vision. The player must rely on these subtle hints and the minimap to find another battery or matchbook to buy them some more time to find the exit.

I eventually fell asleep.

I woke up to the realization that I had attempted (and abandoned) a very similar mechanic during my first Ludum Dare (the original Chibi Pan & Pup idea).

Shaking off the thought of repeat failure I quickly implemented a TileMap class in SI2d.js and a way to crop the viewport allowing the “camera” to follow the player as they moved across the map. I revisted the touch-based controls then created some rough graphic masks to start implementing the different sized beams of light that define the gameplay. Minimaps came quickly. Around this time I realized that the framerate wasn’t going to be acceptable on the iPad and implemented keyboard controls as well.

Power-ups, a compass to reveal the exit on the minimap, batteries and matchbooks to recharge your light supply slotted in pretty easily. Stalkers gave me a bit of trouble initially. They needed to spawn outside of the players cone of vision or else they would flee immediately.

The story arrived in the form of four tweets that became the prologue:

Tomo the Cartographer was on a routine survey mission in Central America when the earth opened up and swallowed him whole.

Miraculously, he survived falling hundreds of feet and walked away with only a broken arm.

Guide Tomo out of the sinkhole before he runs out of flashlight batteries or burns through all his matches.

It will be a lonely climb back to the surface. At least, Tomo thinks he’s alone. He hopes he’s alone.

Around midnight the second and final night I started on the artwork. Like all of my games to date I limited my palette to only colors the NES was capable of producing. Tomo came together quickly, based largely on the Link sprite from the original Zelda (with a strong Mega Man influence). I used Mario from SMB3 as a referene when drawing his vine climbing animation. I had to redraw the power-ups and background tiles a few times but I eventually arrived at something I was happy with. I had a lot of fun creating the onomatopoeia bursts that represent the stalkers.

The remainder of the last day is a disjointed blur. Lots of revisions to stalker behavior. Persisting inventory between levels. In a remarkable moment of clarity I coded, from memory, in one go, an error-free JavaScript port of my Objective-C TextMap class. This allowed me to get some of Tomo’s internal dialog on-screen while playing.

The title screen graphic was a happy accident. While trying to draw grass hanging over the edge at the top of the sinkhole I accidentally turned off (or on) another layer producing the masked out, moss-clinging-to-the-sides effect you see in the finished artwork.

By the end of it all I couldn’t see straight, my own eyes were anti-aliasing the pixel art I had slaved over. But it was totally worth it. It’s creatively rejuvenating, knowing that you just created something, non-negligible, largely from scratch, in just 48 hours. If you participated in Ludum Dare, please play and rate my entry (I’d love any feedback you have as well)!

I’ve been continuing to develop the game in the days since submitting. Improving collision detection, softening cornering, improving keyboard responsiveness, adding Gamepad API support, refining power-up frequency and distribution, tuning stalker behavior. Maps no longer regenerate every time you die. The minimap remembers previously explored areas. Inventory reverts to its unique pre-level state rather than resetting completely. Play the updated version of Sinkhole. Who knows, maybe someday there will be an expanded native iOS version.

Later tonight or early tomorrow I’ll have a new game in the App Store. (For real this time. Last week Horror Vacui 2 showed up on a number of App Store new release lists for no apparent reason despite being released over a year ago.) It’s a small game with more in common with Horror Vacui than The Last Rocket. And it might look familiar.

Chunks is a native iOS port of my most recent Ludum Dare game Escape! Data Entry Sentry. The core gameplay mechanic and most of the graphics were created over a 48 hour period shortly after releasing The Last Rocket. While I’ve been working on a new, more ambitious 8-bit platformer for iOS (somewhere between The Last Rocket and the unreleased Mimeo and the Kleptopus King in scale) I’ve also made time to rename and refine Chunks for a proper release.

In addition to some gameplay tweaks and instructional UI, I composed three new chiptunes, a short game over jingle plus a handful of sound effects. The themes were inspired by falling block giants Tetris and Dr. Mario (with a little The Guardian Legend thrown in for good measure). The tempo of the background music increases with the speed of the conveyor as you play. This change is imperceptible from level to level but after a while you really start to feel the frantic increase in momentum. Grab the NSFe and give it a listen in NoiseES.

Chunks is a universal app so you can play on your iPhone, iPod touch or iPad and includes Game Center leader boards for high score and highest level. It’s a small game with humble origins so it’s only a buck. Check it out tomorrow!

Day-O is a simple menu bar clock replacement with a simple calendar for your Mac. It’s free, as-is (which means I’m not providing support, taking feature requests, addressing perceived inadequacies or releasing the source code). Here’s how it came to be:

My late upgrade to Lion was relatively painless. The only casualty was MenuCalendarClock. It somehow clobbers the Dictionary shortcut key command and gesture which I use daily (if not hourly). I thought I could live without MMC. I don’t use any calendar apps so I was just using the free version for the simple date icon and convenient fly-out calendar. I thought the system menu clock would suffice. Really, how frequently did I use the fly-out calendar?

Turns out, quite a bit. I tried a few replacements but couldn’t stand any of their date icons. MMC developer Objectpark seems to have gone quiet. Fortunately, as I quipped on Twitter, I’ve “never met a wheel I didn’t want to reinvent.”

I was able to piece something together from various NSStatusItem tutorials, the NSDatePicker Class Reference, Stack Overflow answers and GitHub repositories.

I may or may not have had this YouTube video on repeat in the background the entire time.

Download Day-O.

Drag this Past @s link to your bookmarks bar. Then the next time this happens select the tweet and click the bookmarklet to perform a quick Twitter search for recent tweets from this person to you.

Think that’s useful? You might also like my Reply Reach bookmarklet.

function chance(x, y)
{
    // return Math.ceil(Math.random() * y) <= x;
    return Math.random() <= x/y;
};

Which in my testing behaves as intended. chance(1, 32); has an approximately 3% chance of returning true. chance(99, 100); has an approximately 99% chance of returning true.

Hopefully this will save someone else some unnecessary head-scratching.

Update K.M. points out that Math.random() returns a number between 0 (inclusive) and 1 (exclusive) so the Math.ceil() is unnecessary.

I’m increasingly of the opinion that onscreen buttons are not the way forward. Overlays are a poor substitute for a physical d-pad or buttons; it’s too easy for fingers to drift while attention is focused elsewhere onscreen or to obstruct immediate threats to the player resulting in unfair deaths.

They create the expectation of familiar behaviors that they can’t deliver. When you use a gamepad your fingers don’t hover over the buttons waiting to touch each individually. Your thumbs rest on the buttons, then depress and/or pivot to adjacent buttons as needed. On a touch screen it is impossible to distinguish between a resting touch and a touch with intention. (Hold and slide might effectively simulate an analog stick but I’m primarily interested in 2D games where an analog stick offers little benefit.)

Deferred Gratification

If an action is triggered immediately at the beginning of a touch (the press) that’s the only action that touch can trigger leaving you to rely on separate onscreen buttons to provide multiple distinct actions. But, if you delay triggering the primary action to the release, a single touch can be overloaded with at least three distinct actions.

In The Last Rocket, the press triggers a crouching state. From there the player can release to launch (like releasing a spring) or swipe to step in the direction of the swipe. Three distinct actions, zero buttons. While airborne, the press prepares to land in a crouching state, release reverses direction, and when snared by a fan or vent, a swipe chooses a direction. Again, three distinct actions, no buttons.

If Flip launched or reversed on the press then additional onscreen buttons would be required to support the additional actions. This new approach may at first seem contrary to past experience with gamepads and their physical buttons but is intuitive and easily grasped in the new context of a touch screen.

Potential Application

I can imagine a fairly traditional platformer that uses this buttonless approach (there may already be one, I’m not the most voracious iOS gamer): The screen is split down the middle into two equal, invisible regions representing left and right. A press starts the character running in one direction or the other, depeding on which side of the screen is touched (which the player intuitively understands as run towards the touch). A release triggers a jump that maintains the previous forward momentum. A quick tap from a standstill would be a straight jump up. A release after a period of running would be a leap forward. Maybe another touch on the same side cancels vertical momentum, limiting the height of the jump (which the player intuitively understands as the duration their finger is off the screen). A tap in the opposite direction could cease forward momentum without triggering a forward jump.

Definitely something I plan to explore further after submitting The Last Rocket 1.1 to the App Store and porting Data Entry Sentry to iOS.

This time the theme was Escape!. Like last time I came up with three ideas and slept on them before starting any work:

• Farmbreak!: You place obstacles to prevent animals from escaping their pens. Different animals have different abilities (ram, jump, burrow, fly) and each requires a different type of barrier to contain. Yawn.
• Escape from Zombie Hall: Sort of a Space Invaders/Smash TV mashup. A first-year dorm resident of Zombinski Hall is trapped in a zombie outbreak. In the first part of each stage the player moves left and right blasting back the oncoming zombie horde with a shotgun (Space Invaders). One zombie is holding the key to the exit which is behind the player. When that zombie is blasted the key pops out and the player must rush in with a 360 chainsaw attack (Smash TV), collect the key and make it back to the exit in one piece. The only thing less inventive than a clone plus zombies is a clone plus ninjas.
• Data Entry Sentry: Can you make a game about escaping data? Can you make it fun? You can certainly try. Chunks of data slide down multiple conveyors towards a parser and buffer. Some of the data chunks are gremlins. If a gremlin hits the parser it eats all the data between it and its pair. The goal is to fill the buffer without overflowing.

Waking up Saturday morning, Data Entry Sentry seemed the most interesting, unique option. So where do I start? For my first Ludum Dare entry, Breathing Room, I used Flixel. I’m really not a fan of keyboard and mouse games and really enjoyed the simplicity of tapping in The Last Rocket. I wanted to make a game that I could play on the iPad. So Flash was out.

After doing some quick research on HMTL5 game engines I decide to roll my own. Using John Resig’s Simple JavaScript Inheritance I put together a streamlined JavaScript approximation of the iOS framework I used for Horror Vacui 2 and The Last Rocket.

The framework is pretty simple (view source on the game). The primary class is Surface which can have a parent and children Surfaces, has a rectangle for size and position and knows how to render and update itself. Surface is meant to be extended but is also useful for grouping elements at a given zIndex. The GameSystem class extends Surface and is responsible for creating the canvas element and is used as the System singleton so that the Texture and Rectangle classes can draw to the screen. An InputManager class is used by other objects to register to receive input events. Everything else extends Surface. State automatically takes the dimensions defined when initializing GameSystem. Rectangle draws colored rectangles. Tile draws individual tiles in a tilesheet. Wallpaper repeats a single image. SurfaceY is just a Surface that sorts (and renders) its children by y coordinate instead of zIndex.

By the end of the first day I had an ugly, playable prototype. By noon on Sunday I had a design and simple animations I was happy with:

One of the trickier elements of the design was the level numbers. Because of the perspective, the tens and ones columns require two different sets of numbers. I created a special LevelNumber class to properly render the text from a tilesheet containing numbers drawn in both perspectives.

The remainder of Sunday was spent rewriting PlayState to use the new Chunk class and integrate the graphics and complicated zIndexing and stacking behavior. The bulk of the game logic lives in the PlayState update method. Chunks, a subclass of Surface, are moved between different Surfaces (conveyor, stack, Chomplies and dying) and behave differently depending on which Surface they inhabit. Initially this was done as an easy way to manage Chunk zIndexes but ended up being really useful for implementing the behaviors unique to each section of the game board.

As an aside, in The Last Rocket, instead of subclassing subclasses of Surfaces and adding behavior I have an Entity class (which has a little less overhead than a Surface) that has one or more Surfaces. States then iterate over entities which are responsible for the behavior of their Surfaces.

If I had more time I would have liked to create some 8-bit tunes and sound effects to complement the graphics but HTML5 audio still seems to be a tricky proposition on iOS.

Ultimately, Ludum Dare was, again, a rewarding experience. Maybe once The Last Rocket and NoiseES updates are done I’ll port Data Entry Sentry back to iOS and finish it up properly.

The Last Rocket has been approved and is available now on the App Store! Check out the site for the trailer, some iOS wallpapers and (if you have Flash Player installed) a preview of the music.

Yesterday I twondered if there had been any developments in the browser space regarding linking directly to arbitrary elements. I wanted to link to a specific section of a page on a site I don’t maintain but that the author hadn’t anticipated linking to. The solution I proposed was a jQuery-like syntax for a normal CSS selector added to a url as part of the hash.

Then Eric Meyer pointed me to this proposal for Using CSS Selectors as Fragment Identifiers (co-authored by Simon St.Laurent).

Almost exactly what I was looking for but still just a proposal. So I put together a simple Safari Extension called CSSFrag that implements #css() selectors in url fragments (sans fallbacks). Then Laurian Gridinoc ported it to Firefox as a restartless extension (source). And then Lim Chee Aun ported it to a Chrome extension (source). Later, David Hasather ported it to an Opera extension (source). Progress!

Download CSSFrag for Safari, Firefox, or Chrome. Here’s an sample link to try once installed: Daniel Brown’s excellent Metroid Piano covers. (Note that attribute selector values must be quoted as well as URI encoded). The best part is that even if you don’t have the extension installed the link still works.

Author-designed versus User-designed urls

CSSFrags are not meant to replace more concise, author-designed urls. CSSFrags enable a site’s users to address specific sub-content that the site’s author may not have anticipated as being interesting. Think about user stylesheets and how they afford another layer of control above author-designed stylesheets. This was also the intention of the original proposal.

Caveats

Like normal fragment identifiers, CSSFrags may not be able to jump to an anchored element if the page is modified by JavaScript that causes the document to reflow or otherwise modifies attributes. Not sure if there’s a sensible solution to that problem.

Because CSSFrags might rely on content or specific document structure they are considerably more volatile than “normal” links. But, unlike a traditional broken link where a 404 results in missing content, a broken or unsupported CSSFrag only results in a loss of context, leaving the user to manually find the relevant element.

When I’m writing an @reply, it would be cool to know how many of my friends would be seeing it in their feeds.

Which reminded me of Eric Meyer’s Followerlap. So for my morning mental calisthenics I whipped up a simple JavaScript bookmark that allows you to check your reply reach before hitting the Tweet button.

Just drag this Reply Reach link to your bookmarks bar and give it a click the next time you hit that reply link.

Good level design coaxes a player into first discovering then utilizing their abilities in a variety of situations. It requires balancing revelation and repetition.

The first few levels I make are really about discovering and internalizing the bounds of the abilities at the player’s disposal. How many blocks high can be jumped? How wide a gap can be cleared? With a tap of the jump button? With a longer press? In Breathing Room, how many blocks can be traversed after inhaling? While jumping or dodging threats?

Subsequent levels look more at interactions of the various pieces. How do threats interact with each other? With the environment? How can these interactions limit the player’s movement and define a path through a level?

These experiments aren’t intended for play by actual players but are an essential step towards understanding how to best utilize the level design building blocks at my disposal. The initial challenges conceived during this phase will probably be too difficult to be included in the game as is (at least in earlier levels) but can serve as a good point to work back from and may even suggest small code changes to timing and physics.

With this rudimentary undertanding of the possiblies you can then identify specific lessons the player must learn to succeed. Breathing Room’s primary lesson being: inhale to slow down threats.

Once you have that the first few screens are easy. You limit peripheral information and place the player in a relatively safe situation designed to prevent them from proceeding until they have achieved a basic mastery of the desired skills. The following screens should reenforce these lessons with variations on the theme (see Auntie Pixelante’s excellent article about Super Mario Bros. 1-1).

This is where my process currently breaks down. How long should each level be? With what frequency do I introduce new concepts and threats? At what stage do single threat introductory screens become patronizing rather than educational? Repetition is necessary for learning but at what point does the lesson become too repetitive? That last one is especially difficult to gauge since Breathing Room’s game mechanic encourages trial and error and I’m playing each level (at least) twenty times more than the casual player ever will.

I have a feeling that trial and error is the name of the game from this point on and a hope that experience will eventually start answering those questions before the handwringing sets in.

This past weekend I participated in the 20th Ludum Dare, a 48 hour game making competition. I still consider myself a novice game developer with only one finished game to my name (with another on the way) so Ludum Dare was a great way to see how far I’ve progressed. This year’s theme ended up being a reference to NES classic The Legend of Zelda, “It’s Dangerous to go Alone! Take this!” I turned this into a Flash “game” called Breathing Room. (I’d recommend playing the post-Dare updated version now.)

In the week leading up to the competition the southeast US was hit by severe weather so I was without power for the latter half of the week—which was when I had planned to set up my development environment and get up to speed on the new Flixel.

On Your Mark

Upon hearing the theme late Friday night I developed 3 ideas (the client in me rejoices):

• Chibi Pan & Pup: Pan (the god, not the Peter) is stranded in Winter Cave and given a wolf cub to help him survive the trip back to Summer Wood. Pup can sniff out rejuvenating food and the omnipresent threat of less helpful, fully grown wolves in the whiteout outside Winter Cave. In this top-down game the player must find food to keep his strength up and avoid wolves while searching for each exit. Pup’s portrait in the HUD would change based on whether Pan is going towards or away from food. Music would change to indicate an approaching or receding threat.
• The Asthmathlete: A bubble boy is given an inhaler that grants him superhuman speed and reflexes (which in gameplay is represented by the slowing down of other entities). In this sidescrolling platformer, the player must navigate an impossibly fast gauntlet using the Asthmathletes unique power.
• Pogo Bass: A professionally trained (and sharply dressed) concert bassist uses his upright as a pogostick. Plucking each of its four strings produces a different offensive waveform in this sidescrolling metroidvania. The bass was given to him by an old man in a dimly lit cave. What.

After spending about three quarters of the first day working on the Chibi Pan idea I decided it wasn’t going to work out. I wasn’t sure the simplistic hot-or-cold mechanic would prove sufficiently interesting to carry a game. I also realized that I wasn’t going to have time to develop the maps to really explore the mechanic sufficiently. So around 6pm on Saturday I moved on to my next idea.

Get Set

Around this time I also switched back from Windows to OS X. Flash Develop really is a great tool but Windows 7 was actively working against me and the absence of Photoshop was killing me. I work and think best when tabbing back and forth between pixels and code. Initial attempts to get mxmlc playing nice with Xcode or TextMate failed so I ended up in a trial version of Adobe Flash Builder 4 for the remainder of the project. (Only much later did I realize that mxmlc was probably working fine. The problem was swfs were launching in one of the many out-of-date Flash Player apps the Creative Suite and others have littered across my harddrive rather than the current standalone Player I had just installed. Sigh.)

Getting up to speed on Flash Builder and Flixel was pretty painless. I quickly worked through the EZPlatformer example on Flash Game Dojo. AdamAtomic’s Mode was also extremely helpful when figuring out sprites, sounds, groups and emitters. I still don’t know why Flash Builder insists on highlighting every occurrence of a frequently changing and seemingly arbitrary variable name.

Go!

I spent a short amount of time in Photoshop to create some very simple assets for the player, various threats and level tiles (the video attachment of initial gameplay was added to Dribbble four hours later).

The bulk of my time was spent implementing the helpful “cross your heart and hope not to die” checkpoints and various threats like repeating horizontal and vertical darts, spikes, bouncing exploding bombs, the masher with its invisible trigger and flickering platforms.

I wrestled with DAME for a bit but never figured out a workflow for producing populated levels. I ended up manually editing a CSV of solid tiles and calculating threat and checkpoint positions manually for the final, sadly brief, working level.

The last three hours (especially) were a blur, writing and producing some music in GarageBand (the threatening, crunchy Breathless and it’s pluckier, Zelda-tinged counterpart Respite that plays after using your inhaler) and implementing the title screen. I guess at some point in these last hours I implemented the lung HUD too.

I was under the impression our games had to be submitted at the 48 hour mark and had it uploaded about 5 minutes shy of that window. Turns out we had a whole hour after the working 48 to upload. Gah.

Rematch

What would I do with more time?

• Multiple self-contained levels. Initial levels would introduce each threat in isolation (with plentiful checkpoints) before exploring their interaction with previously encountered threats (with fewer and fewer checkpoints).
• Additional threats like rising platforms (below spikes), falling platforms, rushing bolders, falling ceilings and rising floors.
• Additional abilities like exhaling to power peak flow meters that temporarily open doors.
• Better visual and audio presentation, including sound effects and a proper title screen/ending. Music shouldn’t restart when you die.
• Explore the development of rhythm as it relates to inhaling, level design and audio.
• Improved character physics. Jump control becomes increasingly important as you cluster horizontal and vertical threats.

All said, I’m proud of what I was able to accomplish in the short 48 hours. Flixel is a capable framework and ActionScript 3 was surprisingly easy to pickup (and luxuriously succinct compared to Objective-C). Once The Last Rocket is out the door I might even return to this idea and flesh it out into a full game.

I do this for a couple reasons:

• To keep track of games that I’ve heard great things about but never played. There was a period during college and a couple years after where I didn’t own any consoles. I missed out on some great titles and I’m still catching up. The Unplayed.

• To keep track of games that I’ve started (and may have been distracted from finishing). I’m playing more games lately as research and sometimes stumble across a game so good I forget about the game I was playing for pleasure. The Unbeaten.

• To keep track of games I’ve put down and why. The Beaten and The Abandoned. I’m human, I like specific genres (eg. jRPGs and metroidvanias) and repeating my mistakes (eg. any Dragon Quest game without Rocket Slime in the title).

To date I’ve maintained this list privately. I’m not looking for recommendations for the next game I should play or recognition for the games that I’ve played. Nothing turns me off a game (or show or technology or app) more than an unsolicited, vociferous recommendation. I’m backwards, I accept this.

For a couple years I kept this list in a text file on my hard drive. About a year ago I set up a Tumblr site and kept each category on its own page. Last week I switched to a simple system using PHP includes and Markdown files.

Last night Neven asked if there was a service for games similar to Goodreads. I shared my current solution and offered to zip up the files for him forgetting that our overlapping followers would also see the link and offer. A few of you asked for the files too so here we are.

Unplayed is just a single PHP file that includes a flat, Markdown-formatted file for each category of game (it uses and includes PHP Markdown and PHP SmartyPants by Michel Fortin). Lessn is simple, Unplayed is stupid simple. Like Lessn, Unplayed is offered as is with zero support—take it and make it your own.

Update Four days later Neven offered up some CSS tweaks for iPhone and I added a footer (again, feel free to make it your own). Just diff your index.php with the new one if you made any customizations (I use TextWrangler’s Find Differences for that).

Genesis

One of the last features added to Horror Vacui 2 was the Sound Test, a convenient way to listen to the four tracks included in the game. (The final addition was a Mimeoverse audio Easter Egg—there’s a hint on how to access it hidden somewhere in the Horror Vacui 2 mini-site.)

This Sound Test was the beginning of a simplified NSF player, something I had toyed with previously but abandoned because of the lack of individual track names in the NES Sound Format and the complexity of syncing your NSF collection (this was before iOS 3.2 which introduced iTunes File Sharing).

Super NSF

Then I stumbled across this post on ChipMusic.org which introduced me to NSFe. This Extended NES Sound Format includes track names and durations, and (when properly tagged) removes annoyingly short sound effects. Using what I had built for Mimeoverse and Horror Vacui 2 as a starting point and NSFe’s additions to the format I was able to create a dedicated NSF/NSFe player that was comparable in utility to Music.app (or iPod.app on an iPhone).

Mega Drive

NoiseES had a very short development cycle, about a week total (not counting the initial experimentation months ago). Most of that was learning how to wrangle Core Data. I pushed through quickly because I really wanted a portable NSF player—and I wasn’t even sure Apple would approve it (Sid Player did give me hope though). Right before submitting the app for review I discovered a crashing bug in the Playlists and Likes features and rather than prolong development of an app that might never see the light of day I cut both features and submitted. (I’ve since ironed out those issues so both should be back in the 1.1 update.)

Eventually I would like to add support for other Nintendo sound formats like SPC but first I need to find an appropriately licensed library for unarchiving .zip and .7z archives (unRar4iOS looks promising for .rar files). Maybe in 1.2.

TurboGrafx

NoiseES unapologetically riffs on Apple’s Music.app and the original Nintendo Entertainment System’s product design. It mimics Music.app’s behavior and appearance (with minute, usually pixelated, differences) wherever similar functionality is found. I tried to strike a balance between the native iOS controls and the oversized pixels and limited NES palette that I’ve been so enamoured with lately. As I originally quipped on Dribbble, the overall aesthetic “is a tangled homage to two of my favorite companies (or rather the companies responsible for some of my favorite products).”

You can imagine my pleasure when Neven Mrgan said:

Awesome. Your blend of iOS and pixel aesthetics is impeccable. I cannot pec it at all.

So if you still can’t get enough of the soaring squares, galloping triangles and staccato noise of 25 year old NES soundtracks NoiseES might scratch your 8-bit itch.