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.

Business Time (Part II)

by Tim
Fri, August 28, 2009 -- 18:16 UTC

This is the second installment of what I suspect will become a weekly series of articles on our adventures in starting our own company. If you haven’t read the last one, you might want to check it out here. Today’s topic is: The Partnership Agreement.

As you most likely know, incorporating is all about creating a collective legal body that represents your business, which can be convenient for a number of reasons. For one, this entity can acquire and own property, and can transfer it to other people. Secondly, it can represent a sort of a firewall against debt and lawsuits; a straw man that will burn in effigy for your mistakes. Lastly, it is immortal, in that it endures even when those that created it have passed on. You may have noticed that some of these qualities are shared by golems, robots, voodoo zombies, and Giant Robo. This is because they, too, are mindless automatons that possess no soul of their own*. They are surrogates that can only be operated by proxy.

You and your corporation!

You and your corporation!

When you incorporate, you are given your very own legal entity that you can use to do business with the world at large. The tricky question is who gets to control it, and under what circumstances. The answer lies in the Partnership Agreement, which is the subject of today’s post. When you found the company, you establish a contractual set of rules that govern the inner-workings of the corporation. These rules must be arrived-upon in advance, to resolve any number of hypothetical future disasters. Some examples of the kinds of questions the partnership agreement should attempt to answer:

  • When making major decisions, how should they be decided? An executive decision-maker? A vote? Consensus?
  • What happens when a new parter joins the company?
  • When the company makes money, who gets it, and how much?
  • Who decides what the company does and doesn’t spend its money on?
  • If someone puts more money in, should they get more money out, or get their money back first?
  • If someone leaves the company, do they get to take their contributions with them?
  • If someone dies or becomes permanently disabled, what happens to their share in the company?
  • What happens if someone stops showing up to work, or gets another job?
  • Involuntary termination: What happens if someone starts stealing from the company, commits a felony, goes insane (like, clinically insane)?
  • If a third party wants to buy someone’s share in the company, is that allowed?
  • If the sale is allowed, does that person become a decision-maker, or just a money-maker?

It took us a while to come to agreement on the answers that best matched our vision of the company. In particular, we opted for decision-by-consensus for all major decisions, such as bringing on a new partner, selling the company, etc… We also decided on an even-split on profits, with equal initial investment. Suffice to say, you will want to find a lawyer with whom you can discuss the best solutions people have found to answering these questions. The implications of these decisions are very serious, and there are some popular answers that do not play nice with consensus-run organizations.

It was interesting, having the three of us and our lawyer in a room, talking about the various common nightmare scenarios that come up when you set out to share decision-making power with other human beings whose vision, needs, and goals can never fully line up with your own. Looking around the room, you must force yourself to imagine how those that you most trust might some day be standing on the other side of a line you drew together in the sand. I imagine that this is similar to what it feels like to draft a pre-nuptial agreement. It was sobering, and it is my hope that I will never come face-to-face with the scenarios we so carefully shielded ourselves against in that document. Still, one cannot help but wonder what a post like this looks like when you return to it years later.

After a few serious meetings, we arrived at answers we were willing to stand by, with our lawyer taking on the task of drafting it into a legal document. It took a while to figure it all out, but there’s clearly a great deal of value in coming to an up-front legal agreement regarding your basic management and ownership assumptions. Going through this process showed us that there are a number of problems that are very hard to resolve if you do not decide on the answers to them in advance. That’s it for this installment, check in next week for Part III!

* = Except for Robo, who posesses a soul and learned long ago how to love.

How We Met

by Mike
Wed, August 26, 2009 -- 19:29 UTC

At some point in their history, companies of any sort seem to depend on a significant amount of time spent sitting down and discussing Matters Of Importance. Final Form is no different: we have meetings every day. However, in the early days of furtive after-work gatherings and secret wikis, they were more than just a way to share information and make decisions.  Meetings were hugely motivational to us, and played a pivotal role in keeping the whole enterprise moving on the steep up-slopes of our first few years. Today’s post is going to ramble a bit about how we got those conversations to happen, make the occasional jest, omit plenty of crucial details, and hint at some lessons learned without actually making them explicit. Now: come away with me!

Final Form took shape the way most collaborative endeavors do: in fits and starts. We all shared a desire to make games together, but the details of how and when that would happen were hand-wavey to say the least. At the beginning, we’d make time for occasional bursts of productivity, and have ad-hoc group discussions whenever the stars aligned, but it wasn’t until somewhere around the summer of ’07 that we committed to meeting on a weekly basis. That decision was an encouraging indicator of how serious we actually were about the whole enterprise, but it was also a logistical challenge that taught us quite a bit about how we’d function as a company.

We did several experiments with our schedules, particularly with our willingness to physically transport ourselves any more than 10 feet from bed on a weekend morning. As it turned out, our ability to lurch into action after a Friday-night bender greatly exceeded our expectations, and meetings on Saturday mornings became the routine. These were held in person at first (at one of our houses) and then, during the one-year rolling transition from California to Pennsylvania, via some combination of in-person (for whoever had that option) and a rotating cast of tools including Skype, GChat, a wiki site, Google Docs, a dev blog, iPhone 3-way calling, and cellphones set to “speakerphone” mode. Under duress, we would chain these techniques into multi-hit combos like “cellphone set to speakerphone mode and then held up to a built-in laptop microphone that’s transmitting via Skype,” and other fun mash-ups with myriad (and hilarious) side-effects*.  Most meetings were between one and two hours long. Ideally, these meetings were followed by a sandwichcraft master-class demo at Gregoire.

The meeting finish line.

The meeting finish line.

We learned some valuable stuff by doing this.

The obvious:

    Spock collaborating hella efficiently.

    Spock collaborating hella efficiently

  • When it comes to a multidisciplinary discussion of the intricacies of videogame development, face-to-face conversation is intuitively easier, higher-bandwidth, and (by virtue of that bandwidth) tends to be higher efficiency than basically any other mode of communication that isn’t a Vulcan mind-meld.
  • When you only touch base once a week, Efficiency = Good. Two hours can become six in the blink of an eye when you have a week of solo time to cover per person.
  • Our commitment to the whole idea was tested by the intrusion of our real jobs and lives into what was essentially a glorified side project. When crunch time for work snatched one of us away like a thief in the night, the other two had to keep meeting and sustain momentum while that person was grappling with the forces of evil. Once that person emerged, often a month or two later, having the other two standing right there to say “we’re still here, here’s what’s been going on” went a long, long way towards convincing each other that we were all in it to win it. Tim often used to say that he hoped for a company where every single person was crazy enough to finish the project alone if wild circumstances robbed them of their compatriots. Overcoming these challenges didn’t just keep the ball rolling: it also showed us we were the right kind of crazy.
  • Google Docs is pretty neato! It provided us with a very good method for collaborating and sharing significant quantities of information, all while remaining more or less in sync over large (3000+ mile) distances.
  • Gregoire makes a rude sandwich. Possibly the rudest.

The not-so-obvious:

  • As neato as it is, Google Docs has some pretty for-real limitations that caused headaches for us when the difference between Almost Real-Time and Actually Real-Time began to matter. As Tim pithily tweeted last week, “GDocs is beautiful tease who offers you the things you’ve been dreaming of, but she will let you down once things get serious.” We suspect/hope that within the next year or two, Google Wave will be perched atop a throne fashioned from the skulls of 1st- and 2nd-gen web 2.0 apps, and that the befouled remains of the entire Google Docs suite will be providing little more than lumbar support to the tool they tried and failed to be.
  • If your roommates use bittorrent on a communal network connection (to share recipes, say), they probably A) generally start it running late at night and B) aren’t awake early enough on Saturday to respond when you wonder aloud why someone is attempting to download the EGI (Entire Goddamn Internet). If this happens to you, kiss your Skype session goodbye.
  • Being forced to communicate through something sub-optimal (from an efficiency standpoint) exerted a lot of pressure on us to increase our efficiency in the areas we could control. We started coming to meetings with more material in a presentable form, often sending the materials out via email hours or even days before the meeting itself. Regimented meeting durations, with each minute of each section budgeted and accounted for, became the norm. We took notes while other people were talking, to make sure we didn’t squander time interrupting a coherent thought out of fear that we’d forget what we wanted to say. We established rotating jobs like Stenographer and Timer, to smooth out transitions between meeting sections and keep people accountable for how long they talked. We started reviewing minutes, to remind ourselves of what we’d already spent time discussing. Finally, we postmortemed every meeting in order to revise and optimize our meeting process (more on that in our inevitable Postmortems Are Civilization post). This was particularly important in a dynamic environment where the location, participants, and available communication tools were changing meeting-to-meeting: one process couldn’t fit all. We got very good at the agile application of traditional meeting techniques, simply as a result of being forced through the crucible of serious inconvenience.

For the results-oriented among you, we’re sadly not quite ready to throw down some definitive takeaways from the story so far. The transition into daily in-person meetings is still underway, you see, and who knows where those new data points will lead us? We’ll probably get into it in some eventual Part 2. In the meantime, we welcome you to vigorously defend Google Docs’ honor (or bemoan the time you’ve wasted in meetings) in the comments.

* The on-board microphone on the Axiotron Modbook is situated flush against the cooling fan for the whole computer, which results in your friends on the other end occasionally interrupting the conversation to politely ask if you’re calling from the interior of a jet engine, or perhaps a combine harvester.