Jamestown Has Been Unleashed!

by Mike
Thu, June 16, 2011 -- 9:12 UTC

On this very date in 1607, after a month of extremely hard labor, 104 exhausted settlers finished constructing the first fort at Jamestown (the colony):

Looked something like this.  Unclear if giant statue of Powhatan is to scale.

Looked something like this. Unclear if giant statue of Powhatan is to scale.

Jamestown (the game) took almost two years to build with a core staff of just 3 people, so… this analogy could use some work. STILL! We felt that this would be an appropriate day to take a quick break from our post-release duties and shout the following message from the rooftops:

:D :D :D

Steam put us on their front page for four glorious days.  Right next to Duke Nukem Forever.  It's... absurd.  And awesome!

Steam put us on their front page for four glorious days. Right next to Duke Nukem Forever. How crazy is that? HOW AWESOME?!?

Not only is the game out, but people have been playing it and writing what they think about it! On the internet! Here’s a sampling from the first batch of reviews (emphasis ours):

“As for the game proper, it’s just a class act. The range of enemies, the design of them, the placing of them, the way they burst in a shower of nuts and bolts that you’ll want to collect, the way the guns feel, the music, the pacing, it’s all fabulous.” – Rock, Paper, Shotgun


“The environments, the enemies, the troops fighting in the background – every single graphical element of this game is absolutely stunning, to such degree that even those who don’t care for pixel art are sure to be pleased with how Jamestown looks. Every inch of the screen suggests lovingly handcrafted and passionate art, and soaring through it all was a joy.” – Bits ‘n Bytes Gaming


“…one thing’s for sure: if you had told me that Jamestown was Final Form’s first title, I wouldn’t have believed it. … Accompanying the stellar design are a stellar soundtrack and sound effects. The music in Jamestown is indistinguishable from a big-budget epic soundtrack, and the game’s sounds are an excellent mixture of retro and modern shoot ‘em up titles.” – GamerLimit


“In a world of me-too shooters plagued by uninspired presentation and flat gameplay, Jamestown is a standout, a breathtaking experience that not only hearkens back to the golden age of gaming but also smartly offers fresh game mechanics at every turn. Jamestown has rock-solid mechanics, beautiful art direction and depth of content, and it’s a pure joy to play.” – Press X or Die


And for those of you who think reading is so 2010, here are some of our favorite video reviews/first-looks:

ByteJacker –  “I gotta tell you: this thing, with four Xbox controllers, and an HDMI out to your TV, has got to be, like, THE definition of kick-ass gaming. It’s just really, really amazing.

NorthernLion –  One of the best indie games I’ve played this year and, as you know, I’ve played pretty much all of them.”

Total Biscuit, The Cynical Brit –  “One of these is homing! ALL OF THESE ARE HOMING!

Our profuse thanks go out to all the writers, commentators, and pundits who spent some time with our game, and then made the effort to tell the world about it!

This is Jamestown running in a Taito cabinet.  Guess we can check that off the ol' Impossible Dream list!

This is Jamestown running in a player's arcade cabinet. Guess we can check THAT off the ol' Impossible Dream list!

Overall, the response to the game has been overwhelmingly positive. Players have been going out of their way to let us know that they’re having a blast playing Jamestown, which is like a firehose of warm-fuzzy-feelings right into our sleep-deprived hearts. So, to everyone who has been tweeting, posting, and emailing us with kind words: Thank you, thank you, a thousand times, thank you!

We’re also thrilled and gratified by the community that’s forming around the game. Watching our players help each other learn to play, post expert sessions on YouTube, stream Divine Gauntlet runs live from Japan, and energetically debate the finer points of Bomber usage in our Steam forums has been a true joy. ;)

Finally, it should go without saying that we are extremely flattered (and somewhat taken aback) to see our little game being compared to the works of CAVE, Takumi, Treasure, and ZUN. That said, their influence on Jamestown is hopefully unmistakable; they are our heroes, after all.

Much like that very first fort at the actual Jamestown colony, the first build of our game was hardly the last. Right now, we’re working hard to fix bugs, answer emails, and keep getting the word out about Jamestown. If you want to help us with that last bit, and you love the game, then please don’t be shy about telling the world! Our twitter hash-tag is #jtown16xx; go nuts!

More updates to follow. Until then: thanks again, and enjoy playing!

Final Form, Year One: WHERE WE’RE GOING

by Mike
Thu, July 1, 2010 -- 19:59 UTC

It took 365 days of hard livin’, but we’re finally here: Final Form Games is one year old today! You are our loyal, never-say-die readers with whom we will always shoot straight, and we hope you are excited to celebrate with us! Over the past few days, we’re brought you up to speed about where we’ve been and where we’re at, but said very little about…



Seriously: What In Tarnation Are You Guys Working On?

What a good question! We are working on a rad videogame! It represents a lot of what we love about games, its working title is Jamestown, and we think it’s going to be a blast.


First things first: The screenshot we posted back in October wasn’t an image of functional gameplay. We know, you’re shocked. HOWEVER! That image does represent the overall aesthetic and milieu that we are striving to deliver to YOU, the customer! To vouch for the truth of our words, here are some totally real, in-game (and very Work-In-Progress!) screenshots of what the game looks like on this very day:

And HERE are some scintillating details:

- Jamestown is an old-school, handcrafted shoot-em-up (or “shmup“) with a new-school twist: 4-player co-operative play!

You will roll deep.

You will roll deep.

- As many have guessed (amazingly), it is set in 17th-century British colonial Mars. It will feature: Famous alt-historical figures! Majestic alien landscapes! Steampunk space tech! Hard-bitten settlers taking their shot at ekeing out a better life in the New World! Redcoats and Martians settling their differences with spear and space-musket!


- With the gameplay, we’re striving to press all the important hardcore gamer pleasure-buttons, while still leaving room to innovate on what co-op can really mean in the context of a classic shooter. We just love co-op games so much!

In 2011, one of these ships could be you.

In 2011, one of these ships could be you.

- We hope to tell a story within this world that is legitimately engaging and worth reading/watching/playing. A story that one might use the word “swashbuckling” to describe! Or, “coherent!” Or even, “explodathon!”

- In terms of timeline, we plan to submit to IGF this year, and hope to release on PC sometime in 2011, with other platforms to follow. The comments section awaits your snarky comments about release dates!


This is our first project, and we undoubtedly have plenty of rough waters to contend with between now and ship day, but we are optimistic about the journey ahead. As you may have read in our previous two posts, Year One was largely about investing a huge percentage of our energy into developing the game mechanics, technology, tools, and skillsets that we think are necessary to make our game great. Year Two is going to be about using them.

Thanks for being here with us on our first birthday. More to come.

Touhouhou and a Bottle of Rum

Fri, September 25, 2009 -- 21:06 UTC

Chris over at Paper Dino recently put up a  post on the lessons he learned from playing the Touhou shmups, e.g. Perfect Cherry Blossom and Imperishable Night. For those who don’t know, this is a series of shmups (shoot ‘em ups) made by one guy from Japan who calls himself ZUN. He’s iterated a lot on the basic vertical scrolling shooter formula and his shoulders are great ones to stand on when you’re making a shmup yourself.

Chris did an excellent job of highlighting several key lessons.  Here are some of the things I took away from my own explorations of the series.

Welcome to Bullet Hell

Welcome to Bullet Hell

Slow/Technical Mode

If a bullet hits the dot on her waist, you're dead. Anywhere else and you're home free.

If a bullet hits the dot on her waist, you're dead.

Almost all of the Touhou games I played had a button that, when you hold it down, makes you go slower. In the earlier Perfect Cherry Blossom you activate this mode by holding down the fire button, a’la DoDonPachi. In later games, however, ZUN remapped this slowdown to another button entirely.

One of the most subtle benefits of this slowdown is that it puts a small dot on your character showing your “real” hit-box. As Chris mentioned in his post, it’s usually a good idea in shmups to make the player’s hit box (i.e. the part of the player that, if it touches a bullet, will result in player’s death) much smaller than the image of the player’s ship.

Notice the little white dot on the player on the image to the right. That’s the player’s hit-box; as long as you remain in slow mode the game displays this point for you allowing for a highly technical level of play.

Modal Gameplay

Left: Slow Mode, Right: Normal

Left: Slow Mode fires wavy bats, Right: Normal fires spread

In most of the Touhou games the player’s main vulcan fire* is slightly different when slow mode is engaged. In Imperishable Night, the players main attack gets extremely different. As you can see on the right, the main character’s sprite also changes to reflect this.

With the character(s) pictured, the slow mode actually leaves guns behind in screen-space (the red circles above her are the guns) so you can put a gun down, for example, somewhere you know the boss often is while you’re off somewhere else dodging. By contrast, the main mode is a very traditional vulcan spread shot.

Currently in "I can kill you, you can kill me" mode

Currently in "I can kill you, you can kill me" mode

This allows for tactical decisions. All of the sudden you have an interesting choice of which gun to use for each wave of enemies that comes at you. Do you fire the spread to cover more screen, or do you leave a gun on one side of the screen to cover the other?

Imperishable Night makes this even more interesting by changing enemy behavir based on which mode you’re in. These things, called “familiars”, are usually spawned by bosses and shoot bullets at you. When you are in slow mode they won’t harm you by touch, but you can’t kill them either. When you are in normal mode, however, your bullets can kill them and they can kill you by running into you. This offers even more interesting play choices such as, for example, you choose whether to remain in regular mode so you can kill them and stop them from firing at you, or just to switch to slow mode and fire through them to get to the boss while dodging bullets.

Boss Locator

The last mechanic that I’ll mention is the boss locator. Whenever you fight a boss, the word enemy appears on the bottom of the screen directly under where the boss is on screen (screenshot below). This lets the player see where the boss is with a minimal effort even when he’s busy dodging hell of bullets at the bottom of the screen. It’s a great innovation that’s particularly well-suited to the smaller bosses of the Touhou shmups. We may have to borrow this.

crude red drawing added by the editors for emphasis

Crude Red Drawing added by the editors for emphasis

This is by no means all of the lessons these games have to teach. The bullet patterns alone could be the subject of a dissertation; I’m sure I’ll go back to that well. For now, though, these are my big takeaways from my brief research time. If you haven’t had a chance to play these yet I heartily recommend them, Imperishable Night in particular.

* The vulcan is pretty much the standard issue primary weapon in shmups. Originally named after the real M61 Vulcan cannon, the original standard gatling gun on American jets post WWII, in shmups a vulcan is a high speed, high rate-of-fire weapon.

FallGuy Prototype – Day 3, part 2

by Mike
Sat, September 19, 2009 -- 2:04 UTC

This is the second in a series of posts that document the process of building a prototype game in about 7 days.  Because I am writing it, it places special emphasis on the particulars of how the art and animation got made.  It’s also getting increasingly technical.  You can catch up with Part 1 here.

When we left our heroes, the time had come to start on the first screenshot mockup of FallGuy.

The first decision was game resolution. Most of the great modern pixel art games (DoDonPachi, ProGear, Street Fighter III, etc.) run somewhere in the neighborhood of 320×240 pixels, but there tend to be subtle variations on those numbers depending on which arcade board the game was designed for. I looked at screenshots of vertical shmups like Ikaruga and the bulk of the Cave lineup, and arrived at the conclusion that 224 pixels wide by 320 tall was going to work fine for our needs on this project.


As soon as I had a resolution target, I made a blank Photoshop file at that rez and started working on our protagonist. The main character sprite is the representation of the player in the game, so getting him right is one of the most important art tasks. He needs to have the correct scale, a clear silhouette, good contrast with the environment (i.e. background, enemies, bullets), and general visual appeal. Finally, he needs to support core gameplay functionality with things like a clearly-indicated hitbox and a logical point from which bullets can be emitted. As I didn’t have any environment art yet, I focused on scale/silhouette/gameplay for the first pass.


My crappy, crappy earlier designs.

When I was done, the character was just a simple black outline with a white fill, but all the heavy lifting of the character design was largely squared away. And yet… he wasn’t excellent? Really at all? This is probably a good time to mention that for this project, I was focused on getting things to the Good Enough line and then moving on, with a plan to return and polish/revise/start over if time allowed. For example, the character above is doing something with his right hand that looks more like a lewd gesture than holding a pistol. That issue became obvious as soon as I got him to this point, but the clock was ticking! Rather than embark on a complete character redesign, I simply considered the odds that all this art would get thrown away anyway, decided those odds were rather high, and focused on the biggest bang-for-buck revisions I had time for.

For example, if bullets are supposed to come out of that right hand, it should probably be aligned with the center of the character instead of being 5 pixels off to the right. That was an easy fix, so I made it (and a few others) before I started animating. Anything more difficult than that fell right off the back of the results train, and not just for expediency’s sake either. The fact is, I’m enough of a novice at this style of art that every single piece I create teaches me another 5 important lessons, so the payout of just putting miles on the tires still greatly exceeds the payout of mastering a single turn of the track.*

Before Hal could actually use the art I’d created, I had to convert it into whatever format he needed on the code side.  After some brief discussion, we determined that the easiest (though somewhat painful) solution was to create animated .gif files and then go through the laborious task of converting them into .swf files in Flash.  This process cries out for automation, but javascripting workflow improvements in Adobe’s CS3 suite was way, way, WAY out of scope for this project.  I sucked it up, checked the converted main character test image in, and got to work on his first animation.


The idle loop is actually somewhat rare in the classic shmup world, as most player craft are spaceships or airplanes of some stripe and have no soft bits to apply constant motion to. Typically, that sort of thing is limited to some sort of flicker in the exhaust of the jets or rockets or whatever the propulsion system of the ship is. In contrast, our character was wearing a business suit, and had no jets, so the natural idea was to animate his clothes flapping in the wind as he flew through the air.

This brought me to a tools question that I’ve been meaning to find the answer to for a while: what software will I use to produce these animations? For previous projects, I had used the following process:

  1. Animate at high resolution in an open-source 2d animation program called Pencil
  2. …export that animation as an image sequence…
  3. …then batch downrez/crop the frames to the target size in Photoshop CS3…
  4. …import those frames into an open-source pixel animation program called Pixen
  5. …and proceed to cleanup/color from there.

Long as that list is, this process actually had some nice things going for it: it allowed me to animate at high rez, which is great for someone who is new to the expressionist mental kung-fu that pixel art requires. Additionally, passing through Photoshop gave me access to all the filters and associated knobs/buttons that make it the definitive industrial raster software the world over. Finally, it worked, which is always a plus.  Unfortunately, this pipeline suffered from having a lot of difficult-to-automate steps, and from relying on not one but two pieces of buggy open source software.

For the idle loop, which looked very simple anyway, I decided to try doing the whole process in Photoshop.

Many people don’t know about the remora of animation support that clings to the underside of Photoshop CS3; I suspect its presence would be classified as a bug by the folks over at Adobe. By that version of the Creative Suite, almost all the animation support features had been relocated from Photoshop/ImageReady to another Adobe app called Fireworks. However, just enough of it remains in Photoshop that you can still get animations done if you plan carefully. And as we all know, if you’re animating in 2d, you should be planning carefully anyway.


Only an Armani would flutter like this.

What I learned from doing this animation in Photoshop was that you can indeed still use it, but it’s a deeply counter-intuitive workflow for someone with a traditional animation background. For example, it stores individual layer visibility state per-frame instead of the typical discrete-images-along-a-timeline metaphor. This probably makes a lot of sense when you’re creating web graphics, but it’s maddening if you’re planning to draw a custom image for every frame anyway. One useful side-effect of that design decision is that you can use the feature in concert with layer and group masks to achieve useful things like per-limb frame offsets and the like. Unfortunately, such feats are unwieldy in the extreme, especially in comparison with any given 3d animation package (where the difficulty of said feats would be most readily compared to that of falling off a log).

There are of course days when it’s worth the pain, so I’ll definitely keep Photoshop it in my back pocket for certain classes of task, but most of my takeaway was that I should find a better (or at least more straightforward) tool for my meat-and-potatoes 2d animation work.


My next task was to animate him swinging his sword with gust and bravado.  After the weirdness of using Photoshop, I felt renewed excitement to revisit Pixen. While buggy, Pixen was obviously designed from the ground up for this exact purpose (probably after looking at GraphicsGALE), and I was able to stop fighting the tool after just a few hours and focus my energy instead on bringing the character to life. That old 2d animation juice started to flow for the first time in years, and actually I managed to create something I was pretty happy with:



The lessons of Pixen were to save often, and keep things simple whenever possible. This is because it’s definitely, definitely going to crash on you all the time. The core functionality is (fairly) safe, but the further you venture out into the badlands of the extended feature set, the greater the odds that you’re going to step on a landmine.  Also, even though it’s got lots of neato features like per-frame layers and custom palettes and so on, I found the complexity of wrangling all the moving parts of a 10 frame animation to be all that I could handle. Even something as simple as dealing with layers pulled me out of my fragile groove and got me thinking about my tools again, instead of what I was trying to create with them.

I suppose that was the other lesson of Pixen: that besides being the best of what was around, it was also good enough on some absolute scale of my particular needs.  The day will probably come when I convince Tim to write me the pixeling tool of my dreams, or at least to spot-weld features and bugfixes onto Pixen until it becomes that tool.  For now, though, I’ve used nothing better for turning jumbled piles of pixels into believable animated characters.

Thus concluded Day 3. See you next time for Day 4, which features Unexpected Reversals and A Moment Of Truth!

* FYI, you can count on more tortured/mixed metaphors in that style from here on out.

FallGuy Prototype – The First 2.5 Days

by Mike
Mon, September 14, 2009 -- 18:04 UTC

This is the first in a series of posts that document the process of building a prototype game in about 7 days.  Because I am writing it, it places special emphasis on the particulars of how the art and animation got made.  Hopefully someone out there in the nettertubes will find it useful/interesting/boredom-slaying.

So there we were.  PAX was 7 days away, and we wanted to show some sort of playable prototype product to the beautiful people there.  Tim was busy in the Code Mines, slaying dragons with fell monikers like “Reflection,” “Serialization,” and “Lua Integration.”  He could not come to our aid.  That left Hal and I with just a stick, a ball, and the elaborate game-prototyping framework that Hal’s been chipping away at in Flash for the past year.

Undaunted, we made the following plan: Hal and I would prototype a playable somethin-somethin in a 7-day sprint.  Tim would be present for brainstorming/playing stuff/giving feedback, but otherwise uninvolved.  Scary as that was, we sallied forth bravely into the dark woods of prototyping adventure.

Days 1 and 2:

Getting our version control pipeline going took up the first 1.5-2 days of the sprint.  This involved setting up the new .svn and .hg repositories, linking them together in a delicate lattice that allows me to check in art that is sym-linked into hal’s flash code directory, testing that setup, fixing what didn’t work, and then writing a script that sets all that up with the push of a button.  Having gone through this process already with the website and a small Python game really smoothed these preparations out considerably. However, a website is not a flash game is not a regular game, and in each case we have needed to iterate and explore a bit before finding the optimal setup.

Anyway.  Found it.  Took about 2 dev-days when you count lunches and lengthy discussions about that most elusive of prey, the “best” solution.  While prototyping is typically oriented around “good enough” solutions, we felt a carefully-considered repository structure was worth the investment because it would make all subsequent Flash prototypes (such as the one we’re doing this very week) much much easier.  So you can call this a 5-day sprint with a 2-day speed-bump, if you like.

Day 3, part 1:

And they’re off!  First, all three of us brainstormed in the manner described a few posts down.  Then we culled and refined in a manner to be discussed in some subsequent brainstorming post.  By the end of the session, we had a pretty clear idea of what our goals were for the project:

- Get a generic shmup working. In this case, “generic” means a 2d game with a scrolling background, a ship or other craft that can be moved around the screen, the ability to shoot, and enemies to shoot and be shot at by. We didn’t brainstorm with this genre restriction locked in, but it certainly had a leg up on most other options.  This was because A) shmups have been the main genre we’ve planned to explore since before starting the company, B) we’d already used Hal’s tools to lay a lot of the groundwork for a game in that style, and C) it’s frankly one of the easiest genres of videogame to implement.   However, we still kept the door open to other styles of game during brainstorming, just in case something unexpectedly awesome and practical snuck in during the conversation.

- Add a sweet feature or two. This is what makes the prototype interesting!  Even Space Invaders, which is among the oldest and most powerful of the Elder Shmups, had more going on than the baseline features I described above (including destructible environments ZOMG).  Given how tight the project schedule was, we weren’t sure we’d even get the basics working, so this goal was mainly included in the plan just in case we found the time for it.  The sweet features we were most excited about trying out were a melee attack (most likely involving a sword), and a fighting-game-esque special attack mechanic.  Think Ryu’s fireball from Street Fighter, and you’ll get the basic gist.  In fact, think Megaman learning Ryu’s fireball in Megaman X and you’ll get even more of the gist, as that was another game that cross-bred core fighting game features with a different genre (in that case, a platformer).

- Make it look neato. This meant coming up with a coherent look for the thing, and then producing a lot of art in that style very quickly so that nothing utterly temporary (i.e. flat-colored boxes and circles) remained by the time we were done.  This actually isn’t the way we’d approach the art side of prototyping normally, as prototyping is ideally as fast and nimble and prone-to-throwing-things-away-when-they-don’t-work as possible.  Ordinarily, that would mean simple flat-colored boxes and circles were perfectly acceptable art elements until quite a few gameplay concepts had been tried.  However, this project was meant to see the light of day (unusual for a prototype) at PAX, which basically meant it would be doing double-duty as a gameplay experiment AND a piece of marketing material for our company. As such, we decided to try and eliminate all blatant placeholder art from the final product. Additionally, I still need all the practice I can get producing pixel art quickly (more on that later), particularly animation, and this project was a chance to do that on the clock in an actual production environment. The process of trying new techniques and comparing various style treatments is itself a form of prototyping, so that was a part of this goal as well.

The broad strokes of the art direction fell pretty naturally out of the high concept Hal pitched to us during the meeting.  His idea was to make a vertical shmup where the player “ship” looked like a Brock-Sampson-esqe action hero in a business suit, flying through the air with a pistol in one hand and a samurai sword in the other.

Our muse.

Our muse.

It was pretty clear from the reaction in the room that we could all get down with that, and so I started on the first step of the art process: working up a screenshot mockup for the game we would eventually start referring to as “FallGuy.”

Next post: the rest of Day 3!  There will be animated pixels and swordplay.  See you there.