Development and analysis of community-sim

Material Information

Development and analysis of community-sim a 2-D environment for the simulation of decentralized local economic models
Hoshiko, Derek Lane
Publication Date:
Physical Description:
xii, 136 leaves : ; 28 cm

Thesis/Dissertation Information

Master's ( Master of Science)
Degree Grantor:
University of Colorado Denver
Degree Divisions:
Department of Computer Science and Engineering, CU Denver
Degree Disciplines:
Computer Science
Committee Chair:
Chlebus, Bogdan
Committee Members:
Clark, John
Gethner, Ellen


Subjects / Keywords:
CommunitySim ( lcsh )
Econometric models -- Computer simulation ( lcsh )
Environmental economics -- Computer simulation ( lcsh )
Community development -- Computer simulation ( lcsh )
bibliography ( marcgt )
theses ( marcgt )
non-fiction ( marcgt )


Includes bibliographical references (leaves 135-136).
General Note:
Department of Computer Science and Engineering
Statement of Responsibility:
by Derek Lane Hoshiko.

Record Information

Source Institution:
|University of Colorado Denver
Holding Location:
|Auraria Library
Rights Management:
All applicable rights reserved by the source institution and holding location.
Resource Identifier:
66899830 ( OCLC )
LD1193.E52 2005m H67 ( lcc )

Full Text
Derek Lane Hoshiko
B.S., University of Colorado at Denver, 2001
A thesis submitted to the
University of Colorado at Denver
in partial fulfillment
of the requirements for the degree of
Master of Science
Computer Science

(This page left intentionally blank)

This thesis for the Master of Science
degree by
Derek Lane Hoshiko
has been approved
Bogdan Chlebus
Ellen Gethner
k? I #?/&>& 5

Hoshiko, Derek Lane (M.S., Computer Science)
Development and Analysis of CommunitySim: A 2-D Environment for the
Simulation of Decentralized Local Economic Models
Thesis directed by Professor John Clark.
CommunitySim is a 2-D simulation environment developed by the author
that provides a flexible user interface and an extensible core framework for
the development of decentralized local economic models. While it is similar
in design to artificial life simulation environments such as breve and
StarLogo, CommunitySim specifically focuses on providing a foundation for
real-world applications of ecological economics and eco-localism. It avoids
but does not ignore the physical characteristics that are essential to
evolutionary biology and physics models. Instead, it provides a framework
for models employing three basic object types: resources, agents, and
products. It also implements an economic basis for trade and monetization.
CommunitySim is strongly influenced by a trans-disciplinary approach to
local economic modeling employing complex systems, artificial intelligence,
ecological economics, and eco-localism and has strong ties to game theory.
Trees and Fruit is an economic model developed in tandem with
CommunitySim to test and demonstrate its abilities and to motivate research
and analysis of the local multiplier effect. The primary question for Trees
and Fruit is, What initial conditions and agent behaviors generate a steady-
state solution that is not the zero-state? The ultimate goal of the system is
to provide a platform for rapid development of local economic models for use
by policymakers, not-for-profit organizations, neighborhood organizations,
and small-medium sized enterprises.
This abstract accurately represents the content of the candidates thesis. I
recommend its publication.

This paper is dedicated to Arta Doci, whose timely advice and support
enabled the groundwork for this research before it began.

My sincerest gratitude goes to my thesis advisor Professor John Clark for the
opportunity to work with him, for his allowance and support of this research,
and to my committee members Bogdan Chelbus and Ellen Gethner. A
special thanks to my girlfriend Tatiana Cattand who has been immensely
supportive in countless ways, to Hue Nguyen for providing office space, to
Bogdan Chlebus for providing computer equipment, and to Genci Sula for
providing computer equipment and accommodations.
Thanks go out to many people in Seattle who have supported my thesis
work, including Viki Sonntag with EcoPraxis, who has been a key consultant
on the local multiplier effect and an excellent editor, my officemate Brian
Gershon for his help with Python, consulting, and support, my officemate
Wanda Benvenutti for offering to share her beautiful South Lake Union office
and for her moral support, and Alex Tokar for his consulting and support.
The thesis guild was most helpful by helping keep my focus and providing
suggestions and insights at key moments. Thanks go to the guild members
Professor John Clark, Professor Bill Barnes at the University of Portland,
Matt Gordon, Sara Berman, and Viki Sonntag.
Thanks go to Isabel de la Torre and David Batker for their enthusiasm and
for organizing the USSEE Conference in Tacoma, WA, to Joshua Farley for
insights gained from personal conversation, to Herman Daly and Joshua
Farley for their work on Ecological Economics and its companion workbook,
and for their motivating presence, and to Atossa Soltani, founder and
director of Amazon watch, for her compelling and motivating presentation at
the July 2005 USSEE Conference in Tacoma, WA.
Many people were instrumental in shaping the research with their insights
and suggestions. I would like to thank BALLE Seattle, Alexey Voinov at the
GUND Institute in Vermont, my long time friend Patrick Nelson, a former
student Jason Rush, and the author of breve Jon Klein. Thanks to the
Graduate School and the Department of Computer Science for their support.
For their contributions in forming this research, many thanks go to present
and former instructors at UCD: John Clark, Arta Doci, Neill Kipp, Bill Wolfe,
Dianne Kumar, Boris Stilman. Bogdan Chlebus, Ross McConnell, and John
Noll. Special thanks to the office and staff of the UCD Office of Financial Aid
for financial support and for the generous Advantage Scholarship, without
which this research would not have been possible. Thanks to my friends
and family, and others who contributed to this effort, for which the list goes
on and on. It has been an honor to have the chance to work and interact
with such great people.

1. Introduction.....................................................1
1.1 Executive Summary...........................................1
1.2 Background..................................................2
1.3 Problem Statement...........................................6
2. Literature Review................................................8
2.1 Local Multiplier Effect.....................................8
2.2 Stock-Flow and Fund-Service Resource Types..................9
2.3 Existing Software Package Review............................9
3. Research Methodology............................................12
3.1 Trans-disciplinary Approach................................12
3.2 Development Methodology....................................13
3.3 Agent Motivation...........................................14
4. CommunitySim Application........................................17
4.1 CommunitySim Overview......................................17
4.2 Development Environment....................................20
4.3 CommunitySim Extensible Core Framework.....................21
4.4 Trees and Fruit............................................24
4.4.1 Story.................................................25

4.4.2 Requirements and Staged Release Plan..................26
4.4.3 Decision Making Design and Implementation.............30
5. Results.........................................................34
5.1 Actor Low-Level Motivation Test Scenarios..................34
5.1.1 Obstacles.............................................34
5.1.2 Room..................................................37
5.1.3 Maze Walkthrough....................................39
5.2 Actor High-Level Function Test Scenarios...................43
5.2.1 Traffic Jam...........................................44
5.2.2 Diamond...............................................47
5.2.3 NLV Diamond...........................................49
5.2.4 Maze Forest.........................................50
5.3 Economic Model Scenarios...................................52
5.3.1 Fruit Preserves.......................................52
5.3.2 Auction House.........................................55
5.3.3 NLV Diamond Revisited.................................58
5.3.4 Las Esquinas..........................................61
6. Analysis........................................................67
6.1 Community Sim Application..................................67
6.2 Development Environment....................................68
6.3 Trees and Fruit............................................69
6.4 CommunitySim Extensible Core Framework.....................70
7. Future Work.....................................................71
8. Conclusion......................................................74

A. Manifest........................................................77
H. 114
Key Terms and Acronyms........................................... 133

1.1: The basic interconnection of disciplines (BASID)................4
1.2: Sustainability mapping of BASID.................................5
1.3: Problem domain overview.........................................6
4.1: Resource/agent/product (RAP) model.............................19
4.2: CommunitySim high-level subsystem interaction..................22
4.3: CFEnergy abstract data type....................................24
4.4: The Trees and Fruit model......................................26
4.5: Simulation event handling......................................31
4.6: ATActor._MoveTowardGoalLocation Python implementation..........32
5.1: Obstacles setup................................................35
5.2: Obstacles movements............................................36
5.3: Obstacles final configuration..................................36
5.4: Room simulation setup..........................................37
5.5: Room simulation movements......................................38
5.6: Room simulation final configuration............................38
5.7: Maze Walkthrough setup.......................................39
5.8: Planning maps with a horizon of 23 at location (0,0)...........40
5.9: Planning maps with a horizon of 23 at location (1,4)...........41
5.10: Planning maps with a horizon of 13 at location (0,0)..........42

5.11: Maze Walkthrough final configuration...........................43
5.12: Traffic Jam setup................................................44
5.13: Traffic Jam simulation snapshots.................................45
5.14: Traffic Jam, day 21..............................................46
5.15: Traffic Jam, days 11-21..........................................46
5.16: Diamond setup....................................................47
5.17: Diamond final configuration......................................48
5.18: NLV Diamond setup................................................49
5.19: NLV Diamond Actor wealth after 360 days..........................50
5.20: Maze Forest setup..............................................51
5.21: Maze Forest final configuration................................51
5.22: PDFruitPreserves key functions...................................53
5.23: Actor Fruit Preserves production.................................54
5.24: Actor producing Fruit Preserves..................................55
5.25: Simple auction house.............................................56
5.26: Simple Market, auction created...................................56
5.27: Simple Market, auction sold......................................57
5.28: Simple Market monetary exchange..................................58
5.29: NLV Diamond 8, 360-day simulations.............................58
5.30: Actor wealth comparison 2, 1500-day simulations................59
5.31: NLV revenue comparison 2, 1500-day simulations...............60
5.32: Actor energy comparison 2, 1500-day simulations................60
5.33: Las Esquinas setup...............................................62
5.34: Las Esquinas Actor state transition diagram......................62
5.35: Las Esquinas final configuration, 2000 days......................63

5.36: Las Esquinas auction results..............................64
5.37: Total Actor energy, economic trade system disabled........64
5.38: Total Actor energy, economic trade system enabled.........65

1. Introduction
1.1 Executive Summary
CommunitySim is a 2-D simulation environment developed by the author
that provides a flexible user interface (UI) and an extensible core framework
(ECF) for the development of decentralized local economic models. The
simulation reveals the importance of community as a framework that
supports resource sharing by signifying its benefits. Further,
CommunitySim expresses the concepts of localism and sustainability. These
concepts form a definition of the problem domain that is trans-disciplinary
(TD) in nature, involving computer science, ecological economics,
sustainability and eco-localism.
The problem statement implies the development of a local economic model
that includes resources, agents, and products. This in turn suggests a
computer simulation which considers whether a steady-state solution exists
that is not the zero-state, given various initial configurations and agent
behaviors. To address this, the author developed CommunitySim in tandem
with an economic model called Trees and Fruit. The two foci chosen to
motivate the direction of this research are the local multiplier effect (LME)
and wealth distribution. The LME occurs when money spent locally tends to
circulate within the local economy, creating a positive feedback that
increases economic activity.
Linguistic geometry (LG), a field of artificial intelligence (AI), provides the
definitions for the 2-D environment that CommunitySim employs. It is
based on the complex systems and is strongly motivated by the language of
hierarchies, both defined by Stilman [2000]. The language of hierarchies is
discussed in this paper primarily for the purposes of agent motivation.
However, future work with a systems approach to the aforementioned
problem domain is inevitable. It will enable the hierarchy of formal
languages to map to a hierarchy of ecological economies, with potentially
startling results. Considering these factors, a TD research methodology is
particularly applicable to the problem domain.
CommunitySim is a new simulation environment that is similar to artificial
life environments. A number of simulation environments were considered,
and it was discovered that breve [Klein 2002] and StarLogo [Starlogo] were
the most applicable. CommunitySim focuses less on biological and physical

processes and more on economic processes. A flexible, iterative development
methodology was employed in the realization of the software.
At the heart of the thesis is the description of the CommunitySim application
itself, including the development of a generalized model for resources,
agents, and products, which forms the basis for the model types that are
supported by CommunitySim. The core framework is discussed at length
before introducing a local economic model called Trees and Fruit. The Trees
and Fruit model was developed in tandem with CommunitySim as a means
to discuss and demonstrate the concepts relevant to eco-localism and the
local multiplier effect in particular.
An analysis of the important components of this research is provided,
followed by a discussion of potential future work, which includes foremost
the promise of applying CommunitySim to real world problems at the
community level. The advantages of the system and the limitations of the
environment are discussed. Stakeholders such as local government
policymakers, not-for-profit organizations (NPOs), neighborhood
organizations, and small-medium size enterprises (SMEs) could develop a
relevant economic model. This model could then be simulated using
CommunitySim thereby providing useful results that could be used to guide
policy decisions.
1.2 Background
Pondering the philosophical grounds and the interconnections and
intricacies of various disciplines such as mathematics, computer science,
physics, literature, art, psychology, history, ethics, philosophy, economics,
and so on, led to the beginning of this research which occurred one day as
many an idea does with an instantaneous, ah-hah.
One day a few years ago I had an occasion to saw a piece of fiberboard and
as I did not have a saw, it was reasonable to go to Home Depot and buy one.
Although I initially considered it unethical, an employee there suggested that
after using it, I return it to the store for a full refund. I was able to saw the
board, but instead of returning it, I kept it. How many times have I used it
since then? I could count on one hand. The ah-hah came much later after
moving to Seattle and discussing tools with a friend. How many people
living in this apartment building have a saw? If someone who doesnt have
one needs one they will likely go to the store and buy one. What happened?
Because the people living at the apartment building dont know each other,
because we live in an individualistic and competitive culture, the opportunity
for sharing the saw is lost. What would happen if we shared the saw?
Resources would not be wasted to produce products that were being
duplicated unnecessarily. This relates directly to the economics concept of
excludability. Ah-hah! An excludable resource is one whose ownership

allows the owner to use it while simultaneously denying others the privilege.
[Daly and Farley 2004, authors emphasis]
Extending the concept of sharing, I therefore had to question the concept of
scarcity versus abundance and this thinking simultaneously led me to the
idea of community as a framework for sharing. Hence, there would seem to
be a superposition of utility gained from resources and products that are
shared within a community. In essence, the utility is multiplied through the
community that shares the given resource or product. This generalizes to
monetary flows as well and leads to the concept of the local multiplier effect
(LME). Sonntag [2004a] explains that, Independent of growth in spending,
[local] multiplier theory suggests that communities can benefit from
initiatives to localize economic activity by increasing the proportion of local
to non-local spending.
There are many conditions required in order to support sharing in a
community. Cooperation is a necessary condition. Cooperation is contrasted
with competition. The prisoner's dilemma ... has been the subject of much
research, both theoretical and experimental. Results from experimental
economics show that humans often act more cooperatively than strict self-
interest would seem to dictate. [Cooperation 2005] The prisoners dilemma
falls under the umbrella of game theory in particular, but extends easily into
computer science. Thus it is easy to make the interconnection between
economics, game theory, and computer science.
The novel approach and in essence the focus of the research is localism
which provides a lens through which these disciplines can focus. Wikipedia
defines localism as emphasizing local and small-scale phenomena in
contrast to large, all-encompassing frameworks. Localism can therefore be
contrasted with globalization, although the two are best seen as
complementary rather than opposing. [2005] This last piece can be
connected with economics in general and with game theory, as discussed
above. This foundation will be referred to as the basic interconnection of
disciplines (BASID). See Figure 1.1.

Figure 1.1: The basic interconnection of disciplines (BASID)
Two branches lead from this foundation. Having been a former business
major and taking both macroeconomics and microeconomics, as well as
studying land-use, transportation, and environmental issues throughout the
past decade has provided the necessary background for the first of these two
branches. Furthermore, having moved to Seattle, numerous opportunities to
interact with NPOs and progressive thinking individuals have opened new
horizons. Consider the economic component of the discussion above.
Combining the idea of localism with economics and adding the key concept
of sharing relates to the overarching concept of sustainability. Sustainability
is thus defined:
The goal of societies is to survive and prosper, to be sustainable social
systems. To achieve this goal, people around the globe must fulfill their
present needs within the carrying capacity of the planet, without
compromising the ability of future generations to meet their needs.
(Quoted in Willard 2005]
Sustainability as a concept goes beyond 1990s environmentalism. For
example, social responsibility is often a consideration. However, an in-depth
analysis of sustainability is beyond the scope of this research. Figure 1.2
shows the evolution of BASID through sustainability. Adding a component
of sustainability to localism implies eco-localism. Curtis explains eco-
localism in that, Economic sustainability is best secured by the creation of
local or regional self-reliant, community economies. [2003]

Figure 1.2: Sustainability mapping of BASID
Similarly, interpreting sustainability in the context of economics implies
ecological economics. Ecological economics is, An economic perspective that
views the economic system as a subset of the broader ecosystem and subject
to biophysical laws. [Harris 2002]
Work in computer science and in particular with AI, social systems
modeling, artificial life, intelligent agents, object design, and software
engineering provided the necessary background for the second of the two
branches mentioned earlier. Consider the game theory component of BASID.
The connection was already made between game theory and computer
science. Considering the fields of computer science, AI and its related
artificial life and LG, as well as intelligent agents, strengthens this
connection. Intelligent agents and artificial life are also inter-related, as are
AI and LG. All these disciplines contribute nicely to the ability to model
socio-economic systems. The role of modeling has yet to be discussed.
Various fields have benefited greatly from the use of models. The separate
fields of ecological economics and eco-localism are both relatively new. Eco-
localism in particular lacks a suite of analytical tools that are tailored to the
study of these new concepts. This problem is exacerbated by the TD nature
of the sustainability mapping of BASID, which is a synthesis of each of these
fields, thus forming a new research area. Therefore, it is reasonable to

assume that there are no tools available for the study of community
economics. Thus, combining these concepts into one single coherent model
forms the problem domain of this research. Figure 1.3 illustrates this by
swapping game theory with computer science and placing sustainability at
the top; a new model is created that summarizes the problem domain in a
single picture.
1.3 Problem Statement
Develop a local economic model given specific resources, agents, and
products, called a RAP model, and simulate it using a computer simulation
program. Employ an existing software package if applicable, or develop a
new one. Determine if there is a sustainable configuration. In other words,
determine if there is a steady-state solution that is not the zero-state. If no
steady-state solution exists, explore conditions on configurations that will
maximize the time the system survives. Motivate the analysis through the
lenses of the LME and wealth distribution. Questions to consider include:
How is the local economy affected by differing conditions? How does a dollar
spent locally differ from one not spent locally?

Given the problem statement, some initial thoughts emerge. The following
are some design considerations for the development of the RAP model:
Resources can be classified in many ways, for example they can be either
rival or non-rival and either excludable or non-excludable. Or, they can
be stock-flow or fund-service. Consider the role of resource types in the
Resources can be transformed between the above types.
The model should support any number of autonomous agents; however,
one must have a minimum of two to have an interesting scenario.
Agents harvest Resources and use them to create Products.
Agents can use or consume Products and Resources.
Agents create Products.
Products can be used or consumed.
Products might simply be another Resource that is added to the
Resource pool. This depends on whether it is important to make a
distinction between natural resources and agent-created resources.
Being clear about what the motivating problem is and making a connection
with the real world are both important. Patterns or similarities between
seemingly disparate models, situations, or problems will undoubtedly reveal
themselves. Thus, the following initial thoughts on requirements emerge.
Note they both relate to agents having dollars.
Local Multiplier Add regions to the environment. Analyze positive
feedback of money spent locally. Dollars could be objects instead of
scalars and thus be tracked with respect to the LME.
Wealth Distribution Also could be called inequality. This is an analysis
of have vs. have not. Add an attribute to the agent. Start with some
agents richer than others. Do they get more money or do they balance
out under differing scenarios?
These thoughts focus and motivate the research project. These foci connect
together in a dynamic tension that provides the potential for contrasting
analyses. Ensure that these foci are observed and not predetermined by

2. Literature Review
While Section 1.2 focused on a top-down approach defining the broad-based
background, Section 2.1 focuses on the LME, specifically addressing the
details of the relevant literature, then spiraling outward demonstrating a
broader context of research. Section 2.3 provides a basic description of
existing software packages.
2.1 Local Multiplier Effect
The concept of the multiplier has been applied to the study of employment,
income, and the effect of purchasing decisions, among others. The basic idea
is that purchases from a local entity have a greater positive local impact
beyond the benefits of the immediate transactions. This is referred to as the
local multiplier effect (LME). Money spent locally circulates within the local
economy before it leaks out. According to Shrestha and Lorelli, a company
spends money, ... in the form of wages paid to workers, contracts with local
suppliers, profits gained by owner, utility bills, state income taxes, and so
forth. While some of this money ultimately leaks out of the state, much of it
will remain in circulation in the local economy, increasing [local] economic
activity. [2003]
Recent research performed by the New Economics Foundation (NEF) shows
that the concept of the multiplier can be extended to differentiate between
the benefits of purchasing local over traded goods. Purchasing locally
purchased goods results in a higher multiplier than purchasing traded
goods. Moreover, eco-localism theory suggests that purchasing locally
produced goods results in greater cooperation in preserving the natural
capital that supplies the products as well as ecosystem services.
Although the primary question of this research is answering whether or not
a socio-economic model that simulates present-day society can be given a
sustainable configuration, the LME, in addition to wealth distribution, will
motivate and focus the modeling by introducing constraints and
assumptions. In particular, this is accomplished by tracking dollars as they
move through the economy and reporting where each one actually is spent
as the simulation progresses. In programming terms, this means creating a
Dollar object, which has a serial number, or ID, and an ordered list of
bearers with time-stamps and locales. Further, it would be interesting and
useful to contrast societies where local spending is non-existent, prevalent,
or a mixed bag.

Thus programmatically, in addition to tracking dollars, it will be important to
consider the effects of local spending in each agents decision-making
scheme. Lastly, by considering two seemingly disparate foci simultaneously,
namely the LME and wealth distribution, it will be possible to gain insight as
to whether local spending habits have a beneficial effect on the distribution
of wealth among agents.
2.2 Stock-Flow and Fund-Service Resource Types
Viki Sonntag points out that the Trees and Fruit model, Will help address
the need for an analytical basis for behavior (consumption choices) beyond
the strictly individual economic behavior ... that governs analysis now. She
explains that the basis for choices regarding fund-service resource types
have previously been non-quantifiable. Earth Economics describes the
A stock-flow resource is transformed materially into what it produces.
It can be used up at almost any rate. Examples of stock-flow
resources include oil, minerals or timber. A fund-service resource, in
contrast, provides a service at a fixed rate and does not become a
part what it produces. Examples of fund-services are ecosystem
services such as purification of air and water, detoxification and
decomposition of wastes, and generation and renewal of soil fertility.
The relationship between natural capital stock-flow and fund-service
resources is important for informed economic decisions. The use of a
biological stock-flow resource (such as timber) at an unsustainable
level also depletes a corresponding fund and the services it provides.
For example, removing trees from a forest alters the ability of the
forest to provide the other ecosystem services it previously provided.
Thus, economic decisions that consider only the biological stock-flow
aspect of a resource will be incomplete and distorted. [Categories]
2.3 Existing Software Package Review
In order to support the simulations that the problem statement would
require, a choice had to be made between implementing a new simulation
environment and using an existing software package. Rather than reinvent
the wheel by implementing a software package completely from scratch, the
choice of pursuing an existing software package was clear. Several packages
were reviewed including breve, Tierra, StarLogo, Avida, Physis, Framsticks,
and Darwinbots. Stella, a well-known commercial environment, was not
evaluated. The first three environments are noteworthy.

breve is an integrated simulation environment which aims to greatly
simplify the implementation of decentralized systems and advanced artificial
life simulations. [Klein 2002] breve runs simulations that are written in an
interpreted language called steve. Steve is procedural in nature and its
syntax resembles Objective-C. breve runs on GLUT, which in turn runs on
OpenGL. breve boasts a significant amount of documentation, an
apparently large class library, and many examples. [Klein 2002]
Several steve scripts were simulated using breve on two different computers.
Even on relatively simple configurations, breve showed debilitating
performance issues. Optimizations may be possible with a different
combination of hardware configurations, drivers, and OpenGL/GLUT
settings. Nonetheless, this ultimately proved prohibitive.
Thomas S. Ray developed a simulation environment called Tierra. The
environment supports simulations in which computer programs compete for
computer resources such as processors and memory. The programs, which
are essentially digital organisms are each individuals and can evolve,
mutate, and reproduce. Charles Ofria, C. Titus Brown, and Chris Adami at
the California Institute of Technology developed Avida, which is based on
Tierra to some extent. Both of these systems are artificial life simulations,
however upon further analysis, were not appropriate tools for this research.
For example, Avida seemed to be tailored toward evolutionary and biological
research. [Tierra 2005)
Several other environments were also researched, including Physis,
Darwinbots, and Framsticks. Many of these were found to be similar to
Avida. Framsticks was more difficult to track down yet initially seemed
promising. Darwinbots was the most applicable of the artificial life
simulators discussed thus far. Ultimately, however, the problem was that it
did not offer a programming language for development as in steve. It was
possible to program the agents behavior, but its syntax appeared wholly
Further, some aspects of the simulation environment would have to support
economic trade using a clearinghouse, as banks do, or an auction house for
trading goods. This leads to a problem with any artificial life design because
it adds an element of complexity that does not fit. Although a clearinghouse
or auction house could be considered to be a single-instance agent, the
interactions would be much too complex given the precepts of artificial life
Setup requirements for analysis of Physis and Stella were time or cost
prohibitive; therefore, neither of these two environments were evaluated.
StarLogo is the closest to being able to fit the problem domain. The website
itself explains that StarLogo is, A programmable modeling environment
designed to [explore! decentralized systems, such as ... market economies.
[StarLogo] There were no apparent disadvantages to using StarLogo.

Due time was spent considering Java, Ruby, C++, and Python for
development. The existing packages discussed above were abandoned in
favor of the development of a new system for several reasons:
Inability to promote a positive change in the performance of breve
Appeal of learning a new programming language
Prohibitive learning curve associated with developing and
understanding an existing system
Risk associated with adapting an existing system to new project
Appeal of developing a new simulation environment, with novel
features that are tailored specifically to the problem domain

3. Research Methodology
Section 3.1 examines the intricacies of the TD approach to this research.
Section 3.2 delves into the choice of development methodology and the
advantages and disadvantages of the decisions that were made. The chapter
concludes in Section 3.3 with a description of the methodology used to
motivate agents employing AI.
3.1 Trans-disciplinary Approach
A strong trans-disciplinary (TD) approach was employed throughout the
project. The use of a TD approach is not simply a consequence of
performing research that combines computer science with economics via
simulation; rather, it is fundamentally necessary to provide the full range of
tools and perspectives required to solve real problems.
The problem domain combines ecological economics, which is itself a TD,
with eco-localism and computer science. Hence this research adds an
additional layer of complexity. Interestingly, variants of the term complex
appear frequently. For example, the simulation environment is modeled
after a complex system. The TD approach itself requires systems thinking,
which Farley et al relate to complexity [2005], Nonetheless, complexity itself
falls just outside the domain of this study.
Farley et al suggest that a given real world problem, ... determines the
tools and disciplinary insights needed to resolve it. The necessary tools,
methodologies, and insights for resolving the problem can be drawn from
any discipline ... and that, By incorporating knowledge across disciplines,
very often the combination of tools and ideas lead to new tools and ideas,
and the [TD] knowledge and understanding is bom. [Farley, et al 2005,
authors emphasis]
In our case, the tools and ideas include ecological economics, localism, AI,
intelligent agents, and object design, among others. The disciplinary
insights come from each of the disciplines in the problem domain. These
tools and insights are considered at each step of the research process and
are synthesized in CommunitySim and its local economic models.

3.2 Development Methodology
One particularly interesting and important consideration is the approach to
development. Any new software project is doomed to failure if this is not
considered in earnest. There are many development methodologies with
different names each of which is the subject of intense debate. Even the
theoretical constructs are debated. Nonetheless, rather than mention
specific names, only relevant options, choices, and considerations will be
Two seemingly disparate development methodologies were initially
considered. The first begins with specification and requirements
development, continues with software architecture, high-level design,
progresses through detailed design, and then implementation and testing.
Lastly, the project enters maintenance. At any stage, the project can
transition one stage forward, or any number of stages backward. This
methodology has been a pillar for development, and has been very
One precept of this methodology is that software never dies. Even after
leaving a project, the software may resurface years later with an unexpected
phone call, for example. A work product is produced at each of the stages,
and over the lifetime of the project, the process is documented in great
detail. Diligent consideration should be made as to the affect of decisions at
one stage and how it affects the next stage. Moreover, the cost of fixing a
mistake made at one stage j that is discovered in stage k, is
For example, a mistake made in high-level design and detected in
implementation and testing will require 100 times the amount of work than
would have been required to fix the mistake if detected and fixed in high-
level design.
The second methodology begins with specification and requirements, but
then divides the project into smaller software projects, each of which
implements a small subset of the requirements in a continual stepwise
progression. At each stage, the software project is deliverable. Little or no
focus is given to design and documentation, as they are left to the
programmer. Thus, design, implementation, and testing are done repeatedly
throughout the project life cycle.
Many of my colleagues and advisors suggested using a methodology that
includes implementing solutions in stages and adding complexity gradually.
They recommended using a bottom-up design approach, which has the
benefit of rapid development, and to look for and implement the least
complex non-trivial subset of the problem. These recommendations are in
contrast to the object-oriented approach of top-down design, bottom-up

implementation. Thus, it was challenging to consider adopting the second
methodology after having been accustomed to the first.
The tipping point occurred upon receiving an email with impeccable timing
from colleague Alex Tokar highlighting reasons against writing a spec,
indirectly and inadvertently advocating the second choice. Linus Torvald,
Linux creator, is quoted as saying:
[A] 'spec' is close to useless. I have _never_ seen a spec that was both
big enough to be useful _and_ accurate. And I have seen _lots_ of
total crap work that was based on specs. It's _the_ single worst way
to write software, because it by definition means that the software
was written to match theory, not reality. [Quoted in Andrews 2005]
Colleague Patrick Nelson made the suggestion of starting programming
immediately, rather than spending time on design. This came at the same
time as Linus quote, which stated more or less that specs are a bunch of
garbage, so to speak. Thus, it seemed advisable to follow Mr. Nelsons
suggestion. In the end a synthesis of the two methodologies was employed,
with a strong bias toward the second methodology.
Instead of designing up front, incremental stripes were defined for the
implementation, focusing on implementing the next most important piece of
functionality. There are advantages and disadvantages to this approach.
Two disadvantages are that it is often the case that one must re-implement
functionality as the program evolves and that functionality is not always
evenly divisible into stripes. The fact that documentation is left as an
afterthought is a disadvantage. Advantages include continually having a
working application, being able to test the system immediately, and being
able to design by experience. In the end, the iterative, second approach
proved to be both a critical and ideal choice.
3.3 Agent Motivation
A discussion of agent motivation will highlight one particular aspect of
research as it relates to the development of CommunitySim. Developing an
effective implementation of an artificial intelligence (AI) is non-trivial. In
general, every object would conceivably have an AI of some kind; this
includes in particular both agents and resources in the RAP model. A
bottom-up design is straightforward and introduces the least risk to the
software project. Furthermore, this approach interoperates with the
development methodology discussed in Section 3.2.
For this project, a bottom-up design approach of AI is most effective because
it lends itself more to the exploratory nature of artificial life, rather than
prescriptive theory. Agent AI functionality can be phased-in incrementally

by designing, implementing, and proving progressively more complex agent
behavior. For example, it is simpler to focus on getting an agent to walk
from point a to point b, than it is to consider all possible interactions at the
top-level and try to develop lower-level constructs to support the top-level.
Continuing with the example, once the agent can walk from point a to point
b, the agent can then make low-level decisions about where to walk. Later,
questions can be answered as to why to walk to one place or another.
Furthermore, the logical and physical constraints for the model can more
readily be integrated into the design at the lower-levels and largely ignored at
Foremost, this bottom-up approach leads to a hierarchy of intelligence which
closely mimics that of human development. For example, humans learn to
walk before they learn to ride a bicycle or learn to decide where to go.
Higher-level functions operate on a foundation of lower-level functions. For
example, the higher-level function to go to the store to buy food requires the
lower-level function of walking.
This methodology for the design and implementation of agent motivation
provides a potential for the utilization of AI in an ever increasing level of
sophistication that extends beyond the decision making of the agent itself.
For example, Stilman [2000] explains how LG tools employ hierarchies:
[The] tools are applicable to models where the local agents are less
constrained and operate autonomously with some distributed
intelligence. Each super-agent develops a model of the opposing
super-agent and operates assuming that the adversary will do its
best within this model. The model is used for planning the agents
actions and choosing the optimal one. The model establishes local
goals for local agents. These local goals are coordinated with the
global goal of the corresponding super-agent. Motions directed to the
local goals are intended for a super-agent to achieve the global one.
The model is dynamic: after every action, which may include
concurrent movements of agents of both sides, it is updated taking
into account the new situation ... [The] dynamic model can be viewed
as a hierarchy of subsystems. We introduce local goals by
decomposing the system of local agents into subsystems striving to
attain these goals.
He further explains that the hierarchy of subsystems is represented as a
hierarchy of formal languages. In this research, a portion of the hierarchy of
formal languages is employed primarily for agent motivation. Yet, the
multiple hierarchical levels of intelligence employed by a particular agent
become part of a hierarchy of intelligence that extends to communities of
agents, and communities of communities. A natural progression of this
thought will enable the hierarchy of formal languages to map to a hierarchy
of ecological economies. This systems approach to the aforementioned
problem domain is inevitable.

The agent motivation research methodology employs a bottom-up design and
implementation, focusing in particular on the use of the hierarchy of formal
languages. As discussed above, this methodology is interoperable with the
development methodology discussed in Section 3.2, but also interoperates
with the TD methodology discussed in Section 3.1 by considering an ever-
broadening, over-arching set of goals. More information on the design and
implementation of agent motivation and an analysis of the systems decision-
making capabilities is provided in Chapter 4.

4. CommunitySim Application
Section 4.1 explains CommunitySim in general, defines the RAP model in
detail, and explains two novel concepts for trade, the non-local vendor and
the marketplace. Section 4.2 discusses the choice of development
environment among available alternatives. The design of the CommunitySim
Extensible Core Framework (ECF) and the high-level interactions of the
various subsystems are discussed in Section 4.3. The Trees and Fruit model
and its design and implementation are discussed in detail in Section 4.4.
4.1 CommunitySim Overview
CommunitySim is a simulation environment designed and developed by the
author for the analysis of local economics. It is written in Python with the
wxPython graphical user interface (GUI) toolkit. It is designed to be as
generic and extensible as possible, with the key feature being the ECF,
which provides an application independent suite of tools for the construction
of locally relevant economic models. CommunitySim has applicability with
governments, NPOs, SMEs, and academic research.
CommuntySim and other artificial life simulation environments share some
similarities and some differences. CommunitySim supports the simulation
of decentralized models employing agents and focuses on economics, rather
than physics and biology. It also is based on a complex system, which is a
departure from artificial life. CommunitySim is being developed in tandem
with the Trees and Fruit model, which will be discussed at length in Section
4.4. The evolution of both CommunitySim and the Trees and Fruit model is
relevant to the overview of CommunitySim.
It was necessary to expand the RAP model with a concrete example in order
to motivate a solution for the problem statement. Simultaneously, it was
necessary to limit the scope of the model with basic assumptions. Two
useful questions are whether labor is valued and traded and whether agents
are both producers and consumers. The principal assumption is that all
resources are valued with money, and thus a monetary exchange is created
rather than having a strictly barter system. Fund-service resources have
been undervalued when those resources are not traded locally but bought
from elsewhere. This provides an opportunity in simulation of the model to
adjust pricing and monitor the outcome. Currently only the Dollar is
supported. This would assist in data collection, among other benefits. Two
other important assumptions are that labor is not valued nor traded and

that agents are both producers and consumers. A detailed analysis of the
socio-economic consequences of these assumptions is beyond the scope of
this paper.
In order to minimize scope creep and to have a successful system running
sooner, only one community will be developed at a time, and only one
community will be implemented at first. As a result of this, trade
interactions with the external world are modeled with an object called the
Non-Local Vendor (NLV), which represents a non-local means of sourcing,
and possibly exporting as well. Regardless of the number of communities
involved in a simulation, the NLV would still be required, unless one is
modeling an entirely closed economic system such as the Earth itself or a
community that is off-the-grid. Hence, the RAP model can be summarized
as comprising the following possible entities: resources, value-added
products, time, and agents. Value-added products could be acquired from
the NLV or from another agent. Moreover, products could be limited to food
and other applicable necessities. Food could be bought or gathered from the
environment, and buying could occur through the NLV or from another
Consider a forest for a moment. Trees produce breathable air, which is a
non-rival use, yet they can be consumed for fuel to bum a fire, which is a
rival use. One construct could be that if there arent enough trees in the
world, agents start dying. This could occur, for example, when the number
of trees falls below a minimum threshold. Although this would certainly
model physical systems more accurately, the focus is on the local economy
and thus CommunitySim does not initially include explicit support for the
resource types of rival, non-rival, excludable, and non-excludable. Instead,
it employs a single resource concept. However, this does not preclude the
interpretation and analysis of particular resources as being of a given type.
For example, eco-localism argues that the difference between non-local and
local buying is that local spending attributes a higher value to fund-service
resource types. Via the use of the ECF, however, resource types can easily
be added later. Thus, the RAP model is now complete. Figure 4.1 depicts
the full version of the RAP model with the resource types.

Agents can Move, Gather, Produce, and Trade. Produce means to create a
product from resources and possibly other products. Trade means to buy
and/or sell products or resources. For example, each time step, agents
could choose to do two of the above, such as move two cells, or move one cell
and then gather resources.
Of the agent moves, Trade is sufficiently complex as to warrant additional
discussion. One idea is that agents could, Go to town every week. That is,
provide a marketplace or auction house where agents can trade resources
and products. This would allow the price for resources and products to vary
over time, depending on the availability of natural capital and the money
supply. Incentive to produce can be supported in the case that an agent has
one or more of a particular catalyzing item such as a tool, which would allow
for more efficient production and in essence allow agents to earn more
money from sales. Waldrop explains this concept as an autocatalytic set
[1992]. Agents that have products that help catalyze production would earn
more money, and thus the potential for an unequal wealth distribution is
Expanding on the idea of the marketplace, each individual could store
information about past performance, which may be a necessary condition.
Under this scenario, each individual would bring information, or heuristics,
to the marketplace to help them make decisions, i.e. how many of a given

resource they encountered during the last week or the price of the last item
that sold successfully. By supporting the village marketplace concept, a
unique set of models can be simulated that expand beyond the dynamics of
a predator/prey simulation. One application of this capability is to
determine whether agents who buy locally would value fund-services more
than agents who do not buy locally.
4.2 Development Environment
Several programming languages were considered for the development of
CommunitySim, including Ruby, Java, C++, and Python, among others. The
primary factors for decision-making were the language itself, the choice of
integrated development environment (IDE), the choice of GUI toolkit, the
availability of personal assistance, and the availability of other tools.
The factors affecting language choice were primarily the existence of object-
oriented programming features including polymorphism and inheritance, an
extensive class library, and the ease of learning the language. For the choice
of IDE, it was important to have multiple IDEs to choose from, but most
important features were the ability to organize files in a project and browse
classes and methods, effective library documentation, syntax highlighting,
and foremost a debugger. In terms of a GUI toolkit, the most important
factor was interoperability, which is non-trivial to deduce at first. Other
important considerations for GUI toolkits are the readability of the class
library or API set, the ease of implementation with a minimization of required
customization, and the existence of a form editor. Lastly, the availability of
add-ons and other tools that were developed to extend the programming
language were also important.
C++ was already known, and there was actually a strong motivation to
develop the GUI environment from scratch using assembly language, C/C++,
DirectX, or MFC. Ultimately, portability and write-ability reined supreme.
Ergo, Python 2.4 was the language of choice due to its relative maturity,
simplicity of syntax, extensive class library and built-in functions, object-
oriented features, documentation, availability of IDEs, availability of GUI
toolkits, and most importantly, colleagues that know the language. This was
a bold move, but it provided the opportunity to learn a new language.
Several IDEs and text editors for Python were considered, including
Pythonwin, WingIDE, BoaConstructor, and PSPad, among others. WingIDE
was the IDE of choice, even though it does not employ an open source
development model. This choice was clear due to its crisp interface,
apparent stability, documentation, and inclusion of the desired features
discussed above. The usefulness and importance of an effective IDE cannot
be overstated. Lastly, PSPad proved to be an excellent backup IDE.

The GUI toolkit of choice was wxPython. Python ships with a GUI toolkit
Tkinter, and there are other options available such as Swing via Jython.
wxPython appeared to be very well received in the Python community and
upon evaluation, it was perfectly interoperable with WingIDE and Python
with an acceptable level of issues. wxPython is essentially a Python
implementation of wxWidgets for C++. In terms of other tools, PyOpenGL
and SciPy were strongly considered in order to support an implementation of
the user interface that could show the agents and resources on a 2-D
graphical map. These were abandoned under the synthesized development
methodology discussed in Section 3.2 and to avoid the risk of interoperability
issues, the time required learning yet another system, and the cost of
configuring another tool.
In summary, the development environment is Python 2.4 running on
Windows 2000/ME/XP, WingIDE, and the wxPython GUI toolkit. When
Internet connectivity is non-existent, PSPad replaces WingIDE. Section 6.2
contains an analysis of the choices for development environment.
4.3 CommunitySim Extensible Core Framework
A description of the overall CommunitySim architecture is required in order
to discuss the ECF in greater detail. CommunitySim is divided into the
major subsystems and major components as follows:
Main application
o Core Framework
o Foundation
User Interface (UI)
o Agents
o Products
o Resources
o World
The main application forms the entry point for program execution, and
creates the UI and World objects, initializes them, and starts the
applications event processing and windowing system. The core framework
defines the abstract base objects, which form the heart of the ECF
inheritance hierarchy. The foundation provides the ECF with a toolkit of
model independent classes, which can be employed to quickly develop a new
local economic model. The UI provides the windowing system, GUI, and bi-
directional interface to the World object. The agents provide definitions of
the types of agents a specific model supports. Similarly, the products and
resources provide definitions of the types of products and resources a
specific model supports. Lastly, the World defines the rules for incorporating
resources, agents, and products into the World, defines the nature of the
map itself, and interconnects the UI. Figure 4.2 describes the relationships

between these subsystems at a high level. It highlights two key design
features. First, concrete classes of agents, products, and resources in the
World subsystem inherit the abstract base types CFAgent, CFProduct, and
CFResource in the ECF. Second, the interaction between the subsystems is
restricted to the UILog and the CFTimer objects. The World reports changes
via the UILog, and the UI dispatches user interactions via the CFTimer,
which links to the World.
User commands
Core Framework
Figure 4.2: CommunitySim high-level subsystem interaction
The ECF is divided into two main components, a core framework, which
contains the abstract base classes, and a foundation, which contains a
model independent class library. The inheritance hierarchy is as follows:
o CFItemObject (CFObject)
CFProduct (CFItemObject)
o CFMapObject (CFObject)
CFAgent (CFMapObject)
CFResource (CFMapObject)
CFItemObject represents any item that has an owner or parent object. In
other words, it can be held by another object. CFMapObject represents any
object that occupies a map location. CFProduct derives from CFItemObject
and therefore products are assumed to be carried and do not have a map
location whatsoever. Conversely, CFAgent and CFResource derive from

CFMapObject and therefore both agents and resources occupy cells on a
map. The advantage of this hierarchy is that a particular economic model
can employ any class type at any level of the hierarchy to fulfill specific
requirements. Moreover, since Python supports multiple-inheritance, an
object can conceivably be both an item object and a map object, however, in
that case the method resolution order must be considered.
The other component of the ECF is the foundation, which consists of the
following classes at the time of this publication:
CFIDGenerator, CFTimer, and CFRandom employ the singleton design
pattern. Because Python does not support access modes, this design
pattern is non-trivial to implement. The Python implementation of the
singleton design pattern is based on "A simpler singleton," by Matt Kangas
[2001]. The UIs UILog also employs this design. This is important, as these
four objects are stateful. An alternative approach may be possible using
class variables. The current implementation of CFRandom employs the class
libraiy random. The current implementation of CFTimer employs the
wx.PyTimer class, but only for the purpose of receiving a periodic signal
based in milliseconds. A dynamic tension exists between employing more
wx.PyTimer functionality to increase the robustness of CFTimer at the
expense of the generic code which is significantly more portable. At present,
CFTimer performs its own event handling and message passing.
As has been mentioned previously, CommunitySim is based on complex
systems, and specifically employs a 2-D map. CFLocation represents a
position (x,y) on this map. It provides a number of bound test functions,
string formatting, and a function to find valid neighboring cells. CFMap
represents the finite set of valid locations and the state space of the complex
system, maintaining the locations of CFMapObjects using objectIDs.
References can be made by objectID employing a dictionary or by location
employing a doubly subscripted list. CFMap maintains both data structures
with functions that allow map objects to be added, removed, or moved.
CFMap and CFLocation are interoperable.
CFEnergy represents the energy of an object. At present, CFEnergy is
optional and may be added to world objects as an instance variable. Energy
objects provide a novel abstraction and an opportunity for performance
enhancement in models employing hundreds or thousands of agents and
resources. Figure 4.3 describes the CFEnergy abstract data type. The object
is given an initial energy, and a mode is selected. Modes are: object decays

or loses energy over time, regenerates or gains energy over time, or does not
change whatsoever. There are four methods: Tap, Consume, Acquire, and
Update. Tap returns the requested energy, if available, and reduces the
energy of the object accordingly. Consume returns all remaining energy, and
sets the energy of the object to zero. Acquire is the complement of Consume,
and will add to the object the amount of energy input. This allows energy to
be exchanged between objects employing CFEnergy. It is possible for the
CFEnergy object to die, which occurs when the object has zero energy. In
that case, it ceases to operate normally. The Update function is rather
complex. When the CFEnergy object is created or updated, it is marked with
the current CFTimer value. CFEnergy objects need not be updated each
time step for their energy to be correctly computed. Instead, when the
update function is called to query the object, the difference between the last
updated time and the current time is multiplied by the delta value and
added or subtracted to the energy object before returning the state of the
object. In this way, world objects may be left alone for several time steps,
and they will automatically update when queried.
Lastly, CFDollar represents a single unit of currency. It provides a serial
number, in conjunction with CFIDGenerator, but employs its own set of
numbers distinct from those used by CFObject. CFDollar also maintains a
list of handlers, which can be used to gather relevant economic statistics.
CFWallet is a container class for CFDollar. It provides methods to add and
remove CFDollar instances either singly or as a list. It also maintains a
scalar value of the amount of money in the wallet.
4.4 Trees and Fruit
Trees and Fruit is a concrete RAP model that is implemented using
CommunitySim for the purpose of demonstrating its capabilities as well as
providing the model for studying the economic concepts of LME and wealth
distribution. Section 4.4.1 explains the model in detail. Section 4.4.2

summarizes the high level requirements of Trees and Fruit and includes
definitions of the development stripes, which constitutes a staged-release
plan for the software project. Section 4.4.3 provides an analysis of the
decision making processes of resources and agents, although the focus is on
4.4.1 Story
The simulation of the model occurs on a 2-D grid. It consists of three types
of objects: resources, agents, and products. Agents are called Actors and
they consume resources and create products, which are themselves
consumed or used. A basic assumption is that the population of Actors
never increases. The primary goal of the model is for the Actors to survive
There is only one primary resource type: A Tree. Trees are the only objects
in the World that can regenerate their energy supply. Regeneration mimics
the conversion of solar energy into plant energy. The primary Agent is the
Actor, who loses energy over time. Trees will produce and store Fruit over
time. Actors can harvest Fruit. The Fruit will slowly decay once picked.
Fruit can be eaten by Actors to sustain them. A fresher Fruit gives an Actor
more energy than an older Fruit. Trees age over time. The older they get,
the better the Fruit they produce and the larger the Tree grows. Trees can
also be plundered for Wood. Older Trees produce more Wood when
plundered than do younger Trees. Trees also reproduce when they are old
enough and conditions are right. When a Tree reproduces, another younger
Tree appears nearby on the map, and the parent Tree is tapped for energy.
Wood can be used as fuel to produce a Saw. Using a Saw can increase an
Actors yield when plundering a Tree for Wood. Wood and Fruit can be used
to produce Fruit Preserves. Fruit Preserves are a more concentrated, higher
quality food than the Fruit itself: it lasts longer and provides more energy
when eaten. Actors can only carry two items by default, so for example if
they plunder a Tree and it gives seven bundles of Wood, they will only be
able to carry two bundles, assuming their hands are empty. The other
bundles are therefore lost. Alternatively, Wood and a Saw can be combined
to produce Crates. Crates can hold up to eight items, but not another Crate.
Thus, if an Actor has one Crate, they can carry up to nine items, and if they
have two Crates, they can carry up to 16 items, rather than the minimum of
Actors can trade resources or products using Dollars as a medium of
exchange. They can also store Dollars in their Wallets. Actors start with a
preset amount of money. All trades will occur via another agent called the
Auction House (AH), which represents a local marketplace. Actors can
purchase resources and products from an agent called the NLV, which

represents non-local trading and is a sink for the money supply. Note that
there is currently no provision for the expansion of the money supply -
except possibly selling products to the NLV.
The Trees collectively are a fund-service, providing energy in the form of
Fruit for the Actors to eat. Fruit is ultimately the only source of food. The
Trees simultaneously provide a stock-flow in the form of Wood. Plundering
Trees results in a reduction in the ability of the resource system to provide
Fruit, thereby potentially jeopardizing the livelihood of the Actors in the long
run. Figure 4.4 depicts the Trees and Fruit model with these concepts.
O o
Figure 4.4: The Trees and Fruit model
4.4.2 Requirements and Staged Release Plan
After a significant amount of brainstorming and initial development, a formal
process began to form. The first goal was to have a working World with a
map, Trees, and Actors. Trees are simpler to implement than Actors. Hence,
the first task was to get a map implemented with Trees. The key to success
of this initial development was to be able to show changes to the map. A
choice had to be made between developing for a command-line interface (CLI)
and a GUI. At each time step, a timer signals a new day, and each
MapObject in the Map reports its status. Ultimately, a compromise between

both a CLI and GUI was chosen such that GUI controls were used, but the
status of the World was shown with text using a trace window. The
inspiration for this design came from the Java applications implemented for
intelligent agents by Bigus [2001], A few simple control buttons and menus
were added to pause, start, and stop the simulation, to report status, and to
control the creation/deletion/modification of various MapObjects. Object
IDs were used to make changes. Ultimately, this choice proved to be a good
middle ground between a full on graphical map, whilst maintaining the
image of a GUI. After initial prototyping and design work, the official
development process began.
The following descriptions explain the development process in detail,
highlighting the requirements for each step, or stripe, in the iterative
design, implementation, and testing process. The stripes are defined first,
followed by specific code examples and descriptions.
Stripe 1
The development methodology encourages completing the most important
and interesting functionality first. Thus, in order to show the passage of
time, a Timer is required and a way of showing the time, as well as a way of
starting, pausing, and stopping the simulation. These commands are
accessed through the Simulation menu. Buttons are optional and shortcut
keys are preferable. The timer status can be shown in a status bar or in a
static text item. Timer values will be 0 for not running, and 1+ for running.
There should be a simulation status as well; the valid states are Stopped,
Paused, and Running. States may change as improvements are made.
The Timer object is required to get a start value, stop value, and pause
capability. This is much different than timer events, which indicate no
inherent passage of time. The status bar displays the current state and the
correct timer value. Add shortcuts to the menus.
Stripe 2
Implement the text area for the CLI, display events, provide a simple logging
functionality for this UI element, and implement the buttons to add a
resource and to add an agent. Create pop-up dialog boxes that appear with
the click of the button that specify whether to add a resource or an agent.
Provide the details for these objects.
Stripe 3
The following is a two-part stripe. The first part is to create a map, which
consists of a two-dimensional list of MapObjects. Define the minimum
requirements for the Object and MapObject classes. Do not consider
ItemObject at this time. Pay particular attention to ensure the map
coordinates work interchangeably with MapObjects. The second part is to
implement the resource class and a rudimentary Tree that can be created
and inserted into the World. This requires a dialog box to select the Tree
type and its parameters. Note that Tree will have to register as a resource.

Stripe 4
Create the Energy object and begin creating the Tree. Then, get the Tree to
regenerate energy and correctly update energy levels when queried. Report
these results in the application. Improve the look and feel of the application,
including adding a speed control to the CFTimer object and link the control
to the presentation layer.
Stripe 5
Implement Fruit and the ability for Trees to produce Fruit automatically.
The Fruit need not yet decay as this will be functionality for a later date.
Also, add the ability for a Tree to reproduce itself.
Stripe 6
Improve the UI by having three panels instead of one:
Object Inspector
o This is not the final version of the object inspector, but it
should be made to be robust. Use a grid, tree control, or list
control to show information about the objects in the world at
any given time.
Text-Based Map
o This is not the graphical map display, but it is much more
effective than the current implementation. Utilize a text
control to continuously display the map.
o Create a substitute for the UILog target display. This text
control is used only to show useful logged events.
This stripe is necessary given that the text control buffer has a 32K limit that
fills rapidly when repeatedly displaying maps and trace information.
Stripe 7
Develop the CFAgent object and the ATActor(CFAgent) object. Implement
them with the minimum functionality required to manage energy and be
displayed on the map. Then, provide the capability for the Actor to move
from location [xi,yi) to location (x,y). Provide the required UI elements to test
and demonstrate this capability. Show Fruit in the rudimentary Object
Inspector as a subordinate of Tree. Create a separate dialog box that allows
modification of the Actors goal or target coordinate.
Stripe 8
Get the Actors to properly pick Fruit from the Trees. Conditions for this are
that the Actor be at a Tree, and that the Tree has Fruit. Set the amount of
Fruit to pick to be a parameter, and the default is to get as much Fruit as
possible. Do not include functionality for the Actors to move toward Trees by
themselves as this will be part of a separate stripe. For now, tests can have
Actors move toward trees manually using the UI. Eating the Fruit is an
instant effect, and so does not constitute the entire AIMove. Remove dead
Fruit before the turn.

This stage in development was very challenging. Due to the speed of
simulation, it was almost impossible to see what was happening with
objects, so single-step mode for the CFTimer was also required. Further,
Actor death was required. Many questions surfaced about the behavior of
Actors and how they move. For example, deciding when to eat and how
much to eat, or whether Actors can eat any food they have before or after
making their move, or both, all had to be decided upon. Although it was not
done in this last stripe, it had become necessary to upgrade the map display;
as the complexity of the logic increased, it became very difficult to see what
was happening showing objectIDs in the ASCII text map display.
Stripe 9
Re-implement the map display only by upgrading the text output only as
follows. Provide row and column headings for convenience and eliminate the
objectID display and replace it with T for Tree and A for Actor.
Stripe 10
Convert the map display to use wxGrid instead of wxTextCtrl. Depending on
complexity, consider implementing with deltas instead of passing the entire
map to the UI each day.
Stripe 11.1
Get the simulation to stop properly when the Stop Simulation menu item is
selected. This will improve testing efficiency.
Stripe 11.2
Implement capability to add agents and resources to the map by clicking on
the map. Begin by having the existing dialog boxes capture the coordinates
from the grid object. Expand by adding a toolbar, menu item, or button that
allows agents and resources to be added quickly.
Stripe 12
Prevent Actors from getting stuck. Do this by implementing the shortest
trajectory algorithm.
Stripe 13
Ensure the Actors do not die when alongside a Tree that has Fruit. Consider
tweaking the UI to allow program control of variables to perform this tuning.
If the Actors can be made not to die as quickly, make the Actor self-
motivating, so that they look around and decide what to do among current
alternatives. One good test case is to have several Trees in a spiral pattern,
with a fixed amount of Fruit on each. The Actor would have to go between
Trees to survive. Consider this as a possible demo.
Stripe 14
Create the CFDollar object and CFWallet objects. Provide any necessary UI
and logic infrastructure to support use of these new objects. Implement a
demo menu that will auto-generate test maps. Include the demos that were

discussed in Stripe 13. Provide a way of toggling tree reproduction and actor
auto-goal seeking (AGS).
Stripe 15
Implement the NLV. Provide UI support to add one or more NLV(s) to the
map. Enable actors to buy of items at the NLV. Also implement Wood.
Enable Actors to purchase Wood at the NLV. Next, allow Actors to plunder
Trees for Wood. Update the UI to show Wood as items being held by actors.
Stripe 16
Develop and add the Traffic Jam demo to the application. Modify the Stop
Simulation function to reset the timer count and empty the trace window.
Modify the trace window so that it never fills up. Implement functionality to
streamline demo map setup. Add functionality to set agent goal locations
automatically. Add capability to display actors as either A or its object ID,
and provide a checkbox in the UI that supports toggling between these two
options. Provide the Actor with income. Implement the NLV Diamond demo
and integrate it with the UI. Provide a checkbox to toggle tree plundering.
Stripe 17
Implement a stub for the AH. Ensure that they can be instantiated and full
UI support is available. Develop a demo that includes an AH. Develop
Products for the ECF. Develop, implement, and test Fruit Preserves. Ensure
that Actors can produce and carry Fruit Preserves. Develop and add the Las
Esquinas demo to the application.
Stripe 18
Implement AI logic for Fruit Preserves. Ensure that Actors can eat Fruit
Preserves. Implement starting auctions and auction buyouts for the AH.
Implement AI logic for Actors to start auctions and buyout auctions.
Develop a demonstration for the AH and integrate it with the application.
4.4.3 Decision Making Design and Implementation
Section 4.4.3 explains the decision making process of the Trees and Fruit
implementation using the CommunitySim ECF. It begins with a high-level
explanation of how decision making processes are initiated through the
application. The low-level Actor motivation process is explained later.
All actions that affect the world itself, including user commands and
simulation events are initiated through the CFTimer object in the ECF
foundation. This is shown in Figure 4.2. User commands call the CFTimer
method World to gain access to the current world object. The UI element
may then call any public method in the World object. In the future, a
message passing architecture may be preferable to avoid problems with
changes in the World subsystem. Simulation events occur in the form of a

timer tick. The CFTimer method _TimerEvent is called whenever the
pyTimer object signals. If appropriate given the state of the CFTimer object,
_TimerEvent calls the WOWorld method RunTimeStep. The WOWorld object
manages all map objects via a WOMap instance, which is a container for all
map objects, including resources and agents. RunTimeStep then calls the
method AIMove for each map object. Polymorphism determines which
AIMove method to call. In the case of a Tree, for example, the
RSTree.AIMove method is called. If a map object doesnt override AIMove,
then the base class CFMapObject.AIMove is called instead. For the case of
the Actor, the method ATActor.AIMove is called when the map object in
question is indeed of type ATActor. Figure 4.5 diagrams the process for
handling simulation events.
Figure 4.5: Simulation event handling
Actors can be thought of as deciding between two categories of choices.
Actors can either move from their current location to another location or
perform an action at their current location. The process by which Actors
move between locations is highlighted next. Once an Actor decides to move
to another location, it will set a goal location (x,y) on the map. AIMove then
calls _MoveTowardGoalLocation. Figure 4.6 shows the Python
implementation of this function. An explanation follows.

1 def _MoveTowardGoalLocation(self):
2 world = CFTimer.WorldO
3 valtdChoices = world.GetEmptyNeighboringCells(self.LocatlonO)
4 goodChoices = []
5 if self.Location0,IsOn(self._goalLocation):
6 return False
8 minLocs = [1
9 minVal = self._horizon
10 for item in CFLocation.DIRS:
11 temp = self.Location0.OfHere(item. world.GetWorldXO, world.GetWorldYO)
12 if (temp is not None):
13 value = self._mapSum.FindByLocation(temp)
14 if value is not None:
15 if value < minVal:
16 minVal = value
17 minLocs = [temp]
18 elif value is minVal:
19 minLocs.append(temp)
21 if len(minLocs) > 0:
22 selection = CFRandom.Seleet(minLocs)
23 else:
24 dist = self.Locationfl.Distance(self._goalLocation)
25 shortestDistance = self.Location0.Distanee(self._goalLocation)
26 for cell in validChoices:
27 distHereToCell = self.Location().Distance(cell)
28 distCellToGoal = self._goalLocation.Dlstance{cell)
29 if (distHereToCell + distCellToGoal) is shortestDistance:
30 goodChoices.append(cell)
31 if len(goodChoices) is not 0:
32 selection = CFRandom.Select(goodChoices)
33 elif len(validChoices) is not 0:
34 selection = CFRandom.Select(validChoices)
35 else:
36 selection = None
37 if selection is not None:
38 world.MoveMapObject(self.lD0, selection)
39 self._intentionalFocus -= 1
41 return True
Figure 4.6: ATActor._MoveTowardGoalLocation Python implementation
On Line 1 is the Python function header. At the time of this publication.
ATActor does not perform planning of trajectories, and therefore some degree
of computation is reduced by considering only neighboring cells. The list of
neighboring cells is obtained on Line 2 and is considered to contain the only
valid choices. In order to refine this list, an empty list of good choices is
started on Line 3. Lines 4 and 5 prevent further processing if the Actor is
already at the goal location.

Lines 8-19 implement a shortest trajectory algorithm. A precondition on
_MoveTowardGoalLocation is that the three maps self._mapHere,
self._mapThere, and self._mapSum are already generated. These maps are
nxm and match the world size. Obstructions are represented as empty
locations in these maps. For each entry (tj) in self._mapHere, the shortest
number of steps required to reach location (ij) from the Actors current
location is given in that cell. Similarly, for each entry (Jc,Q in self._mapThere,
the shortest number of steps required to reach location (k, Z) from the Actors
goal location is given in that cell. Lastly, the map self._mapSum is the
matrix sum of self._mapHere and self._mapThere. Thus, in lines 8-19, the
Actors current location is mapped onto self._mapSum. For each valid
corresponding neighbor cell, the set of cells with minimum values represent
the best choices.
The self._horizon variable limits the choices to a certain number of moves.
This variable is set at a higher level of the AI. For example, the horizon can
represent the maximum number of days before the Actor dies, and therefore
the AI should not attempt to go to a goal location that exceeds this value.
The algorithm guarantees that the locations in minLocs are on the shortest
trajectory and that the Actor will not be blocked by obstructions. In other
words, the Actor will find a path to the goal location, if it is reachable.
However, it does not apply in the case where the goal location is not
reachable. Lines 21 and 22 determine if the first part of the algorithm was
successful. If it was, it makes this selection.
Lines 23-32 implement the naive algorithm for finding the shortest path.
Line 24 computes the distance between the current location and the goal
location, which is also the shortest distance. Lines 27 and 28 compute the
sum of the distances between the current location and one of the valid cells
and that valid cell and the goal location. On lines 29 and 30, if this sum is
the same as the shortest distance, then it is considered a good choice.
Although this is the naive algorithm, it can be shown that this solution is a
special case of the Grammar of Admissible Trajectories [Stilman 2000]. This
naive algorithm applies when the goal location is blocked and first algorithm
can not be applied because the self._mapSum map is completely empty.
Lines 33 and 34 implement the random selection algorithm. When no valid
choice is a best choice, then _MoveTowardGoalLocation selects randomly
from any neighboring cell. When no possible move can be made, Lines 35
and 36 set the selection to None. Lastly, lines 37-41 actually make the Actor
move. The World object must be called to do this so that its data structures
can be updated accordingly. One remaining item is intentional focus.
Intentional focus allows Actors to avoid unnecessary computation at higher
levels. This focus is diminished the closer the Actor gets to the goal location,
and thus the variable is decremented for each move that is made.

5. Results
Chapter 5 contains results from specific demonstrations and analyzes their
outcomes. It provides detailed explanations and screen shots of
CommunitySim operating under a variety of circumstances. Section 5.1
provides examples of Actor motivation under three test scenarios. Section
5.2 provides examples of Actors performing higher-level functions under
three test scenarios. Section 5.3 expands further with examples of economic
models employing a wide range of CommunitySim capabilities.
5.1 Actor Low-Level Motivation Test Scenarios
Three examples that demonstrate low-level actor motivation are considered
in this section. They are the Obstacles, the Room, and the Maze -
Walkthrough. The Obstacles is a reproduction of an example of obstacle
avoidance given in Stilman [2000]. The Room example shows that an Actor
can enter and leave a room even when the length of the shortest trajectory is
greater than the shortest directed distance due to the presence of obstacles.
Lastly, Maze Walkthrough demonstrates that an Actor can get through a
complex network of walkways to get to a goal location. This example is
shown with a horizon of 13 and of 23. All examples in this section are
performed on an 8x8 grid.
5.1.1 Obstacles
Figure 5.1 shows the initial configuration of the simulation. A brief
introduction to the UI will assist further discussion. The left section
contains a tree control which is the object inspector, which lists all map
objects, their locations, any items it is holding, if applicable, and the objects
energy level, if applicable. The center section contains a map display on the
top and a trace window on the bottom. The right section contains user
controls for the simulation. At the top are the quick-add buttons, which will
add an instance of a map object to the world at the current cursor location,
if the location is empty. At the bottom are the buttons to add a resource or
agent via a dialog box, and to modify an agents goal location. The
checkboxes control whether or not Trees reproduce and whether Actors seek
their own goal locations. The status bar at the bottom shows the state of the
simulation, which can be stopped, running, or paused. It also shows the

current day. Simulations start from day 0 and increment by one day each
time step.
I Fie Snxiation Qemo
I --BResoirces
, Tree 1 (0)
! Tree 2(0)
| Tree 3(0)
' - Tree 4 (0)
, -Tree 5(0)
Tree 6 (0)
i Tree 7 (0)
Tree 6(0)
* Tree 9(0)
Tree 10(0)
B Agents
B Actor 11(0)
(3,2) 3000
(4,2) 3000
(4,3) 3000
(3,3) 3000
(3,4) 3000
(4,4) 3000
(3,5) 3000
(4,5) 3000
(5,1) 3000
(6,1) 3000
(7,0) 300
e A
l_ 2 v
3 T i T
4 T T
S T | T

| Quck Add Tree |
( Quick Add uctor j
| QuKkAddMLV |
New Tree created at (4,4).
New Tree created at (3,5).
New Tree created at (4,5).
New Tree created at (5,1).
New Tree created at (6,1).
New Actor created at (7,0).
User requested Actor 11 to new target goal: (2,2)
Tree reproduction cfisabied.
Actor auto-goal seeking dsabied.
Modfy Agent...
jj| Enable tree reproduction
Status: Stopped Day: 0
Figure 5.1: Obstacles setup
This simulation sets Trees at locations indicated by T on the map display.
Our Actor is at location (7,0). The Actor is directed to location (2,2) using the
modify agent feature. Tree reproduction is disabled to prevent changes to
the obstacles. Tree plundering is disabled in code for this example. The
Actor AGS is also disabled to prevent the Actor from straying from the goal.
Figure 5.2 shows each movement in the simulation as the Actor moves
toward the goal location. For brevity, the details of the construction of the
maps are omitted.

< *i3smszi


I New Tree created at (4,4).
i New Tree created at (3,S).
i New Tree created at (4,5).
I New Tree created at (5,1).
I New Tree created at (6,1).
j New Actor created at (7,0).
| User requested Actor 11 to new target goal; (2,2)
j Tree reproduction disabled,
i Actor auto-goal seeing disabled.
Tree reproduction disabled.
Actor auto-goal seefcng dsabled.
Svmiabon is now Paused,
Sngle step mode enabled.
Single step mode enabled.
Sngle step mode enabled.
Sngle step mode enabled.
Chcaces: [ (6,0) ]
Actor 11 moved to (6,0).
Sngle step mode enabled.
Sngle step mode enabled.
Single step mode enabled.
Choices; [ (6,0) ]
Actor 11 moved to (6,0).
Single step mode enabled.
Sngle step mode enabled.
Choices: [ (5,0) ]
Actor 11 moved to (5,0).
Choces: [ (6,0) ]
Actor 11 moved to (6,0).
Sn^e step mode enabled.
Sngle step mode enabied.
Choices: [ (5,0) ]
Actor 11 moved to (5,0).
Sngle step mode enabled.
Choices: [(4,1) (4,0) ]
Actor 11 moved to (4,0).
Actor 11 moved to (4,0).
Sngle step mode enabled.
Single step mode enabled.
Single step mode enabled.
Single step mode enabled.
Single step mode enabled.
Choices; [ (3,1)]
Actor 11 moved to (3, !)
Figure 5.2: Obstacles movements
The left panel shows the initial configuration. The second panel shows the
Actor moved to location (6,0). The shortest trajectory algorithm only
provided one choice. The fourth panel shows the Actor at location (4,0).
Note in the trace window that the Actor chose between (4,1) and (4,0). Thus,
there are two trajectories that are shortest paths for the Actor. The right
panel shows the Actor in its penultimate location. Figure 5.3 shows the
application when the Actor reaches the goal location.
Hi CornmunitySim
| file Simulation Qemo
Map Object 1 Energy 1
v a Resources
Tree 1 (4) (3,2) 3300
j Tree 2 (7) (4,2) 3064
Tree3(10) (4.3) 2868
-Tree 4 (6) (3,3) 31S6
-Tree 5 (6) (3,4) 3156
Tree 6 (9) (4,4) 2940
Tree 7 (7) (3,S) 3084
j ; Tree 6 (5) (4,5) 3228
f Tree 9 (7) (5,1) 2940
Tree 10(4) --0- Agents (6,1) 3228
Actor 11 (0) (2,2) 346
Wallet: 0
| Quick Add Tree ]
| Quick Add Actor )
| Quck Add fg.V |

Sngle step mode enabled.
Sngle step mode enabled.
Sn^e step mode enabled.
Choices: [(3,1)]
Actor It moved to (3,1).
Sngle step mode enabled.
Sn^e step mode enabled.
Choices: [ (2,2) ]
Actor 11 moved to (2,2). 5.
} Add Resource... ]
| AddAgant... |
| Modfy Agent... j
Enable tree reproduction
Status: Paused_ _________ _____ ________________Pay: 14
Figure 5.3: Obstacles final configuration

The status bar shows that the current day is 14. However, the Actor only
made five moves. The reason for the delays is that the Actor stopped to pick
Fruit along the way and also stopped to rest (chose the do nothing move).
On day 0, the Actor had 300 units of energy. On day 14, it had 346 units of
5.1.2 Room
The Room simulation uses Trees to create the walls of a room. The Actor
must either get into the room or out of the room. For brevity, only the
former case is discussed. The settings remain the same as for Obstacles
above. Figure 5.4 shows the initial configuration of the simulation. The
cursor in the map display indicates the Actors goal location (4,4).
I CommunitySim
I Fie gmulabon gsmo
| Map Obiect {Location 1 Energy

Tree 96(0) (4,6) 3000
! Tree 84(0) (5,4) 3000
\ Tree85<0) (2,6) 3000
; ; Tree 86 (0) 0,6) 3000
1 t-Tree 87(0) (1,5) 3000
Tree 88(0) (1,4) 3000
j Tree 89(0) (1,3) 3000
1 Tree 90 (0) (2,3) 3000
Tree 91 (0) (3,3) 3000
Tree 92(0) (4,3) 3000
Tree 93(0) (5,3) 3000
) Tree 94(0) (5,6) 3000
Tree 95(0) (5,5) 3000
Actor 97(0) (3,0 300
New Tree created at (2,3).
New Tree created at (3,3).
New Tree created at (4,3).
New Tree created at (5,3).
New Tree created at (5,6).
New Tree created at (5,5).
New Tree created at (4,6).
New Actor created at (3,1).
User requested Actor 97 to new target goal: (4,4)
QcackAdd Xree |
Quick Add Actor )
QtickAddtf.V |
Add Resource...
Add Agent...
0 Enable bee reproduction
f~l Enable actor auto-goal seeking
Status: Stopped Day: 0
Figure 5.4: Room simulation setup
The Actor has a choice for the first move between locations (2,2), (4,2), (2,1)
and (4,1) because the Actor is positioned relative to the center of the
symmetric room. In our case, the Actor chose location (2,1). Figure 5.5
shows the map display for each of the Actor moves.

Figure 5.5: Room simulation movements
The Actor took 43 days to arrive at the goal location, having stopped to
gather Fruit and rest along the way. Figure 5.6 shows the final configuration
upon arrival at goal location (4,4). The object inspector indicates that the
Actor is holding a piece of Fruit in their left hand with object ID 280 and 16
units of energy.
I CommunitySim
Fie gkniabon Qemo

: 0- Resources
~ Tree 96 (14)
: Tree 84(10)
j Tree 85 (18)
-Tree 86 (10)
j Tree 87(11)
) - Tree 88(18)
* Tree89(13)
Tree 90 (12)
i Tree91(13)
| !- Tree92(13)
I Tree93(15)
j Tree 94 (12)
| Tree 95(12)
-Actor 97(1)
r Waflet: 0
l- Left Hand: FnJt 280
(4,6) 3150
(5,4) 3510
(2.6) 2862
(1,6) 3294
0,5) 3006
(1.4) 2862
(1,3) 3006
(2,3) 3150
(3,3) 3150
(4,3) 3150
(5,3) 2934
(5,6) 3006
(5,5) 3438
(V) 297
>i*T* T*Wd j Quck Add Iree
0 . ,i
l! 2 ; - ; : | Qiick Add Actor
tIt t i T ' El i X | Quck Add (J.V
T __L_>
i, E t TT ! :
Choices: [ (3,6) ] $j:
Actor 97 moved to (3,6).
Single step mode enabled.
Choices: [ (3,5) (4,5)]
Actor 97 moved to (4,5).
Sngte step mode enabled.
Single step mode enabled.
Choices: [(4,4)]
Actor 97 moved to (4,4).
| Add Resource... j
[ Add Agent ... j
Q Enable tree reproduction
[~1 Enable actor auto-goal seeking
Status: Paused_________________________________Pay: 43_____
Figure 5.6: Room simulation final configuration

5.1.3 Maze Walkthrough
This simulation uses Trees to create the walls of a simple maze. A single
Actor must find a path through the maze to the goal location at (6,5). Figure
5.7 shows the initial configuration of The Maze Walkthrough simulation.
Hie StaJabon gemo
MapObiect 1 Location 1 Energy I
i~ Tree 4(0) 0,1) 3000 A
. h- Tree 5 (0) (4,1) 3000
i~ Tree 6 (0) (5,1) 3000
Tree 7(0) (6.1) 3000
j ; Tree 8 (0) (7,3) 3000
Tree 9(0) (6,3) 3000 II-
Tree 10(0) (5,3) 3000
: Tree 11(0) (4,3) 3000 1
Tree 12(0) (3,3) 3000 a
Tree 13(0) (2,3) 3000 1
1 Tree 14 (0) (1,3) 3000
! r Tree 15(0) (0,5) 3000
j j- Tree 16(0) (1,5) 3000 i*
j Tree 17(0) (2,5) 3000
! Tree 18(0) (3,5) 3000 f
Tree 19(0) (5,4) 3000 *
Tree 20(0) (5,5) 3000 *3
Tree 21(0) (5,6) 3000 I
Tree 22(0) (6,6) 3000 I
I Tree 23(0) (2,7) 3000 V
Tree 24(0) (1,7) 3000
} Tree 25(0) (0,7) 3000 4 t ii
| Tree 26 (0) '-S'Agents (3,7) 3000
0 Actor 27 (0) Walet: 0 (0,0) 300 ! V
{ QuckAddlree j
| Quick Add Actor j
| Qijck Add tf-V |

New Tree created at (6,6).
New Tree created at (2,7).
New Tree created at (1.7),
New Tree created at (0,7).
New Tree created at (3,7).
New Actor created at (0,0).
Tree reproduction dteabied.
Actor auto-goal seeking dsabied.
User requested Actor 27 to new target goal: (6,5)
J_______Add Resource ..._________I
| Add Agent... |
^~tniinIIWoitf)rAgent~~. |
QEnabte tree reproduction
Q Enabie actor auto-goal seeigng
Status: Stopped
Day: 0
Figure 5.7: Maze Walkthrough setup
Rather than show each movement on the map display, the three planning
maps discussed in Section 4.4.3, self._mapHere, self._mapThere, and
self._mapSum will be explored for horizons of 13 and 23. The minimum
horizon to find the goal location is 23. Figure 5.8 shows the planning maps
generated for this simulation by CommunitySim with a horizon of 23.

Map Display self.jmapHere
0 ; 2 3 4 5 6 7 0 2 3 4 5 6 7
0 A 0 0 1 2 3 4 5 6 7
j T T T T T T T X X X X X X X 7
2 2 14 13 12 11 10 9 8 8
3 T T T T T T T 3 14 X X X X X X X
4 T 4 15 15 16 17 18 X X X
5 T T T T T O 5 X X X X 18 X 23 23
6 T T 6 22 21 20 19 19 X X 22
7 T T T T 7 X X X X 20 20 21 22
self.jnapThere self._mapSum
0 2 3 4 5 6 7 0 2 3 4 5 6 7
0 X 22 21 20 19 18 17 17 0 X 23 23 23 23 23 23 24
1 X X X X X X X 16 ] X X X X X X X 23
2 10 10 11 12 13 14 15 16 2 24 23 23 23 23 23 23 24
3 9 X X X X X X X 3 23 X X X X X X X
4 9 8 7 6 6 X 1 1 4 24 23 23 23 24 X X X
5 X X X X 5 X 0 1 5 X X X X 23 X 23 24
6 8 7 6 5 4 X X 1 6 30 28 26 24 23 X X 23
7 X X X X 4 3 2 2 7 X X X X 24 23 23 24

Figure 5.8: Planning maps with a horizon of 23 at location (0,0)
The top-left panel shows the map display for convenience. The top-right
panel shows that the Actor can reach the goal location at (6,5) in 23 moves.
Note that locations (6,5) and (7,5) are not reachable within the horizon of 23,
even though these locations are not blocked by trees. The bottom-left panel
indicates the regions that can reach the goal location. The bottom-right
panel shows the matrix sum of the self._mapHere and self._mapThere. At
each time step, the Actor chooses the location with the minimum map sum
value among available choices. Hence, the Actor will choose only to move to
locations with corresponding map sum values of 23, in this case. Later in
the simulation, the Actor reaches location (1,4). Figure 5.9 shows the
changes in the planning maps at this point in the simulation.

Map Display self.jnapHere
0 2 3 4 5 6 7 0 J 2 3 4 5 6 7
0 0 15 14 13 12 11 10 9 9
) T T T T T T T X X X X X X X 8
2 2 2 2 3 4 5 6 7 8
3 T T T T T T T 3 X X X X X X X
4 A T 4 0 1 2 3 X 9 9
5 T T T T T 0 5 X X X X 3 X 8 8
6 T T 6 7 6 5 4 4 X X 7
7 T T T T 7 X X X X 5 5 <5 7
self.jnapThere self.jnapSum
0 i 2 3 4 5 6 7 0 } 2 3 4 5 6 7
0 X X X X X X X X 0 X X X X X X X X
; X X X X X X X X 1 X X X X X X X X
2 X X X X X X X X 2 X X X X X X X X
3 X X X X X X X X 3 X X X X X X X X
4 X X 7 6 6 X 1 4 X X 8 8 9 X 10 10
5 X X X X 5 X 0 1 5 X X X X 8 X 8 9
6 6 7 6 5 4 X X 1 6 15 13 11 9 8 X X 8
7 X X X X 4 3 2 2 7 X X X X 9 8 8 9

Figure 5.9: Planning maps with a horizon of 23 at location (1,4)
The top-right panel shows that all unblocked areas of the map are reachable
within a horizon of 23 and that the goal location is reachable in 8 moves.
The bottom-left panel shows that the Agent is blocking the path to the top
part of the map, and therefore these areas are marked as unreachable. The
bottom-right panel shows the locations marked with 8 as part of the
shortest trajectory. Now consider the same map configuration with a
horizon of 13. Figure 5.10 shows the planning maps in this new scenario.

Map Display self.jmapHere
0 2 3 4 5 6 7 0 1 2 3 4 5 6 7
0 A 0 0 1 2 3 4 5 6 7
T T T T T T T X X X X X X X 8
2 2 X 13 12 11 10 9 8 8
3 T T T T T T T 3 X X X X X X X X
4 T 4 X X X X X X X X
5 T T T T T O 5 X X X X X X X X
6 T T 6 X X X X X X X X
7 T T T T 7 X X X x X X X X
self.jmapThere self.jnapSum
0 I 2 3 4 5 6 7 0 1 2 3 4 5 6 7
0 X X X X X X X X 0 X X X X X X X X
! X X X X X X X X J X X X X X X X X
2 10 10 11 12 13 X X X 2 X 23 23 23 23 X X X
3 9 X X X X X X X 3 X X X X X X X X
4 9 8 7 6 6 X 1 1 4 X X X X X X X X
5 X X X X 5 X 0 1 5 X X X X X X X X
6 8 7 6 5 4 X X 1 6 X X X X X X X X
7 X X X X 4 3 2 2 7 X X X X X X X X

Figure 5.10: Planning maps with a horizon of 13 at location (0,0)
Within a horizon of 13, the goal location is no longer reachable. Thus the
shortest trajectory algorithm does not apply in this situation. The Actor will
still reach the goal location by resorting to the naive algorithm. This means
that there may be some cases where the Actor could still become stuck.
Figure 5.11 shows the result of running the simulation to the end with the
horizon still set to 13.

I CommunitySim
file Simulation Qemo
Map Object 1 Location J Energy
51 Tree 6 (8) (5,1) 3342 *
J 5} Tree 7 (8) (6,1) 3702
Tree8(ll) (7,3) 3558
-Eft Tree 9 (14) (6,3) 3198
Tree 10(12) (5,3) 3486
Tree 11 (IS) (4,3) 3198 . f
1 Tree 12(12) (3,3) 3702
Tree 13(9) (2,3) 3486
! -Tree 14(14) (1,3) 3342
i -Tree 15(8) (0,5) 4134
> Tree 16(15) (1,5) 3196
-Tree 17(11) (2.5) 3630 fi
Tree 18(13) (3,5) 3558
-Tree 19 (13) (5,4) 3630
Tree 20 (8) (5,5) 3486 1
Tree 21 (14) (5,6) 3270
Tree 22 (4) (6,6) 3558
Tree 23 (8) (2,7) 3646
! -Tree 24 (13) (1,7) 3342
-Tree 25(14) (0,7) 3916
-Tree 26(11) Agents (3,7) 3702 £
Actor 27 (2) Wallet: 0 (6,5) 413
Right Hand: Fruit 62S 24 J-
T T ; T T;TT T
T1 T T 1T T T T
T El
876S4XX 1 )
setf ._map5um: [
QuckAdd Tree
j Quick Add Actor |
1 QJckAddjjL V 1
Add Resource...
Add Agent...
0 Enable tree reproduction
0 Enable actor auto-goal seekng
Figure 5.11: Maze Walkthrough final configuration
The Actor is holding two pieces of Fruit upon arrival at the goal location
(6,5). Its energy is at 413, which is higher than the initial level of 300. It
took 63 days for the Actor to arrive at the goal location. The Obstacles, the
Room, and the Maze Walkthrough examples succinctly show the intricacies
of agent motivation using CommunitySim. The Maze map will reappear in a
forest example in Section 5.2.
5.2 Actor High-Level Function Test Scenarios
Four examples are considered that demonstrate high-level Actor
functionality. They are the Traffic Jam, the Diamond, the NLV Diamond,
and Maze Forest. Traffic Jam is a lively multi-agent demonstration of the
actor motivation capabilities. Diamond introduces the actor auto-goal
seeking (AGS) capability. It is a steady-state solution involving Tree
resources and one agent Actor. NLV Diamond is the same as Diamond, but
using NLVs instead of Trees. Maze Forest is the same map as Maze -
Walkthrough described in Section 5.1, but demonstrates actor tree
plundering instead.

5.2.1 Traffic Jam
The Traffic Jam simulation demonstrates a multi-agent competitive
environment. Two teams of four Actors compete for control of a passageway
that links two sides of the map. Their goal is for each team member to reach
their designated goal locations before the other team. There is no explicit
collaboration between Actors on the same team or otherwise. Figure 5.12
shows the output of the trace window upon setup and describes the initial
configuration of the map. In order to distinguish individual Actors on teams,
a new checkbox is provided in the UI to display Actor object IDs instead of
the symbol A.
Trace Window
Simulation reset.
New Actor created at (CUD).
Target goal for Actor 1: (4,0)
New Actor created at (0,11.
Target goal for Actor 2: (5,0)
New Actor created at (1,0).
Target goal for Actor 3: (6,0)
New Actor created at (1,1).
Target goal for Actor 4: (7,0)
New Actor created at (6,6).
Target goal for Actor 5: (0,7)
New Actor created at (6,7).
Target goal for Actor 6: (1,7)
New Actor created at (7,6).
Target goal for Actor 7: (2,7)
New Actor created at (7,7).
Target goal for Actor 8: (3,7)
New Tree created at (3,0).
New Tree created at (3,1).
New Tree created at (3,2).
New Tree created at (33).
New Tree created at (4,4).
New Tree created at (4,5).
New Tree created at (4,6).
New Tree created at (4,7).
New Tree created at (42).
New Tree created at (3,5).
l ll 1| 3|4; 5| 6 ?|
New Tree createe
. New Tree created
: New Tree crewed
; New Tree created
New Tree created
New Tree created
New Tree created
' New Tree creates
: New Tree created
at (3.1).
at (3.2).
at (3,3).
at (4,4).
at (4,6').
at (4,7).
at (4.2).
at (3,5).
0 1 2 3 4 5 6 7
dl T s ST f
9 9 T , r'

T J-
/ T b b
4 T £ 9
.jgpcrfy Agent
0 Enable treereoroducbon
0EnaWe acax ACS
0Enabie Object S3 Dsptay
Figure 5.12: Traffic Jam setup
The left panel shows the initial positions of the Agents. Team One Agents
are labeled 1-4 in the map display, and are shown in the upper-left hand
comer of the right panel. Team Two Agents are labeled 5-8 in the map
display and are shown in the lower-right hand comer of the right panel.
Arrows point to the goal locations of each of the agents. Figure 5.13 shows
the simulation at key points.

On Day 10, Actor 5 and Actor 3 become locked in a battle for passage to the
other side. Actor 3 loses that battle, but on Day 21, Actor 2 enters the
passageway before Actor 5 can get through. Actor 5 concedes on Day 24,
letting two of Team Ones Actors through. By Day 30, Actor 5 makes it back
to the passageway and passes through on Day 30. On Day 36, Actor 1
passes by the unprotected passageway. Neither Actor 7 nor Actor 8 is able
to intervene. On Day 46, Actor 3 makes it through. All of Team Ones Actors
have crossed the passageway. By Day 52, Team One wins. On Day 59,
Actor 8 makes a random move, as the passageway to its goal location is
blocked by Actor 6. Finally, on Day 74, Team Two finishes. No Actors died
during the course of this simulation.
The total number of moves made by Team One was 58. Team Two made 100
moves. The Actors in Team One made 19, 11, 17, and 11 moves,
respectively. The Actors in Team Two made 19, 28, 21, and 32 moves,
respectively. To further investigate the nature of this simulation, Figure 5.14
shows the movement of Actors in the ten days leading to Day 21.
Actors 2 and 5 are highlighted as they are pivotal to the outcome of the
simulation. Actors 8 and 9 have made the most moves in the past ten days,
whereas Actors 3 and 4 have recently made the least moves. Black arrows
indicate the last move. Dark grey arrows indicate the penultimate move.
Light grey indicate the twice previous move. It is apparent that many agents
are in a looping pattern, including Actors 2 and 5.

Figure 5.14: Traffic Jam, day 21
Actor 3 held location (3,4) from day 7 until it moved away on day 18. Actor 2
arrived at location (3,4) the following day. Actor 5 first arrived at location
(4,3) on day 9, but left to location (5,2) on day 14, and looped between the
two thereafter. Figure 5.15 shows a matrix of locations of the Actors from
day 11 through day 21.
1 2 3 4 5 6 7 8
11 (2,3) (1.4) (5,6)
12 (1.0)
13 (5,7)
14 (1.3) (5,2) (5,5)
15 (2,1) (2,3) (6,6) (6,3)
16 (5,6) (5,4) (6,6)
17 (4,3)
18 (2,4) (6,3) (5,5)
19 (2,0) (3,4) (2,5) (2,4) (5,2) (6,5) (5,4)
20 (2,6) (4,3) (5,6) (6,5)
21 (2,1) (5,5)
Figure 5.15: Traffic Jam, days 11-21

5.2.2 Diamond
The initial configuration of Diamond is shown in Figure 5.16.
In Diamond, a single agent must survive without being given an explicit goal.
The core of the Actor AGS algorithm is rather simple. If the Actor is not
hungry, it will explore and move toward Trees that are as far away as
possible, otherwise it will search and move toward the closest Trees.
Diamond positions two Trees on the main diagonal closer than the Trees on
the opposite comers, thus tempting the Actor to only visit locations (6,1) and
(1,6) and leave locations (0,0) and (7,7) alone. In order to balance the
movement choices, the Actor employs a heuristic when exploring. To reduce
computation and to prevent the Actor from looping between choices, AGS
sets a variable self._intentionalFocus, which is a counter set to the minimum
between the number of days required to arrive at the goal location and the
number of days before the Actor dies. When the variable is positive, AGS is
deactivated. It is decremented each time the Actor makes a move. When the
variable becomes zero or negative, AGS is again activated.
For this simulation, there is a 30% chance that the Actor will choose the
furthest target and a 70% chance that the Actor will randomly pick a target.
Simulation settings enable AGS but disable the Tree reproduction. A steady-
state solution is assumed if the Actor lives at least 5,000 days. In this
example run, the Actor chose the first goal location (1,6). Subsequent goals

were location (0,0), location (7,7), and then location (0,0) again. A steady-
state configuration was achieved. Figure 5.17 shows the application on day
Figure 5.17: Diamond final configuration
This steady-state configuration was achieved with the following initial
conditions for the Actor:
Initial Energy: 300 units
Decay Rate: 5 units/day
Maximum Energy: 500 units
Hunger Threshold: 200 units
Full Threshold: 400 units
Horizon: 13 moves
Exploring-Far Threshold: 30 (of 100)
Conditions set for the Tree:
Initial Energy: 3,000 units
Regenerate Rate: 42 units/day
Maximum Energy: 5000 units
Minimum Energy: 200 units
Maximum Fruit: 20 pieces
Fruit Energy Cost: 72 units/piece
Fruit initial conditions:
Initial Energy: 50 units
Decay Rate: 2 units/day

Maximum Energy: 100
Tree growth was enabled for the simulation. The Tree level limit was set to
5. Fruit produced by Level 5 Trees have 72 units of energy, rather than
their initial 50 units of energy. This gave the Actor an advantage. However,
running another simulation without the tree growth capability still yielded a
steady-state solution running at least 1,600 days with no evidence that the
Actor was in peril.
5.2.3 NLV Diamond
The initial configuration for NLV Diamond is shown in Figure 5.18. In
contrast to Diamond, the diamond pattern has been reflected across the line
x= y. This helps to avoid confusion between the two demonstrations.
The purpose of NLV Diamond is to demonstrate Actor purchasing at the
NLV, where Wood and Fruit are available for sale. For the purposes of this
simulation, Wood purchasing is disabled. The simulation operates correctly
with both AGS enabled and disabled. A steady-state was shown for 360
days, although an extended simulation was not attempted. Instead, five
simulations were run with AGS enabled, and then five simulations were run
with AGS disabled and a goal location specified at location (2,2). No changes
were made to the initial conditions between the two types of simulations,

however, doing this led to unexpected results. Figure 5.19 shows results
from the ten simulations.
Run AGS Enabled AGS Disabled
1 87 11
2 93 46
3 78 2
4 87 36
5 73 6
Figure 5.19: NLV Diamond Actor wealth after 360 days
The relevant initial conditions for the NLV instances were:
Fruit Selling Price: 3 dollars/piece
Fruit Initial Energy: 25 units
Fruit Minimum Energy: 15 units
Maximum Fruit: 5 pieces
Actors earn 1 dollar/day and begin with empty wallets. When AGS was
enabled, the Actor wealth averaged 84 dollars after 360 days, whereas with
AGS disabled, the Actor wealth averaged merely 20 dollars after the same
amount of time. Further discussion of this discrepancy is beyond the scope
of this section and will be further explored in Section 5.3.
5.2.4 Maze Forest
In order to better facilitate user interaction, Maze Forest is simulated with
the benefit of an additional checkbox in the UI that enables/disables Actor
tree plundering. Maze Forest demonstrates Actor tree plundering
capability, therefore, the Actor tree plundering checkbox is enabled. Actor
AGS is enabled as well. Figure 5.20 shows CommunitySim with the
aforementioned settings.

There are initially 26 Trees and one Actor. The simulation will be run for
100 days. The results of this simulation are shown in Figure 5.21.


9 Fite Sniatioo Qeno
Nap Object
r-BWaflet 100
Doiar 1 (1)
Dotar 2(1)
| Doiar 3 (1)
1' ' Doiar 4(1)
i Dof*-S(l)

Tree 6 (11) (5,1) 3744
Tree 7 (17) (6.15 3456
; Tree 8 (15) (7.3) 3096
' Tree 9 (13) (.3) 3744
Tree 10(13) <5.35 3600
Tree 15(16) (0,5) 3528
-Tree 17 (10) (2.5) 4243
Tree 13(11) 0.5) 4032
~B?ree 19(15) (5>4) 3384
i-BTree 20{H) (5.5) 3312
Tree 21(11) (5.6) 3528
. Tree 22 (14) (,} 3523
: Tree 23(9) {1.7, 3600
Tree 24 (n) 0,75 3672
!-Tree 25(12) (0.7) 3960
- Tree 26 (9) 0.75 4032
Agents : Actor27(2) (5.2) 408
in. f] . t^tT s T ,T T
*1 ! T .
£. - liT .7iT.T J T : ;i.T; ;
: Single step mode enabled.
Tree 13 has died'
Actor 27 moved to (4,2).
Single steo mode enabled.
Single step mode enaoted.
Smgie step mode enacted.
Actor 27: Pfcjndenng tree 18...
Single step mode enadled.
Actor 27 moved to (5,2$.
I Quiet.Adductor
[ 3Jdudcit.y
Acd Agent..
Modify Agent ~
QEnatAs free reproduction
pi Enable actor AGS
[3 Erta&te actor free otundering
0£naWe object ID dspta*

Figure 5.21: Maze Forest final configuration

At the end of the simulation, there are only 16 Trees remaining. The
relevant initial conditions for the Actor were:
Minimum Wood Yield: 0 pieces
Maximum Wood Yield: 2 pieces
Trees do not yield wood when plundered until after they grow to Level 1 or
higher. For this simulation, Tree reproduction was disabled. A separate
simulation, not shown, with Tree reproduction enabled yielded 20 Trees
remaining after 100 days. More test runs and variations of initial conditions
would be required to analyze the role that Tree reproduction plays in the
Maze Forest simulation.
5.3 Economic Model Scenarios
Section 5.3 combines and expands upon the capabilities demonstrated in
Sections 5.1 and 5.2. The look and feel of the UI is upgraded, a larger 13x13
world map is employed, and economic production and trade are shown. The
Actor AI heuristics have also been modified for these examples. Section
5.3.1 and 5.3.2 explain Fruit Preserves and the Auction House, respectively.
The NLV Diamond demonstration from Section 5.2.3 is revisited in Section
5.3.3. Section 5.3.4 introduces and discusses the Las Esquinas
5.3.1 Fruit Preserves
Fruit Preserves, as mentioned in Section 4.4.1, are a product made by
Actors. Fruit Preserves require Wood and Fruit to be made. Fruit Preserves
are a higher quality food than Fruit. As such, more than one piece of Fruit
is used in its production. In order to produce Fruit Preserves with more
than one piece of Fruit, a Crate is required, because in the Trees and Fruit
model one hand is initially holding a piece of Wood, and the other hand is
holding a piece of Fruit. Therefore, there is no way to create Fruit Preserves
with more than one piece of Fruit.
The solution involves producing Fruit Preserves over several days, so that
Fruit can be added to the Fruit Preserves over time. Class PDFruitPreserves
derives from CFProduct, which in turn derives from CFItemObject. Figure
5.22 shows the code for three key functions in PDFruitPreserves.

1 def StartFire(self, wood):
2 max_energy = wood.ShowEnergyO
3 energy = wood.BumO
4 self._flre = CFEnergy(energy, max_energy, 0, CFEnergy.MODE NONE)
5 if energy >= self.COOK_ENERGY_COST:
6 self,_state = self.COOKING
7 return True
8 return False
10 def Cookfself, fruit):
11 if not fruit.ShowEnergyO:
12 return False
13 if self.IsCookingO and self._flre is not None:
14 if self._amount < self.JAR_SIZE and \
15 self._fire.Tap(self.COOK_ENERGY_COST):
16 energy = fruit.EatMeO
17 self._energy.Acquire(energy)
18 self._amount += 1
19 UILog.LogfCooking Fruit Preserves. Jar is %d/%d full." % \
20 (self._amount, self.JAR_SIZE))
21 else:
22 self.SeakJarO
23 return True
24 return False
26 def SealJar(self):
27 if self.IsCookingO and self._amount >= 1:
28 self._state = self. COMPLETE
29 UILog.LogfFruit Preserves %d completed." % self.IDO)
30 return True
31 return False
Figure 5.22: PDFruitPreserves key functions
PDFruitPreserves is a stateful class. The three states are READY, COOKING,
and COMPLETE. When a PDFruitPreserves instance is created, its initial
state is set to READY. The function StartFire is defined in lines 1 -8 of Figure
5.22. StartFire consumes a piece of Wood that the Actor is holding, thereby
freeing a hand for carrying more Fruit. Once the fire is started, it keeps
burning until it runs out of energy. Energy from the fire is used only when
cooking. The function Cook is defined on Lines 10-24. Cooking consumes a
piece of Fruit, thereby freeing a hand for carrying more Fruit. The Actor may
cook as many times as desired until the jar is full, a limit defined by
PDFruitPreserves.JAR_SIZE or when the cooking fire runs out. SealJar is
defined on lines 26-31. SealJar is called by Cook when the jar is full, or
can be called explicitly by the Actor if it is important to complete the cooking
process sooner. Figure 5.23 shows how the Actor produces Fruit Preserves.

1 def JProduceFruitPreserves(self):
2 fruit = self._GetFruitO
3 wood = self._Get("Woodj
4 fp = self._Get("Fruit_Preserves")
5 if fruit is not None:
6 if wood is not None:
7 ID = CFIDGenerator.NewIDQ
8 fruitPreserves = PDFruitPreservesflD, self)
9 if fruitPreserves is not None:
10 UILog.Logf'Actor %d has begun cooking Fruit Preserves. " % self.IDQ)
11 if fruitPreserves.StartFire(wood):
12 self.JRemoveDeadWoodO
13 if fruitPreserves. Cook(fruit):
14 self._RemoveDeadFruitO
15 self._CarryItem(fruitPreserves)
16 return True
17 if fp is not None:
18 if fp.IsCookingO:
19 UILog.LogfActor %d continues cooking Fruit Preserves.' % self. IDO)
20 if fp.Cook(fruit):
21 self._RemoveDeadFruitQ
22 return True
23 return False
Figure 5.23: Actor Fruit Preserves production
Line 1 is the Python function header. Lines 2-4 gather information about
how to proceed by getting object references, if they exist. Lines 5-6 test
whether to create new Fruit Preserves. If needed, lines 7-8 create a new
PDFruitPreserves instance. Lines 11-12 start a cooking fire and consume
the Wood. Lines 13-14 cook the Fruit and line 15 carries the newly created
Fruit Preserves in one of the now empty hands. The alternative case is that
the Actor is adding to existing Fruit Preserves that are still being cooked.
Lines 17-18 test this condition. It is then a simple matter to cook the Fruit
as the PDFruitPreserves are already created.
The Actor will continue adding to the Fruit Preserves until the call to
fp.IsCookingO returns False. In that case, the Actor may continue to carry
the Fruit Preserves, eat them, or take them to the AH for sale. Figure 5.24
shows a simple example of an Actor cooking Fruit Preserves.

I CornmunitySim
Figure 5.24: Actor producing Fruit Preserves
5.3.2 Auction House
The Auction House (AH) developed for this research is relatively simple. It
supports two primary functions. Start Auction and Buyout Auction. Only
Fruit Preserves are allowed in the AH at this time. Ultimately, the AH is
designed to support many advanced functions, such as being able to specify
the duration of an auction, specifying the buyout value, charging a
commission for running an auction, allowing for a starting bid that is less
than the buyout value, allowing multiple bids over time, and allowing
different item types. Figure 5.24 describes how the AH works.
Auctions run indefinitely or until bought out. The price is set by the AH and
is defined by ATAuctionHouse.DEFAULT_PRICE. Figure 5.26 shows the
Simple Market demonstration in action.

Seller Agent
Start Auction
Buyout Auction
Figure 5.25: Simple auction house
I CornmunftySim
Pile gmutabon Qemo
MapObiect | Location JjSSSE 1
1 **v MapWWow
: Resources .. fZL tm i *uj n m
/n 3840 W o 1 2 sNisi, i;
j ta iivCv, uevei 3 Agents 0 Actor 1 (2) Wti) (1,2) 203 0. .1 m .4. N .
2 T 1 2 H
Walet: 185 Left Hand: Fru*5?4 38 A N f j
Right Hard: Fruit 556 26
j- & Actor 2 (0) (8,2) 192
i Wallet: 162
3 Aucbon.House 3 (1) (9,2) 5000
I Auction for Agent 474: Fruit_P 153
~3 NLV5(10) (0,0) 2000
r Revenue: 3 FriJt 579 wood 36 15 -2: < >
Fruit 501 FrutS84 17 Trace Window - 19
1 Wood 9 1 i FrUtS89 i- wood 16 Frist 593 ! Wood 22 Wood 29 3 NLV 6 (10) i~ Revenue: 13 (0,0 23 25 2000 | Smiiabon is now Paused. 1 Single step mode enabled. 1 Sngle step mode enabled, i Actor 2 moved to (8,2). i Sngle step mode ensiled. | Actor 1 moved to (1,2). : Single step mode enabled, Agent 1 selected goal: (0,3) i Actor 2 created auction. * I.
Fri# Sfifl <.. ,is * .>.
Status: paused Day: 168
Map Objects
QtSck Add free
QuckAddM-V |
Quick Add Auction Bouse ]
Add Resource...
Motffy Agent...
Simulation Settings
3 Enable tree reproduction
3 Enable treepowth
0 Enable actor AGS
3 Enable actor tree plundering
3 Enable economic trade system
3 Show al map objects
Figure 5.26: Simple Market, auction created

On Day 188, Actor 2 at location (8,2) starts a new auction, indicated in the
trace window. Auction House 3 at location (9,2) is shown in the object
inspector with one auction, namely Fruit Preserves 474 with 153 units of
energy. Actor 1 is several days away from the AH. Figure 5.27 shows the
application state several days later.
file Smuiabon Demo
| Map Object |Locabon J
1 Resources #
j S-Tree 4: Level 0(9) (0,2) 3996 p
j-B Acta 1(1) (8,1) las fe;
Walet; 184
Left Hand: Fru*_Preserves 47' 153 ill
r B Acta 2(0) (4,3) 122 W
Walet: 191 w
Auction _House 3 (0) (9,2) 5000
BNLV5(10) (0,0) 2000 p.
t Revenue: 3
Wood 16 i
Wood 36
! Wood 9 8
- Prut 620 15
: Fri* 624 19
j Frut 627 21
Wood 22
r Fruit 631 23
Frut 634 25
- Wood 29
0-NLV6(lO) (0,1) 2000
- Revenue: 13
. Wood 38
Wood 11
Fntf 671 is
* >*** m
Status: Paused
q|i |3 4|S S[7 a

Map Objects
| Quick Add free ]
j Quck Add Acta |
1 QuckAddMLV |
[ Qiick Add Aurtoi Bouse J
| Add Resource... j
| Add Agent |
1 BodfyAQar*... |
Trace Wrdow ....................... Simulation Settings
3 Enable tree reproducbon
0 Enable tree vowth
n Enable actor AGS
0 Enable actor tree plundering
0 Enable object ID display
3 Show al map objects
Srv^e step mode enabled. g)$
Actor 1 moved to (7,1).
Actor 2 moved to (6,3).
Sngle step mode enkiied.
Actor 1 moved to (6,1).
Acta 2 moved to (5,3).
Single step mode enabled.
Acta 1 won auction.
Acta 2 moved to (4,3). .-<
Day: 202
Figure 5.27: Simple Market, auction sold
On Day 202, Actor 1 has moved to location (8,1) adjacent the AH and just
purchased Fruit Preserves 474. The trace window indicates that the auction
was won. There are no more active auctions at the AH. The price of the
Fruit Preserves has been transferred from Actor 1 to Actor 2 by the AH
automatically. The difference can be seen by comparing the object inspector
of Figure 5.26 and 5.27. Because Actors earn one dollar per day, the
monetary exchange is non-obvious. The value of
ATAuctionHouse.DEFAULT_PRICE is 15 dollars. Figure 5.28 explains how
the money was exchanged.

Day Actor 1 Actor 2
188 $185 $162
189 186 163
... ... ...
201 198 175
202 199-15=184 176+15=191
203 185 192
Figure 5.28: Simple Market monetary exchange
5.3.3 NLV Diamond Revisited
The NLV Diamond demonstration from Section 5.2.3 demands additional
consideration. The application was enhanced to enable logging of data to a
file, which enabled the use of a spreadsheet to analyze data. Thus, eight
new simulations are considered with the same simulation duration of 360
days. Later, two new simulations are considered over a 1500-day time
frame. The first sets of comparisons occur with four runs with AGS enabled
and four runs with AGS disabled. Figure 5.29 shows the comparison.
Dollars Dollars NLV NLV Energy Energy
Figure 5.29: NLV Diamond 8, 360-day simulations
The same unitless scale is used for all data. The sets of data are in groups of
four. The first two groups represent the Actor wealth at the end of 360 days

with AGS disabled and AGS enabled, respectively. The second two groups
represent cumulative NLV revenues at the end of 360 days, with AGS
disabled and AGS enabled, respectively. The third two groups represent the
energy state of the Actor on day 360, with AGS enabled and AGS disabled,
respectively. These results concur with those previously reported.
Conclusions will be drawn at the end of this subsection.
Two, 1500-day simulations were performed with the same initial conditions
and configurations. Figure 5.30 shows a comparison of wealth as a function
of time for the Actors.
Actor Wealth Comparison
----AGS Enabled--------AGS Disabled
Figure 5.30: Actor wealth comparison 2, 1500-day simulations
The top line represents the wealth of the Actor with AGS enabled, which is
strictly higher than that of the Actor with AGS disabled with the possible
exception near the beginning of the simulation. Note the ever-widening gap
between the two. Figure 5.31 shows a comparison of cumulative NLV

Figure 5.31: NLV revenue comparison 2, 1500-day simulations
Notice the inverse situation has occurred. The bottom line represents the
simulation with AGS enabled. Yet, the NLV revenues are much more stable
than the Actor wealth counterparts. Furthermore, the variance between the
two data sets is much smaller. Figure 5.32 shows the comparison of Actor
energy levels.
Actor Energy Comparison
AGS Enabled-------AGS Disabled
Figure 5.32: Actor energy comparison 2, 1500-day simulations

The Actor energy comparison is interesting as well. In the simulation with
Actor AGS enabled, the Actor averaged 250 units of energy, whereas with
AGS disabled, the Actor averaged 438 units of energy. Note that the hunger
threshold is set at 200 units of energy.
These results are counterintuitive and interesting. It bears repeating that
the initial conditions, configuration values, map, and AI were identical for all
simulations. The difference is that in the AGS enabled case, the Actor moves
around the map actively, choosing goal locations, and moving toward them.
In the AGS disabled case, the Actor moves to a fixed location and remains
standing alongside the NLV the entire time.
When the Actor is active, its personal savings are greater and consumer
spending is less. The variance in NLV revenue is not significant relative to
the variance in Actor wealth during the same time period. Both simulations
appear to be steady-state solutions as the trends of each provide no
indication of significant, long-term hunger or impending death. However,
consider the active Actor maintained energy average of 250, well above the
hunger threshold and spent less money doing so. Conversely, the sedentary
Actor maintains a significantly higher average energy level of 438, which
could be interpreted as obese, and spends more money in the process.
Based on appearance of the trends of the actor wealth in Figure 5.30, one
may speculate that the active Actors wealth is growing linearly, while the
sedentary Actors wealth is growing sub-linearly, perhaps as a square root.
5.3.4 Las Esquinas
Las Esquinas is Spanish for The Comers. This 13x13 map contains NLVs
and Trees at the comers as well as a square of Actors near the center, thus
forming more comers, and thus the demonstration is aptly named. Figure
5.33 shows the CommunitySim application with the Las Esquinas
demonstration loaded.
Las Esquinas employs every user-configurable option discussed thus far.
The state transitions of the Actor are not obvious for a simulation of this
complexity. Figure 5.34 depicts a simplified version of the valid state
transitions given the rules and heuristics prepared for this simulation. For
example, the state variable AT(location) is not represented.

Figure 5.33: Las Esquinas setup
Figure 5.34: Las Esquinas Actor state transition diagram

Each of the seven circles represents a separate Actor state. Each smaller
circle represents one of the Actors hands. The distinction between left and
right hands does not matter, thus reducing the number of states. The letter
F stands for Fruit, W for Wood, and FP for Fruit Preserves. The
transitions for eating fruit alone are grey. Basic transitions are not labeled.
Transitions that are part of the economic trade system are shown with thick
arrows and are labeled. When the Enable economic trade system checkbox
is unchecked, the states that include FP are inaccessible, thus precluding
the ability to Produce Fruit Preserves, Start Auction, and Buyout Auction.
The Las Esquinas demonstration is run four times with the Enable
economic trade system checkbox checked, and four times with the checkbox
unchecked. The time limit was 1000 days. In order to fully support the
economic trade system, new code was written, the UI was improved, and
changes were made to existing code. These latest and relevant changes are
shown in the code listings in the Appendix. Interested readers are
encouraged to refer to them. Two noteworthy functions in particular are
ATActor.AIMove, which is responsible for low-level AI functions, and
ATActor.SetGoalLocation, which is responsible for high-level AI reasoning.
Moreover, SetGoalLocation determines what the Actors current overarching
goal is, whereas AIMove determines what the Actor should do given the
current situation. Figure 5.35 shows the results of one of the simulations
after 2000 days.
r Tree 2178: Level 4 {16}
Tree 6: level 5(15)
* Tree 7: Level 5 (20)
Tree 2317: Level 3(17)
-Tree 12169: Lev* i (i2>
j-ffiTree 6417: Level 2 (13)
j- Tree 8933: level 1(17J
: Tree 9240: Level 1(12)
--Tree 6425: Level 2 (165
- Tree 9115: Level 1 0)
r Tree 10525: Level 1 {11}
- Tree S2S2: Level 3 (165
Tree 12071: Level l (12)
-Tree 809: Level S (17)
i Tree 3243: level 3 (13)
Tree 11053: Level 1 (15)
Tree 5550: Level 2(13}
; Tree 10799: Level l (16)
Tree 7538: Level 2 (13)
I Tree 7478: Level 2 {16}
--Tree 7991: level 1 (10)
Tree 11962: Level 1 (10}
Tree 4924: Level 2(12}
Tree 12606: Level 1 (14)
Trr? 6467: i 7 041....
.l\& ..
Wap Window
Oj i I'it Si 4! si 6 !>1 1 a
nJ T:T;t T T
t 4. : IT TjTT T T:
2 IT IT :T T T
i 1 | 1T T
! 4 : [ i j
Is : : i i
:T j f Hi j [ [
r: : i j j i M
L Ti IT. 1 | 1 ! i
9 T T Ti S 1 :
U T T T 7 MM
13 T T T T ; II;:
U T T T ; [ ^ j | *N a
Wap Objects
|. Quid

Tree 5282: Grow move added to choes...
Tree 5282: Grotvng...
Tree 5282: tow level 3 ...
Simulation s now Paused.
Single step mode enabled.
Actv 4 moved to (0,1).
Srtj^e step mode enaoied.
Single step mode enabled.
Srtgie step mode enaoied.
QtXkAOC Actor
QudtAod Auction {yuee
Add Resource...
Add Agent..,
1 ftxfcfy Agent.
0 Show at map oogects
, Sfmifcaton Settrgs
0Eraabe tree reprodurton
0Enaaetree growth
0Er>ae*eactot AGS
3 EnaWe actor tree plLrde1ng
EnaSte earnout trade system
3 Wrfte evert log to file
Day: 2000
Figure 5.35: Las Esquinas final configuration, 2000 days

Notice this simulation is one where the economic trade system was disabled.
Actor 4 is at location (0,1) in the upper-left hand comer. Two forests are
growing from the comers on the map. It would appear that this particular
simulation is a steady-state solution for the Actor. In general, however, none
of the Las Esquinas simulation configurations investigated in this research
is reliably steady-state. Figure 5.36 shows the total number of auctions
started and sold and the duration of each of the four simulations.
Duration Started Sold
809 9 6
481 5 4
760 5 2
734 4 1
Figure 5.36: Las Esquinas auction results
The only allowed auction item for this demonstration is Fruit Preserves. The
auction house is configured are using the same configuration discussed in
Section 5.3.2. The durations of the simulations ranged from 481 days to
809 days. Hence, they are all zero-state solutions. Consider Figure 5.37
and Figure 5.38, which depict the total energy states of the Actors for each of
the simulations.
Figure 5.37: Total Actor energy, economic trade system disabled

Figure 5.38: Total Actor energy, economic trade system enabled
Notice that both figures depict a general downward trend for the first 500
days. However, at this point, the simulations with the economic trade
system disabled recover and appear to become steady-state solutions. When
the economic trade system is enabled, however, no recovery occurs. The
simulations all end by the 809th day.
Las Esquinas uses a larger map, thus increasing the risk of starvation
among Actors for both simulation types. Yet these results are the result of
an improperly conditioned simulation. These two simulation types can not
be fairly compared because Actors in the economic trade system are required
to set a goal location at the AH and their counterparts have no such
requirement. By setting a goal at the AH, there is a distinct disadvantage in
being able to reach food supplies before starvation occurs. Future work
could benefit from pre-stocking the AH before starting the simulation.
Another alternative is to run the simulation until Actors stock the AH, but
set their CFEnergy modes to CFEnergy.MODE_NONE for a period of time,
then set the mode back to CFEnergy. MODE_DECAY when the actual
simulation is to begin.
Although no steady-state solution was found for the economic trade system
for Las Esquinas, there is no evidence of a bug or AI logic flaw. Therefore, an
interpretation is possible. The average NLV revenues were higher for these
simulations with the economic trade system enabled. Not surprisingly, the
average Actor wealth was consistently lower for the same class of
simulations. Actual charts are not shown for brevity.

When the Actors lives are complicated with more tasks and goals, the range
of values for which stable equilibrium exist is reduced and it becomes more
difficult to find a steady-state solution. Given the same AI, the Actors in the
economic trade system failed to survive, whereas in the more basic situation,
they did survive. Thus, it can be concluded that Actors require greater levels
of intelligence to survive.

6. Analysis
An analysis of the architecture, implementation, design choices, and the
applicability of the software is presented in Section 6.1. Section 6.2 briefly
analyzes the choice of development environment. Section 6.3 analyzes the
Trees and Fruit model itself, while Section 6.4 analyzes the CommunitySim
6.1 CommunitySim Application
The most beneficial aspect of CommunitySim is the marriage of complex
systems with economic analysis. This allows geographical considerations
such as the distribution of resources, transportation costs, agent commutes,
and some geological constraints to be effectively modeled in an nxm map.
Further, AI can be readily applied to the complex system design and thus the
economic models. Experimentation with heuristics, initial conditions, and
constraints can provide insights into agent behavior and community
economics. At the application level, the world is represented as an object,
which allows for future work by enabling simultaneous simulations for the
purpose of comparison. It also provides the ability of world objects to
interact, which would allow for an entirely new dimension of future work and
thus be another level of hierarchy not considered thus far.
Another benefit of CommunitySim is that it emphasizes local communities.
This allows the varying levels of communities to be defined as the system
boundaries, thereby providing tools for analysis of bioregions and cities, or
even smaller entities such as businesses, neighborhoods, families and
individuals. Interactions with the external environment can easily be
simulated and tracked.
One limitation of CommunitySim surrounds the use of a 2-D complex
system using squares as the cell. The distance for an agent to move from
one cell to the next is different for the horizontal and vertical movements of
south, east, north, and west, than it is for the diagonal movements of south-
west, south-east, north-east, and north-west. CommunitySim defines this
distance to be one unit between each of these eight movements.
Mathematically, the horizontal and vertical movements have a distance of
one. However, the diagonal distances are the square root of two, which is
greater than one. Thus, CommunitySim does not accurately reflect distance
in movement.

CommunitySim also lacks built-in support for land ownership, for resource
exclusion, and does not allow for blocked cell locations, which would be
necessary to correctly model geographical constraints. There is no support
for multiple map objects to be in a single cell at the same time. Lastly, there
is no support for item objects to appear directly on the map, however this is
easily accomplished with a resource or agent that acts as a container. Most
of the limitations described above can be mitigated through future work.
6.2 Development Environment
As mentioned in Section 4.2, the development environment is Python 2.4
running on Windows 2000/ME/XP, WingIDE, and the wxPython GUI toolkit.
When Internet connectivity is non-existent, PSPad replaces WingIDE.
WingIDE was an excellent choice. The auto-complete, debugger and the
source browser were the most effective tools. There is a difference between
the personal and the professional versions, and it is preferable to have the
professional version as key features are not provided in the personal version.
Nonetheless, PSPad is a very workable free alternative. WingIDE has a built-
in Python shell, which is excellent for testing code snippets without having to
rework or comment sections of code. However, Python itself inherently
provides this functionality. WingIDE simply provides this capability within
the IDE environment itself.
wxPython is very useful but also has several issues. It is apparent that the
wxPython project implements a very thin fag ad e design pattern over
wxWidgets for C++. There is no completed comprehensive documentation for
wxPython specifically, so one must resort to interpreting wxWidgets C++
class reference documentation. Fortunately, the constants and functions are
seamless. The second problem with wxPython is the lack of a form editor,
which necessitates hand-computing coordinates and sizes, or relying on
auto-scaling features, which are difficult to grasp at first. This also
necessitates recompiling and running the application every time one wishes
to visualize changes. Lastly, the widgets are implemented by various
developers, and although some widgets have excellent documentation, others
have little or none.
The wxPython DEMO is the most effective tool for shopping for GUI
elements. It provides a way of browsing various dialogs, windows, and
widgets. Each demo has three tabs associated with it, the overview, a code
listing, and the demo itself. The DEMO offers an in-line execution window,
which allows for specific demos to run as children in the parent window.
wxPython is cross-platform and open source, which makes it exceedingly

Although there was a steep initial learning curve, application of this suite of
tools has been an integral part of this research. It operates seamlessly with
the development methodology discussed previously. Lastly, the use of
Python and wxWidgets without the use of other external libraries allows for
maximum portability and a minimum of setup time. This has been
particularly helpful when working on a variety of computers in multiple
cities, offices, houses, coffee houses, and institutions.
6.3 Trees and Fruit
Trees and Fruit is a relatively simple, yet non-trivial RAP model. It was
designed and implemented in tandem with the CommunitySim application.
There are three agent types, the Actor, the NLV, and the Auction House.
Each of these are map objects. The Tree is the primary resource type and is
a map object. Fruit and Wood are item object resource types. Fruit
Preserves, Saws, and Crates are products and are also item-objects. One of
the most beneficial aspects of the Trees and Fruit model is that it is concrete
and easily understood. It is flexible as the rules for interactions are not well-
defined in the model itself, and thus a significant amount of experimentation
is possible. One significant limitation of the model is that Actors can only
hold two items, and this makes it difficult for them to develop products
without endangering their livelihood. The design of the Fruit Preserves
reduced the impact of this limitation. Another limitation is that the money
supply never increases or increases only by the sale of items to the NLV. In
the former case, if any Actors use the NLV, the money supply will eventually
be exhausted. Thus, the Trees and Fruit model does not provide a complete
basis for an economy. A small change allowed Actors to earn incomes.
Employing a subset of a RAP model, such as was demonstrated with the
Trees and Fruit model, can provide interesting results by eliminating either
the resources or the products. Thus, a resource/agent model or an
agent/product model is possible. The Diamond demo is an example of a
resource/agent model. The assumption that the population of Actors never
increases helps to reduce the number of variables that are considered in
analyzing economics. Next, consider the novel aspects of Trees and Fruit.
Firstly, Dollars are objects. Instead of treating money as a scalar, Dollars
are implemented as objects and their movement between agents can be
tracked and reported in excruciating detail, down to the movement of a
specific dollar through the economy. This allows for local multiplier studies
and analysis of wealth distribution, among other analyses.
The introduction of the Auction House for trade allows for agents to interact
in a unique market economy and allows for prices to fluctuate as market and
system-wide conditions change, which would be a composite of agent
behaviors, availability of resources and products, the size and distribution of

the money supply. The NLV allows for money and resource flows to be
monitored through the economy as well as analyzing how agent behavior
affects the agent itself, the money supply and economy, the environment,
and the other agents.
Trees and Fruit provides insight into the CommunitySim application. One
such insight is that the system can easily support the use and analysis of
alternative or complementary currencies using capabilities such as the fact
that Dollars are objects, that Actors have Wallets, that external monetary
flows are processed through the NLV, and the use of the AH. Money can be
created or destroyed within the system and via external monetary flows.
Resources and products can also be created or destroyed in any manner. All
of these can be easily monitored.
6.4 CommunitySim Extensible Core Framework
The CommunitySim ECF provides a toolkit of object types and functions that
are generic as well as a basic agent, resource, and product types, each of
which and can be applied to any RAP model and extended as needed. The
simulation environment provides a framework for extending existing models
and creating new models at varying levels of customization. The
CommunitySim ECF provides a library of useful objects which can be
employed or adapted in a multitude of ways. Via the use of inheritance, this
functionality can be overridden or extended, depending on requirements. At
the subsystem level, the interconnections between the three components
CommunitySim ECF, the CommunitySim UI, and the World with the Trees
and Fruit case study are minimized as much as possible. This modularity
allows for any subsystem to be replaced with a different implementation.
Employing a complex system provides the ability to apply AI techniques to
specific agents and potentially to the whole system. Object design enables
the inherent hierarchical nature of the world to be modeled. Geographical
information can be integrated into the complex system representation of the
system thereby increasing the accuracy of the model for a given case study.
Modeling agents as separate autonomous agents that make their own
decisions is a departure from LG and in-line with artificial life and intelligent
agents. It allows systems to emphasize unique behavioral characteristics for
each agent. Characteristics, for example, could be values and altruism
versus self-interest.
Energy is the basis for system dynamics. In the Trees and Fruit model for
example, Trees are the only objects capable of regenerating and thus provide
an energy input to the system. This is analogous to solar flux, which can be
easily monitored. Values can be modified as necessary to adapt the system

7. Future Work
There are three general areas in which further development of this research
could occur: additional work on the Trees and Fruit model, further
development of CommunitySim, and general research. Possibilities for
future work in each of these areas are discussed in turn.
Two aspects of the Trees and Fruit model were not implemented, which
could be added: the Saw and the Crate. In Chapter 6, the limitation of the
model supporting only two items would be partially mitigated with the Crate.
Allowing Wood to stack would eliminate other structural problems with the
model. Stacking means that more than one piece of Wood could occupy the
same item slot. An analysis of whether or not it would be beneficial to allow
other item types to stack would also be an interesting exercise.
Improved heuristics and planning could be implemented for the Actor and
the consequences and tradeoffs could be explored. Alternative approaches,
such as neural networks or genetic algorithms, could also be investigated.
Lastly, allowing Actors to sell items at the NLV could be implemented.
For CommunitySim, there are several major and minor improvements and
further developments that have been considered. For example, item slots for
agents could be moved from the model level, where they are now, into the
ECF. The world size could be made configurable from the GUI, rather than
requiring a recompile to make the change. In that vein, the demos could be
re-implemented to be mathematically defined, and therefore could be run on
any size world map.
Several key improvements at the subsystem level are possible. Foremost is
implementing a message passing system which would allow the user
interface, the ECF, and the model code to be completely encapsulated. One
possibility for the implementation would be to employ more of the PyTimer
event handling functionality. In order to support the message passing
environment, special objects called interface objects could be implemented to
support communication of information between subsystems. Lastly,
functionality from the Trees and Fruit model can be abstracted into the ECF
inheritance hierarchy, thereby expanding the ECF for future use and
simplifying the Trees and Fruit implementation.
At the functional level, improvements could be made to error handling by
including Python exception handling capability, log files, and error object
passing. Program robustness could be improved by performing validations
on user input in particular, but also by protecting from other errors

throughout the application. File input and output could be added to support
persistence of simulations, simulation settings, maps, and potentially entire
models. Caution is indicated, however, as the reason for the author
implementing CommunitySim and avoiding existing environments was
largely due to the lack of programmability. Hence, the programmable and
extensible aspect of CommunitySim should not be eliminated in favor of
placing models and agent behaviors in data files.
A serious look at efficiency and scalability to larger models has not been
evaluated thus far and would be a wise future step. In terms of efficiency,
improvements could be made to the generation of planning maps. The
planning maps are generated on the fly each time step for each Actor in the
Trees and Fruit model, which places a significant constraint on scalability.
This alone could result in a worst-case time complexity of roughly Ofn3). For
the UI, faster or large-scale simulations are currently not possible due to the
complete reconstruction of the object inspector each time step. Hence,
improvements to the UI are indicated.
On the subject of the UI, a graphical map would allow for improvements to
efficiency and provide an improved look and feel of the program. Larger
maps could provide two views, one showing detail, and one showing the
entire world map. Further, implementing pair-wise comparative runs would
allow users to vividly demonstrate the difference between two sets of
heuristics or configurations on the same map, where time progresses in
lockstep. These simulations could provide the opportunity to show, for
example, the contrast between an economy being sustainable or suppressing
excessive disparities in wealth distribution and an economy collapsing or
widening a class gap. These simulations could then be captured and
exported as video/animation footage. Lastly, more of the preferences and
constants could be made configurable in the UI, rather than by hard-coded
class variables.
Management of information could also be improved. An Energy Manager
could maintain the energy supply and monitor the input/output flows of
energy through all means. These global statistics could be reported and
used both dynamically by the user and in a log file for further analysis.
Similarly, a Statistics Manager/ Statistician could maintain information
about tree reproduction, trades, actor deaths, and monetary information,
including local multiplier data.
In terms of the research, the development of a different model could help
improve the flexibility of the ECF and provide additional insights. The use
and integration of other AI research such as neural networks, learning
systems, and knowledge management into the ECF could simplify the
development of future models, as well as expand the decision making
capabilities of the various agents.
Further research of the LME and applications thereof with CommunitySim
would also be beneficial. Lastly, starting a medium to long-term project with

a NPO, neighborhood organization, SME, or local government to develop a
model would greatly enhance this research and its applicability to the real
With these considerations in mind, the development of the next model or
further work with Trees and Fruit would need to place a greater emphasis on
the LME as well as wealth distribution. Fortunately, the basis for this is now
in place. For Trees and Fruit, multiple communities could be modeled by
placing resource areas in clusters sufficiently far apart. A simpler and
compelling possibility upon solidification of the remainder of the Trees and
Fruit model would be to compare two simulations of the same map with the
same conditions, except that Actors can share the Saw. This simple form of
community sharing would likely provide interesting results. A stronger
emphasis on the role of resources and the information that agents have
about resources as well as a greater understanding of the impact of agent
consumption choices of different resource types would enhance the
relevance to ecological economics. Similarly, an increased understanding of
the role of community sharing of resources and auto-catalyzing products as
well as understanding the role of local purchasing preferences would
enhance the connection to eco-localism. Combining these two along with the
groundwork already laid through this research would provide the necessary
tools to fully demonstrate sustainability through community sharing. Thus,
in conclusion, the need for the TD approach remains ever present.

8. Conclusion
But it is strange because some Trees are killed, and others are not. Its like
some of them are invincible or something. And its the invincible ones that
hang the application. Author
An exploration of existing artificial life modeling software led the way for the
design, development, and testing of CommunitySim, the new simulation
environment. In the end, much of the initial research project goals have
been accomplished. This chapter discusses the extent to which these have
been fulfilled, as well as any shortcomings. The primary goals of this
research project can be summarized as follows, each of which will be
discussed in turn.
Develop a RAP model and simulate it using a computer simulation
Provide a flexible UI and an ECF.
Provide a platform for rapid development of local economic models.
Test and demonstrate CommunitySim abilities and motivate research
and analysis of the LME.
The goal to develop a RAP model was accomplished with the development of
the Trees and Fruit model, which was discussed at length in Section 4.4.1.
It was largely implemented and simulated in specific examples using the
CommunitySim computer simulation program. These examples were shown
throughout Chapter 5. Surprisingly, almost every aspect of the Trees and
Fruit model was implemented, with the exception of the Saw and the Crate.
One problem that arose was that the Actors could only hold two items.
Thus, the creation of products by Actors was precluded at the outset.
However, as discussed in Section 5.3, this effect was nullified in the case of
Fruit Preserves with the novel introduction of the cooking fire and
statefulness of the Fruit Preserves implementation.
The role of resource types for the Trees and Fruit model was discussed in
Section 4.4, and explored in Section 5.3. However, transformation of
resources between resource types was not considered.
The Trees and Fruit model as well as CommunitySim itself support multiple
autonomous agents in a pseudo-concurrent model. Each agent is allowed a
move for each time step. Several scenarios involving two or more agents
were explored at length. Agents harvested both Fruit and Wood from Trees.
Agents could produce and consume one product, namely the aforementioned
Fruit Preserves. It was important to make a connection with the real world.
Although Trees and Fruit is an abstract model, it lends itself to real world

interpretations due to the selection of concrete recognizable type names and
the apparent complexity of the model which allows for many situations to
emerge that are readily recognizable. For example, the fact that Fruit decays
over time or that Actors carry money in Wallet objects.
The goal of providing a flexible UI was accomplished as a side effect of the
development methodology and choice of GUI toolkit and therefore met with
limited success. The development methodology motivated a step-wise
refinement of the UI starting initially with a simple trace window, which
evolved as needed as more functionality was implemented. In the end, an
attractive and usable UI was provided. Every attempt was made to keep UI
functionality separate from the remainder of the application. In many ways
this was successful, however, in the course of development, complete
encapsulation of the subsystems was prohibitive. String data, Trees and
Fruit specific code, and configuration crept into the UI subsystem code. The
GUI toolkit, wxPython, proved to be a major component to providing a
flexible UI. The wxPython DEMO provides a uniform, one-stop shop for
selecting widgets. One shortcoming is that with only a cursory knowledge of
how events and event handling works with wxPython, it was difficult to
develop a manageable object-oriented UI, and thus much functionality found
itself in UITextPanel (see Appendix).
The goal of an ECF was directly accomplished with the development of the
CommunitySim ECF, which was discussed at length beginning in Chapter 4.
In most cases, the ECF was instrumental in providing standard functions
across multiple object types as well as a suite of standard low-level classes
such as CFLocation, which was used extensively throughout the application.
One excellent example of code reuse occurred with CFMap, which was
developed initially for use by WOMap, but later became a key part in the
development of planning maps for the Actor.
The goal of providing a platform for rapid development of local economic
models was successful insofar as the ECF is concerned. The development of
the RAP model and the Trees and Fruit model form a precedent for further
development. New models can be developed via categorization via the RAP
approach, and implemented using the ECF, which certainly would be faster
than developing new models completely from scratch. However, it is unclear
whether this would constitute rapid development.
The goal of testing and demonstrating the abilities of CommunitySim was
achieved remarkably well, as was shown in detail throughout Chapters 4-7.
Striking results were achieved with the NLV Diamond and the Las Esquinas
demonstrations. The design of select components of the application was
discussed at length, although for the sake of brevity, many aspects were left
to the reader of the code listings in the Appendix. Ergo, testing and
demonstration were given preference. The goal of motivating research and
analysis of the LME was met with only marginal success. Only a cursory
demonstration of the LME was achieved in the Las Esquinas demonstration.
Indeed, as the quote at the beginning of the chapter suggests, the focus of

the research was on the development of a new simulation environment and
at times was mired in the depths of application development and debugging.
The NLV Diamond demonstration provided unexpected and interesting
results. The Las Esquinas demonstration employed the full range of tools
and model capabilities of the entire application and thus provided interesting
results as well.
One of the major motivating factors of the research was determining whether
there is a steady-state solution that is not the zero-state for a given model
and a given set of initial conditions. In the case of several examples, steady-
state solutions were discovered. These solutions were non-trivial to
condition, but the work done thus far shows that they do exist for the
examples explored. In future work, it would be beneficial to employ learning
systems to automatically condition variables to generate equilibrium
Although very interesting, the second focus of wealth distribution was not
explored due to scope reasons. It remains a useful component and can be
explored in conjunction with the LME in future work. One of the most
challenging aspects was determining how to develop a local economy with
the presence of an NLV. A problem is that if the NLV is a sink for money,
and the money supply never grows, then eventually there will be no money
left. Fortunately, the LME analysis can still be considered with this case.
The second part of the question dictates that if no steady-state solution
exists, than it is still useful to explore conditions on configurations that will
maximize the time the system survives. Interestingly, the presence of the
NLV is the only way to analyze the LME, because without it the local
economy becomes a closed monetary system with no sources and no sinks.
Of course, the sky is the limit on the number of variations that could be
explored in this vein alone.
CommunitySim has provided interesting and compelling results and forms
the basis of continued work in this area. It demonstrates that it is possible
to fuse the disciplines discussed throughout in a TD approach that provides
workable results. The groundwork laid by this research focused on
providing a foundation for real-world applications of ecological economics
and eco-localism in particular, local economic modeling.

A. Manifest 841 92 550
World, py 304
Resources, py 195
Agents, py 841 92 1053

# Application Specific Main Entry Point
# CommunitySim Thesis Project
# University of Colorado at Denver and Health Sciences Center
# Department of Computer Science and Engineering
# Author: Derek Hoshiko
# Created: 05 Oct 2005
# Subsystem: User Interface
# Classes -
# UIMainWindow(wxFrame)
# UlCommunitySim(wxApp)
from wxPython.wx import *
from Foundation import CFTimer, CFEnergy
from Userlnterface import UIMenuBar, UIStatusBar, UITextPanel, UILog, \
UlSplitter, UlObjectlnspector
from World import WOWorld
class UIMainWindow(wxFrame):
def _init___(self, parent, ID, title, pos, size):
wxFrame.__init__(self, parent, ID, title, pos, size)
self.splitter = UlSplitter(self, -1)
self.textPanel = UITextPanel(self.splitter)
self.objectlnspector = UlObjectlnspector(self.splitter)
self.splitter.SplitVertically(self.objectlnspector, self.textPanel,
# Menu Bar
self.menuBar = UIMenuBar(self)
# Status Bar
self.statusBar = UIStatusBar(self)
class UlCommunitySim(wxApp):
POS = (50,50)
SIZ = (925,600)
TITLE = "CommunitySim"
def Onlnit(self):
# Initialize World = WOWorld(10, 4)
# Initialize UI
self.frame = UIMainWindow(NULL, -1, self.TITLE, self.POS, self.SIZ)

return true
# Create instance and start the event loop

# Extensible Core Framework
# A collection of classes used by the extensible framework, including
# ResourceFramework, ProductFramework, and AgentFramework.
# CommunitySim Thesis Project
# University of Colorado at Denver and Health Sciences Center
# Department of Computer Science and Engineering
# Author: Derek Hoshiko
# Created: 05 Oct 2005
# Subsystem: Core Framework
# Classes -
# CFObject
# CFItemObject(CFObject)
# CFMapObject(CFObject)
# CFResource(CFMapObject)
# CFAgent(CFMapObject)
# CFProduct(CFItemObject)
from Foundation import CFLocation, CFTimer, CFEnergy
class CFObject:
def __init___(self, objectID):
self._objectID = objectID
self._dayCreated = CFTimer.Value()
self._dayLastUpdated = CFTimer.Value()
def ID(self) :
return self._objectID
class CFItemObject(CFObject):
def __init___(self, objectID, parent):
CFObject.__init__(self, objectID)
self._parent = parent
def Parent(self):
return self._parent
def SetNewParent(self, newParent):
self._parent = newParent
return newParent
class CFMapObject(CFObject):
def __init___(self, objectID, loc=CFLocation(), isMoveable=True, \
CFObject.__init__(self, objectID)
self._location = loc
self._isMoveable = isMoveable
self._isSelfMoving = isSelfMoving
def Location(self, loc=None):
if loc is not None:

self._location = loc
return self._location
def GetLevel(self) :
return None
def ShowEnergy(self):
return self.DEFAULT_ENERGY
def _DoNothing (self) :
return True
def AIMove(self):
return True
class CFResource(CFMapObject):
def __init__(self, objectID, newTypeName, loc=CFLocation()):
CFMapObject. init (self, objectID, loc)
self.typeName = newTypeName
class CFAgent(CFMapObject):
def __init__(self, objectID, newTypeName, loc, initEnergy, maxEnergy,
energyRate, energyMode):
CFMapObject. init (self, objectID, loc)
self.typeName = newTypeName
self._energy CFEnergy(initEnergy, maxEnergy, energyRate, energyMode)
def ShowEnergy(self):
return self._energy.Update()
def GetNumltems(self):
return 0
class CFProduct(CFItemObject):
def __init__(self, objectID, newTypeName, parent):
CFItemObject.__init__(self, objectID, parent)
self.typeName = newTypeName

# Extensible Foundation Classes
# A collection of generic classes used by more than one subsystem, which are
# part of the generalized, extensible core of the application. That is, no
# application specific classes are defined here.
# CommunitySim Thesis Project
# University of Colorado at Denver and Health Sciences Center
# Department of Computer Science and Engineering
# Author: Derek Hoshiko
# Created: 05 Oct 2005
# Subsystem: Core Framework
# Classes -
# CFIDGenerator
# CFTimer
# CFRandom
# CFLocation
# CFMap
# CFEnergy
# CFDollar
# Credits -
# CFTimer singleton design is based on "A simpler singleton," by Matt Kangas
# on 24 Jun 2001 who contributed to the forum "The Singleton Pattern
# implemented with Python" on the ActiveState Programmer Network
# originally submitted by Jurgen Hermann. Last accessed 11 Oct 2005.
import time
import wx
import random
class _CFIDGenerator:

def call (self):
return self
def init (self):
self._ID = 0;
self._serialNumber = 0;
def ResetIDGenerator(self) :
def NewID(self):
self,_ID += 1
return self._ID
def NewSerialNumber(self):
self._serialNumber += 1
return self._serialNumber
CFIDGenerator = _CFIDGenerator()
del _CFIDGenerator
class _CFTimer:
def __call__(self):
return self
def Value(self):
return self._value
def IsRunning(self):
return self._state is CF_TIMER_RUNNING
def IsPaused(self):
return self._state is CF_TIMER_PAUSED
def IsStopped(self):
return self._state is CF_TIMER_STOPPED
def IsStepping(self):
return (self._state is CF_TIMER_PAUSED) and (self._singleStep)
def SetSingleStep (self):
self,_singleStep = True
if self._state is not CF_TIMER_PAUSED:
self._state = CF_TIMER_PAUSED
def Statusstring(self):
if self._state is CF_TIMER_STOPPED:
elif self-_state is CF_TIMER_PAUSED:
elif self._state is CF_TIMER_RUNNING:
def Start(self, mutate=True):
if mutate is True:
self._state = CF_TIMER_RUNNING
def Pause(self) :

if self,_state is CF_TIMER_PAUSED:
self._state = CF_TIMER_RUNNING
self._state = CF_TIMER_PAUSED
self._StateChange ()
def Stop(self, mutate=False):
if mutate:
self._state = CF_TIMER_STOPPED
def Initialize(self,evtHandler=None, stateHandler=None):
self._eventHandler = evtHandler
self._stateHandler = stateHandler
self._timer = wx.PyTimer(self._TimerEvent)
self._state = CF_TIMER_STOPPED
self._rate = CF_TIMER_DELAY_MS
self._quitFlag = False
self,_singleStep = False
def LinkWorld(self, evtHandler):
self._worldLink = evtHandler
def World(self):
return self._worldLink
def Faster(self):
self,_rate = CF_TIMER_DELAY_MAX
self._rate -= CF_TIMER_DELAY_DELTA
if self._state is not CF_TIMER_STOPPED:
def Slower(self):
self._rate = CF_TIMER_DELAY_MIN
self._rate += CF_TIMER_DELAY_DELTA
if self._state is not CF_TIMER_STOPPED:
def Normal(self):
self._rate = CF_TIMER_DELAY_MS
if self._state is not CF_TIMER_STOPPED:
def Quit(self, trigger=False):
if trigger is True:
raise SystemExit
return self._quitFlag
def _TimerEvent(self):
self ,_worIdLink.CheckSelectedCell()
doRun = self._state is CF_TIMER_RUNNING
doStep = self._state is CF_TIMER_PAUSED and self,_singleStep

# Update timer
if doRun or doStep:
self._value += 1
# Run world
if self._eventHandler is not None:
if doRun:
if doStep:
self._singleStep = False
def _StateChange(self):
if self._stateHandler is not None:
CFTimer = _CFTimer()
del _CFTimer
class _CFRandom:
def __call__(self):
return self
def Select (self, seq):
return random.choice(seq)
def Acquire(self, seq):
selection = self.Select(seq)
return selection
def Shuffle(self, seg):
def Roll(self, stop=100):
return random.randrange(1,stop)
CFRandom = _CFRandom()
del _CFRandom
class CFLocation:
DIR_SW = 1
DIR_S = 2
DIR_SE = 3
DIR_W = 4
DIR_E = 6
DIR_NW = 7
DIR_N = 8
DIR_NE = 9
def __init__(self, xLoc=CF_LOCATION_DEF_X, yLoc=CF_LOCATION_DEF_Y) :
self._location = [xLoc, yLoc]
def X(self, xLoc=-l):
if xLoc is not -1:
self._location[0] = xLoc
return self,_location[0]
def Y(self, yLoc=-l):
if yLoc is not -1:

self,_location[1] = yLoc
return self._location[1]
def Loc(self):
return self._location
def Test(self, xBound, yBound):
return (self.XO in range (0, xBound) ) and (self.YO in range (0, yBound) )
def OfHere(self, direction, xBound, yBound):
initX = -1
initY = -1
if direction is self.DIR_SW:
initX = self.XO 1
initY = self.YO + 1
elif direction is self.DIR_S:
initX self.XO
initY = self.YO + 1
elif direction is self.DIR_SE:
initX = self.XO + 1
initY = self.YO + 1
elif direction is self.DIR_W:
initX = self.XO 1
initY = self.YO
elif direction is self.DIR_E:
initX = self.XO + 1
initY = self.Y()
elif direction is self.DIR_NW:
initX = self.XO 1
initY = self.YO 1
elif direction is self.DIR_N:
initX = self.XO
initY = self.Y() 1
elif direction is self.DIR_NE:
initX = self.XO + 1
initY = self.YO 1
return None
targetLocation = CFLocation(initX, initY)
if targetLocation.Test(xBound, yBound):
return targetLocation
return None
def Distance(self, loc):
translateX = abs(loc.X() self.XO)
translateY = abs(loc.Y() self.YO)
if translateX >= translateY:
return translateX
return translateY
def Showstring(self):
return "(%d,%d)" % (self.XO, self.YO)
def IsOn(self, loc):
if loc is not None:
if self.XO is loc.X():
if self.YO is loc.YO:
return True
return False
def Isln(self, list):
for item in list:
if self.XO is item.XO:

if self.YO is item.YO:
return True
return False
def _ShowStringLocationList(list):
display = "[ "
for item in list:
display += item.ShowString() + "
display += "]"
return display
ShowStringLocationList = staticmethod(_ShowStringLocationList)
class CFMap:
def __init__(self, xSiz=CF_MAP_DEF_X_SIZ, ySiz=CF_MAP_DEF_Y_SIZ,
defFactoryValue=0, allowDuplicates=False):
self.x_siz xSiz
self.y_siz = ySiz
self._map = []
self._objects = {)
self._allowDuplicates = allowDuplicates
self._defFactoryValue = defFactoryValue
for i in range (0,xSiz):
for j in range (0,ySiz):
def FindBylD(self, objectID):
if self.TestBylD(objectID):
return self._objects[objectID]
return None
def TestBylD(self, objectID):
if self._objects.has_key(objectID):
return True
return False
def FindByLocation(self, loc):
if self.TestByLocation(loc):
return self,_map[loc.X()][loc.Y()]
return None
def TestByLocation(self, loc):
if self._map[loc.X()][loc.Y()] is not self,_defFactoryValue:
return True
return False
def AddObject(self, objectID, pos):
duplicateTest = not self.TestBylD(objectID)
if self._allowDuplicates:
duplicateTest = True
if (duplicateTest) and (not self.TestByLocation(pos)) and \
self._objects[objectID] = pos
self-_map [pos .X ()] [pos Y () ] = objectID
return True
return False
def RemoveObject(self, objectID):
if self.TestBylD(objectID):
pos = self,_objects[objectID]

self._map[pos.X()][pos.Y()] = self._defFactoryValue
return pos
return None
def MoveObject(self, objectID, newPos):
pos = self.RemoveObject(objectID)
if pos is not None:
return self.AddObject(objectID, newPos)
return False
def GetNullLocationList(self):
nullList = []
for i in range (0,self.x_siz):
for j in range (0, self.y_siz):
if self._map[i][j] is None:
return nullList
def _MatrixSum(mapA, mapB):
x = mapA.x_s i z
y = mapA.y_s i z
if x is mapB.x_siz and y is mapB.y_siz:
matrixSum = CFMap(x, y, allowDuplicates=mapA._allowDuplicates)
for i in range(0, x):
for j in range (0,y):
a = mapA._map[i] [j ]
b = mapB._map[i][j]
if a is None or b is None:
matrixSum._map[i][j] = None
matrixSum._map[i][j] = a + b
return matrixSum
return None
MatrixSum = staticmethod(_MatrixSum)
def Showstring(self):
display = "[\n"
for j in range (0, self.y_siz):
display += [ "
for i in range (0, self.x_siz):
if self._map[i][j] is None:
display += "X "
display += "%d % self,_map[i][j]
display += "]\n"
display += "]"
return display
class CFEnergy:
def __init__(self, initEnergy, maxEnergy, rate, mode, isMutable=True)
if initEnergy > maxEnergy:
self._energy = maxEnergy
self._energy = initEnergy
self._maxEnergy = maxEnergy
self._rate = rate
self,_isMutable = isMutable
self._mode = mode