- How will the simulator work?
Initially the simulator will read in files representing the two ants (red
ant and black ant) and the ant world. Your simulator should populate the
red ant hill with red ants and the black ant hill with black ants. (see
section 2.12 of specification for rules on how to start the simulator).
Once all initializations have been made the
simulator will start processing ants
in rounds. Whenever an ant is processed (the step function for each ant is
called), the simulator will take some action corresponding to its state. In
a single round all the ants will be processed sequentially in ascending
order. The game is played for 100,000 such rounds.
- How will the command-line based simulator work?
The simulator will work in two modes. In the regular mode it will just
simulate 100,000 rounds and then print the results.
In the debug mode it will print traces of its actions to stderr. See
further details at:
- Do the students have to make their own world, or are they given its
No, students do not have to make their own world files. A
collection of random worlds satisfying the specifications can be found
"http://icfpcontest.org/worlds/" or local copies can be found in
For JUnit testing, you might want to define some very small worlds yourself
- Do the students have to consider extensibility of the design?
Yes, it is always advisable to consider extensibility of the design. It is
all the more relevant in your case as initially a command-line version
is required that will be enhanced with a GUI in later phases.
- Are the students allowed to use random number generator from Java?
To match the trace output given by the contest you must implement a
random number generator as given in section 2.10 of the specifications.
However, to make things easier, you may use the random number generator
provided in Java, and we will provide you with a trace file using the Java
generator with a seed of 12345.
- Are the students required to build a Compiler from high-level language
to finite-state-machines? -OR- a Compiler for language that builds
into ant instructions?
In phase #1 of the project you are just building a simulator that will have
to parse the ant specifications and store the specification in a suitable
internal form. The simulator is really like an interpreter which keeps
the state of the world and the state of each ant. On each round the
state of each ant is updated according the ant specification.
Later on, in phase #5 you are asked to develop your own ant. You may write
this ant directly in the ant language given in the project specification (which
may be painful) or you may build some tools (like a small compiler) that
translates from another high-level ant specification.
It is this last
phase where you can chose to do something simple (use existing tools from
ICFP contest winners to generate an ant, modify an existing ant) or
something more complex (define your own ant language and a translator from
your new, higher-level language to the state-based ant language understood
by the simulator). If you use existing tools or existing ants then you
must clearly document what you used, and show that you understand how
they work and what you have changed.
Of course, more sophisticated solutions will receive more marks. You
may start to work on phase #5 as soon as you have a running simulator.
- What is the total number of states for ants?
Ants can have maximum
of 10000 states (numbered 0 to 9999).
It depends on your design/strategy as to how many
states you use for your ant. A simple ant described in section
1.0 of specifications just had 16 states. Another sample ant file is
You may also find other example ants on the ICFP winners' web sites,
- Why are the ants referred to as finite-state-machines?
Ants are bound
to follow a finite number of rules given in the input files. Each line
of the input specification corresponds to what the ant can do if
it in that state. The first line corresponds to state 0, the second line
to state 1, and so on. If the ant is in
state x, then it applies the rule for state x and then goes to
a new state (as specified by the rule). Thus, each instance of an
ant can be summarized by its current state.
Initially all ants are at state 0.
When simulator has to take an action for an ant it knows where the
ant is on the board and can test and set various things about the
(as specified in the ant language). Thus, the action the ant takes will
be based on the ant's state and the state of the board. This action will
result in changes to the board and an updated state for the ant.
Further detail is available in section 1.0 of specifications document.