Awww, yeah. Git your leaderboards and achievements on.

http://itunes.apple.com/us/app/thorn-zombie-dungeon-survival/id445292868?mt=8

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:

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 gets a write-up on mobile app breakfast:

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

http://mobileappbreakfast.com/2011/07/20/thorn-zombie-dungeon-survival/

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.

http://www.148apps.com/reviews/thorn-zombie-dungeon-survival-review/

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

Yowza!!!

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

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

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.

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

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!!!

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)

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

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:

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:

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

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

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…

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

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

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.

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.

Enjoy.

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.

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.

Click to enlargenate. I’ll post more as my process continues to develop.

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:

Huzzah.

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.

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.

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.

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

“bombtrack started as a sketch in my notebook”

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

Outdoor terrain. Note the cows.

Experiments in construction paper and shadow overlays.

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

Orthographic projection and onscreen controls.

Crappy shadow effects.

Megaman! And some new tilesets.

Pixel-art thorn, and some rock experiments.

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

Hand-drawn animated sprites. Also, traps.

3D models, although still on an orthographic projection.

Thorn goes ISO.

New 3D ISO tileset.

Thorn circa 01/01/2011.

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.

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:

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.

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.

Anyway.

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.

Serving:

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

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

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

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

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

Skull

Batz

Wormz

Grunt

Brute

kick ass!

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

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.

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.

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:

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

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.

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:

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:

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.

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.

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.