Alex is the CEO of AgentSheets Inc. and a professor in computer science at the University of Colorado, Center of LifeLong Learning & Design. Andri is a researcher at the Center of LifeLong Learning & Design. They can be contacted at [email protected] and andri@ cs.colorado.edu, respectively.
Interactive simulations provide a way of exploring, comprehending, and communicating complex ideas. They can, for instance, empower biologists to explore the growth of cells, network managers to analyze the flow of information, city planners to play through complex growth and pollution scenarios, school children to experience the fragility of food webs, and more. The combination of affordable computer hardware with high-resolution graphics and Internet connectivity is a crucial factor enabling people to run, exchange, and build interactive simulations. Using the Web, interactive simulations can be delivered as Java applets and JavaBeans for others to access through web browsers. In this sense, simulations become a new medium of communication that -- unlike more static forms of content such as e-mail -- includes interaction.
However, interactive simulations used as a medium for communication need to be end-user programmable to fit the needs of a wide user community. SimCity, for instance, is a finished simulation program mostly used for entertainment as a simulation game. While SimCity is able to communicate a number of complex issues (such as the intricate relationships of variables capturing a model of a city), it cannot be modified extensively or even be retargeted to other application domains, such as the simulation of electrical circuits.
In this article, we'll examine interactive simulations as a communication medium using AgentSheets, a development environment our company produces (http://www.agentsheets.com/). In the process, we'll provide an overview of the AgentSheets simulation construction tool, which lets end users build their own SimCity-like interactive simulations and export those simulations as Java applets or JavaBeans to the Web. This system has been used by user communities ranging from elementary school kids simulating food webs, to NASA scientists simulating E.coli bacteria in microgravity experiments, replicating the experiments aboard the Discovery space shuttle with John Glenn.
Development of AgentSheets
AgentSheets initially grew out of the idea of building a new kind of computational media that allow casual computer users to build highly parallel and interactive simulations, replacing simple numbers and strings of spreadsheets with behaving agents. An early prototype built in 1988 was created in Lisp running on Connection machines (highly parallel computers with up to 65,536 CPUs and 12-dimensional hypercube communication topology). Building the prototype revealed three main problems:
- The programming tools available at the time proved to be intricate and not suited for computer end users.
- The architecture of the Connection machine, Single Instruction Multiple Data (SIMD), was a mismatch for heterogeneous AgentSheets applications in which there typically were many different kinds of agents.
- Finally, it was hard to build interactive simulations with rich mouse-based interaction between the users and the running simulation.
For these reasons, the next generation of AgentSheets was built on a radically different platform -- the Macintosh.
The main challenge of designing an interactive simulation authoring tool is to find the right kind of end-user programming paradigm. Such a programming paradigm should allow a wide variety of users to create simulations for a wide range of application domains. At the same time, the simulations built should run reasonably fast.
The first version of AgentSheets on a Macintosh came into existence in 1989. It was written in Digitool's Macintosh Common Lisp (http://www.digitool.com/). This early version of AgentSheets featured a Lisp-like, object-oriented programming language called "AgenTalk," used to define the behaviors of agents. While AgenTalk, in the hands of professional programmers, was a powerful programming approach, it failed to enable the kind of users who use spreadsheets, which was really the main goal of AgentSheets. In 1991, this led to a completely new programming approach extending the notion of graphical rewrite rules with agents and programming by example. Using graphical rewrite rules, users define behaviors by manipulating agents; for instance, by moving them, and in the process of doing so creating before and after pictures. Apple Computer became interested in these kinds of programming approaches, resulting in collaboration for commercialization. Starting in 1993, AgentSheets versions were implemented in experimental new programming environments, including the ill-fated SK8 (later ScriptX) and finally Java.
The idea of graphical rewrite rules used in AgentSheets91 proved to be highly usable in the sense that even children could quickly, and without any previous programming background, create simple animations. However, the graphical rewrite rules were not sufficiently powerful to create more realistic simulations and sophisticated games, especially when compared with the earlier text-based AgenTalk programming language of AgentSheets. In 1995, the desire to achieve a better balance between language usability and expressiveness resulted in the implementation of Visual AgenTalk, a completely different programming approach called "tactile programming," described here. The current Macintosh version of AgentSheets is written in Macintosh Common Lisp. Users can build simulation using the Macintosh authoring environment, and with the press of a button turn them into Java applets or JavaBeans, using our Ristretto agent-to-Java bytecode generator. A 100% Java version of AgentSheets exists for Windows and UNIX users.
The AgentSheets Simulation Construction Toolkit
The AgentSheets environment (Figure 1) is a combination of end-user programmable agents, spreadsheets, and Java authoring tools. In AgentSheets, agents are autonomous processes able to perceive and act in their environment. An extendable set of sensors (conditions) lets agents perceive mouse clicks, sound input, voice commands, keyboard input, and even read and parse web pages. Agents can act by moving in a simulation world, changing their appearance, play sounds, speak, open URLs, and compute formulae. The mapping between perception and action is determined by the agent's end-user programmable behavior, Visual AgenTalk (VAT), in the form of If-Then rules. These rules can be constructed by choosing conditions and actions from predefined palettes (Figure 2).
Collections of agents interact with each other in a spreadsheet-like grid to create an AgentSheets simulation. These simulations can become complete Java applets at the press of a button, using Ristretto. With these capabilities, AgentSheets lets nontechnical users build a wide range of applications, including interactive simulations, games, and intelligent web agents.
Typical use of the AgentSheets system entails a spectrum of activities, ranging from the use of existing simulations to the design of completely new simulations. Specifically, we have identified the following distinct activities in the spectrum:
- Using existing simulations.
- Learning from example agents in existing simulations.
- Modifying agents in existing simulations.
- Designing and building simulations from scratch.
At one end of the spectrum, use of simulations may put users in a more passive mode because they are consumers of someone else's creations. At the other end of the spectrum, designing simulations lets users be more active in constructing computational artifacts and thereby shift into the role of producers.
Using Existing Simulations
The Educational Object Economy (http:// www.eoe.org/) is a collection of educational applets put together in a library accessible to educators and students for exploring a range of subjects, from math and science to language and social studies. In this pool of applets, a number of simulation applets can be found. Users can run these existing applets, or run other AgentSheets-generated applets found on web pages of individual users or the AgentSheets showcase (http:// www.agentsheets.com/showcase.html). Figure 3, for example, shows the Sustainopolis Applet that you can access at the showcase. This is a simple SimCity-like application that communicates a pollution model. The pollution from pollution sources (cars and factories) is diffusing over time and space. Users can explore and change the simulation world (the worksheet) by adding or deleting agents (such as cars, factories, trains) or by changing the configuration of the road and railroad system and observing the consequences. This activity is essentially at the same level as SimCity. Even though changing the world enables users to actively and interactively participate in the simulation that is unfolding, they are still consumers of someone else's creations. Unlike SimCity, however, AgentSheets allows modifications of the pieces that make up the simulations, and not just at the simulation world level, but at the level of the behavior of the simulation pieces, namely the agents.
Learning from Example Agents in Existing Simulations
To achieve a level of sophistication and be able to modify the behavior of agents, users go through the phase of exploring the behavior of the example agents in existing simulations and learn from them. In the Sustainopolis example, when users decide to explore the behavior of agents in the simulation from the showcase page they can either download the sources for the entire simulation or go to the Behavior Exchange web site where the Sustainopolis agents reside (Figure 4) and acquire individual agents. The Behavior Exchange is an evolving web-based information space that lets users exchange agents that have been created in AgentSheets. Users locate the relevant agents in the Behavior Exchange pages and acquire the ones that are interesting to them by copying them into the design environment (by clicking on them in the web page). Then, users play with the downloaded agents to comprehend what they do, evaluate usefulness, and decide whether to keep the agents or modify them. Agents acquired from the Behavior Exchange are not black boxes that can only be executed. As the full specification of the agent's behavior comes along with them when they are downloaded, users can open up the behavior editor of the example agent and figure out what the behavior does.
Figure 5 shows the behavior of the downloaded Car-Source agent, which specifies that a new Car agent is going to be produced on its right, once every six seconds, provided there is a piece of road in that direction. The behavior of an agent in AgentSheets is defined using VAT, a graphical rule-based language designed for computer end users without programming experience. If-Then rules in VAT are made up of conditions and actions (Figure 2).
VAT is a tactile language that goes beyond visual programming. Tactile programming is more than drag-and-drop because the operations it enables are not used just as construction mechanisms (for example, move, copy, or delete language pieces), but also as a means of direct exploration, which is very important for end-user programming. At any time, users can explore the functionality of any language piece (condition or action command, rule, and method) by simply dragging and dropping them onto any agent in their simulation. A simple case of exploration is, for instance, dragging the Play-Sound command from the action command palette onto a truck agent in the worksheet (Figure 6), which will cause the truck to honk, as this was the specified sound.
Modifying Existing Simulations
Upon moving into a producer role, users retrofit agents to their needs by modifying the agent's behavior and look. In the Sustainopolis example, if users decided to change the Car-Source agent to also be a Train-Source, they can select the rule in the behavior editor (Figure 5), and hit the Copy button to duplicate the rule. Then they can change the arguments of the See condition and the New action (Figure 7), to specify that if it sees a train track on its right, it should create a new train agent there (Figure 8).
After modifying the agents, users can share the updated agents with the AgentSheets community by putting them back into Behavior Exchange.
Designing and Building Simulations from Scratch
AgentSheets users, once at the level of proficiency required to build agents from scratch, can create their own simulations and contribute agents to the Behavior Exchange repository. The Behavior Exchange has helped to further facilitate collaborative simulation construction over the Web. Shared agents can be thought of as social currency, combining formal computational and informal information that gets exchanged through web pages. Creating complex interacting agents and sharing them has inspired children and other nontechnical computer users to become active contributing Internet community members, braking the traditional pattern of one-way communication over the Web. Another way of sharing not only simulation pieces (namely agents), but entire simulations, is by packaging the entire simulation into a Java applet using Ristretto, and thus turning their simulation into a format accessible to a larger community of users.
Conclusion
Simulations are powerful means to communicate complex ideas. When packaged as Java applets, simulations are also a good way to convey these ideas to people everywhere and support distance learning. The ability to exchange simulation components can gradually cause the shift from simulation use to simulation design and allow end users who are nonspecialists to build exciting interactive simulations.
Recent work with AgentSheets is concerned with supporting communities of users in using and designing simulations at different levels:
- Agents. The Behavior Exchange (http:// www.agentsheets.com/behavior-exchange .html) lets users exchange individual agents over the Web.
- Applets. The Educational Object Economy (http://www.eoe.org/) lets users choose from a large collection of educational applets.
- Components/JavaBeans. The Educational Software Components of Tomorrow project (http://www.escot.org/) evolves the concept of EOE to an open forum of interoperable components, instead of isolated applets.
Acknowledgments
This work is supported by AgentSheets Inc., the Center of LifeLong Learning & Design at the University of Colorado, and funded by NSF DMI-9761360, RED925-3425, and DARPA CDA-940860.
DDJ
Copyright © 1999, Dr. Dobb's Journal