Doom as an Interface for Process Management
Posted: Thu Oct 20, 2011 7:56 pmDoom as an Interface for Process Management
Dennis Chao
Computer Science Department
University of New Mexico
Albuquerque, NM 87131 USA
+1 505 277 5957
[url]dlchao@cs.unm.edu[/url]
ABSTRACT
This paper explores a novel interface to a system administration task. Instead of creating an interface de novo for the task, the author modified a popular computer game, Doom, to perform useful work. The game was chosen for its appeal to the target audience of system administrators. The implementation described is not a mature application, but it illustrates important points about user interfaces and our relationship with computers. The application relies on a computer game vernacular rather than the simulations of physical reality found in typical navigable virtual environments. Using a computer game vocabulary may broaden an application's audience by providing an intuitive environment for children and non-technical users. In addition, the application highlights the adversarial relationships that exist in a computer and suggests a new resource allocation scheme.
Keywords
Cyberspace, Doom, first-person shooter, games, metaphors, operating systems, Post-Modernism, 3D user interfaces, vernacular, video games, visualization
INTRODUCTION
Those who use computers inevitably encounter some of the metaphors that allow for easier assimilation of abstract concepts. The desktop metaphor is so pervasive that most users hardly notice it [9], but the richness of the science-fiction version of cyberspace is largely confined to research laboratories and Hollywood. The application described in this paper is an initial step towards bringing a richer environment to personal computers.
There is a large gap between how we think about performing actions on our computers and how we actually perform them. For example, people who need to manage processes on a UNIX system think about the ``daemons'' spawning children that may need to be ``killed'' or ``blown away.'' This violent language suggests a metaphor for process management: a first-person shooter game. Each process can be represented as a monster, and interacting with the monsters would affect the corresponding processes. The implementation of this metaphor and the great interest it generated reveal interesting insights about our computers and our society.
IMPLEMENTATION
The Doom process manager (PSDoom) is a modification of the game Doom [8] that displays representations of the processes running on a machine. Rather than using standard text-mode UNIX tools to view and manipulate processes, one surveys and shoots at a room full of bloodthirsty mutants, as shown in Figure 1. When a user starts PSDoom, currently running processes are instantiated as ``process monsters'' in a single room in a ``dungeon.'' These monsters have their associated process' name and id printed on them. The program periodically polls the operating system to add newly-created processes to the game. The user may choose to view the processes from a balcony above the room, as shown in Figure 2, or to enter the room to interact with them. If the user inflicts a wound upon a process monster, the corresponding process' priority is lowered to give it fewer CPU cycles. When the monster accumulates enough damage and is killed, the associated process is also killed.
PSDoom inherits the rest of its behavior from the original Doom, and play is not noticeably affected. Monsters attempt to attack the player and each other. The hostility of the monsters and the user's limited ammunition are disincentives to attack them. Conflict among process monsters could help regulate heavily-utilized systems by making crowded rooms have higher mortality rates. Killing random processes on an extremely loaded system is not an uncommon operating system strategy. When the user is ``killed,'' he or she will be healed and placed at the entrance of the dungeon with a pistol and a modest amount of ammunition.
Doom was chosen for this project for two reasons. The first is that it is a classic game, familiar to most system administrators. The second is that its source code was recently released under the GNU General Public License (GPL) [13]. This license not only allows the author to modify the source code, but it guarantees that future derivatives of the author's work will be available to the public.
RESULTS
PSDoom received a surprisingly large reaction even though it was not publicized [24,26,4,16]. Less than a week after the initial version of the code was written, the project's website was attracting tens of thousands of visitors per day. Approximately 800 responses were e-mailed to the author or http://www.slashdot.org within the first two months. Of these responses 27% praised the project, 23% offered suggestions for improving PSDoom, 10% found the project funny, 10% reported technical problems, 8% related PSDoom to science fiction or to the future of interfaces, 1% disliked the project, and 0.6% were frightened by its implications.
Users found the interface intuitive. One can quickly assess machine load by seeing how crowded a room is. The command line methods to slow down and kill processes are different, while PSDoom unifies them - shooting a monster with a small weapon slows down or ``wounds'' the corresponding process, and repeated firings or the use of a large weapon kills the process, as shown in Figure 3. The violence inflicted upon the monsters reflects the violent terminology of UNIX commands.
Figure 3: Killing a process in PSDoom.
A significant problem with the current implementation of PSDoom is that monsters are much more likely to attack each other than expected. This causes many windows to mysteriously disappear as the program runs. For the same reason, the computer is prone to crashing because certain processes are vital to the computer's operation and should not be killed.
Many users want a larger variety of monsters in PSDoom. If larger or more important processes were represented as larger monsters, it would be easier to assess the machine load at a glance. If these monsters were also more powerful, they would be less likely to be killed by accident and be more able to defend themselves against the player. Several users made similar suggestions for altering the appearance of monsters based on certain attributes. Processes that take more memory could appear wider, while those that take more CPU time can appear taller. Sleeping processes could be represented by napping monsters.
To address some of these requests, I added code to make some of the more important processes ``Barons of Hell,'' the largest monsters in the game. Unfortunately, they had a tendency to quickly kill all of the other processes, and the user could not interact with processes for more than a few seconds before his or her avatar is killed. Making the monsters less aggressive would allow the user to navigate among processes more easily as well as make the computer more stable.
DISCUSSION
The enormous interest that PSDoom generated naturally raises the question of why people find it so compelling. Perhaps even more interesting than the application itself is the set of issues that it raises.
Source:http://www.cs.unm.edu/~dlchao/flake/doom/chi/chi.html
Dennis Chao
Computer Science Department
University of New Mexico
Albuquerque, NM 87131 USA
+1 505 277 5957
[url]dlchao@cs.unm.edu[/url]
ABSTRACT
This paper explores a novel interface to a system administration task. Instead of creating an interface de novo for the task, the author modified a popular computer game, Doom, to perform useful work. The game was chosen for its appeal to the target audience of system administrators. The implementation described is not a mature application, but it illustrates important points about user interfaces and our relationship with computers. The application relies on a computer game vernacular rather than the simulations of physical reality found in typical navigable virtual environments. Using a computer game vocabulary may broaden an application's audience by providing an intuitive environment for children and non-technical users. In addition, the application highlights the adversarial relationships that exist in a computer and suggests a new resource allocation scheme.
Keywords
Cyberspace, Doom, first-person shooter, games, metaphors, operating systems, Post-Modernism, 3D user interfaces, vernacular, video games, visualization
INTRODUCTION
Those who use computers inevitably encounter some of the metaphors that allow for easier assimilation of abstract concepts. The desktop metaphor is so pervasive that most users hardly notice it [9], but the richness of the science-fiction version of cyberspace is largely confined to research laboratories and Hollywood. The application described in this paper is an initial step towards bringing a richer environment to personal computers.
There is a large gap between how we think about performing actions on our computers and how we actually perform them. For example, people who need to manage processes on a UNIX system think about the ``daemons'' spawning children that may need to be ``killed'' or ``blown away.'' This violent language suggests a metaphor for process management: a first-person shooter game. Each process can be represented as a monster, and interacting with the monsters would affect the corresponding processes. The implementation of this metaphor and the great interest it generated reveal interesting insights about our computers and our society.
IMPLEMENTATION
The Doom process manager (PSDoom) is a modification of the game Doom [8] that displays representations of the processes running on a machine. Rather than using standard text-mode UNIX tools to view and manipulate processes, one surveys and shoots at a room full of bloodthirsty mutants, as shown in Figure 1. When a user starts PSDoom, currently running processes are instantiated as ``process monsters'' in a single room in a ``dungeon.'' These monsters have their associated process' name and id printed on them. The program periodically polls the operating system to add newly-created processes to the game. The user may choose to view the processes from a balcony above the room, as shown in Figure 2, or to enter the room to interact with them. If the user inflicts a wound upon a process monster, the corresponding process' priority is lowered to give it fewer CPU cycles. When the monster accumulates enough damage and is killed, the associated process is also killed.
- Figure 1: The PSDoom interface.
- heavyfire.gif (35.39 KiB) Viewed 4047 times
- Figure 2: The view from the balcony in PSDoom.
- balcony.gif (32.58 KiB) Viewed 4047 times
PSDoom inherits the rest of its behavior from the original Doom, and play is not noticeably affected. Monsters attempt to attack the player and each other. The hostility of the monsters and the user's limited ammunition are disincentives to attack them. Conflict among process monsters could help regulate heavily-utilized systems by making crowded rooms have higher mortality rates. Killing random processes on an extremely loaded system is not an uncommon operating system strategy. When the user is ``killed,'' he or she will be healed and placed at the entrance of the dungeon with a pistol and a modest amount of ammunition.
Doom was chosen for this project for two reasons. The first is that it is a classic game, familiar to most system administrators. The second is that its source code was recently released under the GNU General Public License (GPL) [13]. This license not only allows the author to modify the source code, but it guarantees that future derivatives of the author's work will be available to the public.
RESULTS
PSDoom received a surprisingly large reaction even though it was not publicized [24,26,4,16]. Less than a week after the initial version of the code was written, the project's website was attracting tens of thousands of visitors per day. Approximately 800 responses were e-mailed to the author or http://www.slashdot.org within the first two months. Of these responses 27% praised the project, 23% offered suggestions for improving PSDoom, 10% found the project funny, 10% reported technical problems, 8% related PSDoom to science fiction or to the future of interfaces, 1% disliked the project, and 0.6% were frightened by its implications.
Users found the interface intuitive. One can quickly assess machine load by seeing how crowded a room is. The command line methods to slow down and kill processes are different, while PSDoom unifies them - shooting a monster with a small weapon slows down or ``wounds'' the corresponding process, and repeated firings or the use of a large weapon kills the process, as shown in Figure 3. The violence inflicted upon the monsters reflects the violent terminology of UNIX commands.
Figure 3: Killing a process in PSDoom.
A significant problem with the current implementation of PSDoom is that monsters are much more likely to attack each other than expected. This causes many windows to mysteriously disappear as the program runs. For the same reason, the computer is prone to crashing because certain processes are vital to the computer's operation and should not be killed.
Many users want a larger variety of monsters in PSDoom. If larger or more important processes were represented as larger monsters, it would be easier to assess the machine load at a glance. If these monsters were also more powerful, they would be less likely to be killed by accident and be more able to defend themselves against the player. Several users made similar suggestions for altering the appearance of monsters based on certain attributes. Processes that take more memory could appear wider, while those that take more CPU time can appear taller. Sleeping processes could be represented by napping monsters.
To address some of these requests, I added code to make some of the more important processes ``Barons of Hell,'' the largest monsters in the game. Unfortunately, they had a tendency to quickly kill all of the other processes, and the user could not interact with processes for more than a few seconds before his or her avatar is killed. Making the monsters less aggressive would allow the user to navigate among processes more easily as well as make the computer more stable.
DISCUSSION
The enormous interest that PSDoom generated naturally raises the question of why people find it so compelling. Perhaps even more interesting than the application itself is the set of issues that it raises.
Source:http://www.cs.unm.edu/~dlchao/flake/doom/chi/chi.html
