JC0. Text-based Virtual WorldsUser Interface and SimulationsApplications are designed to be microcosms. They all have (or should have) consistent user interface and functionality, to allow the user to understand and even predict how theapplication will work. This is the purpose that the Macintosh Human Interface Guidelines serve: technical notes for creating applications that are true to the "physics" of the Macintosh.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 wewant, 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 andsizes. 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 theland 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 operationsin the real world.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 makesthe Macintosh particularly suited for simulations, provided that the program stick to the Macintosh Human Interface Guidelines. Multiple User Domains: MUDsPerhaps 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 ofpolice, 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 ofMONSTER 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 allsorts, MONSTER's port to UNIX was inevitable. The first port was called MUD, for Multiple User Dungeon (though today it is referred to as he 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. Theinternal 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 ExampleFollowing is a brief example of intereacting with a MUD (user