militaryzoologistAI and Robotics

Dec 1, 2013 (3 years and 4 months ago)



Project manager

Andreas Nilsson (apn2107)

Language and tools guru

Suhan Canaran (sc3055)

System architect

Akshat Sikarwar (as3515)

System integrator

Eric Schmidt (eds2103)

Tester and validator

Aaradhi Tilva (at2577)


A cellular autom
aton is a mathematical model that consists of a grid of cells,
where each cell can be in any of set of states, with an initial configuration specifying the
initial state of each cell, and a set of rules that are applied to each cell in the grid to
e its state in the next time
step of the automaton. British mathematician John
Conway’s “Game of Life” is a cellular automaton with two states, “alive” or “dead,” and
three rules:

1. If alive and have fewer than two live neighbors, die (as if by loneline

2. If alive and have more than three live neighbors, die (as if by overcrowding)

3. If dead and have exactly three live neighbors, become alive

This is the most famous cellular automaton. We believe cellular automata may be useful
tools for modeling

a variety of phenomena, as the game of life suggests they are, and so
we would like to make it easy to construct and visualize them. Our programming
language aspires to make it very easy to describe and visualize a diverse set of automata,
especially auto
mata like the game of life, which have English interpretations.

Design Goals


Since our language is already restricted to the limited application domain
of constructing cellular automata, we would like it to be very expressive. The
user sho
uld be able to construct anything he can think of that could reasonably be
thought of as a cellular automaton.


Again, since the language has only one job, it should be designed to be
very good at it. Thus, another design goal is to make it ve
ry easy to describe the
wide variety of automata that can be described in our language.


So that others may easily interpret the described automata in a natural
language way, the language should be as human
readable as possible. This will
nclude the labeling of states and rules with strings.

Main features

EXGOL describes simulations and can as such be classified as a declarative
language. The character set will be standard ASCII. EXGOL will use Lex
like '%%' to
divide programs into three


1. Specif
ication of parameters
(e.g. allowable states, number of dimensions)

2. Specification of rules

3. Specific
ation of initial configuration
and output

will only support one data type, “

which describes a transition from one
to another. See examples DIE and BREED below. Comments are supported using

” at

the beginning of lin
es. Assignments are done using “:=”
. In the transition rules we
will support relative operators such as =, <, >, <=, =>, &&, ||. We will have a number of
reserved keywords, both for simulation initialization and as help to specify transition
rules. In the program listing below we use the keyword peers to represent the number of
neighbors of the same class. Many of the parameters such as grid, grid_type and
transition_resolution will be optional and have default values.

In addition to specifying an automaton, the user will be able
to specify aspects of
its output as well.

The language will allow the user to write the output to a file as text,
with a variety
of options related to that output. Alternatively, the user may choose a
visualization of the output, and specify parameters
of the visualization
including speed
and zoom. “Stretch” goals
support for the visualization of more than 2
ability to write the visualization, or certain snapshots of it, to a file or set
of files; a graphical “initial configuration” editor where the user can use a pencil and
palette to color the cells with any of the automaton’s states; and having the visualiz
displayed in a visualization controller that allows the user to dynamically step forward or
backward in the automaton, and change the speed and zoom, as the visualization

Conway's Game of Life in EXGOL alpha 0.1

# Initialize simulation

class := {black}

state := {empty, occupied}

grid := [20 x 20]

grid_type := BOUNDED

transition_resolution := HIGHEST

# Declaration of transition types

trans DIE := occupied
> empty

trans BREED := empty
> occupied


# specify transi
tion rules

transition LONELY: (DIE, peers < 2, 1)

transition OVERPOPL: (DIE, peers > 3, 1)

transition BIRTH: (BREED, peers >= 2 && peers <= 3, 1)


# populate the grid

populate(black, random, 0.1)

# start simulation using a chosen number of trans
ition rules


Extended Game of Life in EXGOL alpha 0.1

# Initialize simulation parameters

class := {bacteria, virus}

state := {empty, occupied}

trans DIE := occupied
> empty

trans BREED := empty
> occupied



note that we changed probabilities and added the number of enemy neighbors into the

# Overpopulation is good in times of war.

transition LONELY: (DIE, peers < 2, 1)

transition KILLED: (DIE, enemies > peers, 0.5)

transition BIRTH: (BREED, peers

>= 2 && peers <= 3 && enemies < 1, 1)


populate(bacteria, square, 2, 2, 5)

populate(virus, circle, 10, 10, 5)