www.cs.unm.edu/~dlchao/flake/doom -> www.cs.unm.edu/~dlchao/flake/doom/
For example, walking along a tricky path through a swamp would be the same as going through a firewall. The mapping of abstract operations to an intuitive environment is a difficult problem. There are two distinct obstacles: the environment must be intuitive and the mapping must be accurate. If the environment is not intuitive, it can alienate users. In a good environment, the user would instinctively do the right thing. The quality of the environment is for naught if the mapping is not accurate. For instance, if certain natural actions lead to detrimental results or if desired results can only achieved by performing contrived acts, the mapping to the underlying processes must be learned. The difficulty of the mapping is evidenced by the paucity of good user interfaces that use physical metaphors. The only widespread example is the "desktop" interface, where files are held in "folders" which may be "opened" or "thrown away". This is a fairly good mapping, but there are certainly problems. For example, the user must understand what "links" are to figure out why some folders are not always accessible. The user must also realize that one can close a folder and still see the contents of its sub-folders. As mentioned above, people frequently talk about "blowing processes away", and the Unix command to destroy a process is "kill". Each process can be a monster, and the machines can be represented by a series of rooms.
I downloaded one of the 8 many versions and added a few lines of code that would spawn a new soldier for each process, renice the process when it is wounded, and kill the process when it dies. Some of the potential benefits of using Doom as a tool for system administration: * The machine load is immediately apparent to the player, who can see how crowded a room is. The player can eyeball many machines from a high vantage point and go down to a room that needs maintenance. A user may choose to simply wound processes rather than killing them, which could naturally be translated to renicing them. A rank beginner may not be given a weapon at all and be forced to attack processes with her bare hands. It would take a foolhardy player to attack a room full of monsters, just as a newbie should not kill a bunch of important processes. A more experienced sysadmin would have time to stop a newbie who is trying to kill the wrong process. Once the population in a room goes down, the monsters will stop attacking each other. In a command line interface, all actions take approximately the same amount of effort. One can ls just as easily as rm -rf *, which is kind of unfortunate. In a cyberspace environment, the players are not omnipotent, so performing large actions takes time and effort. They can then defend themselves against inexperienced sysadmins. Doom is a natural environment for player-to-player interactions. A team of players can cooperate to take care of a heavily-loaded system, or they can even take out rogue sysadmins who are killing the wrong processes. A few of the problems of using Doom as a tool for system administration: * Certain processes are vital to the computer's operation and should not be killed. For example, after I took the screenshot of myself being attacked by csh, csh was shot by friendly fire from behind, possibly by tcsh or xv, and my session was abruptly terminated. Should the monster type reflect the CPU as well as memory usage?
|
http://csua.com/feed/