May 31, 2008

Asp Engineering Retrospective

Asp is mostly finished by now. All that's left is to finish and include the illustrations that form the storyline of the game. Download the current story-less version here.

This game is certainly my most polished and well-built yet, but that isn't to say that I didn't make some big mistakes during the programming process. So here's a retrospective on what went wrong and what went right.

Technical Design

Having already built Squadron, I had a decent idea of how Asp would be structured. One of the first things I did when starting to build the game was draw up a list of all the classes I would need. I tried to make good use of inheritance so that I'd end up with clean and concise code.

I did make a few mistakes in this early process. For example, I hadn't anticipated needing separate classes for player squads and enemy squads; adding these two classes unfortunately involved a lot of copy+pasting. Similarly, I didn't include a PlayerShip or EnemyShip class, so each of the individual ship classes (e.g. pFighterShip) included very similar code. Still, if the only big issue introduced by these mistakes was repetitious code, I can't complain too much.

I also used some tools of Java that I hadn't needed before when I was just slapping code together until something worked. Abstract classes, enums, generics, and other features were extremely useful in architecting the game.

Programming Process

Asp was built in Ubuntu Linux. My tools were gedit and javac. I really should have used a more powerful environment, such as Eclipse, but I was comfortable with formatting my own code, and I generally kept things clean. My only big mistake in writing the code was putting so much in a single main file. The classes were all managable and orderly, but the main loop and initialization code ended up taking almost 2000 lines of code in one file.

I started Asp during a one-week spring break, and I finished the basic systems by the end of that week, i.e. ships were flying around and shooting each other on my commands.

With most games I've stopped there, but I really wanted to make Asp more complete and friendly. In between college classes this past term, I've expanded Asp to include a lot of small polishes (minor ship movements, particle systems, etc.) and a few more important elements (a menu system, a tutorial, a campaign, randomized skirmishes). Adding these elements took a lot of time, to my surprise, but I'm satisfied with the final product.

Hurdles

I occasionally hit a few problems that couldn't be fixed right away. Initial playtesting required that I make some UI changes, and I had some strange issues with loss of color depth in Ubuntu (the latter disappeared with Ubuntu 8.04, after I had given up on it).

By far my most problematic and difficult issue, however, was performance. Even when I commented out all of my main loop code excepting the drawing of my background, the game would crawl at about 20 FPS, barely playable. On my Windows machine, it would sometimes drop to as low as 6 FPS.

I did a lot of research on Java 2D graphics and performance, and I learned quite a lot. I was introduced to VolatileImages, managed images, the limitations and advantages of different Java graphics methods, and more. It's unfortunate, in a way, that I had to learn all of this since Java works so hard to keep the programmer from having to be concerned with it.

After much experimentation and asking for help on the Sun Java forums and Javagaming.org, I was able to get marginally closer to my goal. The problem was certainly that some images weren't being hardware accelerated for some reason. At first I thought that the issue involved some images (like the background) being too large, but other large images, as well as many small images, were still fast.

I continued experimenting until I eventually discovered that, while I had correctly created my images such that they should be accelerated, I had overwritten them when I loaded my images from files. The unaccelerated background images had not been touched since then, so they slowed down the rest of the game. The issue was fixed and the game runs comfortably at over 60 frames per second.

Lessons Learned

Design for your specific game, but also design with flexibility in mind.

Keep code files compartmentalized and of managable size.

Use powerful tools when available and useful.

Fix major issues when they first appear; waiting will just make it harder to deal with them.

May 21, 2008

Encoding Ideology

We finally got to talk about games in my Intro to New Media class, and as expected, it turned out to be interesting and enlightening. We began by reading two academic papers on games, both of which used Civilization 2 (a game that's closer to perfect than any other I've encountered) as an example.

One of them ("You Have Unleashed a Horde of Barbarians!" by Christopher Douglas) made the case that games are "existentially soothing", since unlike the real world, the player of a game can be sure that the game world was intelligently designed with a certain purpose and meaning for him. There is order. Douglas then goes on to argue, on a somewhat different tack, that Civ2 supports an ideology of American imperialist expansion, taming the natives of an uninhabited-yet-inhabited land. The "goody huts" in Civ2, he claims, are represented as people who exist only to be exploited or destroyed (as "barbarians").

I have a number of problems with his specific claims here, but the paper got me thinking about the interplay of game mechanics and narrative. It would be wholly possible to replace the goody huts with, say, goody caves, which might have bandits inside (to replace barbarians) or treasure or scrolls of ancient wisdom or whatever, thereby changing the narrative without changing the game mechanics. It would be impossible, however, to claim through narrative that the Sioux civilization in the game is fundamentally different and should be treated as an enemy; since the mechanics treat all civilizations alike and the Sioux are functionally equivalent to the English, this story wouldn't be consistent.

Narrative thus acts as a sort of mask over the game mechanics. You can swap out certain elements of the narrative freely, and these elements can be important in the end product, but they're ultimately limited by the mechanics. The tricky part is maintaining that consistency. I've written before about Jonathan Blow's critique of Bioshock; essentially, the complaint was that Bioshock's gameplay and its story don't match very well. What the mechanics actually "teach" the player is to shoot everything that moves from as far away as possible. On the other hand, I'd argue that Bioshock's climactic cutscene involves a perfectly consistent interplay of mechanics and message.

Blow also made the argument that games provide a world with an explicitly defined meaning of life. The world has a goal, the player has a purpose, and everything in the world is meaningful only with respect to that purpose. It actually sounds quite similar to "encoding ideology" in gameplay.

So while I disagree with Douglas's argument that Civ2's gameplay has encoded the ideology of imperialism, I think that it's fair to say that Civ2 encodes some sort of ideology. Ultimately, it's a game about expansion, growth, and domination of other civilizations. Whether or not that influences the player, displays the ideology in an artistic way, or has no effect whatsoever is a different question.

Thoughts?

May 13, 2008

Commentary: Shadow of the Colossus

I picked up SotC after hearing about how it was yet another underappreciated masterpiece. Not quite as underappreciated as Beyond Good & Evil, Ico, or Psychonaughts, but a fantastic game that everyone ought to play. So I played it.

In truth, I was pretty ambivalent at first. I was interested enough to play through the first few colossi, but I didn't have the interest to continue. The battles were well-designed and all, but... maybe action-adventure just isn't my thing.

Then I played it once with my roommate and his friends standing behind me calling out advice, and it was ridiculously fun. They helped with the puzzles, while I did my best to pull off the requisite acrobatics and attacks. The game proceeded more quickly and we burned through another two colossi.

I find that I tend to enjoy more the action side of the game. Swinging around a colossus, jumping from a giant head to a giant shoulder, is thrilling. And the puzzles were well designed. I think that there was a bit of clash when they come together, though.

In Portal, the player generally has infinite time to figure out how to proceed. Experimentation is encouraged, and the player can try out whatever and still feel creative when the puzzle is solved. SotC introduces a major danger factor. You can't sit and try to analyze the colossus for weaknesses because if you stop running, you'll die. This might be solved by adding more "safe spots" (or making dodging easier) and making the camera more friendly (keeping greater distance from the player and controlling the angle to include the player when focusing on the colossus). I doubt that you'd lose the thrill of danger, either; there's still a gigantic furry thing trying to kill you.

The best aspect of the game design was centered on the controller. Clinging to the controller corresponded to clinging to a colossus, pushing and stabbing the attack button corresponded to pulling back your sword and stabbing enemies, etc. Haptic feedback was used for heartbeats, charging your sword, and other subtle but inspiring effects.

I had some trouble with the narrative. Others have commented that the colossi are sympathetic characters much of the time, but nothing was really done with this; it never factored into the story. Jonathan Blow talks about finding elements like this and incorporating it into the story, resulting in masterpieces like the Weighted Companion Cube. SotC left this out. And while the game nailed the feeling and flow of a grand tragedy, it might have overdone the ambiguity. It's a tale that would do well to have morally charged content, but our only clues to what is right or wrong is what looks good or looks evil (and as Ico taught us, horns aren't necessarily a bad thing).

Except Agro. That was done well, and deserves credit for subtlety of execution.

May 8, 2008

Commentary: Interactive Storytelling by Andrew Glassner

It turns out that Dartmouth has an Interactive Storytelling course, which is awesome. It also turns out that I'm not allowed to take it. Which is something less than awesome. But the professor is quite nice and allowed me to borrow the class textbooks. I already talked about the first, Chris Crawford on Interactive Storytelling, and it's high time I bit into the other, much thicker book.

Andrew Glassner's Interactive Storytelling is straightforward and thorough. The book is meaty and nutritious for game designers, while Crawford served a more exotic dish. Glassner divides the book into the Story section, the Game section, and the Merging section. Each gives an overview of all the fundamentals that Glassner can come up with.

The Story third of the book reviews common plot structures and features of stories (since time immemorial), and it includes some basic helpful hints. Avoid direct on-the-nose dialogue. Villains must feel internally justified. Characters should have interesting internal lives as well as external ones. It's a lot of bread-and-butter advice of the sort that would be most useful to someone coming from a more technical background.

The Game section is easily the weakest. Glassner spends most of it listing the different ways in which games can be classified. While constructing a vocabulary for the medium is important (and even inspired a few earlier blog posts), this sort of listing didn't really build to anything. Glassner never applies his classifications. We're left to wait for Raph Koster's game grammar for that, I suppose. But this section did include a few interesting ideas, such as a few thought experiments borrowed from game theory and an introduction of the Go terms sente and gote.

The section discussing the merging of games and stories is certainly the heart of the book, and most of the interesting analysis shows up here. After a brief comparison of the forms (identifying several polarities), Glassner entertains the idea that perhaps it's impossible to have a game and a story work synergistically. He makes a good case that it can't be done. In fact, he makes such a good case that one starts to reconsider the whole book with skepticism.

But Glassner is willing to offer enough interesting ideas in the rest of the book that the reader's enthusiasm (if not his confidence) is restored. After discussing and identifying several options (multiple-choice dialogue, hypertext fiction) and making some critical observations (loss of control always breaks immersion, "believable" is more important than "realistic"), Glassner concludes by listing a set of hypothetical interactive story "experiments". They're all quite intriguing, and they leave me with some hope that a merger of these media can be accomplished.

My one gripe with Glassner's approach to uniting stories and games is that he seems to require the resulting story to be entertaining to watch. Again and again he makes the (correct) claim that "people are bad actors." But we aren't asking players to act for the benefit of an audience. All we're asking is that they experience the story firsthand.

Call of Duty 4, as the highly-regarded game critic Ben Croshaw pointed out, has a run-of-the-mill, modern conflict grab-bag story. Some Arabs here, some Russians there, throw in a nuke or two and ship the game. But the focus on immersion and the first-person experience made the game ridiculously fun and, more importantly, genuinely moving. It's that sort of focus on the player experience that will establish games as an art.