Ascape is a framework designed to support the development, visualization, and exploration of agent based models. In this article I will argue that agent modeling tools and Ascape, in particular, can contribute significantly to the quality, creativity, and efficiency of social science simulation research efforts. Ascape is examined from the perspectives of use, design, and development. While Ascape has some unique design advantages, a close examination should also provide potential tool users with more insight into the kinds of services and features agent modeling toolkits provide in general.

Keywords:

Agent-based simulation, computer modelling, software frameworks, Java

Introduction

1.1

Ascape has many similarities to a number of other modeling tools used by agent researchers. However, from the beginning Ascape was designed with a few overriding design goals (Parker 1998).

1. It should be expressive; it should be possible to define a complete model in the smallest possible description.
2. ) It should be generalized; it should be possible to express the same basic modeling ideas in one way and have them tested in many different environments and configurations.
3. ) It should be powerful; it should provide high-level user oriented tools that allow model interaction without programming, but it should also provide an environment capable of modeling diverse and complex systems.
4. Finally, to support these goals, it should be abstract; it should encapsulate modeling ideas and methodologies at the highest possible level.

1.2

While there is much work to be done, I believe that Ascape has largely met these initial design goals. For those research projects that have programming resources available, using Ascape as a development tool should be far more efficient than attempting to develop a model from scratch. Ascape provides a flexible and powerful set of tools to work with and frees resources for actual modeling tasks.

1.3

As I discuss in the conclusion, end-user programming tools are critically important to the further development and usage of agent modeling. Happily, there are very good tools (AgentSheets, StarLogo) available now that help address this need for relatively simple models. For more complex (and in some cases, more testable) models, there is a significant gap. To address this gap, the development of significant end-user programming and composition features has always been part of the longer-term Ascape vision.

1.4

Until such tools are available, model development in Ascape does require one to have available or to acquire some kind of traditional programming expertise. However, I have worked with a number of researchers with limited programming experience who have used Ascape to build significant models. For researchers relatively new to programming and object-oriented development, a mentoring arrangement can often work very well. Ascape can also be a strong teaching and research tool for those organizations without extensive programming resources and can be a good starting point in the development of those resources. Models developed in Ascape can be explored extensively by non-programmers and can be deployed to the web.

Using a Third Party Tool in Simulation

2.1

As mentioned above, there are a number of tools available to support the development of agent based models. Still, it appears that the majority of researchers in the agent-modeling community continue to 'roll their own' models. There are many explanations for this, but I will highlight several key and interrelated reasons that I think are important. The first is that agent based models often seem simple to construct. Secondly, agent based modeling frameworks typically appear daunting and the benefit of such tools does not seem to warrant the cost of learning them. Thirdly, software developers and researchers are culturally very sensitive to loss of control and are not comfortable with subjecting important parts of models to a 'black box' implementation. In this paper I hope to address these particular issues and draw out the advantages of using a framework for agent based modeling.

2.2

The first reason I am positing for resistance to modeling tools is that most agent based models share with a-life and evolutionary computation a quality of simplicity, clarity, and directness of representation. This is a reflection of the compelling magic of the field. It is often quite easy to describe the mechanisms of a profoundly interesting model in a few sentences. The typical constituents of agent based models map so well to common computer data structures such as objects, arrays and queues that a framework might seem superfluous -- especially to a well-trained programmer contemplating agent based modeling for the first time. But as I intend to argue in this article, simplicity of explanation does not always translate to simplicity of representation. In agent modeling as with so much else, the devil is often in the details.

2.3

Beyond the functionality that a framework can offer, the most important advantage of using a tool such as Ascape is flexibility. Users of Ascape are developing for a high-level API and representation that understands agent based models and how they operate. Even in reasonably well implemented OO designs, a web of model assumptions tends to get caught up with itself and can become difficult to manipulate or even to understand. By facilitating high-level representations of details, frameworks help ensure that model design details are isolated from the plumbing of model execution and visualization. This allows one to represent only the level of detail relevant to the actual model description.

2.4

More importantly, a framework should allow one to explore and test a model against different assumptions. As we'll explore below, Ascape in particular is designed so that a given model can be exposed to many different topologies and behavior patterns through changes in one place in the code or user environment.

2.5

The second reason for resistance is that it does require an upfront expenditure of time and resources to learn a modeling framework. A simple model could probably be designed in less time than it would take to become familiar with a tool such as Ascape. But this is a one-time cost that will prove its worth in the long run. Ascape and other tools provide features that would probably never be cost-effective to develop independently. And once a high-level framework such as Ascape is learned, the entire model development process can become much more efficient. Models only need to be defined at the highest level, and low-level details are often completely transparent. While this might be disappointing to hard-core programmers, it should be liberating to those whose ultimate goal is the construction of useful, interesting models.

2.6

The third and final reason for resistance is that Ascape and other frameworks do in some sense insulate model developers from the details of a model, and it is reasonable and appropriate for a developer to be concerned that a framework will mask important details. This is one reason why agent-modeling frameworks should be open-source -- open in the sense that source code is available, not necessarily in the sense that it is free. If source code is not available, then internal framework behavior should be extremely well documented.

2.7

More importantly, while a framework may usefully gloss and abstract implementation details, it should expose important modeling issues. And these issues might not always occur to an independent developer. By providing a consistent interface and clear choices, Ascape can encourage a model developer to engage directly with important modeling issues. For example, by exposing an interface for controlling execution style, we provide a frame for the developer to address easily and understand the issue of activation regime (see below.)

2.8

That said, default choices must often be made in framework design, and it is true that the default choice may be an essentially arbitrary one. Ultimately, it is the developer's responsibility to be cognizant of model design issues and to explore the model's sensitivity to them. Ascape user - and developer - level tools contribute to the exercise of this responsibility.

2.9

Notwithstanding the points above, it is true that modeling frameworks are not appropriate for all models. For example, very large models composed of very simple agents running on a single computer, (such as Robert Axtell's trade network model, which has millions of simple agents trading on a single Macintosh CPU), may not always be suitable candidates. My aim in this paper is to provide a clear picture of the advantages that Ascape and other modeling tools offer in order to help potential users make an informed choice.

The Ascape User Environment

3.1

Ascape provides a number of tools that allow non-programmers to interact meaningfully with models. Users have wide control over model visualization, model behavior and dynamics. This level of user control is a real advantage to the modeling process.

Figure 1. Typical model environment

3.2

Most model interaction happens through the model control bar. This control bar is provided by default for all Ascape models. The control bar displays the current model iteration and state and allows the user to easily navigate between various views. It allows models to be started, stopped, paused and resumed. Model speed can be controlled using the 'flag' slider. Control bar buttons also allow the user to quit the environment, control model settings, view 'about this model' information and create new charts. The camera button allows the creation of movies of running models. The open model button opens a standard dialog to open other Ascape models including a built-in library of models. (This dialog also appears when Ascape is launched without a model specified.)

Figure 2. Model Control Bar

3.3

As described above, all views in Ascape are pluggable. Views can be added, minimized, or removed dynamically. Views that are not active will not use computational resources. Ascape provides a number of common view types and some that are not so common. There are many opportunities for enriching existing views and the architecture provides a simple and clean way to develop new view types.

Figure 3. Overhead (Helicopter) [Long House Valley; Dean et al 2000]

Figure 4. Relative 2D Views [Retirement; Axtell & Epstein 1999]

Figure 5. 1D Scrolling View [Social Norms; Epstein 1999]

Figure 6. Vector Representations [Firm Formation; Axtell 1999]

Figure 7. Simplex Views [Class Formation; Axtell, Epstein, Young 2000]

3.4

The user can customize the views by selecting different drawing features while the model is running. In the Ascape architecture, a Scape (a collection of agents, and the basic building blocks of Ascape models, see section 4) can be used as a repository for agent interpretation methods. A draw feature is a visual interpretation method for an agent's state. For example, a given draw feature might fill a rectangle with a color representing the cell's 'hydrology' value, and another might paint a crosshatch pattern in a cell with a farm located upon it. Default features are provided that use standard agent color and image properties to select agent and cell color or images. The model designer can provide more complex features. These and other features can then be selected for each view. By double-clicking a view the user can bring up a dialog that allows the selection of drawing features. The order of feature drawing can also be specified.

Figure 8. View Customization Dialog

3.5

Ascape views also provide agent and cell inspectors. By meta-clicking (option on Mac, alt on PC) on a model cell, the user can inspect the state of that cell. For scapes composed of cells capable of hosting other agents, users are also able to view the state of any resident agent. All such information is gathered automatically based on the Java getter and setter idiom (see section 5); there is no need to write any extra code to make the model state visible in this way. Of course, additional getters and setters can be created to make aggregate information or other data interpretations and setters available to the user at runtime. By shift-meta-clicking on an agent, users can create a tracking inspector that follows an agent as it moves throughout a Scape. In smallworld views, the inspector will also show the neighborhood of the cell. Finally, users can scan over cells and agents by meta-clicking and dragging over a view. Cell inspectors work in 1D scrolling representations and vector representations as well.

Figure 9. Cell and Agent Inspector

3.6

Ascape provides powerful and easy-to-use charting and statistics tools. Model developers can easily create model statistics that the framework collects and makes available to model users and researchers. (See below for an explanation of the development process.) These statistics are then available to be used for charting, exporting and other functions. Charts can be created as part of a standard model view development, so that model developers can provide them as standard visualization tools. Users can then customize existing charts or create their own.

Figure 10. Time Series

3.7

Users can select different data points by simply picking them from a grid which locates statistic names on one axis and various measures -- including count, total, min, max, average standard deviation and variance -- on the other.

Figure 11. Chart Customizer

3.8

In addition to time series styles, Ascape also include histograms and pie charts. These can be selected on the fly. For time series, users can also select the number of data points visible at any time. Finally, the user may control coloring of all data series as well as chart foreground, background, and plot background color.

3.9

In a do-it-yourself modeling approach, parameter changes and other model feature modifications are often made in the source code with the result that model exploration inevitably becomes embroiled in the edit-compile-run-debug cycle. With Ascape and other agent modeling tools the user can control parameters at runtime. More importantly, Ascape allows the user to control rule execution, aspects of topology, and interaction regimes at run time.

3.10

Ascape provides standard user dialogs for this purpose. The parameter settings dialog allows the user to change any model-wide values at runtime. As in the cell inspector design, these values are discovered automatically. The model developer need only follow standard Java idioms to have them included. Note that these parameters are updated from the model so that internal model changes can affect parameter settings and so that users may also change them directly.

Figure 12. Model Parameters Panel

3.11

In this example, the parameters include radius and random edge ratio. These can be used to control the topology of a small world representation at runtime. As Rob Axtell relates (Axtell 2000), an understanding of interaction topology is often critical to a full understanding of model dynamics. Subjecting a model to different interaction topologies is an important part of understanding how well results generalize.

3.12

The ability to make these kinds of parameter changes at runtime allows for a much more natural and efficient anecdotal exploration of model dynamics. Of course, rigorous explanation often requires a more disciplined approach, but end-user tools can help with this as well. Sweep and batch management tools are supported in the developer environment and are under development for the user environment.

3.13

Ascape also provides a rules tab, that allows the user to select the rules that are executed and the order of their execution.

Figure 13. Model Rules Panel

3.14

The rules area is also used to control activation regime. As we know from informal observation and as related in the Sugarscape work (Axtell & Epstein 1996) and in Axtell's recent work (Axtell 2000), activation regime can be extremely important in determining model dynamics.

3.15

The user can set whether rules are executed in agent order or rule order. For instance, in a given iteration, do all agents check their death condition at the same step? Or does each agent run through its entire repertoire of behavior, including checking for death, in turn?

3.16

The user can also control how agents have rules executed upon them -- that is, how they are activated. Again, this has been shown to be a crucial, yet often overlooked, issue in agent modeling. Most current models employ an approach that activates all agents in some random order. But many models still employ a random activation scheme that simply activates a randomly selected agent for n times -- where n is the number of agents in the population. Clearly this approach does not ensure that all agents are visited and allows agents to be visited more than once within a given cycle. While this can sometimes be a sensible approach, it is probable that it is usually chosen merely for its ease of programming.

3.17

This observation suggests an important point. A hidden cost of building one-off models is that the cost and effort of development may preclude the exploration of interesting areas of models. More importantly, it may mean that models aren't exposed to a full range of environments and that their results are not sufficiently generalized. Further, a researcher may avoid a particular design simply because of the complexity of development. I do not argue simply that the best single solution is not always the easiest to develop. Rather, I argue that it should be possible to easily expose a model to many different interaction topologies and activation regimes, and Ascape allows the researcher to do that.

3.18

Finally, it is easy to provide custom model manipulation panes. The model panel below is a custom 'slider' area. These kinds of tools make the process of working with a model more intuitive and provide a flavor of continuous direct interaction. Again, as with the parameter settings, sliders are two-way so that endogenous changes to the model affect the slider state and so that users may also perturb the variables directly.

Figure 14. Model Slider Panel

3.19

Ascape provides a rich environment for exploring model dynamics. By developing a model in Ascape, researchers gain a great deal of functionality. More importantly, Ascape's flexibility and ease of use encourages the exploration of model mechanisms that might normally be ignored in a purpose-built model implementation.

The Ascape Design

4.1

The Ascape design provides a number of key abstractions that facilitate the composition and exploration of agent based models. These abstractions also facilitate many of the user-oriented innovations mentioned above. We briefly survey these abstractions here, but they are covered in somewhat more detail in a recent paper. (Parker 2000)

4.2

First, Scapes are essentially collections of agents with very rich functionality. They know not only what they contain, but also how to iterate across what they contain, details of the topology of what they contain, appropriate ways to interpret what they contain, and so on. More importantly, Scapes are themselves first-class agents. Anywhere that a model can use an Agent, it can use a Scape. Thus, scapes can always be composed of other scapes. This allows a very natural method for model composition. It also ensures that any behavior that occurs across an Ascape model occurs in a well-defined way.

4.3

In Ascape, models are always composed of hierarchies of scapes and agents. For example, the following model of a demographic prisoner's dilemma has a lattice across which players move, play and reproduce and a vector that contains the population of players. A 'hosting' mechanism allows players to place themselves upon the lattice. The players and lattice belong to a root scape.

Figure 15. Prisoner's Dilemma Model

4.4

A further example illustrates how complex models can be unpacked into a hierarchical structure. This construction was used for a model of settlement patterns and resource utilization for the Anasazi (ancestral pueblo) people in Northern Arizona.

Figure 16. Long House Valley Model

4.5

A second important Ascape abstraction is that scape structure is typically hidden from Ascape agents. That is, agent behavior including searching and neighbor interactions can and should be designed without respect to a particular topology or activation regime. This is a critical benefit because it allows the exposure of Ascape models to different topologies and activation regimes through a single line of code and in some cases without any code changes at all (see above.) For example, one could define a search or an optimization involving radius 2 nearest neighbors for given agents upon a scape. The following diagram shows how this search would be interpreted depending on the topology of a scape.

Figure 17. Model Topology Abstraction

4.6

This anticipates the final abstraction that we will address here. Behavior occurs only across Scapes. There are no other high-level mechanisms for executing behavior on Agents. This ensures that all behavior occurs across a model in a well-specified way and provides a natural hierarchical framework for behavior amenable to user tools, straightforward explanation, and declarative design approaches. Ascape makes use of this same rule mechanism to handle its own infrastructure. Ascape uses rules to control execution, to collect model statistics, and to manage model views, as we discuss below.

4.7

After executing all rules in a given time step, statistics are gathered for the model. Again, because statistics are gathered as part of the model behavior, it is not necessary to write any code to tour the model. Statistics gathering can occur in two phases to facilitate dependent statistics such as bins.

4.8

Ascape makes use of a Model-View-Controller design for handling views, using the Java event model to mediate between the model and its views. Views belong explicitly to Scapes. Of course, views comprise not only scape visualization but also a host of non-visual model output, including data and console output. Model control events may be initiated by standard control views, but they may also include batch control, moving parameterizations during model runs, and sophisticated run-to-run parameter exploration mechanisms.

4.9

For each iteration (time step) following statistics collection, all views are notified that the scape has been updated. Once all views have had a chance to fully respond to the model change and report back that change to the model, the model is free to iterate again.

Figure 18. Model View Updating Process

4.10

Ascape is implemented in 100% pure Java. This provides a number of key benefits. The most obvious benefit of Java is that it allows the development and deployment of models on nearly any computer platform. Ascape models have been deployed to Windows, Macintosh, Unix, Linux and web environments. (Because it makes use of the Java 1.2 API only selectively, Ascape web applications can be deployed to any common browser.) Java language features such as garbage collection, strong typing, and a constrained reference model provide greatly improved programmer efficiency and increased robustness and safety. A less obvious advantage is gained from having the common paradigm, class libraries, and rich set of idioms that the Java environment provides. This dramatically decreases time devoted to integration issues and, in many cases, completely eliminates them. By providing a kind of lingua franca for developers, Java eliminates the cognitive and actual dissonance associated with mapping designs from one environment to another. That said, we should never hope for a world where one language or platform completely dominates all others. Ignoring the loss in technological diversity that such hegemony would represent, it is often extremely helpful to expose models to different languages and environments, because such exposure invariably uncovers hidden assumptions and design flaws.

Developing models for Ascape

5.1

We offer here a brief example of a typical, albeit simple, Ascape model design in code. The following section is not intended to be a complete tutorial on Ascape, but it should provide those with some programming experience a sense of what is involved in Ascape model development. For brevity, comments and extraneous code have been removed from the following examples.

5.2

Ascape models are simply special cases of Scapes. Therefore, most models developed for Ascape will simply subclass an appropriate Scape. This is typically a ScapeVector, as models are usually composed of a number of agent collections. In this case, we are defining a demographic Prisoner's Dilemma model. (Epstein 1998) We also define some symbols for the agent cooperate and defect states. We then define a number of parameters.

 
public class PD2D extends ScapeVector {

    public static final int COOPERATE = 0;
    public static final int DEFECT = 1;

    protected int payoff_C_C = 2;
    protected int payoff_D_C = 6;
    protected int payoff_C_D = -6;
    protected int payoff_D_D = -5;
    protected int fissionWealth = 11;
    protected int inheiritedWealth = 6;
    protected int initialWealth = 6;
    protected double mutationRate = .1;
    protected int deathAge = 100;
    ...    

5.3

For each parameter, we also provide standard Java getters and setters. (We only show one here.) Following this Java 'property' idiom is not only good coding practice, but it allows us through introspection to automatically gather model information without explicit coding. This data and metadata is used for the parameter displays and inspectors shown above and for other appropriate cases. Note that introspection only occurs in these special cases and isn't used anywhere within an actual Ascape model. This is important because Java introspection can be slow. As we'll see, data gathering and other functionality is handled through indirection a more efficient and flexible method but also one which requires some additional work. At some point, it is possible that we'll allow introspection to be used selectively in these other cases.

...
    public int getFissionWealth() {
        return fissionWealth;
    }

    public void setFissionWealth(int fissionWealth) {
        this.fissionWealth = fissionWealth;
    }
    ...

5.4

Next we define the constituent scapes of the model and the two methods that we'll use to construct the model and its views.

    ScapeGraph lattice;
    ScapeVector agents;
    Overhead2DView overheadView;
    ChartView chart;

    public void createScape() {
    ...
    }

    public void createViews() {
    ...
    }
}

5.5

Using another common Java programming idiom, functionality is added to the model scape by overriding appropriate methods. Model structure is typically defined in the 'createScape' method. The super method creates the basic underlying data structures and in the case of the root model builds the basic infrastructure necessary to support a running model.

    public void createScape() {
        super.createScape();
        lattice = new ScapeArray2DVonNeumann();
        lattice.setPrototypeAgent(new HostCell());
        lattice.setExtent(latticeWidth, latticeHeight);
        Player player = new Player();
        player.setHostScape(lattice);
        players = new ScapeVector();
        players.setPrototypeAgent(player);
        players.setExecutionOrder(Scape.RULE_ORDER);
        addAgent(lattice);
        addAgent(players);
    }

5.6

The 'createScape' method then creates the lattice that the agents will move upon. In this case, the lattice is two-dimensional and uses a von Neumann neighborhood. That is, cell neighbors are considered to be the cells to the North South, East and West. This type of lattice is by default periodic; that is, each opposite edge is connected so that the lattice forms a torus. We then set a prototype agent for the Scape. On creation, the lattice will be constructed of cells cloned from this prototype cell. In this case, we use a HostCell because we want the lattice cells to be capable of hosting our players. If we wanted to have special properties or behaviors available in the cells, we would create a subclass of HostCell and set it as the prototype agent. Finally, we define the size of the lattice by setting its extent.

5.7

Next we create an instance of Player. Player (as described further below) is a subclass of CellOccupant and as such is capable of being hosted by another cell. We assign the lattice as a host scape to the cell so that the cell will know in general where it will live. We then create a ScapeVector 'players' to contain the population of all players. To define this, we make the player agent the prototype agent for the 'agents' Vector. We also set the execution order to 'RULE_ORDER' which is different from the default 'AGENT_ORDER'. Rule order specifies that each rule in turn be executed across all agents. Agent order specifies that each agent in turn has every rule executed upon it. To complete the basic model design, we add the lattice and agents scapes to the root scape -- the scape that forms the basic structure for the model.

5.8

All agents in Ascape derive from the same basic Agent class. In the case of the Player agent, we derive from the CellOccupant class because we want to be aware of our context in a host scape. Again, for brevity, all comments have been stripped out of these examples. Readers may wish to examine the source code for more detailed information. First we define the instance variables (properties) of each agent. Again, we have omitted the getters and setters from this description, but they should be defined as part of good Java programming practice and are needed for the proper functioning of cell inspectors and other tools.

 
public class Player extends CellOccupant   {

    protected int strategy;
    protected int age;
    protected int wealth = 6;
    protected int lpWealth = 0;
    ...

5.9

The next step is to initialize the agent. This method will always be called once for each agent at the beginning of each model run. In this case, we just need to pick the agent's strategy and set a random initial age.

    public void initialize() {
        super.initialize();
        if (randomIs()) {
           strategy = PD2D.COOPERATE;
        }
        else {
           strategy = PD2D.DEFECT;
        }
        age = randomToLimit(((PD2D) 
        scape.getModel()).getDeathAge());
        }

5.10

For convenience, Agent classes can use a 'scapeCreated' method. This method is called once at model construction for the prototype agent and provides a place for rules and appropriate statistics to be added if desired. While this arguably violates an OO principle, it does allow basic behavior to be defined from within the class that the behavior will be executed upon. The logic is that this method will be called once and only once for all agents at the moment that the scape for a collection of agents is known. If this violates the model developer's sensibilities, rules and statistics can also be added directly to a scape as part of the general model definition. In this case, we add a number of standard rules to the Player agents collection. Initial rules are fired once at the beginning of each run, and after agent initialization. So agents are first moved to a random location on their host lattice. Then, for each agent, each period, agents take a random walk, play the prisoner's dilemma game with their neighbors, fission if appropriate, update their status, and die if appropriate.

 
    public void scapeCreated() {
        getScape().addInitialRule(
        MOVE_RANDOM_LOCATION_RULE);
        getScape().addRule(RANDOM_WALK_RULE);
        getScape().addRule(PLAY_NEIGHBORS_RULE);
        getScape().addRule(FISSIONING_RULE);
        getScape().addRule(UPDATE_RULE);
        getScape().addRule(DEATH_RULE);
    }

5.11

For reference, a typical rule definition is shown below. While a number of basic rules are provided with Ascape, custom rules can be and typically are used. Rules are used by the Ascape engine to inflect behavior on agents and are passed those agents through the execute method. In this case, the fissioning rule will be called on each agent in the 'agents' scape according to the activation method of that scape.

 
    public static final Rule FISSIONING_RULE = new 
      Rule("Fissioning") {
        public void execute(Agent agent) {
          agent.fissioning();
        }
    };

5.12

The fissioning method, like the fissioning rule, is actually defined in the Agent class and is a standard part of the Ascape agent repertoire. Like some other standard Ascape rules, it follows a pattern in which a condition is checked and if that condition is true, the appropriate method is called.

 
    public void fissioning() {
      if (fissionCondition()) {
        fission();
      }
    }

5.13

In this case, our agent may reproduce if it can accumulate some threshold of wealth by playing the prisoner's dilemma game with other agents. To reproduce, the agent first checks to make sure that a neighboring location is available, then clones itself and places its clone on a neighboring site. It then passes some percentage of its wealth to its progeny. There is some chance that the child player will mutate and select a different strategy from its parent.

    public boolean fissionCondition() {
        return (wealth > ((PD2D) 
        getScape().getModel()).getFissionWealth());
    }

    public void fission() {
        if (getHostCell().isNeighborAvailable()) {
            Player child = (Player) this.clone();
            ((ScapeVector) getScape()).addAgent(child);
            child.moveTo(
            getHostCell().findRandomAvailableNeighbor());
            child.wealth = ((PD2D)   
            scape.getModel()).getInheritedWealth();
            child.age = 0;
            wealth -= ((PD2D) 
            scape.getModel()).getInheritedWealth();
            if (getRandom().nextFloat() < ((PD2D) 
              SCAPE.GETMODEL()).GETMUTATIONRATE()) {
                IF (RANDOMIS()) {
                    CHILD.STRATEGY = PD2D.COOPERATE;
                }
                else {
                    child.strategy = PD2D.DEFECT;
                }
            }
        }
    }

5.14

The update and death rules work in a similar way. The update rule simply calls the update method to save the last period wealth and increment the agent's age. If the agent's wealth goes below a certain threshold or its wealth goes above some other threshold, the agent will die. This eventuality is managed entirely by the Ascape agent code which handles such details as removing the agent from its scape and host scape.

        public void update() {
            lpWealth = wealth;
            age++;
        }

        public boolean deathCondition() {
            return ((getWealth() < 0) || (GETAGE() > 
                ((PD2D) getScape().getModel()).getDeathAge()));
        }   

5.15

The play neighbors rule is also a part of the standard Ascape package and causes the agent to have the play method called on the agent with every neighboring agent. Note that on every turn, each agent plays each of its neighbors once. Thus because the lattice graph is undirected, each agent pair may play twice in each period. (Presuming one or the other agent has not moved to another location.) The actual game is simply a set of nested if statements that assign the appropriate payoffs based on each player's strategy.

        public void play(Agent partner) {
            if (this.strategy == PD2D.COOPERATE) {
                if (((Player) partner).strategy == 
                  PD2D.COOPERATE) {
                    this.wealth    += ((PD2D) 
                    scape.getModel()).getPayoff_C_C();
                    ((Player) partner).wealth += ((PD2D) 
                  scape.getModel()).getPayoff_C_C();
                }
                else { //partner defects
                    this.wealth    += ((PD2D) 
                    scape.getModel()).getPayoff_C_D();
                    ((Player) partner).wealth += ((PD2D) 
                    scape.getModel()).getPayoff_D_C();
                }
            }
            else { //this defects
                if (((Player) partner).strategy == 
                  PD2D.COOPERATE) {
                    this.wealth    += ((PD2D) 
                    scape.getModel()).getPayoff_D_C();
                    ((Player) partner).wealth += ((PD2D) 
                    scape.getModel()).getPayoff_C_D();
            }
            else { //partner defects
                    this.wealth    += ((PD2D) 
                    scape.getModel()).getPayoff_D_D();
                    ((Player) partner).wealth += ((PD2D) 
                    scape.getModel()).getPayoff_D_D();
            }
        }
    }

5.16

To round out the Player agent definition, we provide a standard method to return a color based on the player's state -- blue for cooperators and red for defectors. As described above, much more sophisticated and flexible drawing behavior is possible through the creation of drawing features. The agent 'getColor' method is simply an easy way to provide basic visualization services.

        public Color getColor() {
            if (strategy == PD2D.COOPERATE) {
                return Color.blue;
            }
            else {
                return Color.red;
            }
        }
    }

5.17

Returning to the 'createViews' method in the main PD2D model class, we can see how this visualization is set up. The create views method provides visual and non-visual tools for model observation. The super method typically creates standard toolbars, console outputs, and other views as appropriate. Developers can add other kinds of views programmatically. The first thing we do in the method is add stat collectors to the view. (It could be argued that statistics are part of the model itself and indeed they may migrate in future versions of Ascape.) These statistics are then added to the scape. Following each model iteration, statistics are automatically gathered for all agents. For each agent, the 'getValue' method is called with the agent as the passed object. The developer merely needs to determine the agent state that will be used for the statistic. A complete series is kept for each measure as appropriate for the type of the stat collector. For instance, a 'StatCollectorCSAMM' has measures for count, sum (total), average, minimum and maximum. Conditional statistics such as the Cooperate and Defect stats are collected only if 'meetsCondition' returns true.

    public void createViews() {
        super.createViews();
        final StatCollector[] stats = {
          new StatCollectorCond("Cooperate") {
            public boolean meetsCondition(
              Object object) {
                return (((Player)object).strategy == 
                    PD2D.COOPERATE);
            }
        },
        new StatCollectorCond("Defect") {
            public boolean meetsCondition(
              Object object) {
                return (((Player) object).strategy == 
                  PD2D.DEFECT);
              }
        },

-------------------


        new StatCollectorCSAMM("Overall Wealth") {
            public double getValue(Object object) {
              return ((Player) object).getWealth();
            }
        }};
        agents.addStatCollectors(stats);

5.18

The basic overhead view for an agent is created by simply instantiating the view and adding it to the . In this case we also set a cell size (in pixels) since we want a different size than the default.

        overheadView = new Overhead2DView();
        overheadView.setCellSize(12);
        lattice.addView(overheadView);

5.19

The Ascape view design provides a mechanism for discovering at runtime the context the model is running in. A chart isn't appropriate if we are viewing the model in an applet context, but otherwise we want to create a new chart and add it the 'agents' scape. It actually doesn't matter which scape we add the view to because statistics are available across all scapes. To add a plot line for the chart, we simply specify the name of the measure we're interested in and set a color for it. Charts are by default time series; however, as we showed above, the developer or user can also choose histograms and pie charts. We set the number of past data points that will be displayed in a time series view to 100.

        if (!(ViewFrameBridge.isInApplet())) {
            chart = new ChartView();
            agents.addView(chart);
            chart.addSeries("Count Cooperate",   
              Color.blue);
            chart.addSeries("Count Defect", Color.red);
            ((TimeSeriesViewModel) 
            chart.getViewModel()).setDisplayPoints(100);
        }    
    }

5.20

This completes a tour of the entire specification necessary to develop an Ascape model. While the description and explanation are somewhat long, it should be apparent that very little code is necessary to define a fully functioning Ascape model. (And again note that some of the code in the examples above is a part of Ascape itself.) This is in line with Ascape's initial design goals. In fact, in an informal (and thus inherently biased) comparison with other modeling environments, it was in fact possible to define Ascape models using much less code, in the most extreme cases by a factor of more than two. (Parker 1999) This benefit comes mainly from the principle that to the greatest extent possible, all general model behavior and visualization code should be abstracted and pushed down to the framework.

Conclusion

6.1

Ascape was conceived with the idea of providing a relatively straightforward software tool that would encapsulate basic agent modeling ideas in the cleanest and most efficient way while providing a great deal of flexibility and expressive power. It was also designed with the goal of providing as much power as possible to the user at runtime.

6.2

From the beginning, Ascape has been developed with the long-term goal of enabling the design of complete Ascape models without writing any code. Strong composability features are planned. That design goal requires significant resources to accomplish. More than that, it requires a solid foundation and API. Until now, we have concentrated on building that foundation while providing powerful user level tools to explore existing models. In the future, we intend to build on that foundation by providing model composition tools, richer topologies, and other advanced features.

6.3

Ascape and other modeling tools make a significant contribution to agent modeling research projects -- projects that will play a pivotal role in the continuing development of strong new approaches to social science problems. In particular, I hope that Ascape makes possible research projects that might not otherwise be practical because of resource limitations. For less constrained projects, Ascape can free researchers from some of the tedium of developing model infrastructure and allow them to concentrate on exploring the dynamics of complex systems.

6.4

Ascape is free for non-commercial use and is available, along with a number of social science models implemented in Ascape, at http://www.brook.edu/es/dynamics/models/ascape.

6.5

We provide easy to use installers for most common computer platforms. After installing and launching Ascape you can experiment with models mentioned in this article by selecting them from a pull-down menu. People interested in developing models might begin by copying and modifying existing Ascape models. While there is not yet a comprehensive 'Developing Models in Ascape' manual, there is extensive API documentation and a moderated mailing list. For more information see the 'readme' file at our Ascape web site.

References

AXTELL, R.L. and J.M. Epstein. 1996. Growing Artificial Societies: Social Science from the Bottom Up. Brookings Institution Press/MIT Press.

AXTELL, R.L. and J.M. Epstein. 1999. "Coordination in Transient Social Networks: An Agent Based Computational Model of the Timing of Retirement." Center on Social and Economic Dynamics Working Paper The Brookings Institution

AXTELL, R.L. 1999. "The Emergence of Firms in a Population of Agents: Local Increasing Returns, Unstable Nash Equilibria, and Power Law Size Distributions." Center on Social and Economic Dynamics Working Paper The Brookings Institution

AXTELL, R.L. 2000. "Effect of Interaction Topology and Activiation Regime in Several Multi-Agent Systems" Center on Social and Economic Dynamics Working Paper The Brookings Institution

AXTELL, R.L., J.M. Epstein, P. Young. 2000 "The Emergence of Classes in a Multi-Agent Bargaining Model." Center on Social and Economic Dynamics Working Paper The Brookings Institution

EPSTEIN, J.M. 1998. "Zones of Cooperation in Demographic Prisoner's Dilemma." Complexity v.4 i.2:36-48

EPSTEIN, J.M. 1999. "Learning to be Thoughtless: Social Norms and Individual Computation." Center on Social and Economic Dynamics Working Paper The Brookings Institution

DEANJeffrey S., George J. Gumerman, Joshua M. Epstein, Robert L. Axtell, Alan C. Sweedlund, Miles T. Parker, Stephen McCarroll. 2000. Understanding Anasazi Culture Change through Agent based Modeling The Dynamics of Human Primate Society Oxford University Press.

PARKER, M. 1998. Ascape.http://www.brook.edu/es/dynamics/models/ascape. The Brookings Institution.

PARKER, M. 1999. "Ascape: an Agent Based Modeling Environment in Java", Proceedings of Agent Simulation: Applications, Models, and Tools" University of Chicago

PARKER, M. 2000. "Ascape: Abstracting Complexity" Swarmfest 2000 Proceedings, forthcoming (Brookings Website)

Return to Contents of this issue

© Copyright Journal of Artificial Societies and Social Simulation, 1999