Monday, June 23, 2008

Video game apologists: Looking for art in all the wrong places

Alright, I can't take it anymore. For the umpteenth time, a video game fanboy has tried to substantiate the claim that video games are art by pointing to Final Fantasy and a bunch of in-game cinematics. Gaaah. Somebody is wrong, and I must speak.

Video games can be art, but not for the reasons these guys think.

First of all, Roger Ebert was so transparently wrong to begin with that it's almost ridiculous that gamers got defensive about it. Ebert's claim was, in short, that games cannot be high art because they require the participation of the player. By this standard, architecture, sculpture, and installation art are not high art, since full appreciation of those works requires the audience to navigate a space established by the work's form. But that's ludicrous. Any definition of art that excludes these forms is silly on its face.

I mean, come on. Are you telling me Roger Ebert knows more about "art" than the MOMA and the Guggenheim Foundation? There's just nothing to prove here. Don't even bother trotting out your favorite games; it's wholly unnecessary. This claim can be disproved a priori.

On the other hand, as the foregoing analogy illustrates, the other art form that video games most resemble is not cinema; it is architecture. A large contingent of video game apologists, eager to prove that their favorite form deserves the cultural capital endowed by the label "Art", have latched onto the cinematic properties of video games. This is probably because, in our day and age, cinema possesses a cross-product of high-culture respectability, low-culture accessibility, and economic influence that no other art form comes close to matching.

But likening video games to cinema is a fundamental error. Video games may borrow the aesthetic language of cinema, in the same way that architecture can borrow painterly or sculptural gestures, but the nature of a game is that it is an abstract state space through which the player moves. Indeed, video games, like computer code in general, can be viewed as simply the abstract version of architecture.

And so it's not surprising that, although games have come a long way, the games that currently try hardest to be "cinematic" almost always end up being unsuccessful as art. My definition of successful art is this: an artifact that provokes a powerful and seamless aesthetic reaction in the viewer. A good art work seduces us into believing wholly in the world that it proposes, whether that world consists of the abstract geometries of a Mondrian painting or the intricately braided themes of a Beethoven symphony. "Cinematic" games like Final Fantasy, Mass Effect, etc. foolishly attempt to create a game world by mimicking the conventions of mainstream narrative feature film. And they fail — because mainstream narrative feature film centers on interactions among people, and today's computers are incapable of producing even vaguely convincing simulacra of human beings.

Walk up to a character in a typical "cinematic" computer game and say hello. Then say goodbye, turn around in a circle, and say hello again. Chances are, the conversation will go exactly the same way. You can do this a dozen, a hundred, a thousand times, and not once will the character notice that you're acting a little strange. And let's not even get into the painful stiltedness of dialogue trees.

Now, traditional narrative art forms like fiction, theater, cinema, and comics are all unrealistic in numerous ways. But this doesn't matter; our brains are wired to forgive many infidelities in representation, so long as human interactions follow a logic that is recognizably human. Or, at least, as in David Mamet plays, that they follow a course that's deliberately crafted for aesthetic effect. By contrast, conversations in computer games are not deliberately crafted to be stilted, artificial, limited, and repetitive; they just are, because of technical limitations, and an attentive audience can never escape this realization.

Thus, most so-called "cinematic" video games can be highly effective entertainment, but they can at best be middling art.

So when do games succeed at being art?

I can't lay out comprehensive criteria, but I can give a few examples. It seems to me that the following games actually succeed at creating experiences that are both seamless and aesthetically powerful, although in different ways:

  • Geometry Wars Retro Evolved. Yes, you heard me: Geometry Wars (UPDATE 2008-10-26: note that this video does not use the in-game soundtrack). It's the ecstatic love child of Stan Brakhage and a techno music video, in video game form.
  • Shadow of the Colossus. This is the rare example of a game that achieves seamlessness despite being relatively cinematic in presentation. Pay attention, and you'll see how this game succeeds where other games fail: you're practically the only living human being in the whole game. Almost everything else that moves is either an automaton or an animal. The experience is nearly wordless. The aesthetic texture (the visuals, the sound) is breathtaking, but also exceptionally stark. If Shadow of the Colossus were a film, it would be an art film; no mainstream Hollywood studio would greenlight it. And within the dream logic of its lonely world, everything fits together. I could write a great deal more about this game and how it speaks to me, but that's a subject for another day.
  • Echochrome. An abstract exploration of spatial perception and motion with immaculate visuals and music. Would not be out of place installed in the MOMA.
  • flOw. If you like Mark Rothko paintings but not flOw, then I claim that you are a hypocrite.
  • Katamari Damacy. This game is not exactly my bag, but both as a work of absurdist aesthetics and as a cunningly crafted explorable state space, I cannot deny its success.

Now, to the above list, I can add a very long list of games that succeed wildly at being entertaining, and have some merit as art, but don't fully succeed at the latter. For example, BioShock, Okami, and the Half-Life 2 episodes achieve higher quality, both as entertainment and as art, than 99% of television shows or movies; but you can see the man behind the curtain a little too often for them to be wholly successful art works.

Lumines is the video game equivalent of pop music, and roughly as artistic.

And then there are games like Civilization, which manage to be tours de force of complex state space design, but aesthetically barely rise above the level of a board game. If Civilization IV were a work of physical architecture, it would be the New York subway system.

And so on, and so forth. Basically, many video games succeed as entertainment; some of those manage to be less-than-great art; and a very small number manage to achieve a unity of presentation and gameplay construction as to be really good art. And given how far the circle of "art" has widened in the past century and a half, only the most blinkered kind of fool would claim otherwise.

But please, please, stop trying to convince people that games are like the grown-up little brother of cinema (or, even more nonsensically, of literature). They're not. I mean, really.

p.s. I have deliberately elided all mention of multiplayer games, which deserve a whole other analysis. To what extent can collective experiences be art? The Fluxus movement's answer: plenty. Presumably computer-mediated participatory group activities can in theory be art as well. My major uncertainty is that I don't think I've ever played a multiplayer game that I'd describe as a "seamless aesthetic experience". One thing's for sure: listening to a thirteen-year-old bitching into his headset mic does not qualify.

* People familiar with the world of academic game criticism may recognize the distinction I draw as one of "narratological" versus "ludological" game appreciation, with the position I take being roughly ludological. I don't entirely buy into this distinction, mostly because I find "narratological" to be a terrible misnomer. The visual or aural properties of a game are sensory; they are not necessarily narrative.

Saturday, June 21, 2008

Stop X11 from launching xterm (Mac annoyance Saturday)

In short, type the following at a command prompt:

defaults write org.x.X11 app_to_run /usr/bin/true

Wow, it's so intuitive! Mac UI genius scores again.

Via this thread, although the recipe at the top is broken, at least in Leopard. The suggestion at the bottom of the thread is the winner.

(I'm going to start posting my Mac annoyances on Saturdays. From my experiences so far with Mac, I think my only problem will be limiting myself to one per week.)

Friday, June 20, 2008

No, fuck *you*, Barack Obama

Fuck you, Barack Obama. And fuck your staff with a rusty tent pole for throwing this out with the Friday trash so that it wouldn't get much news coverage.

Fuck you, Nancy Pelosi. Fuck you, Harry Reid.

I know you don't care about my vote, so perhaps this will make a bigger impact: you can say goodbye to the $2300 checks I was going to write for this election cycle. Of course, you probably don't care about that either, because you're going to get more and bigger checks from the telecom companies.

Fuck it all, the Republicans can burn down this country and piss on the ashes for all I care, because clearly you chickenshit assholes have nothing better to offer us.

As is often the case, Mark Pilgrim has the most astute reaction.

Thursday, June 19, 2008

Random notes on four version control systems

From 1996 to 2002, CVS was the only version control system I used. For that matter, it was almost the only system that anybody used, at least in the Unix world. (Well, a few nutty holdouts still used raw RCS...) In odd corners of the Internet, there were rumblings about other systems, but none of them had much mindshare or seemed worth the switching costs.

But somehow, over past five years, the version control universe seems to have opened up dramatically. CVS's competitors got more mature, and projects actually switched to them: Linux went to BitKeeper and git, KDE went to Subversion, etc. I'd occasionally use these systems to checkout and build source code, but I still didn't use them for actual development. Then, in 2006, I got a real job, where we use Perforce with some local wrapper scripts. More recently, I converted some of my personal codebases to Subversion and git, and started using them for real. So over the past two years, I've learned more about version control systems than I did in the previous eight.


  • There's no reason for anyone, anywhere, to use CVS for new projects. Subversion is stable; it has a strict superset of CVS's abilities; it requires almost no change in your mindset if you're coming from CVS; it runs on every platform that you're likely to have on your workstation or laptop; you can get hosting from a wide variety of providers; and its frontends are roughly as good as CVS frontends. (I use KDE, and kdesvn is only slightly less polished than Cervisia.)
  • CVS to SVN import is pretty good, but not perfect. It will introduce some spurious entries into revision logs, for reasons that I find obscure, and CVS tags won't be seamless.
  • Perforce is a very nice version control system, and has done a lot to change my mind about using proprietary software development infrastructure tools. I particularly like Perforce's ability to prepare a "changelist" from a subset of files modified in your local copy, and perform actions at changelist granularity (e.g., mailing out the CL for review). My major annoyance going from Perforce to Subversion was the fact that svn commit submits all your modified files to the repository, unless you select a list of files manually; and you can't prepare that submission list in advance. (BTW, gvn is probably going to fix a lot of these problems.)
  • The ability to do really lightweight local branches and commits in git is pretty awesome. git will probably be my weapon of choice for solo projects in the future.
  • git seems to have two sweet spots: (a) solo development, where you use it as a sort of glorified Filesystem of Forking Paths, and the unstructured nature of its repositories doesn't matter so much; and (b) hugely distributed development, like the Linux kernel, where speed matters a lot and tending a centralized repository might be intractable to manage anyway. The in-between space where most collaborative projects live --- where you want a medium-sized, canonical, gatekeeper-controlled central repository with a well-defined tip-of-trunk to which everybody syncs and submits --- seems better suited to Subversion or Perforce. (Yes, you can build that workflow style with git, but you have to do the intellectual labor of setting up that workflow, whereas with Subversion or Perforce the wheels come pre-greased.)

Lastly, I've seen some debates about the merits of fully distributed versioning systems like git vs. centralized systems like Subversion or Perforce. I find this analysis fairly insightful. Workflow matters more than your VCS. Think through your desired workflow, and then build a system that supports it; your VCS will be only one part of that workflow system.

At work, we have an automated process for auditing commits, and an awesome code review tool to support that process. After about a year and a half, I'm now addicted to that process. I would find it deeply disturbing to be building "solid" software (as opposed to personal hacks) in an environment where people can commit to the repository without code review. It also seems retrograde to have people perform code review by mailing around patchfiles and having developers eyeball them, or manually apply them to their local trees. And it's obviously not scalable to have a small pool of "committers" through whom all patches must be funneled.

Yet, as far as I can tell, most open source projects run this way: a carefully tended tree with a small number of dedicated committers, who eyeball and then commit patches from the wider community. Craziness.

My ideal repository workflow system would probably be two-tiered:

  • The central repository is where you keep the canonical tree. From the trunk of this tree, you build release binaries, run a centralized continuous build/test farm, etc. The repository is divided hierarchically into modules. All developers can commit directly to this tree; however, each committed patch must be code reviewed and approved in advance by an owner of the corresponding module.
  • Individual developers keep distributed repositories, which work like git. They can manage their own branches, commit at will, etc. When a developer's ready to submit a patch to the central repository, (s)he prepares a changelist in his/her local repository, then submits it as a patch to the central repository. The central repository keeps the patch, but doesn't permit it to be merged into to the trunk until it's reviewed and approved.

Today, you can build an approximation of the above with a Subversion + git workflow. You can buy Subversion hosting from any number of providers, and you can run git on your own workstation without getting anybody else's permission or hosting resources. I suppose the missing piece is the workflow support system, but I doubt the open source community will leave this void unfilled forever.

Wednesday, June 04, 2008

Soft word wrap for long lines (Wednesday Emacs blogging)

The short story: Use M-x longlines-mode.

The long story: longlines-mode is a minor mode that enables "soft wrap" for Emacs text. In longlines, lines will be displayed wrapped on word boundaries, as under most word processors (but not most text editors). This is useful for editing certain textual formats like HTML or wiki markup.

longlines comes bundled in FSF Emacs 22, but for earlier versions (or XEmacs) do the following:

  1. Get longlines.el, from the longlines Emacs Wiki page.
  2. Copy longlines.el somewhere on your load path. (To add a directory to your load path, add a line (add-to-list 'load-path "/path/to/directory/") to your .emacs)
  3. Add (require 'longlines) to your .emacs.

longlines-mode is a minor mode, and does not automatically hook itself into any major modes. You can hook longlines automatically in the standard fashion:

(add-hook 'html-mode-hook
          '(lambda () (longlines-mode)))

Alternatively, you can simply do M-x longlines-mode to toggle the minor mode manually, as I suggest above.

Once you get started with longlines, you'll probably want to customize its settings to taste. For example, by default the word wrap width won't automatically adjust to the window size. To see all relevant customizable settings, use M-x customize-group [enter] longlines [enter].

Incidentally, this feature is astonishingly obscure and late to arrive to Emacs, given that it's been a standard menu item in crippled brain-dead text editors like Windows Notepad for over a decade. Yet another example of how open source software development is not rationally optimized to serve the needs of the user.