Cliff Chaput and Brian Slator

User Interface and Simulations

A result of this consistency and predictability is a greatly reduced learning curve. When you are using a Macintosh application you know right away that you can cut and paste with Command-X and Command-V. Take a moment to consider the implications of this bit of knowledge: you understand what "cut" and "paste" mean, you understand that you can cut and paste non-text objects even if these objects are new to you, and you can cut and paste across applications. This knowledge is so fundamental to the use of a Macintosh, that if any part of this schema fails, it could be said that the application is functioning incorrectly.

This brings us to the second and most important (though least recognized) benefit gained from consistency and predictability. An application with a simple but powerful user interface constitutes a system that lends itself to understanding. By using certain cues, usually visual, we can look at the state of an application, tell whether the state is what we want, and know how to correct it.

A simulation is just like any other application, except that its "physical rules" are designed to be consistent -- to some degree -- with the real world. In the classic simulation example, SimCity, we deal with zones and transportation rather than fonts and sizes. When a city block is riddled with crime, the player can fix the problem in one of several ways: increase the land value by building roads or parks, or put a police station near the property in question, or raise police funding (if it's not at 100%), or increase the land value of the surrounding zones. While these specific operations are meaningful within the context of the SimCity application - like cut and paste - they are also meaningful operations

The hope is that if the program models some aspect of the real world closely enough, the user can transfer the knowledge gained from the application's user interface across domains to the real world. This, by the way, is the flip side to Virtual Reality, where the sensory input (user interface) is sufficiently real to compensate for the lack of realism in the application content. "Seeing is believing," as opposed to the simulation approach, "Believing is seeing." In any case, the operating system provides a suitable ramp up for understanding the application domain. In the case of SimCity for the Macintosh, one can use familiar user interface paradigms - like menus, windows, point-and-click - to accomplish otherwise difficult real-world tasks, like building an airport. This fact makes the Macintosh particularly suited for simulations, provided that the program stick to the Macintosh Human Interface Guidelines.

Multiple User Domains: MUDs

Perhaps the best way to represent human agents in a simulation is to use actual humans. This would relieve the programmer of simulating a secondary microcosm (people) so that she may focus on the primary microcosm, or the domain. Multiple users would then interact with the "physics" of the application, and interact with each other. This adds a new dimension to the concept of simulation, allowing the introduction of cooperation, competition, delegation, trust, and specialization into the domain. This is a new dimension rather than a feature because multiple players can change the simulation idea in many different ways.

Adding multi-player mode to SimCity, for example, could result in many different designs. One design would have different players in different roles: mayor, chief of police, fire chief, transit authority, city clerk, even aldermen. Another design would pit multiple mayors against each other as their cities struggle for the highest rating. Yet another would flip the model upside down and let the players be the citizens who can all vote on zoning laws, etc. We can see that one cannot just make a simulation multi-player; the simulation has to be designed (or re-designed) to accommodate the desired social structure.

One of the first attempts at a multi-player simulation was Zork. Zork was originally designed to accommodate multiple players in the dungeon. The original design allowed for speaking to other players, stealing from them, even killing them. But the design proved to be too unwieldy and was reduced to single-player mode in the hopes that multi-player mode would be implemented later. But the simulation stuff remained, and though it was in a very crude text format, it allowed for dungeon exploration, puzzle solving, and troll killing.

About 10 years later, MONSTER was developed at Northwestern University. The idea of MONSTER was to take the original design of Zork one step further, working from the original multi-player design and a little known feature called "wizard mode". Wizard mode was put into Zork to allow for debugging of the original dungeon, letting you pick up and move objects that weren't supposed to be moved (like the thief), and letting you redirect exits in a limited fashion. MONSTER was designed to give every player this capability, and the result was a programmable and extensible text adventure. Of course, the shift from single-player to multi-player drastically altered the play of the game. At first, users started creating adventures of their own for other users to solve. But later, more complex patterns of social interaction started to arise.

Since MONSTER was implemented on VMS, and the masses were on UNIX boxes of all sorts, MONSTER's port to UNIX was inevitable. The first port was called MUD, for Multiple User Dungeon (though today it is referred to as the more respectable and more accurate Multiple User Domain), and it was more or less the same as MONSTER. But soon several versions of MUD were written to accommodate changing tastes. The internal programming language was cleaned up, a power structure was devised to avoid uncontrollable growth, and the text language was fleshed out to allow for more intricate social interaction.

A MUD/MOO Example

Last connected Fri Jun 18 17:17:28 1993 CDT from aristotle.ils.nwu.edu

You put tag in gift.

You see broom here.

Wizard says, "Thanks."

Given all this, it should be clear that MUD/MOO can be the ideal platform from which to start creating multi-player simulations. Technically, a MUD is just a multi-user database and messaging system, which happen to be the essential elements of any multi-player game. It runs on a UNIX box and networks using TCP/IP. So the architecture for a multiple player simulation already exists.

MUDs and GUIs

While MUDs support the object management and inter-player messaging that is required for multi-player games, and at the same time providing a programming language for writing the simulation and customizing the MUD, the text-based interface is problematic. This led to the development of a MUD client with a graphical user interface (The MOOPort). The MOOPort interface is customizable, along with the simulation itself, leading to the design of simulations and their user interface together. Once a game is designed, the information for it is stored at the server site, both the simulation information and the user interface. This allows one client to be used with all simulations that are created. It also allows for clients to be written on other platforms with minimal pain.

Future Applications

The combination of a simulation, multiple players, and multimedia is not only an effective education and training tool, but just a compelling application all around. The LambdaMOO development team at Xerox PARC is currently integrating multimedia into their MOO product. This application should eventually support audio and video. But this is more a bandwidth constraint than anything else. To make the client fully independent of user interface, it would have to receive movie information over the network and display it. Since this is currently impractical, the graphical client software will fake it by sending clip titles rather than the video itself, and storing QuickTime files at the client site.

For a brief description of ongoing GAMES research and develpment at NDSU, see Slator's NDSU Computer Science Research Project List