Haverford College put up a lovely article on us over on their website. You should go read it, if only for the really great photo* of us doing our best mac-users-group ‘zine cover pose.
*courtesy of the talented Aaron Stock
Tweet it!
Share it!
One Comment 
It’s A God-Awful Small Affair
Thu, October 8, 2009 -- 21:58 CEST
A peek at what we’ve been up to:
It’s the freakiest show.
Something Very Special
Mon, September 28, 2009 -- 17:34 CEST
The following is a fairly technical post about something that came up during our programming efforts. It assumes a certain amount of experience with the intricacies of C++, so if that’s not your cup of tea, don’t pay this post any mind.
I spent some time yesterday integrating my C++ math library with Lua. I have a pretty robust Lua integration library at this point, but it heavily leverages template partial specialization to achieve the ease-of-extensibility that I want. While I have become rather adept in the past few months at dissecting and making use of template error messages, I ran into a confounding error that I simply had to share*.
Here is a C++ program that represents the kind of task I was attempting to implement. The original code was implementing C++-side templated generation of Lua userdata metatables for my templated mathematical primitive classes. The following code snippet, while contrived, should serve as a more digestible demonstrative example.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 | #include <iostream> using namespace std; // A few generic templates template <int N> struct Foo { }; template <> struct Foo<1> { }; template <int N> struct Printer { static void Print() { cout<< "You have " << N << " " << Texter<Foo<N> >::GetText() <<endl; } }; template <typename T> struct Texter { static const char* GetText() { return "apples"; } }; // Let's call this next specialization "A" template <> struct Printer<1> { static void Print() { cout<< "You have just one " << Texter<Foo<1> >::GetText() <<endl; } }; // And let's call this next specialization "B" template <int N> struct Texter<Foo<N> > { static void Test() { Printer<N>::Print(); } static const char* GetText() { return "apple"; } }; int main(int argc, char** argv) { Texter<Foo<1> >::Test(); } |
So, what would you expect to happen when you run this program? I would have expected it to print out, “You have just one apple” and terminate. What I would NOT have expected is for it to spit out this error:
1 2 3 4 5 6 7 8 9 10 11 12 | 1>------ Build started: Project: TrickyTemplates, Configuration: Debug Win32 ------ 1>Compiling... 1>main.cpp 1>c:\finalformgames\trickytemplates\trickytemplates\main.cpp(40) : error C2039: 'Test' : is not a member of 'Texter<T>' 1> with 1> [ 1> T=Foo<1> 1> ] 1>c:\finalformgames\trickytemplates\trickytemplates\main.cpp(40) : error C3861: 'Test': identifier not found 1>Build log was saved at "file://c:\FinalFormGames\TrickyTemplates\TrickyTemplates\Debug\BuildLog.htm" 1>TrickyTemplates - 2 error(s), 0 warning(s) ========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ========== |
It was telling me that Texter<Foo<1>> does not have a method named Test in it. But there Test is, right above the call to it! All my efforts to statically analyze the program for the problem were fruitless (in part because the actual code was vastly more complex than this example). So, I did what anyone would do in my shoes, and started poking at it with a stick.
One surprising result: if I changed Printer to take in an additional template parameter, typename T, the error went away.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 | ... template <typename T, int N> struct Printer { static void Print() { cout<< "You have " << N << " " << Texter<Foo<N> >::GetText() <<endl; } }; ... template <typename T> struct Printer<T, 1> { static void Print() { cout<< "You have just one " << Texter<Foo<1> >::GetText() <<endl; } }; ... |
Well, that’s pretty strange. Needless to say, this did little to allay my worry.
So, I rolled it back and broke out an old tried-and-true technique I picked up while working with the Metrowerks Codewarrior debugger: try moving blocks of code around. Sometimes this is illuminating, and, in fact, I found that by swapping the order of specializations “A” and “B” (see above code snippets), the error went away. Again, not too reassuring, but it gave me a lead by suggesting that something about this bug must relate to the order in which things are defined.
I searched online for all manner of permutations of keywords relating to the situation, and finally found this post on a site about the programming language D (which has many similarities to C++):
“If two template specialization refer to each other, there is the possibility that one of them will try to instance the other before the specialization for the other is created. The result would be either a compile error or an attempt to instance the wrong template. On the other hand, if I’m not missing something, a compiler would also be correct to lazy evaluate specializations, in which case this problem may well not occur. Some way to ensure the desired behavior here would be needed.”
So, my current understanding as to what was going on is as follows: The Printer<1> specialization is instantiating the Texter<Foo<1>> specialization before the Texter<Foo<N>> specialization is defined. This is because the correct order cannot be determined due to two specializations cyclically referring to each other. As a result, it is masking out the later definition of the Texter<Foo<N>> specialization. When we call Texter<Foo<1>>::Test() in main(), it uses the incorrect specialization, which does not define the a member named Test. This may be inaccurate, but it seems to line up best with the symptoms from what I have figured out. That being said, if you are familiar with this bug, or have a contrasting theory, please share with us below in the comments.
What’s especially surprising about this error is that there is supposed to be an error message you get when it happens! It’s not hard to invoke it, either:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 | // This compiles just fine: template <int N> struct X { static void A() { Y<N>::B(); } static void C() { } }; template <int N> struct Y { static void B() { X<N>::C(); } }; int main(int argc, char** argv) { X<1>::A(); } |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 | // This, however, throws a C2908! template <int N> struct X {}; template <int N> struct Y {}; template <> struct X<1> { static void A() { Y<1>::B(); } static void C() { } }; template <> struct Y<1> { static void B() { X<1>::C(); } }; int main(int argc, char** argv) { X<1>::A(); } |
I do not mean to fault Microsoft for their failure to throw this error at me. It’s one hell of an edge case, and if you’re in this deep, you really ought not to rely on your compiler to bail you out when you do Bad Things. That being said, it’s nice to be able to trust that your compiler is Always Right, and experiences like this make that trust feel tenuous and uncertain.
In conclusion, do not let your template specializations refer to each other cyclically, or you may find yourself a sad, sad panda.
*Please note that this post refers specifically to behavior I experienced using Visual Studio 2008 9.0.21022.8 RTM on a machine running Windows XP. If you are on a different platform, you may or may not experience the same behavior.
Touhouhou and a Bottle of Rum
Fri, September 25, 2009 -- 21:06 CEST
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
Slow/Technical Mode
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 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
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
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.
Style Study: Motion Blur in Street Fighter 3
Wed, September 23, 2009 -- 19:04 CEST
One of the classic problems of 2D animation is the tug-of-war between frame economy (each drawing takes lots of work/time) and high-speed movements (the faster the move, the more likely it is to “strobe” if you skimp on frames). There’s also the issue that, even with a lot of frames, some movements are so fast that they would usually become little more than a blur on film.
As you might imagine, developing a 2D fighting videogame really brings this problem front-and-center. Most of the gameplay in a typical fighting game centers around two large characters executing high-speed attacks, continuously, for minutes at a time. Because traditional sprite-art games typically eschew the use of any semi-transparent pixels, they often have to get pretty creative to emulate the effects of motion blur.
Today I went through my Street Fighter 3 sprite collection* to pick out some good example frames, and was surprised to discover a different fast-motion solution for almost every character. As I went through them frame-by-frame, it became more and more clear that the lead animator of each character was essentially allowed to use whatever technique they preferred to achieve the effects they were after. What follows is a grab-bag of these tricks in action.
This first one is the character Makoto. This is what I think of as a pretty typical post-Disney stretch, being used to sell one hell of a jump-kick. Notice that the contour line around the foot is consistent with the contour treatment on the rest of the character.
They’re also pretty fearless about stretching the physical length of the attacking limb, to further accentuate the speed and force of the hit. Again: classic Disney. Makoto in particular is an absolute masterclass of physical animation, with her oversized gi and super-long headband flying every which-way. The fact that these animators are doing it all within 120-odd pixels square just makes it more impressive.
With Oro, they really loosen up and go nuts with the squash-and-stretch. In addition, there are more subtle differences: notice that the contour treatment is lighter on the fast-moving limb than on the rest of the body.
Here you can see the contour change even more clearly.
And check out this transparency hack, eh? You wacky Capcom animators!
…and now for something completely different. Akuma’s movements are very stiff and staccato in comparison to Makoto’s and Oro’s, though it’s not clear if that’s a deliberate stylistic choice to differentiate their martial arts or just a quality-control breakdown. However, this motion-lines technique is how all his fast movements are treated. Like all the techniques used in this game, it works very well, but what an odd contrast!
Finally, we have Chun-Li. As the original Fastest Character In Street Fighter, this character is all about speed! Strangely, her animators seem to be doing everything they can to avoid squash-and-stretch. When it is used, it’s used… weirdly. In general, the character almost feels like it was filmed using a higher shutter speed. Check it out:
The frame above is the closest I could find to the sort of treatment we saw on Oro, but the foot is clipped to a point. I wonder if that’s to emphasize the contrast between her exaggerated thighs and small feet?
The stretch/motion-blur is pretty dramatic here, but… it’s sitting behind a proportionately normal and fully rendered limb? Plus, the motion trail is actually lit, or at least gets darker in an effort to achieve some sort of fading effect.
Now they’re completely disconnecting the blur element from the limb, and introducing some of that semi-transparent-looking stuff we saw with Oro.
Same deal, but even more obviously out-of-step with the stuff we saw before.
Finally, here’s a frame from her famous lightning kick attack. This was probably the official Fastest Fighting Game Move Of All Time when it debuted in Street Fighter 2 (possibly tied with E. Honda’s hundred-hand-slap), and yet its execution in part 3 is extremely underwhelming. After seeing all the juicy speed effects on the previous characters, this ghost-limb trick really feels like a missed opportunity to me. Again with the high-shutter-speed gag.
Fun as it was to pick apart the monolithic game art achievements of yore, this style study left me with more respect for the Capcom art team, not less. I’ve logged more hours than I’d like to admit on this game, and never once noticed these discrepancies. I’m sure some of that comes from the fact that only two characters can fight on-screen at a time, so the visual hodge-podge will only ever get so ridiculous. However, I suspect the bulk of said hodge-podge skates by because, at these framerates, your brain is only subconsciously able to process what it’s seeing (let alone register that Chun-Li has three legs). “Persistence of vision” is all about our brain wanting to believe in continuity between frames, and these animations have all been ruthlessly tested and refined towards accomplishing that mental sleight-of-hand. The fact that they went about it in different ways turns out not to matter very much, because they all ultimately achieved their goal: the illusion of speed.
Once again, I am amazed by the users’ tolerance for inconsistency in the final product. Take heart, game artists! Your players will forgive you for far more trespasses than you’ll forgive yourself!
*I got all the frames for this post from this excellent website and, by extension, from the seminal Capcom fighter Street Fighter 3. Go check it out if you want to see these animations in motion, and pick up a hefty dose of inspiration while you’re there!
FallGuy Prototype – Day 3, part 2
Sat, September 19, 2009 -- 2:04 CEST
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.
THE MAIN CHARACTER
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
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:
- Animate at high resolution in an open-source 2d animation program called Pencil…
- …export that animation as an image sequence…
- …then batch downrez/crop the frames to the target size in Photoshop CS3…
- …import those frames into an open-source pixel animation program called Pixen…
- …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.
THE SWORD ATTACK
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:
Swoosh!
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.
Highlights from PAX 2009
Thu, September 17, 2009 -- 15:57 CEST
A rockin' good time
The time has come to talk about the awesome things I experienced at PAX 2009. The convention has been over for more than a week now and I have been back east for about half of that time; owing to the stellar performance of United Airlines, my all-day flight transformed into an overnight red-eyed odyssey with a stopover in SFO*. I have finally recovered. Let me share with you some of the wonders I beheld. Note: this post is all pleasure – in future we may put together a Business Time post talking about the connections etc. that PAX yielded but for now, it’s all about fun.
Geek Chic: Classy Gaming Furniture
As I’ve mentioned before, I really enjoy pen and paper roleplaying games. I also enjoy board games, card games, … really almost all tabletop games. As I may not have mentioned, I have a fiancée who also sometimes enjoys these things. She also, however, appreciates a nice-looking home.
Enter Geek Chic. I had the great opportunity to sit down and have a few beers with the folks behind Geek Chic. Robert Gifford, the founder of the company, has a real passion for his work. His angle is that we should treat gaming like we treat more mainstream hobbies. You can play golf with really nice clubs. You should be able to play Pandemic on a really nice table. As soon as we move into an apartment that actually has some space, I hope to give these guys my business.
The only way to play Arkham Horror
Steel Battalion
Not a lot of people have heard of Steel Battalion. Even fewer have played it. Until PAX, I fell into the latter category. Now, all my dreams have been fulfilled.
Steel Battalion was a mech combat game for the Xbox in the early aughts. What made it truly special was its controller. Unlike other mech games that use mouse and keyboard (and might even support a fancy joystick for the hardcore), Steel Battalion came with its own cockpit setup including (but not limited to):
- two (2) joysticks, one with a thumbstick on it
- three (3) pedals (gas, brake, dodge)
- gear shift
- windshield wiper control
- various startup switches
- eject button complete with plastic shield to prevent accidental use
Note: Failing to press the eject button when your mech is destroyed WILL result in the deletion of your saved game. That’s how Steel Battalion rolls.
It was my dream to play it in college. Sadly, I lacked both the Xbox and the several hundred dollars to buy one and the steel battalion setup.
I am here to report that it was officially worth the wait and would like to thank the kind gentleman who taught me how to destroy everyone else by shooting them with with my railgun from a mile away.
The windshield wiper control is one of the wide green buttons on the middle panel. Eject button: sadly obscured by this dude's right forearm.
The TMNT Bus
Here’s a lesson in marketing. First, find something that the members of your target demographic loved as children with a white hot passion. Second, spend thousands of dollars to transform a bus into a shrine to that childhood memory. Third, sit back while the adoring public does your marketing for you.
When I saw the bus pictured below on the PAX exhibition floor, I had to go in. You may not remember the original Teenage Mutant Ninja Turtles or their associated merch; some of you are probably too young. As for me, I spent weekends forcing my parents to drive me from store to store, anxiously searching through every rack for the two action figures I didn’t have yet.
This bus was full of those action figures. The ones I slaved over, the ones I spent my hard earned cash on, and the ones my mother secretly stole the weapons from when I wasn’t paying attention. It was a direct line to my childhood. And here I am, now, talking about it. Playing into the marketing trap.
The downside? At the time I had no real clue what product this bus was selling. In fact, until about five minutes ago while researching this post, I thought that it was to publicize the new XBLA remake of Turtles in Time. I am almost reluctant to play into their hands but I suppose it is only right that I tell you the actual marketing target was the new TMNT Smash Up, a Smash Brothers style game due out later this month for Wii. You win this round, Ubisoft.
Cool, but rude
Mechaton: The Lego Mech Game
Steel Batallion was not the only awesome mech game I played at PAX. I also played Mechaton, a tabletop mech combat game made by D. Vincent Baker. D. Vincent (a.k.a lumpley), for those who do not know, is the maker of such fine other games as Dogs in the Vineyard which I have mentioned briefly before here, and have discussed at greater length elsewhere.
I will admit that I only played Mechaton for about two turns; I had to leave early in order to make it to the PAX 10 panel. What I played of it, however, was awesome. I controlled three mechs, two of which were pretty, pretty ponies (one with a laser lance, one with artillery), and the third was a small dog I used as a spotter. The rules were fun and surprisingly tight for such a whimsical game. I hope to play it again in the near future.
Crush them now, robo-pony!
This was not the only awesome stuff from PAX. I got a chance to play StarCraft 2 (zerg v. protoss comp), watch God and Cthulhu duke it out in Scribblenauts, and test drive at least 5 of the PAX 10 (as well as meet many of their creators, who were an awesome bunch). I met a lot of awesome people (see above) and caught up with old friends. I have, however, already gone on for too long and, more importantly, I do not have awesome pictures of these other things.
Final verdict: PAX 2009 was largely completely awesome.
* As it turned out this was not all bad. Because of the layover, I was afforded a rare chance to have dinner with Chris Cornell (of Paper Dino, not Soundgarden). I got a chance to play his upcoming game, which is shaping up to be a lot of fun, and to get his first reactions to FallGuy
FallGuy Prototype – The First 2.5 Days
Mon, September 14, 2009 -- 18:04 CEST
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.
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.
Hello from Pax!
Sat, September 5, 2009 -- 16:41 CEST
This was penned mid-afternoon yesterday. I was, unfortunately, not able to put it up at that time and by the time I got to the interweb I was had been[sic] drinking. That is another story for another time.
Hello, from PAX!
I am, as I pen this, sitting on a sticky floor next to what I am beginning to suspect are the bathrooms. There is no wireless in this corner, or at least no wireless that is both freely available and is also not, I suspect, poised to steal all of my personal information.
And yet, I am content. This morning, at the game design 101 panel, I had the opportunity to shake Richard Garfield’s hand and, also, to ask him about how he tests out game design ideas. He said two things that made me very happy:
1) Most of his game ideas suck and he has to weed them out too
2) He paper prototypes when he can, and makes flash prototypes when he can’t
He also said something very important: never show graphic-less prototypes to the people you want to give you money, as they usually don’t have very much imagination.
I leave you with Friday’s cosplay image:
Bang from Blaz(e)Blue
Brainstorming Part 1: The Basics
Mon, August 31, 2009 -- 17:33 CEST
This is the first post in a series on brainstorming — that is to say, meetings for idea generation. We use a lot of different techniques to generate ideas. Hopefully you’ll find some of them useful.
You need a lot of things to make a good game. You need decent art, sound, code, and levels. You need a comprehensible UI. More than any of these, however, you need a great central idea: a set of mechanics that’s fundamentally engaging and meshes well with its setting. Without that core, no amount of visual and interface polish can make your game fun.
A very pretty game with ultimately lackluster gameplay
Decent art, sound, code, and levels are pretty much a function of time as long as you’re working with good people. To get great UI you just have to put you game in front of as many potential users as you can, and be willing to take a hefty dose of criticism. Ideas take more than time and user testing. Inspiration is a strange and fickle thing. Great ideas often come from accidental realizations and chance perceptions, or misperceptions. Brainstorming is, at its heart, an attempt to harness this chaotic energy.
So, how do you brainstorm?
There are a lot of different things you can do to maximize the number and quality of ideas coming out of a brainstorm. By far the most important thing is to convince everyone in the meeting to turn off his or her critical mind. This sounds crazy, I know. After all, if no-one criticizes the ideas, then you just end up with a bunch of worthless ideas, right?
Yes, you will end up with a bunch of worthless ideas. The great majority of the ideas you come up with will be below your minimum quality threshold. The good ideas you have, however, will stand taller because they will be standing on top of a pile of the bad ones. Believe me, you will turn a critical eye to these ideas eventually, you will recognize them for the filth they are. Just not yet. I’ll talk about this more in a later article on the idea culling process.
More than anything else, brainstorming is a mindset. In order to get good ideas to come out, you have to get your brain into a place where it wants to generate as many ideas as possible. Good brainstorming practices are all about fostering this state of mind. The quickest way to stop a mind that is off in fairy land creating magical ideas is to bring it back to reality.
As an example, let’s say that I suggest that we should make a game where a turd flies to the moon. This is, pretty much, a completely terrible idea. It is a product that will not sell and turds, on the whole, do not have a lot of exciting gameplay potential. Someone else in the meeting says as much to me and, for the next ten minutes, I’m sitting there thinking about how I came up with an idea that bad and what I can do to fix it. Everyone in the meeting is stuck sitting in silence, trying to come up with a decent idea and failing because there’s nothing to build off of.
Once we turn off criticism, however, the scenario plays out differently. I suggest the game with the flying turd and Mike, thinking of all the flies, thinks of a game where you’re a fly moving from rotting meat to rotting meat. Tim comes up with a game where you use honey and vinegar to attract fireflies into a lantern you use to light up a network of dark caves. Eventually, we have a game about riding to the moon on the back of a giant moth, who you control with a lantern full of fireflies. Which is crazy, but is also, let’s face it, kind of awesome.
This is not a good idea for a game
Crazy ideas, and bad ideas too, get you to places that you never would have gotten without them. Ideas are best grown from the seeds of other ideas; by not throwing anything away for the duration of the brainstorm, you’re pulling from a huge pool of ideas.
Turning off judgment also lets the idea generation gain its own kind of momentum. People love to have a challenge in front of them, especially one they think they can rise to. Once they get into that state, however, they hate to feel frustrated and too much of a sense of failure can pull them right out of it. By cutting the negative feedback out of your meeting you can foster this sense of flow.*
Bottom line: suspending judgment is the single most important part of the brainstorm. Invite people with good listening skills to your brainstorm. Before the meeting begins, talk about why it’s important to suspend judgment. During the meeting, designate someone to watch for judging behavior and call it out. You’ll be generating awesome ideas in no time.
Next article in this series: The Warm Up!
*This principle, called flow theory, is also incredibly useful in game design. I’ll talk more about it in future posts. Meanwhile, check out Jenova Chen’s work on the subject.