We Like Hard Games, So We Made a Hard Game (Thorn v1.0.2 is out!)

on 09/04/2011 by christopher No Comments
When I was growing up, if you claimed that you beat a video game, it meant that you were really REALLY good at it. I’m mostly talking about NES games, which required a ridiculous amount of skill to beat. It still sticks with me that I could never beat Ninja Gaiden. The story was really cool, and I wanted to see what happened. Two decades later, I watched the ending on YouTube.

Over time, quicksave and quickload almost single-handedly changed this. The way games like Call of Duty tend to be played, you can simply run into a volley of gunfire and die, reappearing moments before the events happened.

If a game costs 60 million dollars to make, you don’t want 99% of people missing out on millions of dollars of content because they aren’t good enough to get there.  I think it’s a shift in gaming culture that is worth our attention.

One of our first ideas for Thorn was that it should be prohibitively difficult. Matt had this idea during one of our very first brainstorming sessions years ago to make a cruel game. I think what he was picturing was a game where the traps in the dungeon are actually traps. They are concealed and they can cause permadeath. You were foiled by a trap, you are dead.

I don’t think Escape Mode, in the new version of Thorn that we just released is cruel, but I do think it’s pretty hard. It will take most people a long time to get good enough to see the ending screen.  My endless playtesting over the course of Thorn’s development has made me really good at the game and it’s even hard for me to beat. It takes about a half hour, a good amount of luck, and a tremendous amount of patience and skill. But that’s where we wanted the bar. If it’s hard for us, it’s going to be hard for new players. Those few who get very good at the game will eventually beat it. And you’ll see them on the leaderboards. Next to us.

Escape Mode is a .99c In-App Purchase. The original Survival Mode is now totally free.

Thorn v1.0.1 update — with Game Center support — now available!

on 08/05/2011 by matt No Comments

Awww, yeah. Git your leaderboards and achievements on.


Thorn update sent to Apple!

on 08/01/2011 by matt No Comments

The next Thorn update has been sent to Apple for review! Game Center, Leaderboards, and Achievements coming your way in a few days :)

Here’s a snap to whet your appetite:

How Things Are Going

on 07/21/2011 by christopher 1 Comment

Thorn has been out for over a week, and it has been exciting.

We prepared our toughest skin pre-release. I’ve seen what game releases can do to people, and it’s ugly. There are plenty of reviews and criticisms of games that I’ve read that are borderline soul-destroying. I mentally prepared myself to deal with utter rejection from gamers and reviewers. Luckily, that didn’t happen.

We’ve been well received. For the most part, I feel that players either fall in love with the game or level really fair criticisms at it. These criticisms tend to be:

1. Thorn needs Game Center integration. This is an easy one. We’re going to include it in the next build, which should be out in a matter of days.

2. Thorn needs more mobs. And this is a bit more interesting. Earlier builds of Thorn had tons of mobs with different attributes. Those days, the game didn’t include throwing weapons and it was way less fun. Now that we have ironed out a solid platform, we think it’s worth reintroducing these monsters. After the Game Center build, we’re going to start looking at how to integrate more enemies. Of course, this will probably thrash the legitimacy of previous high scores. If anyone has any ideas how to deal with this problem, we’re open to them.

3. People hate dying and starting over from the beginning. We’re talking about a way to deal with this. Perhaps there are checkpoints or multiple lives? Again, this threatens not only the balance of the game, but also the validity of previous high scores. Tough problems, but they can be dealt with.

As for sales, we think we’ve gotten lucky. The sales probably won’t come close to providing us with the kind of income we would have made if we’d been working at Jobs rather than making a video game. But that wasn’t really the point. Being included on Apple’s New & Noteworthy list was a huge gift and we think it put us on the map.

For our next trick: staying on the map.

Thorn for breakfast? Yes, please!

on 07/20/2011 by matt No Comments

Thorn gets a write-up on mobile app breakfast:

“Thorn has an ornery attitude, and that’s why we like him.” Us too :)


Thorn gets a review at 148apps!

on 07/19/2011 by matt No Comments

Thorn gets reviewed on 148apps.com, who calls it “A Simple Slasher.” Sounds OK to me :)

Kill zombies. Find the dungeon exit. That’s about it. This game is about the essentials: killing zombies and surviving.


Awesome Thorn Review from AppAdvice!!!

on 07/15/2011 by matt No Comments

We got a super-magical-fantastic-ZOMG review from Jamie Young over at AppAdvice.

“The graphics and music are great and the unique controls and gameplay tie it all together in a perfect dungeon slasher package.”


You can read the entire review here:
Kick Some Zombie Butt And Be The Last One Standing In Thorn: Zombie Dungeon Survival

Front Page of iTunes? That’ll Do.

on 07/14/2011 by christopher 1 Comment

We were featured today on the front page of iTunes under New & Noteworthy.

Thorn: Zombie Dungeon Survival on iTunes front page

This is extremely exciting! We won’t know until tomorrow morning what it will do for sales. But what we do know is that someone at Apple likes us. And that’s a really nice feeling. :)

Thorn trailer!!!

on 07/14/2011 by matt No Comments

Thorn walkthrough video

on 07/11/2011 by matt No Comments

A walkthrough of the first level of Thorn: Zombie Dungeon Survival

Thorn is now available on iTunes!!!

on 07/11/2011 by matt No Comments

Thorn: Zombie Dungeon Survival is now available in the iTunes app store!

Here’s a link to iTunes: http://bit.ly/mYxjsm

To give us feedback, feature requests, or bug reports, please check out
our forums.

Wooo!!! Go kill some zombies!!!

Thorn v0.6.5 is Out

on 06/13/2011 by christopher No Comments

This build mostly fixes a bug where walls wouldn’t appear, and adjusts the difficulty curve. It’s a lot easier now, with a more gradual difficulty curve.

– fixed Help screen flow from game start and in-game Pause help
– intercept app interruption (applicationWillResignActive, e.g., from an incoming call) to go to pause screen, so time doesn’t keep ticking down
– fixed race condition bug where Levels could get created before OpenGL textures were finished loading, resulting in nil SpriteSheets (floor and/or wall)
– fixed bug where hero projectiles couldn’t hit chests and crates
– added different-size app icons
– new projectile recipes: tomahawk, betterhawk, evenbetterhawk, bomb, cluster bomb, big red bomb, shrike, talon, phoenix
– added console support for selecting different projectile recipes (r [recipe], where recipe is b1/2/3, s1/2/3, t1/2/3, and d for default)
– changed mob random number formula, to range from 4-6 per room (beginning difficulty) up to 11-20 (max difficulty)
– lowered initial zombie move velocity (now 200 w/ +/- 100 jiggle), then ramp it up with difficulty (+50 * difficulty)
– sped up Hero swing — frames are each 25ms, so attacks arrive in 75ms (3 frames), and overall swing is 175ms (7 frames)

v0.6.4 of Thorn is Released

on 06/10/2011 by christopher No Comments

From now on, we’ll be posting our build changes publicly, for those interested. Version 0.6.4 is faster, harder, and way more intense than any other version. Also:

– new Thorn iOS icon
– new title screen with revised tagline: “Thorn: Zombie Dungeon Survival”
– new help screens
– don’t allow zombies to overlap completely. Reduce physics shape radius, but disallow physics shape overlap. Tweak visualBottomOffset to reduce visual wall penetration.
– tweaked how tapping on zombies/chests/crates works, to hopefully avoid selecting the wrong zombie in HTH combat
– reduced Thorn stun time from 500ms to 200ms, so you don’t getting totally mugged by a zombie pack
– new projectile sprites: tomahawk, shuriken, bomb
– different pickups for each projectile type
– changed “DEFAULT” missile name to “TOMAHAWK”
– increased radius around hero that responds to “go into throw mode”
– reduced delay for throwing (from 800ms to 400ms)
– add fading light(s) under finger when touching the screen
– fixed lighting position bug, for small/medium lights, such as under projectiles
– tweaked offset for exit stairs trigger
– clean up wall tile dark edge in dungeonTileset
– deal with people sometimes “missing” the pause/options button and closing the pause screen: eliminate touch on bg closing of screen; add invisible button over pause area from layer beneath
– new text buttons (Start, Help, Back, etc)
– sprinkled in more help quotes for level loading

Thorn is Getting Done

on 06/08/2011 by christopher No Comments

The game is nearly done. With any luck, we should be shipping to Apple within the next week and a half.

There are all kinds of changes in the last few builds, but the biggest change is the overall intention of the game. Thorn is now a survival game with a high score. You play until you die, and you always die. It works well this way, as the player can commit small chunks of time to the game and then put it down. And go outside. This has prompted a name change from ‘Thorn and The Dungeon of Bad’ to ‘Thorn: Zombie Dungeon Survival.’

Matt also implemented a really nice isometric lighting system with lit wall sconces and movable lights for projectiles and the hero. Here’s a screeny with lots of zombies and the new lighting:


Thorn for iOS with isometric lighting

Projectiles are hugely important in the current version of the game. So we now have support for different projectiles. Thorn can throw shurikens, bombs, and good-ol’-tomahawks. They have different behaviors, including AOE. This also gives us the ability to dream up new projectiles and add them to later versions of the game.

An interesting thing about this phase of development is that we have no idea how difficult the game is. I like to brag that I’m the best Thorn player of all time, which is currently true. I mean, I’m really good at Thorn. But that makes it all the more difficult to determine how easy the game is. Developing and tuning a difficulty curve is no easy task.

Also, today I’m trying to finalize the app icon for the iTunes store. This is pretty daunting, as your icon has a lot to do with how many copies of the game you sell. Here’s the current version:

iTunes store icon for Thorn

Sure, it uses the trite rays-of-something motif, but at least that makes it pop, eh?

A Tree Made of Books

on 04/27/2011 by christopher No Comments

Another side project I’ve been working on recently is a tree made of books.

I built the thing in XSI by first sculpting a basic tree. Using some reference material (Google image search), I built a tree out of polygon cylinders. And not a terribly detailed one.

I then modeled a simple book. For each book in the tree, I took that first model and adjusted the proportions. By the time I stacked a tree’s worth of books, there were 1,200 of them.

This thing will probably end up on some tshirts once I clean it up a bit. I also have a short animation in mind.

In the meantime, enjoy this gigantic animated gif: (you have to click and make it big to get it movin’).


Another XSI Render from Upcoming Art Project

on 04/11/2011 by christopher No Comments

I recently met a solid graphic designer who works extensively in screen printing. We decided to collaborate. I’m building a 3D model of a robot that he illustrated, and he’s going to help me trace and screen print a really ridiculous idea of mine.

Here’s a work in progress render using the Toon_Ink_Lens camera lens in XSI:

I’m sure it’s not obvious, but this is my interpretation of Molloy from Samuel Beckett’s terrific trilogy. My intention is build one scene from each of the three novels. This is only the first, and the source of the bicycle model from an earlier blog post. I’m not sure exactly where this is going, but hopefully it will be funny…

Adding High Scores to Thorn This Week

on 04/08/2011 by christopher No Comments

We’re implementing V1 of our high score system this week…

3D Bicycle Render for Upcoming Side Project…

on 04/05/2011 by christopher No Comments

“They say his 3D modelling skills grew three times that day…”


New Zombie Mob!

on 03/23/2011 by christopher 2 Comments

Everyone loves zombies these days. Zombies zombies zombies. I mean, seriously, I’ve thought about how easy it would be to write a PhD dissertation on zombie fascination as an organic byproduct of contemporary society. Everyone thinks their consciousness is unique, and that their existence on earth is somehow singular. Solipsism is really natural, and zombie daydreaming gives us an outlet to exercise those ideas. In a zombie apocalypse, your singular nature would be actualized.

I digress…

We decided that it would be fun to have hordes of one-hit-kill mobs in our game. But our current mobs didn’t quite fit the bill. Most of them had spears, and swords, and seemed like they should be able to put up a fight.

Violating every good instinct that I wrote about having two days ago, I decided to sit down and model, texture, rig, animate, and render a new mob before testing the swarm mechanics inside of the game. Because I’m just that motivated to think about zombies.

One day of 3D production resulted in this cute little guy:


Sorry about the crappy anti-aliasing. He doesn’t appear like that in the game, but I didn’t know how to optimize the .gif to remove it.

Defining Core Gameplay in the Fourth Quarter

on 03/21/2011 by christopher No Comments

(I spend a lot of time in this post getting around to the point that you should prototype your game ideas. You can skip all that stuff and read the ADHD-friendly bullet points at the bottom, if that’s what you’re into.)

We’ve made a lot of mistakes in the production of Thorn. Nothing shocking there. Neither of us had ever even worked on a video game before. Mistakes were inevitable. Now, months into the project, we’re staring one big ugly mistake in the face.

Call it a nugget, a core, or just “the thing that makes the game fun.” We didn’t get that thing working when we should have–when we started. It actually wasn’t until the game was in its fourth quarter of development that we realized just how deep this problem ran. We met a lot of cool people at GDC recently and had them play Thorn. “It runs really fast,” or, “the art looks great,” or, “the controls are smooth,” they might say. But no one was sold. A common complaint was that there was no hook, no reason to keep playing. It just wasn’t compellingly fun. Having a pretty game that isn’t fun is a hell of a lot like having no game at all.

This is one of those lessons that someone can tell you, but that you probably have to learn for yourself. It’s like having your parents tell you who you shouldn’t date, or to do well in school. Take a look at any wise blog post from a veteran game developer who discusses the steps necessary to make a quality game. Here’s what their post will absolutely, certainly NOT say:

1. Get a really neat idea for a game that sounds cool in your head.
2. Produce a bunch of art assets and code just like you pictured it.

There’s a massive step missing, and that’s the part where you prototype your idea until something is satisfying about playing the game. I’ve gotten so burned by this that the first thought that pops into my head anytime someone mentions a compelling game idea is, “cool, why would that be fun?”

And perhaps this should be in everyone’s head when they’re in the pencil and paper stages of game development. A case to illustrate this point: This weekend, I was sitting in a cafe when I was approached by a young gentleman who wished to share his enthusiasm for games with me. His first topic of conversation was this flash game he liked where, he explained, the object was to:

  • Shoot guns and drive cars
  • Cut off a cop’s head and steal his motorcycle
  • Get the thing
  • Pick up your girlfriend
  • Go back to the safe house
  • (But the safehouse is full of guys, so) Kill the guys in the safe house

He told me that he wanted to learn ActionScript so that he could make his own flash games. Sweet. What games would he make? “I would make games where you could robs banks and kill cops and stuff.” Equipped with (give or take) 8 months of game development experience, it’s easy for me to listen to his gruesome game idea and realize that it’s not a game idea at all. That’s not a game, that’s a plot. And yet, we made roughly this same mistake with Thorn.

It’s not enough to know that your game will be isometric, that it will have dual-analog controls, that it involves hand to hand fighting, powerups, and missiles. These are ideas, but they don’t define the nugget of fun, the thing that makes the game good. Unfortunately for all of us, the thing that makes the game fun is a rich and carefully balanced soup that involves everything from on-screen feedback to jump durations and collision shapes.

I recognize that I run the risk of repeating ubiquitous advice here, but if we were to start Thorn over from scratch today, one thing we would certainly do is prototype.


  • Vetting Your Ideas. The Adventure of Red Square and the White Circles can prove your gameplay concept as either flimsy or compelling. By prototyping your game, you can find out more quickly if a hybrid RTS and SHMUP would be fun, or stupid.
  • For God’s Sake, Don’t Waste Your Time Producing Assets. It took us quite a while to realize that this applied to both code and art assets. Having a fully working, implemented, modeled and rendered object in your game that isn’t fun is a waste of everyone’s time. Get it fun fast, and then expand on it. Having a meeting and deciding that, “we’re pretty sure we’re going to want enemies to hatch from Pterodactyl eggs with cool looking spec maps” is not sufficient to start the production work.
  • Agreeing as a Team. Your team probably has all kinds of words for various game concepts, but you won’t know you’re talking about the same thing until you play it. Having a game in hand makes it a lot easier to point at specific things that you like and talk about them. The same can be said for playing a lot of games similar to the one  you’re working on.
  • Limit Your Scope. Remember when you used to cut your own hair and inevitably one side would be shorter than the other, and then you would keep cutting the longer side until you eventually cut your head off? Working on a game that isn’t fun at its core is a lot like this. Adding yet another thing to the scope of the game won’t suddenly make it a rewarding experience, I promise. Grand Theft Auto 4 has a robust gameplay experience, but you’d turn it off immediately if it was frustrating to walk around, or drive the cars.
  • Define What’s Necessary. As the production artist on the team, this is my favorite part of having an in-hand prototype. Working on stuff that might not make its way into the game sucks, but knowing exactly what the game will consist of allows you to conceive of things as a whole. Not only that, doing things once means spending the time to get them right.

Crunchy, Doomy, Trippy, Apocalyptic Dungeon Music

on 03/03/2011 by christopher No Comments

I’m finally sharing some iPhone game music from Thorn:

Audio clip: Adobe Flash Player (version 9 or above) is required to play this audio clip. Download the latest version here. You also need to have JavaScript enabled in your browser.

This mp3 is roughly mastered so I could send it to the friendly Winnitron folks to have it play over the console during GDC. Unfortunately, I sent it too late and wasn’t able to make my doomy mark on the conference.

This is one of my first attempts to bridge chiptune stuff and the music I actually prefer to make. As such, it has sampled live drums and guitar. I’m not super interested in chiptunes for the sake of chiptunes, but I allowed myself to borrow inspiration from the lo-fi style. For the most part, this means two things:

  • I did use some 8 bit VST instruments for the keys.
  • The better part of the lo-fi stuff is actually recorded live and then the bitrate has been crushed.

Beyond that, it’s business as usual for me. Layer up, and then remove.


And so it was

on 02/18/2011 by matt No Comments


And so it was that THORN, great warrior of notably short temper, found himself imprisoned.

Locked at the very bottom of the evil Lord Evil’s dank dungeon, Thorn had but one desire:

To escape the Dungeon of Bad, and have his REVENGE.


Building a Good Combat Control System on iOS

on 02/15/2011 by christopher 1 Comment

For the past few months, we’ve been paying tons of attention to every combat game (dungeon crawler / fighter) we can find on the App Store. Playing these and testing our own combat mechanics have taught us quite a lot about what makes combat fun on iOS. If I were to distill my learnings into golden rules, they’d look something like this:

Don’t Spread Out Your Buttons. Many games (even good ones) place special moves on the top bar of the screen, away from where your thumbs are most often controlling the action. It sucks to have to search and find a power attack when you need it. If buttons are big enough and organized intelligently, they can all be within close reach of your right thumb.

Five Buttons is Too Many. Not including a joystick, four buttons should be considered the absolute ceiling before things get frustrating. Especially if they’re too small or poorly laid out. Two or three buttons is plenty, considering:

Buttons Should Do More Than One Thing. iOS recognizes various gestures that can be used to expand the functionality of a single button. Swiping the joystick can cause a dash. Holding an attack button can trigger a more powerful move. Swiping an attack button in various directions can trigger different directional attacks. Your iPhone is not a console controller, and shouldn’t be approached as if it were.

Buttons Should be Context-Sensitive. With all this talk of screen real estate, keep in mind that irrelevant buttons can be hidden. If you can’t do something, the button for it shouldn’t be visible.

Blocking is Almost Always Dumb. If your game is a side scroller, tapping backwards can be a shortcut to a pretty cool blocking system. Devoting the screen real estate to a block button is almost never a good idea. We’ve tried block buttons with various functionalities, and witnessed our playtesters ignore all of them. Which leads me to my next point:

Dodging is More Fun Than Blocking. Always.

Buttons Should be Bigger Than They Appear. The visual on-screen button should be smaller than the responsive area. Compensate for human error.

Perils of Indie Game Concept Art

on 01/27/2011 by christopher No Comments

I’ve been thinking a lot lately that my brain is better wired for ADSR than CMYK. That is, I’m probably more inclined to make music than visual art.

I like making visual art, a lot. I’m also partially colorblind and not wildly talented as an illustrator. It could be argued (and I wouldn’t deny) that I simply haven’t put in my 10,000 hours of practice.

So when it comes to making art for Thorn, I often need to develop the workflow in tandem with making choices about how we want stuff to actually look. This is woefully less efficient than say: 1) Knowing what you want and then 2) Getting someone who knows how to do it, to do it.

Here’s what I’m getting at: We’re working on developing a style for the screen flow in Thorn. That is, non-gameplay artwork that goes into the game. The pause screen, the options menu, the GAME OVER screen, etc. A lot of the genesis of Thorn conceptually has been various old-school nerdfare like D&D, fantasy art, and roguelikes. So, we came up with the idea of making these screens look like 70s pulp fantasy art. Like, say, this.

Initially I thought this could be done by just taking a 3d render (since we already have 3d models of all the important characters) and doing some clever photoshopping and comping to make it look hand painted like that retro fantasy art. Unfortunately, I’m not talented enough ‘in post’ to keep that from looking like Neat Photoshop Filterz, brah.

And so I’m still working to develop a pipeline for delivering this style of art. Here’s something that’s on-its-way. This is a 3d render, hand painted in Photoshop and then the painted layer is multiplied onto the rendered layer. In a nutshell.

Indie game concept art for Thorn Click to enlargenate. I’ll post more as my process continues to develop.

TestFlight rocks

on 01/26/2011 by matt No Comments

We recently switched to using TestFlight to distribute our iOS betas. Thus far, it has completely kicked ass.

Previously, Christopher used to refer to syncing the new build through Dropbox and iTunes as BOSP : Beginning Obnoxious Sync Process. Now with TestFlight, he syncs directly to his phone. This is a huge time- and pain-saver. BAM, I say. BAM!!!

Further, TestFlight does the work of sending a notify email to your testers, along with notes of what’s changed in this build. Yay x2.

TestFlight identifies the build version from the [app]-Info.plist’s Bundle version (CFBundleVersion). Before building and uploading the [app].ipa for TestFlight, I use a simple bash script to update CFBundleVersion like so:

# Auto Increment Version Script
cd ~/src/Thorn
CFBuildVersion=$(/usr/libexec/PlistBuddy -c “Print CFBuildVersion” $buildPlist)
CFBuildNumber=$(/usr/libexec/PlistBuddy -c “Print CFBuildNumber” $buildPlist)
CFBuildNumber=$(($CFBuildNumber + 1))
/usr/libexec/PlistBuddy -c “Set :CFBuildNumber $CFBuildNumber” $buildPlist
CFBuildDate=$(date +%d/%m/%y-%H:%M:%S)
/usr/libexec/PlistBuddy -c “Set :CFBuildDate $CFBuildDate” $buildPlist
# set Bundle version, which is used by TestFlight
/usr/libexec/PlistBuddy -c “Set :CFBundleVersion $CFBuildVersion.$CFBuildNumber” $buildPlist
echo “New build: $CFBuildVersion.$CFBuildNumber $CFBuildDate”


Wood iPhone 4 Replacement Back from JackBacks

on 01/24/2011 by christopher 1 Comment

Cracked iPhone 4

This is a picture of the back of my iPhone. Not that it happened recently. My phone was shattered while filming a really fun riot. The San Francisco Giants won the World Series and everyone decided to have a party in the streets. Fires were lit, and everyone was being generally merry if a bit destructive until the riot police decided to break it up.

Watch the phone being knocked out of my hand and broken here, if you want to.

Anyway, I decided it was time to move on and get a replacement back for my iPhone 4. I’d considered getting a wooden case for my previous iPhone 3G, and the idea was still lingering in the back of my mind. Luckily, I happened upon JackBacks. The company is run by a friendly maker named Adam who hand builds each replacement wood iPhone 4 back.

He also laser etches them, if you provide the design. So, I just had to do it. Here’s my shiny new Good Controller iPhone 4:

And cheers to Adam. He was super friendly, and he did great and fast work.

New thorngame site!

on 01/17/2011 by matt No Comments

thorngame.com is now live!

This is our “Thorn iz a game and u can eventually buy it goodie goodie” product page. Check out Christopher’s cool renders.


Granular Synthesis and Kittens

on 01/14/2011 by christopher No Comments

I had a little extra boost coming into this week from meeting a hero of mine last Sunday. A buddy got me into a Q&A with Trent Reznor and Atticus Ross at LucasFilm.  They were talking about the music in The Social Network. I got lucky, in a sense, because they also talked quite a bit about the mixing of the sound in that film–which was something that really caught my ear when I watched it.

One of the things that makes The Social Network a surprisingly watchable movie (even if you don’t give a shit about Facebook or startups) is the sound and pacing. It’s a quick movie, in terms of editing, and it’s bold in its approach to sound mixing. The music is quite loud in several scenes. Partially because the music is so good, it gives these scenes an extra gravity and difficulty that makes them really rewarding. In the club scene, the music in the club is loud. Go figure. But the effect is wonderful. Sound mixing in (mainstream? American?) film has gotten to the point where you hear the burning of the building, the dropping of bullet casings, dialog and the background music at about the same level–and it’s all extremely compressed. This serves a certain purpose, I suppose, but I liked the freshness with which Fincher and team approached sound in the film. It made me wish Daft Punk was playing a whole lot louder in Tron Legacy.

And so but anyway, Atticus Ross isn’t such a comfortable public speaker. When asked about how a certain track came to life, he mumbled something about it starting with Trent Reznor bowing a cello and then running the samples through a granular synthesizer. I think he prefaced this by saying, “without getting too nerdy about it,” but it was just nerdy enough for me. I started my week by learning how to use a granular synthesizer.

Check out Wikipedia for a decent article on how Granular Synthesizers work. In short: they make a transposable soundscape out of pre-recorded samples by breaking them into little pieces first. I spent a few long hours this week taking recordings of motorcycles, singing yogis, and purring kittens and making long, low, rumbling atmospheric sounds out of them. Thanks Atticus! It really proves that all cool sounds are worth recording, even if you don’t know how they’ll ever get used.

Also, after the Q&A I ducked out of the theater after Mr. Reznor and stole a few words with him. He was a really good dude and happy to talk to me. Hero status upheld.

A Thorn Retrospective

on 01/07/2011 by matt No Comments

As we move into 2011 (zomg), we thought it’d be interesting to post a retrospective of Thorn screenshots since inception, just to see how much mental terrain the game has gone through. It’s come a long way since its first pen-and-paper version :)

Early Thorn sketch
“bombtrack started as a sketch in my notebook”

Early Thorn sketch
First version on the Android, 2D tiles. Placeholder sprites borrowed from some mayday dwarf fortress sets.

Early Thorn sketch
Outdoor terrain. Note the cows.

Early Thorn sketch
Experiments in construction paper and shadow overlays.

Early Thorn sketch
Everybody loves Link. Now sprites can turn left/right, and scenery is multi-level/tiled.

Early Thorn sketch
Orthographic projection and onscreen controls.

Early Thorn sketch
Crappy shadow effects.

Early Thorn sketch
Megaman! And some new tilesets.

Early Thorn sketch
Pixel-art thorn, and some rock experiments.

Early Thorn sketch
Thorn moves to the iPhone. I don’t remember whose minotaur sprite this was.

Hand-drawn animated sprites. Also, traps.

Early Thorn sketch
3D models, although still on an orthographic projection.

Thorn goes ISO.

Early Thorn sketch
New 3D ISO tileset.

Early Thorn sketch
Thorn circa 01/01/2011.

Cranking Out Dungeon Stuff

on 12/02/2010 by christopher No Comments

This week I’ve been cranking out stuff that goes in the dungeon. We’re going to try to finish Thorn by Christmas with just the first Zone and then finish the rest in further expansion packs.

This week I made: retractable spikes in the floor, exploding barrels, destructible doors, collapsing crates, and a sweet monolithic rune:

I’m getting pretty sure that this game is gonna be awesome.


Good Ol’ Thorn iPhone Game Development Updates

on 10/08/2010 by christopher 1 Comment

The lack of blog updates doesn’t mean a lack of game updates. Here’s what we’ve been working on lately:

1. Matt had a great idea to use the Tiled map editor as a level editor that maps mob placement, triggers, and physics. We’ve been working on coding in this functionality. Luckily, iTunes now lets you drag documents directly into your app. So we now have the ability to quickly test levels by building them in Tiled and syncing them to the app. Right now level editing, collision and mob placement works. Eventually, we can do cool things like triggering sound effects and traps from the level editor as well.

2. I’ve developed a very easy pipeline to get isometric tilesets out of XSI. I made a 3D dungeon scene that’s already laid out to render working tilesets. It’s now as easy as modelling a new object on the grid, UV mapping, throwing on a material and rendering straight to PNG. I can immediately toy with the new tile in our map editor and make see how it works. What this means is, this is the first Thorn screenshot without any borrowed placeholder graphics:

Screenshot of isometric tileset from XSI working in-game.

I’ve been toying with the idea of recording a video of my workflow for rendering isometric tilesets from XSI. I’m quite sure that there are better methods, but so far this has been working really well for me. Also, crafting 3D renders into 2D isometric worlds fills me with all kinds of satisfaction as a huge fan of the early Fallout games. I’m a big fan of this process from an artistic perspective because it allows for so much control of the final product.

3. Physics tweaking. We’ve been using the Chipmunk physics engine and trying to get satisfying movement and attack from it. I’m sure Matt will eventually post more on this subject.

4. Sound stuff. I’ve been saving a lot of the music and sound production for later in the development process. Mostly because I don’t think we’ll know exactly what we need until we determine what will make the cut and what won’t.  I’ve been making a master list of SFX and possible redundancies. Any time we can use the same sound twice, it helps to save space. That said, I want the sound atmosphere to seem lush. In a 2D world, it seems a deep soundscape and some cool light will make all the difference.

Tennis Dice Game

on 09/04/2010 by christopher 2 Comments

Thinking about video games a lot over the past several months has gotten me thinking about game mechanics in general. What is it that makes a game good? Or that makes it fun? I play a lot of dice and cards in public parks and airports and such. I’ve been upset with the lack of strategy in the dice games we play. I think this probably has a lot to do with the medium. Strategy comes easier with cards and games of luck are more natural for dice.


I decided I wanted to make a dice game based on the principle movements in tennis. That is, you’re standing someplace and you hit someplace else. Perhaps the game I came up with is a bit closer to Atari Pong than the rich complexity of tennis, but so be it.

Here goes, the tennis dice game:

The Basics:

- One player serves at a time and continues serving until a game is won or lost.
- A game is scored like classic tennis (0, 15, 30, 40). You must win by two, like tennis. There are sets of 6 games.
- All rolls are of three dice. There will usually be more dice placed on the table to represent where players are standing and where the ball is being directed. So, you’ll need at least 5 dice.
- The basic premise of the game is that you choose a die from your roll to indicate where you’re standing on the baseline (1-6) and another die for where you’re directing the ball.
- When returning, you need to choose a die from your roll that corresponds to where your opponent directed the ball (to receive it), and another die for where you’re directing it.
-  You can receive balls that are directed away from you with two of a kind and you can hit balls that will be harder to return with two of a kind.


- The serving player rolls three dice. They must roll a 1 or  2 in order to serve. If none of the three dice are a 1 or 2, it’s a fault. They serve again. Two faults results in a point for the other player.
- The 1 or 2 represents the player standing behind the baseline on their side of the court. If you wanted to, you could have them roll a 5 or 6 on alternating serves to mimic a tennis player serving from Ad and Deuce courts. But, that would be stupid.
- The serving player places the 1 or 2 directly in front of them, and another die directly in front of it. The dice that are placed in front of the 1 or 2 indicate where the ball is being directed. If they have a two of a kind (3,3 or 5,5 etc.) they can place both dice directly in front of their 1 or 2. Two of a kind will be harder to return.
- At this point, the serving player has two or three dice sitting in front of them. It would look like 12, 11, 25, 244, 211, etc.

Receiving the serve:

- In order to receive a serve, the opposing player rolls three dice.
- At least one of these dice has to be the exact same number sitting at the front of the serving players stack, or one to the right or left. For instance, if the serving player has a 1 to indicate they are standing at the far end of the baseline, and a 6 in front of it, indicating that they are directing the ball to position 6, the returning player must roll a 5 or 6. If it were a 3 in front of the 1, they could roll a 2,3, or 4. In this way, 1s and 6s are the hardest serves and hits to return.
- If the serving player had rolled two of a kind, the returning player needs to roll a matching two of a kind. For example, the serving player has 144 in front of them. The 1 indicates where they are standing, and the 44 is a powerful hit. The returning player needs to roll two of a kind with 3s, 4s, or 5s to return it.

Returning serves (and playing all of the following hits):

- As we’ve already covered, the receiving player must place a number in front of them to indicate where they’re standing. They may have to place two numbers in front of them if they are returning a two-of-a-kind serve.
- They must choose a die from the remainder of their roll to direct the ball back to their opponent.
- It is to their advantage to choose a number that is not where the server is standing. There are two scenarios here.

  • If they have no options and have to roll a number directly next to the server, the server only has to roll another number around that die. Again, this means the exact same number or one to the right or left. So, if the server is standing at 1, and the receiving player places a 1 at the front of the stack, the server only needs a 1 or 2 on their next hit to receive the ball.
  • If they can hit a number that is not the same as the server’s standing position, the server will have to roll two of a kind that correspond to a position directly around that space. So, if the server is standing at 1, and the ball is hit to a 6 position, they must roll two 5s or two 6s to return.

The rally goes on until someone doesn’t return the hit.

A good variation is to widen the area of response. In this modified situation, a 3 can be returned by anything between 1 and 5. A 6, by anything between 4 and 6, etc.

IsoThorn + visualized physics

on 08/30/2010 by matt No Comments

Two matters of excitement:

* Thorn is now isometric, via isometric map tiles and rendering. This looks dope, and goes better (I think) with the look and perspectives of our model-generated sprites.

* We have the ability to visualize our physics, via a simple collision shape rendering overlay. This keeps me from going batty when weird collision effects start happening.

Thorn’s physics are implemented on top of the excellent Chipmunk Physics package: http://code.google.com/p/chipmunk-physics

OpenAL made easy

on 08/30/2010 by matt No Comments

Big kudos to Karl Stenerud for writing ObjectAL, a clear and pleasant API over OpenAL for iPhone: http://kstenerud.github.com/ObjectAL-for-iPhone

We’re now using this for the sound effects and background music in Thorn :)

Additional badass

on 08/26/2010 by matt No Comments

A couple of posed models as followup, showing off the humanoids.

Mob Menagerie

on 08/24/2010 by matt No Comments

I’m stealing Christopher’s thunder a bit, but here are the latest renders of the super-awesome mob models he’s been working on. Please note that monsters are not [yet] to scale :)






kick ass!

8-Direction Sprites

on 08/21/2010 by matt No Comments

8-D twitchy Thorn lives. Apologies for the shitty screencap.

XSI to SpriteSheet Workflow

on 08/20/2010 by christopher No Comments

Well, it works. Finally.

I’ve developed a workflow for getting workable spritesheets from XSI into our iPhone game engine. I’ve already spotted a few areas where this could be optimized. It’s currently a many-step process. In case you’re interested:

1. I set up 8 orthographic cameras in XSI and a render pass associated to each. They are configured to export every fourth frame so that we don’t have unruly 40 frame walk cycles. What’s nice is that I can go into each scene in XSI and render all of the passes. The render pass has to add a couple of zeros to each file name before the frame number because of some necessary alphabetizing that happens later.

2. OK, so now I have 80 PNG files for, say, a walk cycle. (10 frames per each of the 8 directions the character can face). In Photoshop, I import these into a stack which dumps each PNG into a separate layer.

3. I then run a basic Photoshop script to organize these layers alphabetically.

4. Since the final script takes layers from bottom-up, it’s necessary to to run Layers -> Arrange -> Reverse.

5. Now, I open the Animation editor in PS and ask it to add an animation frame per layer.

6. Finally, I run the RA Animation Exporter. This thing is rad. It takes each animation frame and makes it into a cell on a sprite sheet. Also, it automatically makes the canvas size the lowest possible power of 2–which is necessary in OpenGL.

And that’s it. A short post, but hopefully helpful to other people who need a similar process. Feel free to comment if you have questions about any of the steps, I’d be happy to help.

Another Quick 3D Update

on 08/04/2010 by christopher 5 Comments

We’ve been kicking around the idea of texturing our 3D models with colored pencil sketches. My motto w/r/t art is generally “start with the kitchen sink.” Don’t try to inject character into something at the polish phase, make it cool from the ground up.

So, I took the colored pencil sketch from yesterday’s post and used it to texture the 3D model from yesterday’s post.  The texture stamp was powerfully ugly–I overused the hell out of the clone tool in Photoshop. But I wasn’t too worried since it was only a proof of concept.

Anyway,  I think it works.

The next big step for me is developing a good workflow for going from textured / animated 3D object to sprite sheet. I’ve been looking at SpriteWorks 2, but I don’t know exactly how well it will work with models from XSI. And I don’t really want to throw $50 at it hoping it will stick.

If anyone has a good workflow for 3D -> 2D spriting, I’d be super happy to hear it.

Update On 3D Game Art

on 08/03/2010 by christopher 3 Comments

I mentioned previously that I was ingesting an unholy amount of 3D learnin’. Well, that didn’t stop.

At this point, I’ve done basic tutorials and practiced modelling, texturing, unwrapping, rendering, lighting, rigging, enveloping, and animating. I don’t even want to know how long I spent watching tutorials, but I think at this point I’m up to about two solid college semesters of 3D art. And it sure was a lot cheaper than college.

One important thing I learned is that the rotoscope tool is your friend. 3D artists always talk about reference material as being primary to their work. And you can see why once you start working on something with no reference. It’s incredibly difficult to pull character and depth from thin air.

I asked Matt to draw me Thorn a la ‘The Vitruvian Man.’ I wanted to have a working rotoscope reference and try my hand at modelling a version of Thorn that might end up appearing in the final version of the game. I had done 2 different version of Thorn in 3D previously, but they both came out far too lousy to be posted here. Although I was proud of them at the time, I was so early in the learning curve that there was a lot of exponential improvement to be gained.

So, here is Matt’s ‘Vitruvian Thorn,’ which I centered and modified in Photoshop slightly:

Character Reference art for Thorn--the iPhone game.

And here’s the 3D Thorn that came out of two days’ work:

Here, he is subdivided two levels. Since Thorn isn’t a 3D engine, we’ll need to sprite the final polymesh anyway. So it doesn’t matter how many triangles the actual polymesh has. As for problems, there are a few:

  • Thorn’s head is so big that he can’t lift a sword above himself without leaning way back–like he’s about to fall over. This might be fine, he’ll just be more histrionic.
  • There are very few horizontal vertices across his pecs. This means his torso doesn’t crunch very well.
  • His legs are really stubby and bow-legged. This makes walking animations a little bit goofy. (Once I make a few improvements, I’ll post walking animations to Vimeo).

I Spent Way Too Much Time Learning 3D This Week

on 06/26/2010 by christopher No Comments

Seriously.  Holy hell, I spent so much time learning 3D modeling over the past 5 days. I literally see vertices and scaling points when I close my eyes. But that’s only at night or in the morning, so it’s not so bad, eh?

Well, Matt’s on vacation in Hawaii. So production on the game has shifted gears for the next few weeks. He’ll be sipping from coconuts and drawing concept art while I produce some music for the Alpha build. Since that doesn’t take three weeks, I decided to teach myself how to model in 3D in the meantime.  Yeah, in three weeks.

My first step was to ping my old friend Chris Bott, who has been doing modelling for a while. Chris is a good guy to have on the Gmail chat list because he’s likely to also be sitting in front of his computer working really hard on something. Currently, he’s trying to get an animated movie produced. I asked him what program to learn first and he told me to learn Autodesk Softimage XSI. Apparently, ‘Softimage’ rhymes with ‘loftcollage.’ Don’t ask me why.

Anyway, I attained the program and about four hundred billion hours of training tutorials.

The first useless tutorial showed me how to build an ‘ancient temple’ which was secretly a ‘crappy gazebo.’ It took about 20 minutes, but it helped to learn the really basic stuff. The next series of tutorials showed me how to build a complete swiss army knife with every attachment. It took about 2 days to finish this. Corkscrew, screwdriver, knife, magnifying glass, etc etc. My morale fluctuated pretty dramatically throughout this enduring trial. As one might expect. When you listen to the same dude telling you how to do something for two full days, you get really familiar with his voice. My buddy was going through the tutorial as well and he would flinch every time the instructor’s voice cracked.

I’m nowhere near done with all of the tutorials I got, but I decided to take a break and model a version of Thorn from some concept art. This took another two full days (Chris Bott managed to slap a model of Thorn together in about 10 minutes). I’m pretty happy with how it came out, all things considered. I’ll post images of it soon.

Game development workflow

on 06/15/2010 by matt 2 Comments

One of the things I’ve thought a lot about during my years as a programmer is how to build software well: with what process, methodology, testing, order, etc.  Some people go crackerjacks about this stuff, and spend all their spare cycles arguing the relative value of scrums and kanban.  I’m not particularly interested in religious wars, just in having a good time making software and not being stupid. 

Since I’ve written lots and lots of software, but very few games, I thought it’d be interesting to document my ideas about one possible “good” development workflow for computer games.  YMMV :)

Start on paper.  If you can’t do it on paper, you probably can’t do it on the computer, either.  Working on paper is lighter, faster, and cheaper, and is a necessary precursor to achieving “finished” ideas.  Aka “your notebook is your friend.”

Start with the higher-level concept of the game and gameplay. What is this game? What kind of game is it?  Sketch out gameplay, mechanisms, rules. Why is it fun? Why is it cool? Why would someone play it? Why would someone replay it? Why would someone buy it?  These ideas should be distillable into simple sentences and paragraphs, and into a final “treatment” of <1 page.

Make concept screens and art. Still on paper! Draw sample screens. Draw pictures of characters, monsters, effects, background, weapons, whatever. Eventually these ideas will need to be turned into visible assets on the computer, but it’s much easier to begin with drawings on paper.

Detail the gameplay.  Includes walkthrough, mechanics, lower-level happenings and details.  This is somewhere between storyboarding a movie and writing a BRD (business requirements doc) for software.  Requirements, features, mechanics, actors, use cases, nouns&verbs, and other software analysis techniques all potentially apply.  The goal of this phase is to more exactly define what the game and gameplay is, to a detail that someone could reasonably implement it in code.

Implement the engine.  This is a continuing cycle of a) implementing the game engine code, b) playtesting the working game engine, and c) refining gameplay.  Without an engine, there is no game, so we consider that the first step of development.  Further, a “kernel” of the game engine must exist before it can be playtested, so get to that point first (define kernel as “the smallest possible playable thing”… something on the screen, some controls, etc).  Get to that point, then iterate by adding additional features.  (This is similiar to XP-style software development.  E.g., “what feature should we add next?”)

Design levels.  For the moment I’m just lumping this in with implementing the engine.  Build levels, stitch them into the engine, playtest and refine.

Produce art.  You can’t produce finished art assets before the corresponding concept art is done.  Start the engine with placeholder graphics and sound.  As finished art is produced, it gets folded into the evolving game engine / playtesting / refinement cycle, like so:

Add music.  Music can be added late (last?) in the process.  Think: scoring a movie.  The music will be most appropriate and effective when composed against some tangible, playable experience, to enhance and complete that experience.

Relative development timeline.  Nothing’s ever in stone, but this seems sensible:

Walking Concept Art

on 06/07/2010 by christopher 1 Comment

In order to make sprites for Thorn, I’ve had to learn a little about animation. These days, the first step to learning something new is to just Google it. So I did. I read a bunch, but this was my favorite animation tutorial.

I started a folder on my local machine with a bunch of walk cycle reference images. Based on those and Matt’s early sketches of Thorn, I kept drawing a set of legs. After a week or so, I came up with this four frame walk cycle:

Thorn four frame walk cycle.

Once I’d drawn it and animated it in Photoshop, I watched it for about 3 full minutes. Sure, it was super rough. But it was the first time I felt like I’d made the character come to life a little. After the third minute, I decided we needed a six frame walk cycle.

But that’s for another post. Gotta get back to work.

Some Things That Didn’t Really Work

on 06/01/2010 by christopher No Comments

It seems every time we turn a corner in the building of this game, we run into something that people devote their lives to. Animation, pixel art, web design, etc etc.

So we’ve attempted a few different methods of asset production trying to find something that was both possible for us to do and cool looking. I think we’ve finally found something that works, but it might be a little too early to tell. Before we got here, we tried a few things that didn’t really work.

Our first notion was to attempt a cut-out style. The idea was to cut our hero and mobs out of construction paper, shrink them down in Photoshop, and profit. Matt had the idea to paint the paper with various washes and come up with a really cool textured look. This was probably our least successful method. We ended up doing so much editing at the final size (32px), that we figured we should just give up and draw our assets at pixel level.

I ended up drawing this little guy:
Pixel Art Thorn

He took a long time, but the final product wasn’t bad. When we started pulling it into the engine and playing with different backgrounds, we realized we had a long road ahead of us. Making animations was slow and it took a considerable effort to make Thorn look cool, iconic, and apparent against our textures. In short, we would simply need to take the time and learn pixel art. A process that would take god-knows-how-long.

I was having a beer with a buddy and mentioned the work I was doing. He said he did a lot of pixel art as a kid and wanted to take a stab at drawing Thorn. And so, Vithiet Kak’s Thorn was born:
Vithiet Thorn

Vithiet obviously had more talent with this. Our immediate concern was that we hadn’t ever defined a vision for him. We’d skipped the whole ‘concept art’ stage of video game production. I think all I told him that it should be a mean viking. As far as that goes, he nailed it. It was definitely unsurprising that he didn’t draw the character exactly as he appeared in Matt’s brain.

We decided to take a step back from pixel art and try another method, something that we could produce on our own and manage the vision of what Thorn should be. We went back to the world of cutout and attempted a cutout method in Photoshop.

And thus, our little minotaur was born:

Video game asset, drawn using cutout method.

OK, so this method had a lot of things going for it. First of all, it was fun to make. I just spent a few hours hunting down royalty-free source images and hacking them together into a mob. The Frankensteining was fun. Secondly, it had character. With a stance like Michael Palin, and some big goofy feet, he definitely looked cool.

Unfortunately, some problems arose as well. Sure, we could make a mob with this style, but how could we make a hero character? And more importantly, this thing was a nightmare to animate. Whether I moved individual limbs in PS or tried stretching the whole thing in After Effects, it was just un-fun to animate. And if it’s not at all fun, it’s not worth doing.

It was at this point that we made perhaps the smartest move yet w/r/t asset production: we backed up. We realized we hadn’t truly hashed out and shared our shared vision for the hero and monsters. Over the next couple of weeks, we left our laptop lids closed and stuck to pencil and paper. One sketchbook later, I had a pretty good idea of what Thorn should look like. I also remembered how to draw, which was nice.

Now that we have solid illustrations of Thorn (the hero) and the monsters, every road looks open to us. Pixel art would now be possible, Illustration (a la Paper Moon) would be possible, and if we hired an artist, we would actually have something to show them.

So there’s a good lesson: paper first, computer second.

Making the music for Thorn

on 05/31/2010 by christopher 1 Comment

As Matt and I are building Thorn, making the music continues to be the easiest piece for me. I’m not a game designer or artist by blood, but I’ve been programming music for years. All of the little mistakes and roadblocks that I’m hitting in asset production or game design, I already hit and then broke through with music – years ago.

When I was working with Adam Chisum on the music for Battle Bears, Benjamin Vu (the game’s director) gave some pretty specific direction. He told us to make something that sounded like a mixture of Candyland and Black Hawk Down. After we turned in the first draft of the music, he told us to forget he ever said anything about Candyland. All it took was to remove the oboe and we were back to a pounding military soundtrack.

There was no effort when making the Battle Bears music to make it sound like ‘video game music’. We used samples that belonged in a more traditional film score, added a bunch of electric guitar and keyboard, and then chopped the hell out of it. When I listen to it now, I’m most proud of the strangeness of the arrangement. The few reviewers who discussed the music at all always just referred to it as being militaristic and pounding. They never mentioned how choppy and disconcerting the sampling is. And I like that about it. Maybe the more you listen, the stranger it is.

And so anyway, there’s this interesting question when you’re tasked with making music for a video game: should it sound like ‘video game music’? We’re no longer reliant on the limited power of the chip to produce music, so you can use whatever tools you like to make music for a game. And yet people often choose to use more traditional chip tune sounding MIDI tools to create their soundtracks. I’m not sure – is this atavism?

Since there’s no director above me telling me how the music in Thorn should sound, I’m left with the choice to use all of the tools at my disposal or to limit my palette. Matt’s original vision for the game soundtrack was that it would be very sparse, ambient, and dark. This still fits the current direction of the game. So this is one constraint.

Also, I’ve never explored much with MIDI instruments in all my years of music recording. My preferred tools have been the guitar, the harmonica, a whole bunch of VST plugins and a liberal amount of cutting and pasting. So this time (atavism be damned) I’ve decided to incorporate some old school 8-bit chip tuney elements into the music.

These are my two current constraints for the soundtrack of Thorn: dark-atmospheric, and inspired by the old-school games of my childhood.

A thorn is born

on 05/29/2010 by matt No Comments

Early Thorn sketch

Thorn began as a sketch in my notebook during a plane ride.  In a fit of geekdom I had been working on LISP exercises from SICP, got a bit bored, and just started imagining a video game.  Work had given us nifty new Nexus phones, but frankly most of the games available sucked.  I started thinking what sort of game I’d like to play, right now.  Sort of a rogue-ish dungeon crawl, sort of a Zelda adventure, something full of atmosphere, but still light and fun.  Thus: Thorn.

Good Controller is a small independent video game developer based in San Francisco. We are currently working on Thorn, our first project for the iPhone.