Furious Coder

I've been diving into the development of my next Interactive Fiction title for the 2008 IFComp, which will be my second title after the '04 Comp 8th place winner, Splashdown.  Getting back to writing IF is like sliding into an old, comfortable pair of jeans.  It's familiar and welcoming, a form of "Comfort Gaming" if you will, as it brings back memories of a youth spent playing Infocom titles like Planetfall, Hollywood Hijinx, Ballyhoo, and Wishbringer.

In fact, after a conversation with my wife, I realized that those Infocom titles hold an emotional sway over me that has rarely been matched by any other game I've played.  Sure, Interactive Fiction doesn't have hyper-realistic graphics or sound effects, and thus the "game" takes place in ones imagination.  This leads to part of the emotional attachment, of course, as each player fully internalizes the game play, and carries their own unique memories and vision of what the game experience was like.  However, I realized there was something else about these games that forever made them seem more real than any titles that came after Infocom on other platforms.

By the time I was fully immersed in the Infocom phenomena, all titles were released in what was called the Gray Box Format, that being a box about 7" wide by 9" tall, and 1" thick.  The box opened like a book, with a 20-ish page booklet attached to the box, the first half of which contained a storybook, fake magazine, catalogue, or some other kind of informational media purportedly from the game itself.  (The second half of the booklet contained the game instructions.)  Behind the booklet was a plastic covered depression containing what Infocom called "Feelies", more physical items from the game world.  For Wishbringer, this included a stamped envelope and letter, a map, and a plastic glow-in-the-dark "magical stone".  Ballyhoo had a flyer for medicinal extract, a ticket stub for the circus, and a branded inflatable balloon.  Often, some of these feelies contained clues or vital information required to finish the game, but the vast majority were there simply to enhance the atmosphere.

Feelies did much more than add polish to a game, at least in my opinion.  While providing vital copy protection and additional amusement, they made the games themselves that much more vivid and real by bringing the game world itself into our real world.  Here we had game parts that could be looked at, yes, but also touched and felt and manipulated and smelled.  There were special moments when, stuck on a particular puzzle, I would hold the plastic Wishbringer rock over a lamp for a few minutes, then turn out the lights and stare at it's eerie purple glow, wondering what the solution to the problem could be.  Or I would hold the Ballyhoo circus ticket in my hand, and imagine myself stepping under the Big Top, smelling the popcorn and the lingering odor of elephant.

These additional items added a visceral quality to the games that has been lacking in any title since, and even in the majority of the IF freely available today via the Internet.  While today, there is a push towards cover art and standards of documentation, images and audio within the IF community, I still long for the whole experience of the feelies, to be able to embrace the game world physically, to open that booklet, and to scatter pieces across the table and look at them in wonder, artifacts from an alternate world.

It is my opinion that we will only see a widespread acceptance of IF in the larger gaming community when we deliver packages that are not only excellent games with innovative puzzles and top-notch writing, but also the "whole box experience", feelies and magazines and manuals, items unique to each title that become keepsakes and articles to be admired.  When this happens, console and PC games will seem lacking that extra dimension that cannot be provided with more advanced pixel shaders or better audio algorithms.  Instead, the entire IF title, package and all, will become a collectable treasure to be experienced and shared, and will be a far more immersive experience than can ever be provided via code alone.

Over the past few days, I've finished up playing Bioshock on the XBox 360, and Call of Duty 4 on the PC.  In addition, I've also experienced some retro fun by replaying one of my favorite games as a teen, Neuromancer for the Commodore 64 (via emulator).  Two of these games have pretty strong RPG elements, and all three have a lot of story to them, which has made me think more about gaming, and what I expect from gaming.

Film critic Roger Ebert has spoken about one of his personal qualifiers for great movies, that being that a great movie shows him something he's never seen before.  CoD4 qualifies here for me with it's Spectre Gunship mission alone.  Likewise, the Objectivist Art Deco undersea environment of Bioshock is also unique among video games, and Neuromancer displayed the first video game images of cyberspace, themselves first colorfully visualized in the book of the same name.  While the Gunship mission is a clear reference to a real life incident in Afghanistan, viewable on YouTube, all these games utilize the video game medium to take the character to places they've never experienced before interactively.

However, it's not enough to simply do something new.  Even in 1988, Neuromancer was rich with story and context, cramming a virtual city (albeit a sparsely populated one) and a realized computer network into 64kb of RAM.  The world of Rapture is rich with personalities, memories captured on audio-diaries, fully realized retro-futuristic locations, and psychopaths that would make Hollywood splatter films jealous.  CoD4, for all it's running-and-gunning, attaches the player to the characters with some excellent writing, voice acting, and NPC cooperative action.

What makes all these games great and memorable is the overall polish and experience that they provide.  Too often, games are just another "me too" form of entertainment, displaying the same gameplay as countless others with only different textures and locales.  Even ambitious storylines are sometimes watered down to amateur quality by poor acting, weak graphics, and an overall anemic effort.  Truly top notch games, titles that stand the test of time, provide an emotional experience for the player.  These emotions can be driven by a "wow factor", as well as by being fully immersive and creating characters that the players care about, whether they care about loving them or hating their guts.  Hardly anyone today would argue that Neuromancer is a beautiful game by modern standards, but for the time, it was rich, interactive, and very compelling.  Even today, reading through endless "BBS posts" within the game and interacting with characters like Julius Deane and The Finn, this game draws the player into another world of covert cybercrime.

I think we're finally crossing the boundary where story-driven games (as opposed to casual pastimes or simulation driven titles) can really come into their own as an art form.  It's not just the graphics and incredible sense of realism, but the whole package of polish, compelling story, and wow factor that create truly standout titles.  I'm looking forward to 2008 and 2009, since I think we're going to see some really amazing titles coming out over the next two years.

I was just interviewed for MSN Games "Casually Speaking" series, and while the illustration doesn't exactly highlight my best assets, the rest of the article is pretty cool.

Check it out here.

Three weeks ago, our six-person core team released a new casual game on the MSN Games website, “Hop-It”, which has proven to be reasonably successful in spite of almost no promotion or advertising whatsoever.

I wanted to talk about the process of “finishing”, what it means to complete a title, and share some observations from this last project as well as some previous projects regarding the final crunch towards shipping a product.

At a previous company, I distinctly remember a particular game which was going nowhere fast, ironic, as this was supposed to be a Formula Racing game. (This game was not Forza Motorsport, which was very well managed.) I wasn’t sure why the game was taking so long, as this was only the second videogame title I’d worked on, and while there were some snags, it didn’t seem too unusual compared to previous projects on which I’d worked. The problem, as I came to understand it much later, was that the Lead Developer was essentially running the title, but really didn’t understand what he was doing. There was a project manager, but she was more or less ineffectual, and the Lead Dev overruled her with his masculinity. At the same time, the Lead Dev continually placed blame for shortcomings of this product (poor performance, lousy art, long load times) on everyone but himself. It was the artists fault that the performance was bad, because there were too many polys. It was my fault that the load times were too long, because the network sync was too slow. And so on.

At some point, the managers of this particular company brought in a new Project Manager, someone they considered to be “a Finisher.” At the time, it sounded like the proverbial Closer, a person who completed the deal, occasionally by questionable means, but you could be sure whatever needed to get done got done. This particular PM certainly got things moving. She didn’t put up with the machoism of the Lead Dev, and called him out on several of his deceptions (there’s really no nicer term) and got him back on track. She made necessary cuts, streamlined the process, and got daily status reports on this title that kept the schedule in check. By the end, we did finally “finish” the game, and lots of people came up to be afterwards to say “see? She’s a Finisher!”

They way they spoke this term, though, it seemed that it took a special kind of person to be a Finisher. I didn’t really believe that, and still don’t, as there weren’t any training courses one could take to become a Finisher, and there was no set of qualities that a person could point out to state whether or not any particular person would be a good Finisher. It was just a label, like naming a person a wizard or a guru or a mad genius, and then explaining that term away with “well, just look at them!”

Unfortunately for these people, software development is engineering and a science, and is more skilled trade than art. Even business, good business anyway, follows a tested set of practices, and improves through iteration and exploration, not through any arcane set of mystical talents pulled forth from the Æther.

This brings us to the current project, which, while very good and very polished, began a slip into a fog of uncertainty, but was rescued when we found our Finishers. Actually, most of the team turned out to be Finishers, and the transformation we underwent to realize that we were, in fact, mostly composed of Finishers who could Get Stuff Done™, we hit an amazing stride of productivity and kicked our product up to a new level of polish.

So what does it take to unleash the inner Finisher? How does a team successfully finish a product? The following qualities were the ones I observed occurring when the Hop-It team hit their stride and focused on finishing this game.

• Risk Management- At some point, we all became extremely risk aware. This meant that we could each visualize and articulate to the rest of the team the impact that any additional changes to our product would make. We became very no-nonsense about not accepting any Feature Creep towards the end, and stuck to our guns and our tasks in order to meet our schedule. There was some pushback on this, but to correctly finish, we found we had to be highly disciplined about eliminating risk in order to get the right stuff done.
• Fast Communication – Albert Brooks famous book “The Mythical Man-Month” correctly describes how the real limiting factor on large teams is intercommunication. Adding a new person to a team doesn’t actually grant a project one more person’s worth of work, as there is now a new communication dependency. To get around this, we found that several team members would have fast, informal, clarifying meetings to address issues, where decisions were made on the spot by the people with the best information. We found that we developed a high level of trust after a few weeks of this, as people very quickly knew who needed to be involved in what hallway standups, or deskside chit-chats, and the decisions made moved the project forward without requiring formal conference room style get togethers.
• Going Above and Beyond – Each of us on the team began doing tasks that were not strictly in our job description in order to provide proper coverage. This wasn’t instead of our normal jobs; we did those too, and quite well. But we also stretched ourselves to make sure all necessary tasks were being completed, even if that meant doing the work ourselves. We also found that we became a lot more focused on solving problems properly, individually and in two person groups, rather than placing blame for problems on other team members and walking away. This passion, which was less crunch than drive, really pulled the end of the project into a smooth high gear for the final stages of the game.

There’s one example of a last minute bug that summarizes all three of these points, and really solidified that we were a bunch of Finishers on this team. An interaction with another group’s product was causing a bug in our game that would have made for a very lousy user experience. The other dev on this product hunted around and discovered the root cause, and then talked to the other group and found out they wouldn’t fix the behavior in their product that was causing the bug. At this point, the other dev pulled myself, our tester, and the Lead Developer for the entire group into a hallway meeting. He started explaining the problem and possible solutions, and I distinctly remember my Risk Management alarm going off at one point when I bluntly stated “I hate all these solutions.” Perhaps not the most eloquent way of phrasing it, but my point was that while I realized the other developer was presenting solutions, they were all risky to the game and the schedule. Finally the developer thought about our game for a few seconds, and then realized a simple change he could make that would have only minor impact on the game but would solve the problem. Since I was the other person in the group most familiar with the code base, I immediately realized the impact would be minimal, and I signed off on that change. It wound up working perfectly, and the bug was resolved.

In this five minute meeting, we had a developer who Went Beyond, taking on the tasks of test and development, as well as inter-team communicator, to find the cause of the bug and to come up with possible solutions. We used Fast Communication to shotgun the information to the necessary people, and I was the primary voice of Risk Management, filtering possible solutions through my understanding of our code base and steering the team towards the least risky solution that would work.

By following these steps, attitudes and qualities that were not even quantified before the end of this product, we all became Finishers ourselves. We took on the roles necessary to complete the game, and drove constantly towards delivering a high quality game on schedule. We proved that it doesn’t take a special person to be a Finisher, it just takes the right attitude, the right mindset, and the willingness to get something truly completed correctly and on time in order to be Finished.