Ideally, a modeller would have comprehensive practical experience in a range of modelling/simulation (s/m) systems before choosing which system to use for a specific task. Unfortunately, this is not usually feasible. For this reason several authors (Najlis et al., 2001; Serenko and Detlor, 2002; Tobias and Hofmann, 2004; Rixon et al., 2005; Roberson, 2005; Dugdale, 2006) have surveyed several systems, identifying key criteria that should be considered before making a decision.

General criteria include, but are not limited to:

·         ease of developing the model/using the system

·         size of the community using the system

·         availability of help or support (most probably from the user community)

·         size of the community familiar with the programming language in which the system is implemented (if a programming language is necessary to implement the model)

·         is the system still maintained and/or updated?

·         availability of demonstration or template models

·         availability of technical details and ‘how-to’ documentation, etc.

Criteria relating specifically to a system’s modelling functionality include:

·         number of agents that can be modelled

·         degree of interaction between agents

·         ability to represent multiple organisational/hierarchical levels of agents

·         variety of model environments available (network, raster, and vector); possible topological relationship between agents

·         management of spatial relationships between agents, and agents with their environment

·         mechanisms for scheduling and sequencing events, etc.

These criteria will be weighted differently depending on a modeller’s personal preferences and abilities (e.g. the specification of the model to be developed, programming experience/knowledge, etc.)

Another important distinction separating s/m systems is their licensing policy: viz. whether they are open source, shareware/freeware, or proprietary. Open source s/m systems constitute toolkits or software whose source code is published and made available to the public, enabling anyone to copy, modify and redistribute the system without paying royalties or fees. A key advantage of open source s/m systems relates to the transparency of their inner workings. The user can explore the source code, permitting the modification, extension and correction of the system if necessary. This is particularly useful for verifying a model (see Section 8.2.12). The predominant open source s/m systems are toolkits (e.g. MASON, Repast, SWARM, etc.).

The distinction between an open source s/m system and a shareware/freeware system is subtle. There is no single accepted definition of the term shareware/freeware, but the expression is commonly used to describe a system that can be redistributed but not modified, primarily because the source code is unavailable. Consequently, shareware/ freeware systems (e.g. StarLogo, NetLogo, OBEUS, etc.) do not have the same flexibility, extendibility or potential for verification (access to their source code), as open source systems. Similarly, shareware/freeware systems tend to be toolkits, rather than software packages. Finally, proprietary s/m systems are available for developing agent-based models. Proprietary systems are mainly software, developed by an organisation who exercises control over its distribution and use; most require a licence at a financial cost to the user. These systems have the advantage of being professionally designed and built for a specific use, and are often relatively simple to use. However, they often lack the community support found with open source or shareware/freeware systems. Moreover, since access to their source code is prohibited, a model developed with proprietary software is essentially black box. A modeller may therefore be left unsure about the inner validity of a model constructed with a proprietary system. This situation is compounded when the output of a model is emergent or unexpected.

Striking a balance between the aforementioned criteria is difficult. Unfortunately, while identifying a suitable system for the development of an agent-based model, too much time can often be expended trying to find this balance. This can be perceived as a trade off between the difficulty of developing a model (e.g. in terms of time required to program the model, understand how to develop a model with a specific system, or acquiring experience and knowledge of a programming language if required, etc.), versus the modelling power provided by the s/m system (e.g. modelling capabilities and functionality). The key is striking a ‘personal’ balance between these criteria. For example, those more accustomed to programming may prefer the functionality and flexibility of an s/m toolkit. However, modellers that only wish to develop a basic or prototype model quickly and easily, possibly with little or no programming skills may prefer to use packaged s/m software.