I finally got around to posting documentation for a bunch of little projects I made while I was at USC.

Among them is a game called WhiteSpace, which eventually grew into my current project, The Unfinished Swan. Note that the project started in color, then changed to black and white (unlike just about everything else in the world, which tends to go the other way — films, newspapers, cell phones, etc). I’ve also included footage of the non-interactive previsualization, which is a design methodology I should really talk more about on this blog. In fact, looking back over all these projects I think getting comfortable with non-interactive prototyping was one of the most helpful lessons I got out of grad school.

Basically, making interactive prototypes is hard and often unnecessary. Doing non-interactive prototypes like animations, physical mockups, or shooting video footage can get you most of the way there for a lot less work. And in the early stages all you really need is something concrete to help you visualize where you want to go, as well as to help you start communicating what’s in your head to other people.

Another lesson I’ve taken away from these sketches: quantity is often more helpful than quality. As a designer there’s a huge temptation to make things perfect, or at least less-sucky, and that’s great for later in the process. But early on you’re better off just throwing a ton of ideas at the wall to see what sticks. Or to put it more bluntly, the desire to polish can insidiously prevent you from actually getting anything done. The blog Coding Horror had an interesting post on that subject awhile back related to a pottery class that was given an option to spend their time making one perfect pot or lots of crappy ones.

These sketches are like my shelf full of misshapen pots.

The company’s name is Giant Sparrow and its mission is to create surreal experiences people have never had before. Our first project is a commercial version of The Unfinished Swan for unannounced console downloadable platforms.

Hopefully I’ll be able to talk more about all this soon. In the meantime all I can say is that we’re currently looking to hire a:

• Lead Programmer
• Physics + Gameplay Programmer
• Art Director

If anyone knows people who’d be a good fit, please direct them to our job descriptions.

I presented a new project this week at the Interactive Media Department’s weekly seminar.

It’s an interactive piece called The Remains of Isadore McMurtlemumsy about a clumsy little boy who keeps losing his body parts. There’s a full writeup (including video of the performance) at the link above.

The best part about grad school is finally having enough time to “do all the nothing you want.” Which is why I was able to sit down recently and teach myself the basics of fluid mechanics.

I came across two surprisingly wonderful books I thought worth mentioning since it’s unlikely most people would ever see them.

The first is the dryly titled Fundamentals of Aerodynamics by (the also dryly titled) John Anderson. It’s an undergraduate textbook for engineers that opens with one of the most riveting passages I’ve ever read:

On August 8, 1588, the waters of the English Channel churned with the gyrations of hundreds of warships. The great Spanish Armada had arrived to carry out an invasion of Elizabethan England… On that crucial day in 1588, when the English floated six fire ships into the Spanish formation and then drove headlong into the ensuing confusion, the future history of Europe was in the balance. In the final outcome, the heavier, sluggish, Spanish ships were no match for the faster, more maneuverable, English craft, and by that evening the Spanish Armada lay in disarray, no longer a threat to England. [The battle] taught the world that political power was going to be synonymous with naval power. In turn, naval power was going to depend greatly on the speed and maneuverability of ships. To increase the speed of a ship, it is important to reduce the resistance created by the water flow around the ship’s hull. Suddenly, the drag on ship hulls became an engineering problem of great interest, thus giving impetus to the study of fluid mechanics.

It’s too bad the book is all downhill from there. But how could it not be? At some point you’ve got to stop talking about British naval victories and move on to the equations.

Album of Fluid Motion deftly sidesteps that problem by avoiding text entirely. It’s a book about fluid mechanics that’s ALL PICTURES (and captions).

This is surprisingly helpful since part of what makes fluids so hard to understand is the complex ways in which they interact with themselves. It’s also interesting to see the range of techniques used to visualize fluid flow including: air bubbles, smoke, aluminum dust, oscillating a cylinder with a loudspeaker in a mixture of water and glycerin, and coating a cylinder in condensed milk and pushing it through water.

The photos are unfortunately a little blurry. There’s a similar, more modern book (which I haven’t read yet) that looks like it may have clearer pictures called A Gallery of Fluid Motion.

I’ve had a pretty mixed experience with the classes at USC but the wide range of notable folks who pass through in a given week makes up for a lot. This past week more so than most.

As part of an event celebrating Tracy Fullerton being awarded an endowed chair I was asked to setup a public demo of The Unfinished Swan. The first player? John Riccitiello, CEO of Electronic Arts.

He seemed really into it. We had a chance to talk for several minutes and he had some very interesting suggestions. Of course this is the same man who wanted Mirror’s Edge to switch to a third-person perspective, though he’s big enough to admit that might not have been a good idea in hindsight.

This week I also had a chance to meet Eskil Steenberg, who stopped by to demo his game Love. It’s an MMO being developed by a single man (Eskil Steenberg). It’s astonishingly beautiful as you can see from the screenshots and teaser video.

Since I have a tendency to work in isolation myself I can totally appreciate Eskil’s one-man-band approach to game development. Although I’m personally trying to force myself to work more collaboratively, the principles of working on an ambitious game in a small team are pretty similar to working at it alone. In order of importance, I think it comes down to: (a) knowing what to cut, (b) knowing the tools, and (c) knowing when the existing tools aren’t good enough and you’ve got to roll your own. Eskil is even more obsessed with tools than I am. A lot more.

For starters he wrote his own 3d modeler, Loq airou. And it’s gorgeous. The application starts up with two soft blue point lights gently rotating around each other in a black void. For comparison here it is next to the ghastly startup screen for Maya, the industry standard 3d modeler:

It’s impossible for me to be objective anymore about Maya’s interface. I’ve spent hundreds of hours using it so it’s become more-or-less intuitive for me now. After 5 minutes of Loq airou I’m still completely baffled by it. As far as I can tell there’s no keyboard input — everything is driven by a sequence of mouse clicks and drags that seem cryptic to me but no doubt make perfect sense to Eskil. To be fair, my first experience with Maya was somewhat similar.

And even though I can’t say how much usability was sacrificed for its elegance, Loq airou does have some wonderful touches. Like when you delete a line and it bursts into a zillion particles that scatter across the screen. Or when you click a node and there’s a dazzling flash as if you’d fired some sort of, I don’t know, tachyon cannon or something. For a 3d modeler it feels quite game-like, in a nice way. It reminds me of a developer (maybe Kyle Gabler) who said games should be as “squishy” as possible, meaning that every input from the player should produce some gigantic and pleasing output, even if semantically it’s just a banal acknowledgment that a button’s been clicked on.

Jonathan Mak gave a fantastic talk on visual outputs at GDC last year. I can’t find any video from his talk, just text and audio, but the gist is that even bare bones prototypes benefit from a bit of polish. As I remember it, Jonathan had a plain circle jumping and then a (much more interesting) circle with a beanie hat on which added secondary animation.

Anyway, Eskil and I had a great chat about tools and indie game development. Which of course included a discussion of Introversion’s fantastic procedural city generation work. We’re both in agreement that good tools should help you iterate quickly on problems. No surprises there. And then Eskil mentioned that Love is written entirely in C. Which seems a little crazy to me.

Because conventional wisdom has it that C is the least malleable mainstream language out there. Even people who grumble about the quirks of C++ will toss in a “but at least it’s not C.” But what do I know, I spend most of my time way off in managed-code land. I guess the fastest tool is whatever works for you.

And judging from the current state of Love, whatever Eskil’s doing seems to be working just fine.

Although I couldn’t help noticing one significant ommission in the current build: there’s no sound. No music, no sound effects, nothing. And this is a game that’s been in development for around two years now, though Eskil said he plans on adding sound soon. Clearly he’s a very visually-focused guy — and he’s got the screenshots to prove it.