We can learn a lot from computer games. While most application software can be a source of confusion and frustration for users, people consistently find enjoyment in their games. One way to make everyday software more fun is to incorporate game-like elements, such as action, narrative, and interactive graphics. The problem with this approach is that the individual features that make a game entertaining might not work out of context. For example, a cartoon character stranded in a serious application is not only incongruous, but it could feel condescending to the user. So why not use a complete game as a front-end for a "serious" application? Would this hybrid be as fun to use as the original game? To answer these questions, I created PSDoom, a system administration tool that takes its interface from the popular first-person shooter Doom.
From Doom to PSDoom
I wanted to add an interface to the standard set of tools used to manage programs running on a computer, such as the Windows task manager (Figure 1). These provide data about running programs and allow the user to terminate those that have stalled or crashed. What is interesting about this mundane task is the vivid language used to describe it. People talk about "killing" programs or "blowing them away," "fighting for resources," and letting "daemons spawn." I chose to borrow the interface of Doom to reflect this aggressive language.
In 1999, Id Software released Doom’s source code, making it easy for me to turn Doom into the program manager PSDoom. I added code to create one monster in the Doom environment for each program running on the user’s computer. Each of these new monsters is labeled with the name of its associated program (Figure 2). For example, as I write this article, I can see zombies representing my word processor, a Web browser, and several terminal windows waiting patiently for me in a large room. PSDoom allows the user to affect the running programs by inflicting damage on the monsters. A light wound lowers the corresponding program’s priority to give it fewer CPU cycles, causing the program to run more slowly on the computer. If the monster is killed, the associated program is terminated (Figure 3). The user’s character can also sustain damage, and when it is killed the character is restored to health and loses any items, such as powerful weapons, that he or she had previously acquired. Because part of the fun of Doom is to find and use more powerful weapons, the fear of losing them is a strong incentive to be careful with one’s character.
PSDoom appeared to be an immediate success. Only a few weeks after the application was written, tens of thousands of people visited the project’s Web page and thousands downloaded the code. The computer community seemed ready to have an interface to match the violent language used for system administration tasks. Many system administrators, who would be the most likely to perform such tasks, have played Doom, so its interface is a familiar one. However, out of the hundreds of e-mails I received from people who loved the interface metaphor, only a handful had actually used PSDoom. These users found it much more satisfying to "shoot" a misbehaving program than to click on it in the task manager or to type kill -9 at a UNIX prompt. Unfortunately, they also enjoyed shooting at everything in PSDoom, killing critical programs and causing the computer to crash in surprising and sometimes spectacular ways. So despite its entertaining interface and compelling metaphor, PSDoom never became a practical application.
Metaphors can initially help users become familiar with a system but will inevitably mislead when the metaphor and the system differ. In this case, the metaphor breaks down when one considers the goals in Doom (the game) and PSDoom (the application). The goal of the game is to kill as many monsters as possible, while the goal of the system administration task is to kill processes only when they need to be killed. The PSDoom interface gives no information about which monsters should be attacked, so users often attempt to kill all of them. Even if there were such information, the user, surrounded by hostile-looking monsters, would probably try to shoot them all anyway. Allowing anything to survive would be antithetical to the Doom narrative.
Game-like interfaces have not entered the workplace, but they have entered the home. Developers of children’s software embrace computer games, though not always intelligently. In Interface as Mimesis, Brenda Laurel criticizes educational software that interleaves educational drills and short game segments. Writing about a hypothetical program that allows a child to play a game for 20 seconds if he or she solves three math problems, she asserts:
Either the math problems or the game segments are gratuitous, depending on Jimmy’s point of view. The proper solution is either to eliminate one of the activities, or re-shape the context so that it includes both; e.g., a starfighter simulation in which Jimmy must naturally solve math problems in order to operate the ship.
Adults at work are in the same situation as Jimmysurreptitiously playing a few rounds of computer solitaire or browsing the Web as a reward for using a boring application. Is there a way to integrate work and fun? It will be difficult, but the overwhelming response to PSDoom shows that it would be greatly appreciated.
1. Chao, D.L. Doom as an interface for process management. (2001). In J.A. Jacko, A. Sears, M. Beaudouin-Lafon, & R. Jacob (Eds.), Proceedings of the SIGCHI Conference on Human Factors in Computing Systems (pp. 152-157). New York: ACM Press.
Information on PSDoom can be found here: www.cs.unm.edu/~dlchao/
Source code for PSDoom (for Linux) can be found here: http://psdoom.sourceforge.net/
Dennis L. Chao
Department of Computer Science
University of New Mexico
©2004 ACM 1072-5220/04/0900 $5.00
Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee.
The Digital Library is published by the Association for Computing Machinery. Copyright © 2004 ACM, Inc.