TEXT-BASED (26 pages)

Previewing pages 1, 2, 3, 24, 25, 26 of 26 page document View the full content.
View Full Document

TEXT-BASED



Previewing pages 1, 2, 3, 24, 25, 26 of actual document.

View the full content.
View Full Document
View Full Document

16 views

Unformatted text preview:

C0 Text based Virtual Worlds User Interface and Simulations Applications 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 the application 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 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 in 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 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 multiplayer 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 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 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 Following is a brief example of intereacting with a MUD user typing is in boldface Welcome to the XXXX MUD Type connect username password to connect to an existing character Type create username password to create a new character This MUD is maintained by XXXX connect MudUser9 Connected


Access the best Study Guides, Lecture Notes and Practice Exams

Loading Unlocking...
Login

Join to view TEXT-BASED and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view TEXT-BASED and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?