multi-agent simulations of social phenomena

West University Timisoara

Faculty of Mathematics and Informatics

Computer Science – English Language

GRADUATION PAPER MULTI-AGENT SIMULATIONS OF SOCIAL PHENOMENA

Scientific Coordinator Student

Gabriel Istrate Victor-Emanuel Blaga

Timisoara

2008

West UniversityMulti-Agent Simulations of Social Phenomena

2

Table of Contents

1. INTRODUCTION ............................................................................................................................ 4

2. A USER’S PERSPECTIVE .............................................................................................................. 7

2.1 The Need for Artificial Societies .......................................................................................................... 7 2.1.1 An Uphill Puzzle .................................................................................................................................... 7 2.1.2 Doing Away with the Haystack ............................................................................................................. 8 2.1.3 The Agent-Based Model ....................................................................................................................... 9

2.2 On the Practical Side ......................................................................................................................... 11 2.2.1 The Big Picture outside the Box .......................................................................................................... 12 2.2.2 The “Why” ........................................................................................................................................... 13 2.2.3 The “How” ........................................................................................................................................... 14 2.2.4 Falling in Line ...................................................................................................................................... 15

3. THE SUGARSCAPE ..................................................................................................................... 16

3.1 Components ...................................................................................................................................... 16 3.1.1 The Environment ................................................................................................................................ 16 3.1.2 The Agents .......................................................................................................................................... 18 3.1.3 The Clock ............................................................................................................................................. 20

3.2 Adding Slices to the Pie ..................................................................................................................... 21 3.2.1 Sex ....................................................................................................................................................... 21 3.2.2 Disease ................................................................................................................................................ 22 3.2.3 Trade ................................................................................................................................................... 23 3.2.4 Credit .................................................................................................................................................. 24 3.2.5 Culture ................................................................................................................................................ 25 3.2.6 Combat ............................................................................................................................................... 26 3.2.7 The Pie ................................................................................................................................................ 27

3.3 Off the Beaten Path ........................................................................................................................... 28 3.3.1 Custom Scenery .................................................................................................................................. 28 3.3.2 Change of Conduct .............................................................................................................................. 29

4. DESIGN AND IMPLEMENTATION ......................................................................................... 30

4.1 Design Process .................................................................................................................................. 30 4.1.1 Factory Design Pattern ....................................................................................................................... 30 4.1.2 Observer ............................................................................................................................................. 31

3 Blaga Victor-Emanuel

4.2 The Foundation ................................................................................................................................. 32 4.2.1 Front-End: Java and Swing .................................................................................................................. 33 4.2.2 Scripting Support: Lua 5.1 ................................................................................................................... 34 4.2.3 Input Data: Java Advanced Imaging API .............................................................................................. 35

4.3 Upwards and Onwards ...................................................................................................................... 37 4.3.1 Living off the Land ............................................................................................................................... 38 4.3.2 Part of a Community ........................................................................................................................... 39 4.3.3 I Spy ..................................................................................................................................................... 41 4.3.4 Full Circle ............................................................................................................................................. 42

5. CONCLUSIONS ............................................................................................................................. 43

5.1 Lessons Learned ................................................................................................................................ 43 5.1.1 What Went Right ................................................................................................................................ 43 5.1.2 What Went Wrong .............................................................................................................................. 45

5.2 Like, Finally ....................................................................................................................................... 46

6. BIBLIOGRAPHY .......................................................................................................................... 47


4

1 Introduction

Society works, at times, in mysterious ways – trying to understand it, man has developed a

number of sciences studying its various facets, in what is a more manageable, “divide and

conquer” approach. Nevertheless, studying and developing the methods of human

interaction through the lens of just one particular field of activity will inherently ignore

most, or at times, all factors described by the other social sciences, factors which may have

a noticeable impact on the field of study.

Moreover, decision makers in all lines of work must take into account many seemingly

unconnected aspects of a problem in order to figure out the dynamic of a situation, and plan

accordingly. At this point, one has to turn to interdisciplinary study to attain his goals in an

efficient manner, and social simulation proves to be an indispensable aid to this process.

Sugarscape1 is, in itself, one such social simulation model. Developed by Joshua M. Epstein

and Robert Axtell, it builds a bottom-up social model that is easy to comprehend and

modify. The basis of this model is the concept of individuals (called agents) who live in a

certain environment, and interact with one another and with the land according to a

defined set of rules. Recording the results of these complex interactions as statistical and

map data, we have a reasonable basis to predict the outcomes of a “what-if” scenario.

Dealing with a bottom-up model, the user holds control over the heterogeneity of the agent

population, in terms of traits, and, most importantly, of behavioural rules. This freedom

brings Sugarscape one huge leap forward towards the real world, as opposed to other

aggregate models in use, which tend to oversimplify the matters at hand, by assuming that

each individual acts the same way, or even by completely ignoring the passing of time.

Capitalizing on the need of powerful mechanics and ease of use, this project implements the

Sugarscape model in such a way as to be both intuitive, modifiable, and to require only basic

programming knowledge, akin to the skills a sixteen-year-old gamer learns, in order to

1 Epstein, J. M., & Axtell, R. (1996). Growing Artificial Societies. Cambridge: MIT Press.


modify his favourite game. To this end, this project makes use of interpreted simple,

pictographic maps (in other words, images) to define the environment, and of the LUA

scripting system, widely used in computer games, to define the behaviour of the agents, and

even the flow of the simulation.

The whole point of this project is to allow the researcher to build and analyze observable

patterns in social structures, whether those are the inter-human relationships in an office

building, or the annual migration of the Gnu wildebeests in Africa.

This paper will try to expand on these topics, at first by presenting a user’s perspective of

the issue, and making a point in detail as of why exactly there is a need for a comprehensive

interdisciplinary method of social pattern prediction. We will speak at length about the

current uses of such modelling, as well as the various pitfalls in which separate discipline-

centric analysis of social phenomena tends to fall in.

Moving on to presenting the software’s capabilities from a user’s point of view, as opposed

to a developer’s, we go on to enumerate its various use instances in a range of fields of

work.

Furthermore, we will try to define the artificial world we are building with this software, at

first by determining its structural components: the environment, the agents, and the rules,

each with its own distinctive framework. Secondly, we have to look upon a basic set of rule-

independent interactions that take place between the agents and the environment, in order

to set the stage for more advanced behavioural patterns.

Building on this basis, we will then try to expand the scope of our artificial world, by adding

rules and traits to both agents and environment, in such a way as to develop recognizable

social phenomena among the agent population, akin to what drives society in the real

world. In addition to the standard Sugarscape model, an analysis of the additions and

modifications to its paradigm shall emerge, following the consequences that introducing

real-world landscapes and modifiable agent behaviour have on its reliability and versatility.

Practice follows theory – therefore, with the next section we shall go on to explore the

actual design process and implementation of the software package. Starting with a

systematic walkthrough of the roads taken and not taken during the development process,


6

we continue by going over the technologies embedded in the project and their features, as

pertaining to the advancement of our goals. Finally, we describe in detail the way we built

the Sugarscape, in terms of classes for agents, the environment, the overall society and its

various sub-groupings.

In order to prove our point, we will also provide a series of run scenarios and other

examples, to give a feeling for what output data the user can expect to receive, from a given

model that goes beyond testing, and attempts to mimic a real situation.

To wrap it all up, the project, along with this paper attempt to expand and explain what we

believe to be crucial issues with Sugarscape implementations, namely ease of use and

versatility, while employing off-the-shelf technologies and standardized formats to bring the

application into the mainstream category of software projects.

7 Blaga Victor-Emanuel 2 A User’s Perspective

2.1 The Need for Artificial Societies

As our world grows increasingly complex, businesses, sociologists, armies, policy makers,

and a host of other categories of people find themselves confronted with ever more

complex systems to analyze reliably, and most importantly, with accurate results.

The previous generations of equation-based mathematical modelling tools generally fail at

producing dependable results from their analysis of intricate phenomena due to their

consistent approach of over-simplification and data abstraction. As they say, more often

than not, the devil is in the details – therefore, models of idealized systems tend to break

down in practice and lead to erroneous decisions at higher levels.

Because agent-based modelling does not require the scientist to implement the functioning

system as a whole, does not rely on over-simplification, and literally “grows” out of the sum

of its parts, it manages to capture a realistic picture of the structure it represents, and can

add or remove components more-or-less on the fly.

2.1.1 An Uphill Puzzle

Structurally, most organizations have gradually become more elaborate, mostly because of

the multifaceted environment of their operations. Coupled with diminishing business

resources, the situation can turn into quite a predicament for managers and decision or

policy makers. These people have to continually battle to keep their organizations afloat and

predict emerging trends and opportunities in order to attain specific long-term goals in an

often volatile and ever-evolving environment.

The rate of situational change is in many circumstances dictated by technological progress

and the new mechanics evolved thereof. Cheap storage space means beefier databases and


8

more detail from which to draw conclusions through analysis. Globalized travel and

communications have led to outsourced manufacturing, mostly offshore, in sweatshop-

friendly countries. Former such manufacturing heavens progressively get more expensive to

use, so one has to be able to predict when and where it is profitable to move factories.

Consequently, supply chains will also expand and interweave, meaning that it gets harder by

the minute to perform a centralized analysis on their efficiency.

Globalization also implies that unrest in some remote corner of the third world may have

great impact in the countries that matter to people who use computers to analyze things, as

verified by the on-going terrorism and Islamic liberation trends, or by rising oil prices due to

Nigerian tribal attacks on oil pipelines. Planning for counterinsurgency in a foreign country

has to take a great deal of variables into consideration, and has to be people, or agent-

centric, as it aims to win the hearts and minds of an alien culture.

Transportation networks grow progressively more interconnected, markets become ever

more sophisticated and fragmented; companies grow, escalating the number and variety of

interactions within and with the outside world; infrastructures holding our modern lives

together are interdependent: electricity, petroleum, water and telecommunications – all of

this amounts to a world so complex that mathematical simulations just cannot cope with

the information load.

2.1.2 Doing Away with the Haystack

The approach that non-agent based simulations take to modelling systems or phenomena is

to radically idealize their inner workings. People will throw all detail to the bin in order to be

able to feed the simulation a concept small enough for it to handle. Expectedly, results are

either highly skewed, work only in highly improbable circumstances, or are simply out of this

world, leading to flawed decisions and unwanted consequences.

Over-simplification ranges from assuming you can buy only one product off the market, and

choose from an infinite number of vendors, to the presumption that all factions in a theatre

of operations have the same goal and abide by the same rules. While any corporate CEO will


sneer at the first example, lives and homes may be lost due to decisions made on top of a

faulty and generalized analysis adopting the second as a rule.

Moreover, mathematical simulations will only provide results for long-term outcomes that

imply steady progress over extended periods of time, case that rarely applies to the real

world. The simulation will provide no data for the time in-between the present and the far-

away goal, nor will it be able to compensate for, or even consider disturbances along the

way. Bearing in mind the rapid pace at which our world changes, one may even consider the

phrase “long-term” just short of obsolete.

Simplified models have yet another drawback: by replacing details with assumptions of an

idealized situation, they will not signal that any data is missing, again leaving the person

running the simulation at a loss to explain just why prediction analysis differs so wildly from

the facts of reality.

In all, the previous generations of analysis and planning tools have a workflow analogous to

planning for a needle-in-the-haystack search operation, without taking into account that

there actually is a haystack to search. Unfortunately, more misses than hits in analysis and

pattern prediction leads, in non-technical circles, rather to a change of operating procedures

than to a drive to better analysis tools or shift their working paradigms.

2.1.3 The Agent-Based Model

The “new” way of organizational and situational modelling, the agent-based approach

captures the essence of a system’s behaviour through a ground-up approach. The conduct

of the whole develops as the result of the conduct of each of its parts – of each modelled

agent, in other words. This method enables organizations to convert specific individual

functions, which are tangible, so to say, and well documented, into aggregate group

behaviours and their system-wide implications. Furthermore, the level of detail and the

number of cross-agent interactions are only limited by development time and processing

horsepower, as there are no set limits to how complex a behaviour each individual agent

has.


10

An important point to make about the Sugarscape model is that time flows naturally,

similarly to the real world. Therefore, the observer can follow the results from start to finish,

through all the intermediary steps, having a clear analysis of both the road to his goals, and

of the context of attaining them.

The main drive in agent-based simulations is to mimic the real world as closely as possible,

and then adopt a laissez-faire attitude, to see the results. Once a behaviour pattern is set,

and if it differs from the target goal, the user will tinker with each agent’s individual

behaviour, in order to see what down-to-earth, clear-cut modifications are required for the

entire system to function properly.


2.2 On the Practical Side

Before delving into the structure of the Sugarscape, we first need to fill in two blanks,

namely the reasons to engage in simulations at all, and the methods of solving a practical

problem through an artificial model. There are a number of approaches to simulation, all

geared towards different uses and contexts2, Sugarscape extracting concepts and

functionality from most of them.

• The System Dynamics approach structurally models a high-level dynamic process

over time, without taking an in-depth, detailed view of its inner-workings.

• Discrete-event simulations, although modelling similar types of processes tend to

focus heavily on detail, simulating events that forward the process each time unit.

• Participatory simulations use the concept of people in order to replicate dynamic

decision-making processes, as well as social interactions and the way these affect the

system as a whole.

• Optimization is a process that, as the name implies, tries to find an optimum solution

to a mathematically expressed problem.

• Statistical modelling, however, does not address the system at all, but rather only its

output and inputs, correlating the two with no regard whatsoever to internal

structure or causality.

• Risk analysis focuses on the factors that put an entity at risk, reason for which it is

widely used in businesses that want to survive.

These traditional models will take either what can be called a “strategic” perspective, with a

top-down approach, or a more “tactical” view, in order to be applicable at a more

operational level as well. The Sugarscape itself draws from both worlds, allowing itself to

become most of the above and more.

Nevertheless, suspicion leads us to believe there is a reason behind all this, and somebody

may actually have some gain off using these systems.

2 North, M. J., & M, M. C. (2007). Managing Business Complexity. New York: Oxford University Press.


12

2.2.1 The Big Picture outside the Box

Ever since decision makers in business and government decided they should turn into

control freaks, they needed tools and an underlying organizational framework to analyze

and predict the outcomes of goals, activities, tasks, resource and other constraints on their

companies. People generally employ system analysis to the end of bettering an

organization, by spotting bad or sub-par processes, developing enhanced versions of the

said processes, and predicting the outcomes of their subsequent integration.

A good way of approaching system analysis is through the perspective of the information

flow in an organization: who needs what information, where? Do we generate that data in-

house, or through a third party? Does anyone actually use it, and how much does it cost?

Simulation and modelling serve to monitor and answer these questions, in order to optimize

whatever process they replicate, and provide the big suits with a rationale for writing pay

checks.

The people involved with dissecting the inner workings of an already running process will

start by summing up the details, identifying causes for the visible effects, and will then try to

gain a better understanding of the system as a whole. Though doable with only a pen and

paper, in an eco-friendly world, the analyst does not always have direct access to the


process, or needs confirmation that his theory works, point in time when resorting to the

miracles of computing seems to be the best course of action. Creating computer simulations

of business or more generally, organizational processes and systems will imbue the analyst

with the power to explore the nooks and crannies of the model in his own time, and allow

him to create comprehensive conclusions based on patterns or limit situations otherwise

not observable in everyday life.

Moreover, analysts tend to get lost in the details, and burrow themselves so deep in one

corner or other of the process, that they simply miss the big picture. Computer simulations

force them to consider the greater issues, sometimes for no other reason than simply

because their output relates to the organization as a whole. The analyst can therefore

regain perspective by never having to plunge so deep into the investigation itself that it

becomes a purpose, rather than a means to make more money.

Not all people in a company will get bogged down in the details, however, reason for which

there’s always a conflict over how much detail should be included in a simulation, in order

for it to be valid and true to real life, as well as cost effective and timely. The Sugarscape

somewhat settles the issue, by introducing a minimal standard to the level of detail, due to

its bottom-up methodology.

2.2.2 The “Why”

Since most analysis translates to computer simulation, non-luddites have built up a whole

set of rationalizations for trusting these models and taking decisions based on their output:

• People’s brains are too small, so they cannot hope to comprehend and work an

entire system from scratch, the poor weaklings. Therefore, managers will opt to

model a system before they deploy it and risk having to pick up the pieces.

• Computers are more imaginative, or at least they can explore a much greater range

of possibilities through sheer brute force. Even workaholic managers that have a

good grasp of their target process, and who have all the time in the world to cook up

a wide range of possible outcomes, due to them living at work, become dwarfed by


14

the capabilities of a machine, which can spew out potential outcomes that no man

has thought before.

• Humans think on rails, limiting mental models to their experience and restraining

possible extrapolations to the boundaries of what seems normal. We had better left

it to computers to think up cascading chains of improbable events, before they

actually happen.

• Real visionaries among humans are the minority, and oracles are overrated. While

people will generally not have the ability to predict something completely novel, the

complex interactions of a multi-agent model may amount to a scientifically provable

result that no one had expected.

• We value real-world consequences more than in-game ones, hence the Save and

Load functions. A business owner will likely care less if half his virtual employees

starve to death in a computer simulation, than if one valued employee threatens to

leave the boat for real. Experimentation in real life is discouraged, to put it mildly, so

the masses expect decision makers to get their first resolution right.

We regard agent-based models as the best choice due to each of these incentives, with high

chances of new, insightful results, otherwise impossible to attain through traditional

methods.

2.2.3 The “How”

Building a simulation of something can go on one of two paths:

• Modelling the problem – assuming there is a problem, will focus on getting specific

answers to clear-cut issues.

• Modelling the system – will end up in a simulation that reproduces certain

behaviours and sort of lets the user to take on from there.

Most used in business and for immediate practical use is the first modelling technique,

considered most efficient due to its power of concentrating development on specific areas

with the highest probability of return. Avoiding unnecessary features seems to be the trend

among businesses that hire developers for money.


Other areas of research, though, such as academic study, benefit most from the other

approach, since they need a comprehensive, complete model of the system in order to draw

their conclusions.

2.2.4 Falling in Line

All simulations, no matter the area of research, or the model employed face the same two

defining challenges: data collection and model validation. Sometimes, the latter depends

greatly on the first, since where and how the data was collected influences the viability and

trustworthiness of the simulated output.

These two issues being most important in any model, analysts tend to address them in the

same manner, independent of the modelling technique. Exceptions exist, such as having to

collect data beforehand when building a statistical simulation, as opposed to being able to

do it in parallel with constructing a system model.

Finally, the greatest pitfall simulation developers can fall in is sidetracking. Most models are

there to bring about never before seen processes or procedures, and special challenges may

arise in development. Even the intended focus of the model may at first present itself as

imprecise, therefore each step of model-building has to be refined to a cutting edge, to

ensure that problems do not pop up afterwards and prove to be unsolvable.


16

3 The Sugarscape

3.1 Components

The Sugarscape model rests on three main pillars: the environment, the agents, complete

with the rules to which both abide, and last, but not least, the clock, which apart from

driving time forward, also acts as an invisible hand managing agent actions. Just like in real

life, the model makes a clear-cut distinction between the terrain and its inhabitants, who

roam the landscape pursuing their own goals, interacting with each other and with their

surroundings, as time irreversibly passes. This means that agent spatial distribution will

influence, depending on what we simulate, the dynamics of epidemics, trade, cultural drift,

or even warfare.

Most notably, the agent population is heterogeneous, each agent sporting different traits,

maybe even abiding to different rules, maybe to the extent that no two agents are alike. We

can afford to be just as flexible in building the landscape: no two spots have the same

resources, in the exact same amounts. Moreover, environmental rules may differ from one

spot to another, for example, differentiating the expected mortality rate between

harvesting crops, say, on a field, as opposed to in an active volcano.

Let us, then, take a closer look at each of the three basic components that make up our

simulation.

3.1.1 The Environment

The universe in which our agents live looks pretty much as your average paper map,

meaning that we have done away with the third dimension, limiting the field of vision to 2D,

or at most, 2.5D.


There are two types of environments: one closely mimicking real life, in the form of an

open-world grid, with terrain features and free roaming agents, and another, more abstract

environment, that best resembles the concept of settlements connected by roads. This

second type of environment will remove any other terrain from the equation, resulting in

what looks more-or-less like a graph.

Both environments can handle a virtually limitless number of resources for the agents to

harvest and live on. Being a finite landscape in both resolution and dimension, each grid cell,

by default, represents just enough space for an agent to occupy. Each of these cells

(locations) has resource stocks of varying quantities, each resource type belonging to its

own layer. Therefore, the environment is comprised of a set of concurrently accessible

resource layers, every one of them a landscape in itself, sharing the very same coordinates.

For example, we might have a cornfield on top of uranium-rich soil. Doing away with the

third dimension, an agent standing in the middle of this landscape, will, at the same time,

find himself knee-deep in uranium, and harvesting the dubiously oversized corn for the

day’s meal.

This brings us to the rules governing our artificial universe, most of which relate to resource

grow-back and allocation. We may assign a different set of rules for every resource layer

mapped on our grid locations, or even to every unique grid point. Once harvested, the corn

may grow back incrementally, pop up at full capacity after a certain period of time, or even

instantaneously. This may vary according to location, or even to the amount of uranium held

by that particular spot. An entire ecosystem can thus arise – development time and machine

power the only limits to its complexity.

Not all resources held by the landscape are necessarily harvestable, or even desirable. The

developer may simulate ground altitude, or even pollution, through the very same process.

Should we consider dirt a resource, we get to the logical conclusion that the more dirt on

one spot, the higher its elevation. Conversely, pollution as a resource can have dispersion

rules comparable to the way an ink drop spreads on blotting paper.


18

3.1.2 The Agents

Any given Sugarscape model simulation will usually have a fractured agent population,

forming two or more splinter groups, possibly going as far as to forego grouping in favour of

unique individuals, defined by traits and rules. While homogeneity is certainly possible when

building up the population, the real life social structures that Sugarscape typically simulates

are much more complex and subtle. Not only will agents have different characteristics and

abide to different rules, but some may not have some traits altogether, while others may do

without one rule or another.

The most basic agent model describes individuals that do not have any particular traits,

apart from their name, or ID, and age that roam the landscape in search for food. The rate

at which they collect resources from the environment differs from their in-born metabolism;

therefore, the agent may have a stockpile of resources in his virtual backpack, which he

Movement Rule M: function Agent:look() local locations = List:new() local look = 1 n = self.location.neighbours["N"] s = self.location.neighbours["S"] e = self.location.neighbours["E"] w = self.location.neighbours["W"] while look <= self.vision do if n ~= nil then locations:add(n) n = n.neighbours["N"] end if s ~= nil then locations:add(s) s = s.neighbours["S"] end if e ~= nil then locations:add(e) e = e.neighbours["E"] end if w ~= nil then locations:add(w) w = w.neighbours["W"] end look = look + 1 end return locations end function Agent:chooseNextLocation() local locations = self:look() locations:sort("resources.last.value.current_resources", locations.gt) for location in locations:iterator() do if location.value.occupant == nil then return location.value end end return nil end


slowly eats away. Upon running out of resources to consume, agents die of starvation.

Failing that, they will still die, eventually, of old age.

Typical agent traits concern vision distance, genetic attributes, cultural heritage, group

membership, resource carrying capacity, metabolism, sex, and diseases. The developer may

insert any type of attributes, relating to the object of each particular simulation. These traits

connect closely to the agents’ rules of conduct, that define each individual’s response in

varying circumstances to meeting another agent with, or without, certain traits.

Rules, however, go beyond agent-to-agent interaction. They describe the entire behaviour

of each agent, from movement, to resource consumption, to trade, reproduction, warfare,

death, and any other imaginable action, or set of actions that he undertakes. The most basic

rule of all, movement, does not even concern other agents past acknowledging their

existence in a certain spot. As is the case with the environment, rules can be applied globally

(to the entire population), only to a certain group, or individually, to each agent.

Whereas we thought out built-in rules to be as simple as possible, in no small measure due

to processing and development constraints, custom simulations can use an intricate set of

laws to govern agent and environment behaviour, taking into account multiple variables and

affecting more than one agent.

Agent Action A: function Agent:action() for resource in self.resource_list:iterator() do resource.value:calculateMetabolism() end if self.age == 100 then self:die() else next_location = self:chooseNextLocation() if next_location ~= nil then self.location.occupant = nil self.location = next_location self.location.occupant = self self:consumeAllResources() end self.age = self.age + 1 end end


20

3.1.3 The Clock

A real underdog of the Sugarscape model, the clock drives the entire simulation. Even

though the simulation divides time into finite units, be they years or seconds, agents take

turns in performing their actions within each timeframe. No two agents work at the same

time, lest conflicts appear – therefore the clock is required to choose which agent has

priority.

This means that different choices may skew the results of the simulation one way or

another. Normally, the choice is random, but in some cases, we might want a certain type of

agent to have priority over another, in order for the simulation to be accurate.

Apart from this mechanic, time is a deciding factor in almost any simulation, a vast number

of variables depending on it, such as agent age limits, or crop growth.


3.2 Adding Slices to the Pie

Sugarscape goes way beyond what we have described in the previous chapter. Adding stuff

on top of this basis varies wildly according to the object or objects of study, but assuming

we are studying humans, not ants on a table, and wanting to include and / or examine the

motivators of human society, there are preset rules that Epstein has left for the picking.

3.2.1 Sex

The commonly accepted view of the world is that making babies keeps a species going, in

the interest of which, our special breed of agents need to learn how to produce offspring.

Unfortunately, this does not entail fathers having manly talks with their sons, or mothers

giving out pictures of flowers to their daughters, but rather lines of algorithm code.

Emulating the real world, such an algorithm could base itself for the most part, on age.

Humans are thought to be fertile from around the age of 14, 15, up to somewhere in their

50s or 60s. Since we are not automatically accounting for in-vitro fertilization, we suppose

the two agents first have to be near one another – in other words, within each other’s field

of vision. Then we check if they are both of fertile age, and then, maybe for some other

arbitrary attribute, like money. If the neighbourhood is not currently overcrowded, in the

sense that there is one empty space for the new kid within both parents’ fields of vision, the

two get together and produce another agent sharing similar characteristics with their own,

and lugging a part of their hoarded resources.

Assuming there is no God, and Darwin actually got evolution right, our function will weed

bad “genes” from good ones, be they high metabolism, low vision, or anything else, really.

Neighbour Finding Algorithm N: function Agent:neighbours() local locations = self:look() local neighbours = List:new() for location in locations:iterator() do if location.value.occupant ~= nil then neighbours:add(location.value.occupant) end end return neighbours end


22

This algorithm can even check for similarities in a partner, or can differ from one agent to

the other, depending on how discerning we want the agents to become. If we plan on high

discrimination, and general soberness, we can expect the birth rate to drop dramatically,

but if we do the right choice of engineering agents with a drinking problem, we could even

simulate the population of Bangladesh.

3.2.2 Disease

Speaking of which, (Bangladesh, disease is just coming up) we can simulate an entire range

of illnesses and pandemics through the same process as building a computer virus. First, we

have to differentiate between healthy and unhealthy individuals by setting a variable that

asserts the agent’s state. This is akin to having an executable include the bad code in it.

Reproduction Rule R: function Agent:procreate() if self.age > 15 and self.age < 50 then local neighbours = self:neighbours() local locations = self:look() local baby_loc = nil for neighbour in neighbours:iterator() do if neighbour.value.age <= 15 or neighbour.value.age >= 50 then neighbour:rem() end end neighbours:sort("vision", neighbours.gt) spouse = neighbours.first.next.value for location in locations:iterator() do if location.value.occupant == nil then baby_loc = location.value break end end if baby_loc ~= nil then local agent = Agent:new() agent.location = baby_loc baby_loc.occupant = agent agent.vision = math.floor((self.vision + parent.vision) / 2) for resource in self.resource_list:iterator() do if spouse.resource_list:get("id", resource.id) ~= nil then father = resource mother = spouse.resource_list:get("id", resource.id) new_resource = Resource:new() new_resource.metabolism = (father.metabolism + mother.metabolism) / 2 new_resource.current_value = ((father.current_value / 3) + (mother.current_value / 3)) father.current_value = (father.current_value / 3) * 2 mother.current_value = (mother.current_value / 3) * 2 agent:addResource(new_resource, resource.id) end end population:addAgent(agent) end end end


Furthermore, we attach a function that serves to spread the illness to the other

unsuspecting victims, which amounts to running the said executable. Finally, we can have a

payload, meaning that the disease is more than just a trait, like blue eyes, but it also affects

the agent’s life and behaviour.

On the other hand, we could concomitantly have another illness, called “caring for your

fellow agent”, that has struck a particular group, called “medics”, just so that not all disease

goes untreated.

3.2.3 Trade

Having already familiarized you with our rather dystopian view of how agents grow crops on

top of fertile, uranium-rich soil, let us assume that only some spots grow uranium, but

agents need to grow crops on arid soil as well in order to survive. Consequently, radioactives

become a commodity, and our population will start trading fissionable material in order to

get the day’s meal. Since uranium itself tends to be harder on your teeth and kidneys than

corn, agents will still eat corn, so the mineworkers will not get off easy.

Trade follows a decentralized pattern, presenting agents that are located one near the other

with the opportunity of bartering and bargaining. Each agent can do this with all his

neighbours within vision range, and will naturally choose the best deal, if not influenced by

other, as of yet unmentioned, factors. Agents with what they believe is excess corn will give

away the corn for uranium, and hungry, yet wealthy agents, will give shell out uranium to

grab a snack.

Resource Status Algorithm S: function Agent:resourceStatus() local best = self.resource_list.first.next.value local worst = self.resource_list.first.next.value for resource in self.resource_list:iterator() do if resource:timeLeft() > best:timeLeft() then best = resource elseif resource:timeLeft() < worst:timeLeft() then worst = resource end end return best, worst end


24

3.2.4 Credit

Some agents, due to starting out on a bad patch of land, having a small initial resource

endowment, or simply because they are weak, cannot afford to make a living, produce

offspring, or buy that shiny Lamborghini. One final effort to save their lives or reach their

other goals could be to borrow some resources, be they uranium or corn, from a fellow

agent within range. The simplest form of credit would be one without an interest, payable

at a set later date, but a whole range of credits can be implemented, as well as a whole set

of consequences for not paying on time.

When considering a credit, the lender will first see if he has anything to give away, analyze

how many resources the borrower has been able to gather up to now, in order to assess the

latter’s ability to repay, then think up a payment plan according to the type of credit made.

Trading Rule T: function Agent:tradeResources() if self.resource_list.total_items > 1 then local best, worst = self:resourceStatus() if worst < 3 or best > 10 then local neighbours = self:neighbours() local sell_quantity = (best:timeLeft() - 5) * best.metabolism local traders = List:new() for neighbour in neighbours:iterator() do response = neighbour:acceptBarter(best, worst) if response ~= nil then trader = { id = neighbour.id, val = response } traders:add(trader) end end traders:sort("val", traders.gt) partner = neighbours:get("id", traders.first.next.value.id) if sell_quantity > traders.first.next.value.val then sell_quantity = traders.first.next.value.val partner.resource_list:get("id", best.id):add(sell_quantity) self.resource_list:get("id", best.id):rem(sell_quantity) partner.resource_list:get("id", worst.id):rem(sell_quantity) self.resource_list:get("id", worst.id):add(sell_quantity) end end end function Agent:acceptBarter(buy, sell) if self.resource_list.total_items > 1 then local best, worst = self:resourceStatus() if buy.id == worst.id and sell.id == best.id and best:timeLeft() > 10 then return (best:timeLeft() - 5) * best.metabolism end end return nil end


Visualizing credit networks through a graph will show the very dynamic nature of these

agent-to-agent relationships.

3.2.5 Culture

Since there is a small part of life that is not entirely dependent on either sex, or money, we

have introduced the very fuzzy concept of culture in Sugarscape. In practice, this is just a list

of variables that agents can recognize in others and compare to their own, in the interest of

sex, giving and receiving money, or the odd case of jihad.

Moreover, just like disease, agents can pass on cultural traits from one to another according

to random, user-selected criteria, and can have different spreading patterns. Two African

friends may share a passion for blonde Europeans, but in order to pass on their rationale to

a mutual Pakistani friend, they will have to pass on knowledge of their language first.

Furthermore, those two Africans are likely to pass on their cultural traits, should they adopt

and raise a still innocent blonde European as their child, through a process called education.

The latter form of cultural transmission takes place at birth, similarly to the way parents

pass on their genes to their children. In order to impart cultural traits peer-to-peer, an agent

will have to go through all of his neighbours, select one of its traits, and then look for the

same one in the first neighbour. Three cases can occur: one, the neighbour already has the

same value for that trait, case in which nothing happens; two, the neighbour has a different

value, so the current agent changes it to its own value; and three, the neighbour does not

have that trait at all, so the current agent adds it to his neighbour’s list of traits.

Based on this list of cultural preferences, just as in the case of genetic characteristics, we

can divide the population according to how close their lists match. Two shotgun-approach

comparisons come up: one checking for the same preference in the entire population, the

other checking for global differences in the cultural list.

Since the first amounts to string comparison, there is only a point in explaining the latter.

One way of doing it would involve reducing the culture list to an array of one and zero,

therefore dividing the population by how close to zero the sum of each agent’s list is. This

method, however, only allows for two possible values per cultural preference.


26

The second method is more comprehensive, yet much more time consuming, as it requires

comparing each list with the lists of every other agent, and establishing the percentage of

identical preference values.

3.2.6 Combat

Since we have already included most of the other entertaining activities people partake in,

warfare seemed the next logical step on the road to simulating a civilized world.

We therefore made agents able to cane one another to death over crops and uranium, in

the absence of lambs. Someone may occupy the best resource spots within one agent’s

vision, reason enough to murder them and harvest the crops they had been standing on,

plus some or all of the victim’s resource stash.

Many rules can be thought up to control if and how combat takes place, but the basic, common

sense ones would dictate that the big fish will not get eaten by the little one, and that even a big fish

will not risk eating another one if it leaves him vulnerable to an even bigger fish. In programmer talk,

this means that an agent with an overall resource stash smaller than that of its targeted victim will

not attack, and neither will an agent that has within his vision a third agent that will be bigger than

himself after he will have robbed his mark.

If the attacker can rob the victim of all its wealth, the attacker’s ascent will be close to exponential,

since he will have a better chance at robbing ever more wealthy opponents, its attack deterrent ever

greater. Infinite agent lifetimes would take this to an extreme where after a number of generations

nobody could challenge the Methuselah agents that would grow fatter at the expense of the

youngsters.

However, if there is only a fixed reward for breaking the sixth commandment, and lives are finite,

like on Earth, combat becomes relatively reasonable, in terms of monopoly. If we couple this rule to

agent grouping, group regeneration, possibly through reproduction, and no group infighting, we can

observe an ensuing war of attrition.


3.2.7 The Pie

Adding these components together in one simulation reveals a complex proto-society that

progresses and interacts in patterns remarkably similar to what we observe in real life. Agents evolve

from a rather uniform population into more genetically fit individuals that trade with one another;

divide into spatially segregated groups, according to resource geographic distribution; form

networks of friends and peers, and fight over resources and cultural beliefs.

A potential user can customize this generic artificial society to account for virtually any thinkable

situation that involves individuals, be they human or bacteria.

Combat Rule C: function Agent:isSuperiorTo(rival) local self_points = 0 local rival_points = 0 for resource in self.resource_list:iterator() do if rival.resource_list:get("id", resource.id) ~= nil then self_time = resource:timeLeft() rival_time = rival.resource_list:get("id", resource.id):timeLeft() self_points = self_points + self_time rival_points = rival_points + rival_time end end self_points = self_points * self.vision rival_points = rival_points * rival.vision if self_points > rival_points then return true else return false end end function Agent:fightForNextLocation() local locations = self:look() locations:sort("resources.last.value.current_resources", locations.gt) for location in locations:iterator() do if location.value.occupant == nil or self:isSuperiorTo(location.value.occupant) then location.value.occupant:die() self.location.occupant = nil self.location = location.value self.location.occupant = self end end end


28

3.3 Off the Beaten Path

Since the vanilla version of the Sugarscape has never really served for anything else except

demonstration purposes, we brought a set of modifications to it, both by not sticking strictly

to the book when implementing the predefined agent rule set, and by introducing a couple

of innovative concepts to the mix, so as to prepare this framework for real use. In this

process, we were careful not to degrade the simulation results’ level of accuracy, but rather

prepare the model to deal with real-life data and processes.

3.3.1 Custom Scenery

Worth mentioning are the addition of customizable landscapes and behavioural modification. The

Sugarscape environment is traditionally an unravelled torus, with two hills of sugar, one in the

northeast corner, and another in the southwest corner of the map. This map wraps around both

along the X-axis, and along the Y-axis, forming the said torus, and allowing agents to pop out on one

end and appear at the other.

Since such behaviour is not very consistent with how people move on a map, and because a

landscape usually encompasses other features, apart from two perfectly round hills, we reasoned

that importing custom scenery should be a high priority on our list. The landscape retains the

possibility of wrapping around vertically and horizontally, but this has become an optional feature,

and no one really expects to see this feature in heavy use anytime soon, since we all know the Earth

is flat.

Further modification to the environment is possible, given that we can link locations from off the

map to any point on the grid, or create shortcuts between two places, to simulate fast travel

options. These shortcuts need not even be bidirectional, one location’s north neighbour pointing to

a place far, far away, and the south neighbour of that faraway place being just below on the map.

We opted for this approach after weighing in that versatility is more important than error

prevention, if the latter rules out the first. This means that forging a two-way link between two

places needs linking both to one another, similarly to building a second train track connecting two

stations.


3.3.2 Change of Conduct

The other notable addition to the standard Sugarscape model comes in the form of agent

behavioural modification. Though more an added bonus made possible by our choice of used

technologies, this feature brings the Sugarscape to a completely new level of realism, impossible to

attain otherwise without going through much unnecessary complication.

Even though the practical aspect of this process is unremarkable, i.e. referencing one function

instead of the other, the conceptual implications open up the gateway to real agent change. The

original Sugarscape model fails in providing truly heterogeneous populations of agents – they do not

have the same genetic traits, the same cultural attributes, the same wealth, or the same age; what

they do share in common, is the rules by which they abide.

It would be almost foolish to think that all people adhere to the same code of conduct, which, in

turn, is immutable. Fortunately, we are now able to not only change agent behaviour internally,

based on arbitrary values, but also transmit rules, actions, algorithms from one agent to the other,

allowing for much more complex interactions within a dynamic artificial society.

Our agents now can act differently as a baby, a young adult, or an old person; they can even

“convince” other agents to copy their behaviour, through processes similar to genetic or cultural

attribute transmission. For example, we need not represent disease only as a tag on an agent, but

can attach a manner of conduct specific to that disease, be it in the form of erratic behaviour,

reduced resource-processing rate, or lifespan reduction.

The meaningful difference in our approach is that an agent should not automatically have a latent

ability to act in a certain way since birth – even though the agent does not have that function, it can

reference it from another’s pool of functions, and practically adopt it as its own.

By more closely mimicking real life, these two additions enhance the model’s reliability, going

further along the road of ever-increasing complexity, as opposed to the mathematical models we

have already brought to attention.


30

4 Design and Implementation

4.1 Design Process

Although we wrote and designed a great deal of the application code somewhat

haphazardly, the first step taken was to settle upon a number of design decisions, which

greatly simplified our work. Due to the dual nature of the application, we had to use the

factory design pattern to build a solid and viable framework, as well as try making it as

modular as possible.

4.1.1 Factory Design Pattern

The whole idea behind this design pattern is to provide encapsulation to classes prone to

frequent changes, to avoid the myriad of modifications brought about in virtually all code

segments that use these classes as programmers revise them. Moreover, if we are to adhere

to the Dependency-Inversion Principle3, we ought to try to depend as much as possible on

abstract classes, rather than concrete ones.

Achievement of this objective is possible by introducing a factory class and an interface in

addition to the class or classes that are being included in this pattern, so that we call a

factory method to create the volatile classes, which are all accessible through the same

interface. The factory method may even be able to call a set of different class constructors,

based on the provided parameters, and return a generic object, cast to the appropriate

class, as necessity dictates.

Not all projects benefit from using factories, but they can be of great help as the application

grows ever larger and complex, since they allow higher-up classes to create and manage

instances of volatile classes without depending on how the latter are implemented.

3 Martin, R. C. (2002). Agile Software Development. New Jersey: Prentice Hall.


More to the point of our project, factories were a necessity, instead of just a convenience,

since controlling Java classes directly through Lua script is a real hassle if not done through

helper methods. The incentives to use factory were even greater, since the user interface

classes mapped to the factory are practically tabs containing plot canvases for graphic

representation of the simulation’s output data. Most of these plot canvases are thoroughly

similar, so mapping them to a common interface was mostly a breeze.

Therefore, the user interface, mapped by default in the Lua memory space, and thus fully

accessible through the script, also serves as factory for creating data output tabs of various

kinds, from pie and scatter plots, to fully interactive consoles and other advanced charts.

Even the simulation proper has to use some form of factory to build itself from the provided

input data, even though the inner workings of Lua are very dissimilar to the object-oriented

concepts and restrictions of C++ and Java.

4.1.2 Observer

Another early discovery was the conceptual difference between actually running a Sugarscape simulation, and printing the output data to screen. Since these two do not necessarily go hand in hand, we opted for a completely separate approach.

This clear-cut distinction gives us easy access to perform modifications to the way we output data, without having to access vital functions of a running simulation, or even pause it at all. Equally, when performing modifications to the simulation behaviour, we do not have to worry about matching the new functions to the already defined output charts.

We materialized this decision on two layers: within the Lua script, and in the entirety of the Java user interface.

Inside the script, we decided to have a set of event listeners, or observers, which simply pluck out required data from the running simulation, then pass it on. The only thing the Java executable ever does, apart from starting the simulation, is management of the user interface. Nothing in Java even remotely relates to the Sugarscape itself, the executable thus having the potential to plot completely unrelated data.

4.2

We can

executa

and the

will talk

be on th

Develop

Java. W

correct

In orde

have in

firm be

support

This int

at othe

The Foun

n conceiva

able, which

e Sugarscap

k about it in

he Java imp

ped in Eclip

We carefully

functioning

er to stream

tegrated a

elief that t

t groups an

tegration co

r key points

ndation

bly divide

acts as ge

e model, w

n detail in th

plementatio

pse, the ap

y selected

g on all plat

mline the d

number of

this will fa

d readily av

omes at diff

s throughou

our softw

neral-purpo

which reside

he next cha

on of the ex

pplication is

all attache

tforms supp

evelopmen

open-sourc

cilitate its

vailable thir

ferent level

ut the applic

M

ware applica

ose user int

s wholly in

apter, the fo

ecutable pe

s not OS-sp

d packages

ported by th

t process o

ce, mostly o

use throug

rd-party doc

ls, most not

cation as a

Multi-Agent S

ation into

terface and

scripts. Igno

ocus of this

er-se.

pecific, since

s with the

he JDK.

of the Suga

off-the-shel

gh standar

cumentatio

tably at the

whole.

Simulations o

two main

d input / ou

oring the la

chapter wi

e we devel

intention o

arscape soft

f technolog

rdization, a

n.

e user inter

West Uof Social Phe

parts: the

utput data h

tter for now

ll for the m

loped it en

of facilitati

tware pack

gies with it.

already esta

rface level,

Universityenomena

3

e actual

handler,

w, as we

most part

tirely in

ng their

kage, we

It is our

ablished

but also

32

333 Blaga Vi

4.2.1

Given t

operati

implem

all mod

platform

Moreov

feature

Rich Te

place in

the full

crunchi

are exte

also inc

ctor-Emanue

Front-End

that one o

ng systems

ment the use

dern distri

ms, at virtua

ver, Java p

s, among w

xt read / w

n our softw

y self-conta

ng in the ba

endable, wi

cluded into t

el

d: Java an

of the main

s, such as

er interface

butions of

ally no code

provides cr

which netwo

write capabi

are project

ained threa

ackground,

ith a good n

the Sugarsc

d Swing

n design g

Linux flavo

e in Swing. B

f Java, it

e refactorin

oss-platform

ork and data

lities. Most

t – nonethe

ad access in

without loc

number of e

cape applica

oals of thi

ours or eve

Because the

provides c

g cost what

m, uniform

abase acces

t of these, a

eless, one cr

nterface, wh

cking up th

existing thir

ation.

s software

n Mac OS,

e Swing pac

consistent

tsoever.

m access to

ss, OpenGL

admittedly,

ritical and h

hich enable

e applicatio

rd-party add

is easy p

, the natur

ckages are

results acr

o a numbe

rendering,

do not hav

heavily used

es us to do

on. On top o

d-ons, some

ortability t

ral solution

present in

ross all su

er of othe

as well as X

ve, as of no

d feature o

the heavy

of this, the

e of which w

o other

was to

virtually

pported

r useful

XML and

ow, their

of Java is

number

libraries

we have

One of

Althoug

easy to

surface

integrat

output

from w

update

4.2.2

Closely

primari

industry

well in

corpora

4 The Pro

these libra

gh it somew

o use plotti

plotting w

ted method

data. The

within the s

automatica

Scripting

integrated

ly provides

y profession

excess of 30

ate applicat

ogramming La

ries is JFree

what lacks

ing package

widgets an

d of present

user simply

simulation,

ally.

Support:

d with and

s the basis

nals, who g

0 computer

ions.

nguage Lua, h

eChart, whi

in redraw s

es available

nd associat

ting the use

y has to re

as each tim

Lua 5.1

even driv

for the Su

generally us

r games, to

http://www.lu

M

ich we have

speed, JFre

e for the Ja

ed classes,

er with an in

eport the d

me unit pa

ving the us

ugarscape

e it for artif

date, as we

ua.org/

Multi-Agent S

e used for d

eeChart is o

ava langua

, the Plot

ntuitive inte

esired valu

asses, and t

ser interfac

simulation.

ficial intellig

ell as a sign

Simulations o

data outpu

one of the

ge. Contain

library off

erpretation

ues through

the desired

ce, the Lua

In wide u

gence, Lua

ificant num

West Uof Social Phe

t and visua

most comp

ning 2D gra

fers a con

of the simu

h specific fu

d plot wind

a scripting

use among

script has p

mber of indu

Universityenomena

3

alization.

plex, yet

aph and

venient,

ulation’s

unctions

dow will

system4

gaming

powered

ustrial or

34


The actual library is fast, lightweight, portable and easily embeddable with both C / C++, and

with Java applications. Even though the actual source code is ANSI C in its entirety, there are

a number of third-party Java bindings, allowing the user to handle classes and call functions

of the main application from within Lua.

Dynamically typed, the language itself offers a simple to use procedural syntax, a data

description based on two-dimensional associative arrays, automatic garbage collection, as

well as the option of extending or modifying the language through function re-assignment.

We implement objects and classes, for example, simply by creating an array of functions and

variables, and then having other objects inherit their values.

Our integration of Lua script with the user interface has enabled us to dictate what is shown

on screen from within the simulation itself, or from an additional script, therefore

controlling on the fly both the options available to the user in the given context, as well as

the methods of output data representation.

Lua script already has a well-entrenched user base, which extends over not only the

dedicated Lua forums and newsgroups, but rather over the entire game modding

community, because so many games have implemented their AI using this scripting

language. Additionally, you can find manuals, reference books and a host of tutorials online,

all of which make it easy for even the most inexperienced programmer to take up learning

Lua.

4.2.3 Input Data: Java Advanced Imaging API

To smooth the user’s workflow in relation to setting the stage for the simulation, we have

decided to import the Sugarscape’s environment from TIFF images, and translate it into

hard data, and use it further in the simulation’s mechanics. Taking into account that most of

the times, the user will want to make a map of resources on which the agents can roam, the

most natural way to do it would be from an image editing software package. Our choice for

the specific TIFF image format derived from a number of considerations, among which the

fact that TIFF is not a proprietary format, its high data capacity (4 GB of pixel data), its

support for layers, as well as for arbitrary embedded data, unrelated to the picture itself.


36

Since our data model called for an environment that held multiple resources, which could

each fluctuate at all locations according to minimum and maximum values, we chose to

interpret the TIFF image as follows:

• the image as a whole stands for the entire environment

• each pixel represents a location in the environment

• each layer represents a resource held by the environment

• each layer’s red channel represents the minimum possible resource value, on a per-

pixel basis

• each layer’s green channel represents the maximum possible resource value, on a

per-pixel basis

• each layer’s blue channel represents the current resource value at the outset of the

simulation, on a per-pixel basis

To this end, we have chosen the Java Advanced Imaging API5, linked against the Java Image

I/O library6, both of them being open-source solutions and having a wide user base,

community and even corporate support. While other third party libraries would have

permitted stand-alone reading of TIFF images, this combination adds certain flexibility to the

whole process, and most importantly, allows for 16-bit red, green and blue channel values,

feature critical to approximating real-life data with this software.

5 Java Advanced Imaging, http://java.sun.com/javase/technologies/desktop/media/jai 6 Java Image I/O, http://java.sun.com/javase/6/docs/technotes/guides/imageio/index.html


4.3 Upwards and Onwards

Of real interest, nonetheless, is the actual simulation, residing in the Lua script files. More of

a framework than an actual simulation, our implementation of Sugarscape makes wide use

of the loose rules of Lua to achieve a level of flexibility impossible to attain through any

other programming paradigm. Convey this thought better requires a short description of the

inner workings of Lua script.

To begin with, every single variable and function in Lua is stored as an entry in a table. The

global table _G contains the name and value of all functions and variables available in Lua

memory space, the latter of which can very well be tables themselves. This allows the user

to think about and use Lua similarly to a database, and means that the user treats functions

as variables, in the sense that any function can take the place of another by simply placing

the two on opposite ends of an “equals” sign. All of this is possible since tables in Lua hold

names, type and references to memory addresses, therefore allowing for swift changes in

any of these fields.

Secondly, there is no such thing as classes in Lua, in spite of our object-oriented approach to

building the Sugarscape. What we have are tables with variables and functions, that stand

for objects – these, in turn, can stand as prototypes for other objects. Consequently, when

we define the Agent table, for example, we could have it function both as a class, and as an

instance of itself. Moreover, we can add numerous distinct functions and variables to all

objects that inherit Agent, to the point that all derived agents are unique not only by value,

but also by behaviour and elements contained.

Having absorbed all this knowledge, we set out to lay the groundwork for our model.

Apparently, the Sugarscape needed a whole set of independent data structures to hold itself

and its occupants together: a three dimensional array for the environment, a cross-

referenced hierarchical structure for the population and its groups, sets of formatted data

for agent properties, and specialized containers for holding and passing on the various types

of gathered output data. Building and having these disparate structures work together was

an unwelcome complication, so unifying them seemed in high order.


38

The solution came in the form of a linked list

versatile enough to accommodate all these

requirements at the same time, in conjunction

with a set of descriptive classes derived rather

from real world concepts than from programming

abstractions. What sets this list apart is its

inherent capability of searching for and removing

objects based on their contained fields

and values, as well as the included

modular sorting mechanism that can

order the list according to user defined

criteria.

4.3.1 Living off the Land

The Sugarscape environment is composed

of individual locations (pixels), and layers

corresponding to the different types of

resources present. Mapping this two

dimensional lattice on a linked list

required having each location object store

references to its neighbours, and defining

a function of the environment to calculate

the position on the list of each location,


based on its position on the X and Y axes.

Each location has a set of layer points, or resources – looking at this set is akin to taking out

a vertical section of the local soil sample. Each layer point corresponds to the amount of one

specific resource held by the current location.

Layers are more of a convenience class, since they are to layer points what the entire

environment is to locations. They provide easy access to neighbouring resources of the

same type, should the current simulation require any sort of dispersion, or area calculation.

By structuring the environment in this particular way, we add some sort of third dimension

to it, without having to go through the hassle of actually mapping it, or through the other

pain of having agents search and move along the Z-axis.

4.3.2 Part of a Community

We can view the agent population as a multitude

of sets that share elements, each element being

an individual agent. Since we are not fond of

mathematics, we shall go on to call those sets

groups, and not look back.

The population class has both a list of groups,

and one of individuals, very much in the same

way that the environment handles layers and

locations. The plot twist, however, comes when

we do not make a vertical section of each agent

to partition its internals, but instead opt to allow

the poor sod to belong to one, more, or no

groups whatsoever.

Fitting into a group is just a matter of facade, a

uniform to dress the otherwise unique agent.

We never meant groups to accommodate a


40

homogeneous collection of agents, but rather to imbue these individuals with a sense of

belonging and a way to recognize one from another.

Furthermore, in order to have the user care about his minions, we allowed him to each

agent names, such as “Daisy”, or “Mr. Hyde”. This paves the way to pointing the odd man

out in a simulation of, say, the London bombings of July 2005.

The way our agents act bears both similarities and differences from the way real-world

people go about their business. The difference is that we cannot have everybody act at the

same time, since building a thread of execution for each agent, and then setting

semaphores for each possible resource is both computer-wise, and programmer-wise, hard

work, which should unmistakably be avoided. Thus, we implemented a queue, every agent

standing in line to put his virtual punch cards through the obviously virtual IBM mainframe.

What we brought about in our simulation, however, is the general unfairness of life. Since

resources on our landscape are limited, agents at the front of the queue will have the

chance of getting much better return on their movement and associated actions than the

ones at the end. The ones discriminated against will therefore have a much more significant

chance of dying of starvation, for example, and sadly, we have not implemented the

afterlife... yet.

Given this inherent favouritism, we reasoned that instead of leaving it to pure chance, we

should account for this variable by letting the user decide who his loved agents are. The

population therefore uses the sorting mechanism of the agent list to re-arrange them in the

line, so the user can get his desired action order each time unit.

Another fortuitous similarity to real life is that the agents are greedy, be that an appetite for

food, money, or even other people. Apart from their modifiable decision-making and

movement algorithms, the agents all have a backpack, which they like to fill with goodies.

However, as living also means turning useful stuff into nothing, at best, and into bad stuff, at

worst, each time unit these agents will eat something from that backpack, as well as hoard

some more while reaping the land’s product.

In programming terms, this means that each agent has a resources object that contains a list

of possessions. The agent also has a metabolism function that eats away at those


possessions, or even adds to some of them, as time passes. Should the agent reach a lower

or upper limit of one of those resources, he will die of starvation, inability to pay the rent, or

toxin build-up in his body, as convenient examples.

4.3.3 I Spy

Privacy is of no concern to agents in Lua space,

because, simply put, private variables do not exist.

Algorithmically speaking, a programmer would have

to go through a lot more than the devil had to, in

order to get agent Adam and agent Eve to realize

how exposed they are to the world.

The upside of this problem is that we can build true

event listeners in Lua, which do not have to rely on

the actual agents to report their status, but rather

strap themselves, lock and load, then go in foraging

for the needed information. The simulation goes on

undisturbed, blissfully ignorant of the myriad of eyes

checking in on its status every time unit.

We called these listeners Events, and their overlord, Event Viewer, for maybe no other

reason than lack of a good idea of what they will be supposed to do, finally. Each such event

stores a list of values that it looks for, then waits for the viewer to come in, harvest that

data, and output it on screen, through the Java user interface.

Evidently, we leave the user to build the data harvesting algorithms and to decide upon the

form in which to represent this data, since the framework is supposed to help in building

any kind of custom simulation. What is fixed is the fact that each time unit, after the agents

have accomplished their temporary goals, the Events drop in and record progress from the

comfort of their flying saucers.


42

4.3.4 Full Circle

Completing these structures are the functions and constructs pertaining strictly to the

current simulation, which we meant to leave room for in the “Test” class, defined solely by

the user.

Here one can add and override existing model functionality, insert agent and environment

properties, and define the event listeners. Therefore, we leave both data and its particular

on screen presentation completely to user preference.

The simulation will not work without user intervention, because we did not define any

proper actions in the framework. The framework leaves all environment regeneration rules,

all individual and aggregate agent behaviour, and any other miscellaneous events at the

user’s discretion. Moreover, interpretation of input data is highly customizable, to allow for

changes in environment layer number, initial agent group creation and simulation time

span. Even so, the framework does ship with an example test class and a working factory.

43 Blaga Victor-Emanuel 5 Conclusions

5.1 Lessons Learned

At the end of the day, a retrospective analysis of the development process seems in order,

highlighting what went right and not so right throughout the duration of this project.

5.1.1 What Went Right

The best decision relevant to this project was starting early. It took almost a year to

complete, with an on and off development program, and the pre-production stages have

been critical to understanding and planning for the challenge.

At this stage, we took decisions regarding the outsourced components of the project, and

the technologies involved – we drew up a basic initial plan of the simulation, and started the

documentation process for the various libraries. The two initial choices that proved to be

right were Lua script and TIFF image import.

While studying the former, we discovered the potential for variable agent behaviour,

although admittedly, we initially based our choice for it on the fact that a huge number of

computer games were already using Lua as an AI scripting language. The choice for using

TIFF files, however, came about when we comprehended that the structure of the

environment called for multiple resource strata on the same landscape. Connecting this

requirement to the concept of multi-layered image formats was simple, and the two

available options were Adobe PSD files and TIFFs. Since the former is a proprietary format,

we went for the second, and it proved to be a breeze to work with.

As opposed to other projects, we did not dive into programming from the very beginning.

Instead, we have gone through the stage of UML modelling, feature rationalization and user


44

interface sampling. Skipping this phase would have led to a much more complex and hard to

understand design, and would have probably impeded further development.

Prototyping most aspects of the Sugarscape model, and each user interface component has

also helped in skipping annoying and convoluted debugging further off along the line. The

first two incarnations of the model served as working projects for other classes, requiring

early functionality and hence a modular approach to content additions. In the end, this

proved to be the stepping-stone from a functional application to a usable and adjustable

framework.

The first version of the model would have gone for a mixed hard-coded and scripted

approach, which would not only have gratuitously complicated programming, but also

limited the versatility of the framework. Recognizing the problem, we never even started

the hard-coded version, but went straight for the clear-cut division between scripted model

and static user interface executable.

Developing the second version of the model in tandem with the first user interface

prototype called for a number of modifications in the way we looked at the Event Viewer

and its bridge to the hard-coded application. We rethought a number of functions and

moved them to the actual executable, in order to allow the conversion from raw data to

user-friendly diagrams and plots.

Finally, we held back on putting the documentation on paper from the start, decision that at

first seems bad, as one would think that with time we would have forgotten the details and

inner-workings of the written code. What we did with time was to modify and rewrite the

framework multiple times over, so we avoided recording the documentation repeatedly

with each incremental alteration.

By foregoing documentation, we do not imply sacrificing code comments, as virtually each

line of Lua code has comments to provide an easy to read description of every function of

the Sugarscape model.


5.1.2 What Went Wrong

Initially, we went for C++ with Lua integration for the standalone executable, attempting to

write the code in Eclipse CDT7 with MinGW8 compiler. Since cross-platform usage was a

requirement, the proposed goal was to stick as much as possible to the ANSI C++ standards,

and attach packages of cross-platform static or dynamic libraries for any added

functionality.

We therefore chose Trolltech’s Qt9 library, and added its Qwt add-on, Qt Widgets for

Technical Applications10, which was supposed to deal with chart and graph plotting.

Unfortunately, integrating Qt and Qwt with Lua proved to be somewhat of a pain, and the

real showstopper was the lack of any meaningful documentation or user support for Qwt.

Performance was also horrible, to the extent that simple scatter plots had slow redraw

rates, and creating other types of graphs was undocumented.

In addition, picking Adobe GIL11 linked against LibTIFF12 for image import, though both

seeing widespread use, was an unfortunate one, for the reason that the former will only

compile in Microsoft Visual Studio.

The answer was to switch to Java at the end of the development process, and redo the

entire user interface, image import routines and Lua script handling. Fortunately, we

promptly managed to find alternative libraries for the outsourced code, but the user

interface now looks a bit rushed, mostly because it is.

The bottom line, however, is that we needed to learn to adapt and port important sections

of code from one programming language to another in record time, skill learned on the

front line, so to speak, rather than out of curiosity.

7 Eclipse C/C++ Development Tooling – CDT, http://www.eclipse.org/cdt/ 8 Minimalist GNU for Windows, http://www.mingw.org/ 9 Qt: Cross-Platform Rich Client Development Framework, http://trolltech.com/products/qt 10 Qt Widgets for Technical Applications, http://qwt.sourceforge.net/ 11 Adobe Generic Image Library, http://opensource.adobe.com/wiki/display/gil/Generic+Image+Library 12 LibTIFF – TIFF Library and Utilities, http://www.libtiff.org/


46

5.2 Like, Finally

An agent-based model for social simulations, Sugarscape brings a bottom-up approach to

pattern prediction and analysis in a volatile environment. This specific implementation aims

at taking the model one step further, by adding the flexibility and trial-and-error approach

that Lua script allows for, to the otherwise complex and time-consuming process of building

an entire application.

Overall, this project attempts to bring a fresh approach to agent-based model simulation, in

a flexible and reusable manner, to grow into more than just a static, one-use assignment.

Attaining this goal was possible in part through the introduction of what we see as an

innovative paradigm for creating agent-based simulations, and in part by a good initial

selection of embedded technologies. The versatility of the Sugarscape itself lent most of the

usefulness of our framework, owing more to its initial authors than to the developer of this

particular incarnation.

The source code resides online, at: https://sourceforge.net/projects/artificial-soc

47 Blaga Victor-Emanuel 6 Bibliography

Works Cited

Brantingham, P. L., Glasser, U., Kinney, B., Singh, K., & Vajihollahi, M. (2005). A Computational Model for Simulating Spatial and Temporal Aspects of Crime in Urban Environments. Burnaby: Simon Fraser University.

Epstein, J. M., & Axtell, R. (1996). Growing Artificial Societies. Cambridge: MIT Press.

Ierusalimschy, R. (2003, December 1). Programming in Lua. Retrieved July 1, 2007, from The Programming Language Lua: http://www.lua.org/pil

L, G., & S, B. (2005). FABLES: Functional Agent-Based Language for Simulations. Proceedings of the 2005 Conference on Generative Social Processes, Models, and Mechanisms (pp. 139-150). Chicago: Argonne National Laboratory and The University of Chicago.

Martin, R. C. (2002). Agile Software Development. New Jersey: Prentice Hall.

North, M. J., & M, M. C. (2007). Managing Business Complexity. New York: Oxford University Press.

Singh, K. (2005). An Abstract Mathematical Framework for Semantic Modelling and Simulation of Urban Crime Patterns. Burnaby: Simon Fraser University.

Zaft, G. C. (2001). Social Science Applications of Discrete Event Simulation: A Devs Artificial Society. Arizona: University of Arizona.

multi-agent simulations of social phenomena

Documents