(1) Feedback from users, and,
(2) A personal desire to make the Simulation more programmable.
To date the Simulation has been programmable through two very different means. The first has been through getting the Simulation source code, making modifications and re-compiling the source code. There are rough numbers on the source code downloads that indicates only a fractional percentage of users download the source code. A release, when left for a month, will get about 3,000 downloads for the Macintosh. From this, less than 20 downloads of the source code occur. From that group roughly an email every two months comes in relating to the source code.
The other method of programming the Simulation is through the file format. To date, I have not received an email about the file format. The file format was launched with the Carbon version with a minor bug in the file saving. More than 2,000 people downloaded this version and none reported a problem with the file format. I suspect this was a feature that just wasn't used.
So this begs the question, why add an additional interface to the Simulation that people won't use?
Scripting has actually been a request for the Simulation through a post on download sites. Independently of this, I have also been thinking about scripting the Simulation as a means to solve the Planet Noble Ape as a module of the Noble Ape Simulation problem.
A function-pointer/plugin module required the user to create their own plugins through a C or similar language plugin interface, compile this and then run this on a compatible system. This seemed to play back to the idea of elite users and a large user base that didn't or couldn't get access to the tools required to make an environment.
Breaking this analysis down into haves and have nots, made it clear that the Simulation could be considerably more accessible if it didn't rely exclusively on traditional compiler development.
If the Simulation had one strength, it was its size. A large part of this optimisation had come through extensive code-review and re-writing know as the Stockholm Rewrite, because of where it took place. The Stockholm Rewrite had reduced the code-base by 40% which had reflected directly in the size of the Simulation. Part of this rewrite - in code reduction terms - came in reducing the number of functions used in the Simulation. The introduction of a three-layer maximum in any direction, meant the Simulation rarely had functions, in functions, in functions.
The file format in coreio.c could have been XML. Historically it wasn't XML because the XML parser would have been slightly larger to write and the syntax whilst being of a similar level of detailed required notions of completeness that the Noble Ape file format avoided.
The limits to the file format were;
(1) two entities, variables and objects,
(2) three letter identification for variables and objects,
(3) only numerical, positive integer variables, and,
(4) a relatively strict structure.
(1) and (3) were historical anomalies, not part of the original format. In fact (3) was not part of the original format because signed integer values were used. Yet (2) and (4) were definitely there from the start.
So the scripting would utilise the existing file format both through the actual file scripting and through the scripting window.
A central remit of the Simulation mentioned already in this document is size. The Simulation is not like a word processor or a web browser or most standard feature requiring software. The additional features for the Simulation, things like colour, Ocelot, full operating system integration. These things should come with virtually zero code increase. The largest increase in the development of the Simulation has come through the new file format in 2001. It added about 8-10k to the Simulation. This has been reduced progressively. but it was a sizeable addition. Removing audio from the Simulation reduced its size dramatically too. From the princely size of roughly 100k with audio it fell to 32k without.
From this, an additional window must reuse a substantial component of the existing code. Fortunately the scripting window does this. The basics of console text drawing exist. Monochrome windows and event driven window updates, the Simulation already handles. So with the window and the background aside. What is the scripting language all about?
(1) the Simulation is paused,
(2) all the Apes die,
(3) the Simulation advances 102 days,
(4) the Simulation reaches the first day of the fourth year of Simulation,
(5) an Ape reaches a particular point on the Island,
(6) an Ape is drowning, or,
(7) run the Simulation indefinitely.
Another important point is file I/O. The scripting needs to include some functionality to read and write files and to load files through open/save dialogs if need-be. Automated scripting and running additional files following a currently executed file should also be available through scripting.
Whether the ape's brain is simulated
If the land values are rendered with 16-bit integers or floating point
Number of apes in the Simulation
The graphical environment of the Simulation (Ocelot or monochrome)
In addition to these features the brain dynamics have been hard-coded into the Simulation. These will be opened as variables for each ape to allow an added diversity and degree of control. Although this may appear quite academic the ape's personalities can be developed from the brain characteristics. Six values will initially be converted to variables. These govern the asleep and awake states and the competing ideas of fear and desire represented in the brain equations.
The development of this kind of scripting relies on the success of the initial scripting implementation. As this document is only an introduction it is difficult to predict the optimisation and discovery that will come through the initial scripting implementation.
User feedback plays some part with the scripting progression. Scripting will be a passive/background feature in the graphical version of the Simulation, however it will be central for the command-line environment (CLE) version of the Simulation.
Tom Barbalet, 29 June 2003.