SugarScape

SugarScape is a model developed by Joshua Epstein and Robert Axtell (see references.)

In the first version hungry agents roam the countryside looking for sugar. As they roam, they burn sugar at a rate determined by their metabolism. If an agent burns up all of his sugar before he finds more, he dies. An agent's ability to spot sugar is determined by how far it can see. This is controlled by its vision attribute.

When an agent discovers a patch of sugar, he consumes it and resumes his search for more sugar. Eventually, the patch will grow more sugar at a rate determined by its growBack attribute.

By playing with these parameters-- metabolism, vision, and growBack-- users can gain insight into phenomena such as carrying capacity, distribution of wealth, seasonal migration, and resource consumption.

In version 2 agents have finite life times and the ability to mate. In this version users can also gain  insight into phenomena such as fertility, cultural dynamics, proto-history, even combat.

In version 3 a second commodity is introduced: spice. An agent rich in sugar but poor in spice can trade with an agent in the opposite situation. The number of units of spice equivalent to a unit of sugar fluctuates according to supply and demand. The model provides interesting insights into the performance of markets populated by rational agents versus markets populated by evolving agents.

In version 4, disease is added to the model. Users can study the transmission of disease, the effects on the economy, and disease control policies.

CNP SugarScape

CNP SugarScape is a version of SugarScape 1.0 described above, but with a twist. Following the Contract Net Protocol (CNP), turtles broadcast requests for proposals (RFPs) to all patches within their vision or broadcast range. Patches that receive these requests may send proposals back to the turtle. The turtle selects the best proposal, and moves toward the patch to pick up the sugar.

Here's a screen shot of SugarScape:

Implementation

SugarScape can be implemented by customizing the BAM1 framework.

A turtle has five attributes:

turtles-own [
   energy            ; dead = 0% <= energy <= 100% = max
   proposal-queue    ; nearby patches offering sugar
   broadcast-range   ; how far can RFPs be transmitted
   has-proposal?     ; = true if turtle has accepted a proposal
   target            ; = the patch that made the accepted proposal
]

A patch has two attributes:

patches-own [
   sugar             ; = amount of sugar here <= 100%
   rfp-queue         ; nearby turtles needing sugar
]

Updating Agents

A patch goes through cycles of making proposals in response to RFPs and growing sugar:

to update-patch
  if any? rfp-queue
  [
    make-proposals
  ]
  if sugar < 100 [grow-sugar]
end

A turtle goes through cycles of selecting proposals or broadcasting RFPs and seeking sugar:

to update-turtle
  ifelse any? proposal-queue
  [
    select-proposal
  ]
  [
     broadcast-rfp
  ]
  seek-sugar
  if energy <= 0 [die]
end

Queues as agent sets

A turtle's proposal queue is a set of patches. These are the nearby patches with sugar that have responded to the last RFP.

A patch's RFP queue is a set of turtles. These are the turtles requesting sugar.

Agentset is a NetLogo data type. Don't confuse a set of agents with a list of agents.

An agent set is a set of turtles or a set of patches or the empty set. We can't have an agent set containing a mixture of turtles and patches.

We can create agent sets using the turtle-set and patch-set commands. For example, here's how we can initialize an RFP queue:

set rfp-queue turtle-set []

Here's how a patch, P, can ask each turtle in it's RFP queue to add P to its proposal queue:

ask rfp-queue
[
   set proposal-queue (patch-set proposal-queue myself)
]

Making RFPs and proposals

To broadcast an RFP, a turtle, T, simply asks each nearby patch to add T to its RFP queue.

To make a proposal, a patch, P, simply asks each turtle in its RFP queue that doesn't yet have a proposal to add P to its proposal queue, after which, P empties its RFP queue. Note: only patches with sugar should make proposals.

Selecting a proposal

To select a proposal, turtle T picks the closest patch in its proposal queue. This patch becomes T's target:

set target min-one-of proposal-queue [distance myself]

T empties its proposal queue and sets has-proposal? to true.

Seeking and consuming sugar

If turtle T has no target (possibly because he didn't received any proposals), he moves N steps in a random direction, where N = 2 * vision. This consumes N * metabolism units of energy.

If T has a target he faces the target and takes one step. This consumes metabolism units of energy.

When T arrives at his target, he consumes the sugar he needs, converting it into energy, then sets target to nobody and has-proposal? to false.

T consumes the minimum of the sugar available at the target and the energy needed by T (100 – energy). The target's sugar is depleted by the amount of energy consumed.

There is also an energy cost to eating. Each time T consumes energy, it looses metabolism units of energy.

Growing sugar

As before, we can simulate a patch's gradual replenishing of sugar by increasing the amount of sugar by one unit if the patch is lucky. Generate a random number less than 100. If the number is less than the grow back rate, then add the unit of sugar.