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


Hello from Pax!

Sat, September 5, 2009 -- 16:41 UTC

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!

Bang from Blaz(e)Blue


Brainstorming Part 1: The Basics

Mon, August 31, 2009 -- 17:33 UTC

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

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.

Turd flying to the moon

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.


Apropos of Nothing

Mon, August 24, 2009 -- 17:31 UTC

Preamble: None of this post has very much at all to do with making video games except in the most broad ways, but I like to think about design and about how game systems inform the user experience. I choose to post this first because it lets y’all know a little bit about me: I think about game design a lot, and I like to play pen and paper games. I hope you enjoy.

There are those who believe that the 4th Edition of Dungeons and Dragons is complete and utter crap. They say that roleplaying has been pushed so far to the side that it might as well be a board game. They say, variously, that it is too complicated and/or too simple. They say that playing wizards no longer feels sufficiently awesome.

Fie, I say unto them! Except for the last part, which is mostly true.

How can you not like a game with gorilla flying a biplane AND a jetpack on it?

How can you not like a game with gorilla flying a biplane AND a jetpack on it?

My stance on 4th Edition may be surprising to those who know where I come from, roleplaying-wise. My desire to tell a compelling story is the heart of my play style.  I love games like Dogs in the Vineyard and Spirit of the Century – games that revolve around storytelling and character development rather than crunchy combat mechanics and complicated character building. As a player, I’m the guy who goes over to the dark side, and loses my character, because it makes the overall story that much better. Why, when I value the story aspect of the game so much, do I enjoy this system that is so combat-centric?

One of the things I really enjoy about more descriptive games is the ability to play combat out in a cinematic, overblown way: flips, explosions, running across the ceiling, &c. Because the descriptions are so centered around the just the game of combat, 4th Edition abilities have a lot of room for awesome description.  For example, the fighter ability Cleave — which damages two enemies adjacent to you — could be described as the suggested flavor text, “[I] hit one enemy, then cleave into another,” or you can spice it up: “I stab my sword through both goblins. Greenskin shish kebab tonight,” or as, “I slice the tendons in the goblin’s arm, causing it to fly sideways and hit his comrade-in-arms.”

The basic point is that, because the rules are so tight and specific, your descriptions can range all over the place as long as they map, generally, to the rules. You can really spice up the wizard by going big with the description on his abilities — for Burning Hands, for example, you could say, “I begin to scream unholy syllables and, as I speak, my words become broken and garbled. At once, searing light shines from my mouth as my words become tiny snakes of  flame, seeking something, anything, to burn.” This description breaks nothing about the game.

The other thing I think 4e really has going for it is that the combat is clear and doesn’t get bogged down as some other systems tend to. You always have a clear set of things you can do and you can choose to do any of them. Every once in a while you want to do something cool and, usually, there’s either a system for it, or a power you can have that does it. A smoother combat flow makes for more interesting, engaging description. It also makes for more time doing other scenes. Now, if you’re in a dungeon crawl you’re probably not doing a hell of a lot of roleplaying in towns but you just don’t have to be in a dungeon crawl. Like in any other game, combat can be an occasional spice used here and there to keep things exciting.

This is all by way of saying: if you want to tell good stories 4th Edition really doesn’t do anything to stop you. In fact, it offers real opportunities for good description and storytelling. What it doesn’t do is force storytelling upon you nor does the game itself particularly reward good descriptions. If you and your group want it, however, you can have a pretty awesome time. Even if you are a wizard.