<?xml version="1.0" standalone="yes"?>
<Paper uid="P98-2137">
  <Title>Babel: A testbed for research in origins of language</Title>
  <Section position="3" start_page="0" end_page="830" type="intro">
    <SectionTitle>
2 Requirements
</SectionTitle>
    <Paragraph position="0"> Our approach to studying language is based on multi-agent simulations. Mainstream research on multi-agent systems has given rise to a number of environments and programming  languages for building simulations (consider, for example, SWARM (Minaret al., 1996), GAEA (Nakashima et al., 1996), or AKL (Carlson et al., 1994)), but none of these systems have been designed for specifically linguistic experimentation. Moreover, we wanted to work within the paradigm proposed by Steels (Steels, 1996), where language-using agents construct a shared language through repeated interactions with a precise structure. Examples of such games include naming games, in which agents take turns naming and learning the names of objects in their simulated environment, imitation games in which one agent attempts to meaningfully imitate a linguistic form presented by another, and discrimination games, in which agents attempt to build a system that allows them to discern distinctions between objects in the environment. The tool needed to provide a library of re-usable building blocks with which we could describe the formal structure of these games, represent the principal elements of the simulated environment, and develop models of the agents' memories and learning processes. Moreover, it was important that it should be open-ended, so that we would be able to use pre-defined elements to rapidly build new simulations based on new game types or agent properties.</Paragraph>
    <Paragraph position="1"> In addition to providing building blocks for simulation development, the system must offer an interface for controlling the simulations. This interface should allow users to launch simulations, to modify the environment by adding or removing agents, to change experimental parameters and so forth. To simplify the task of porting the tool and to protect simulation developers from the intricacies of user interface programming, we also wanted to isolate the interface code as much as possible from the code defining the (portable) core of the system and from code written by experimenters.</Paragraph>
    <Paragraph position="2"> Lastly, the tool was required to provide ways in which the data generated by simulations could be visualized. One of the challenges in this type of simulation, particularly where multiple agents are involved, is in getting an impression of the changes that are taking place. We wanted something that could let us 'look inside' our simulations as they ran and try to get an idea of what was actually happening. It should also, of course, provide the means to export the data for subsequent analysis or presentation.</Paragraph>
    <Paragraph position="3"> In summary, the system needed to offer an extensible set of building blocks for simulation development, tools for controlling the simulations, and tools for visualizing the progress of simulations. In the next section we will look at the approach taken to meeting these needs.</Paragraph>
  </Section>
class="xml-element"></Paper>