AK Dewdney
This particular implementation is based on a similar program first written by Michael Palmiter, Temple City, CA., as described by the article “Simulated Evolution: wherein bugs learn to hunt bacteria by A.K. Dewdney ” in Scientific American (Computer Recreations), May 1989.
Turbo Pascal 5.5
John R. Nash of Scottsdale, Arizona began working on this project in 1990. The program is written in Borland Turbo Pascal 5.5 which is now freely available (ironically, as “Antique Software”).
The bugs are stored in a circular double-linked list. The bugs and bacteria are stored directly in VGA video memory and when a bug checks for bacteria the program has to access each pixel of video memory surrounding a bug. This means that the program is video intensive and its performance will vary depending on the type of bus your video card is on (i.e. PCI vs. ISA). The advantage to this is that the user sees everything that happens because it happens in video memory.
After watching the simulation for any period of time the user will notice that the simulation seems to speed up when the bug population drops and slow down when it increases. The reason is that the computer has to do more work per turn (one turn being the time to move each bug) when there are more bugs. The bugs of course are oblivious to real time as long the food is placed on the screen according to bug moves and not real time.
The user might have also noticed that the graph will speed up or slow down depending on how fast bug time is moving. This is because the graph is being updated every 50 bug moves. I tried updating it by real time but the graph got skewed as the bugs moved faster, the graph rate stayed constant and the rise of bacteria was much more pronounced than the fall. The logging file however is updated according to real time. This might seem like a discrepancy but the logging interval is usually much longer than the graph update interval so I don’t think the skew is be statistically significant.
Population Graph
This program was implemented with a language that did not include a library or framework for a graphical user interface (window-based or otherwise). As such, all interaction with the user had to be explicitly captured and processed and if a key sequence was not completed in a timely manor, generate a timeout and return the simulation to its default state. This effort strongly reinforced the quantum leap in ease of programming represented by development tools which handle the complexity of user interface logic inside the framework (Win32 Software Development Kit (SDK) introduced in 1991) so the programmer didn’t have to which allows them to concentrate on the conceptual aspects of the program rather than the tedious aspects of I/O. Since then, there are many frameworks with even easier implementation models such as server side scripting languages with strong support of HTML and XML (PHP, Ruby for Rails & Java for example). With the larger frameworks and more feature rich user interfaces comes a performance penalty however so a MS-DOS implementation, such as this, delivers maximum performance.
Future development goals included a distributed simulation grid such that bugs leaving the edge of the screen travel over a network (TCP sockets) and appear on a “virtually adjacent” computer thereby forming a multi-system simulation grid which can expand the simulation size and overall performance. As Turbo Pascal 5.5 does not have a native TCP/IP socket library, this would have required a re-implementation in later generation language or linking to a 3rd party library or writing one in assembler.
