Using an entity component system (ECS) might be suitable for you. It is
similar to the strategy pattern but any combination of "strategies" is
possible and also saving state along with them.
Each agent is an entity which is nothing more than a set of components
(representing state). A factory class is used to create entities with
the needed component sets. During each step systems (representing logic)
will update the entity by changing its components. For example, a
ReproductionSystem will look for a certain subset of components needed
for reproduction and only update agents who have this subset. To give an
agent the ability to reproduce, just add the needed components and you
This is a simple ECS which I changed for MASON. Some work was needed to
integrate it into the schedule.
On 29.06.2015 03:23, Russell Thomas wrote:
> Is anyone using the “Factory” design pattern to construct agents at run
> time? I am about halfway down this path and I’d love to learn from
> anyone else who has experience with this approach. (See “Difficulties”
> The setting is modeling teams and organizations engaged in design (of
> artificial products), innovation (in how they do design), and
> qualitative learning (i.e. learning new skills, not just getting better
> at existing skills). In other words, I’m modeling endogenous innovation
> involving genuine novelty. My agents are (somewhat) cognitive and
> adaptive, particularly in their ability to acquire or develop novel
> capabilities during the course of a simulation run. Also I’d like to
> experiment with a wide variety of initial conditions regarding agent
> types and capabilities. In essence, what I’m looking for is agents that
> are dynamic bundles of capabilities (i.e. resources, action rules, etc.)
> rather than fixed capabilities as is the norm in most ABMs.
> These requirements suggest the use of a “Factory” design pattern (see
> https://en.wikipedia.org/wiki/Factory_method_pattern for general
> During start( ), the /AgentFactory /is an object that takes as input
> specifications for the agents (i.e. list of capabilities) and also other
> key objects (i.e. environment objects such as /SimState/). The
> /AgentFactory /class includes various pre-built templates and objects to
> produce an agent object of the specified type. (I have a large library
> of capability and processing objects.) Actions to be performed by agent
> at each time step is specified by a special-purpose language that
> describe sequences of tasks and their interdependencies. (Execution is
> by a simple O-O stack machine.) Each task execution records its
> results, and these results can be concatenated and logged in a file.
> Essentially, agents can “explain” what they did and why each step.
> This is useful for both debugging and also as experimental results.
> Clearly, this approach does not result in fast execution and would not
> be suitable for a large population of agents and long simulation runs.
> My simulations will involve tens or at most a hundred agents, so it
> won’t be a problem for me.
> Where I’m running into difficulty is in *software design decisions*: 1)
> how general-purpose to make the code, and 2) how to avoid unnecessary
> complications. The advantage of making it fully general-purpose is that
> it will (later) reduce the design and debug time for specific ABM
> designs. The disadvantage is that it takes more time now for thinking,
> planning, coding, and testing (e.g. debug capabilities for the
> special-purpose stack machine).
> In pursuit of general functionality, I am probably making the software
> design too complicated. It would be nice to see what other people have
> done and maybe learn from their experience.
> Also, I want to use built-in capabilities of Java and also available
> Java libraries. For example, when I get to the point where agent
> specifications will come from a text file, I’ll probably use ANTLR to
> parse my special-purpose task language. But I might be unknowingly
> “recreating the wheel” in many cases by creating my own classes for
> various low-level functions.
> Russell Thomas
> Computational Social Science
> George Mason University