Category : A Collection of Games for DOS and Windows
Archive   : BUGSIM2.ZIP
Filename : BUGS.DOC

Output of file : BUGS.DOC contained in archive : BUGSIM2.ZIP


(Carnivorous Mutating Tribbles From Hell)

Version 2.0
31 Jul 89

Alpha Chi Rho Programming Cooperative
1621 Tibbits Avenue
Troy, NY 12180

Software and Documentation Copyrights:
Version 0.8 - Copyright (C) 1989, Peter Oehler for ACRPC
Version 2.0 - Copyright (C) 1989, Shannon Posniewski for ACRPC


Bugs is an interactive graphic simulation of Darwinian evolution;
specifically through survival of the fittest. This program is
based on an idea presented in the May 1989 issue of Scientific
American in an article titled "Simulated Evolution: wherein bugs
learn to hunt bacteria", by A. K. Dewdney.

For bio majors:

In our scenario, the environment is a pond and living in the pond
are protozoa. The protozoa (usually called bugs) are block shaped
critters moving about the screen. Their purpose is simple: to
exist and to reproduce. They are out in search of food, bacteria,
in the form of blue dots scattered about the screen. Reproduction
is carried out in a somewhat strange fashion. The process might be
termed mutational mitosis, since two individuals are produced from
a single parent, where one is identical to the mother and the other
is similar, but differs slightly in its genetic makeup.

For Trekkies:

In our scenario, the environment is the grain storage area on
Starbase 5. Living in this grain storage bin, much to Captain
Kirk's chagrin, are tribbles. For our purposes, they are block
shaped critters of various color wandering around the screen.
Their purpose is three-fold: to exist, reproduce, and make a
science fiction television series. To do this, they are in search
of food, in particular quadro-triticale. The super-grain has been
dyed blue for ease of identification and is scattered about the
screen randomly. As Dr. McCoy noticed, reproduction is by
"mutational mitosis or somethin'" in these fuzzy creatures. As
Spock cogently explained later, two individual entities are
produced from one. The first is identical to the mother, whereas
the second is slightly different genetically.

As an aside, this is one reason we subtitled our program
Carnivorous Mutating Tribbles from Hell. Although tribbles are not
insects, they are referred to as "bugs" from here on.



The Programmers:

This "project" (some call it a fiasco) was started by Pete "the
Feet" Oehler when he decided that it was about time to see if the
stuff they publish in Scientific American was worth its salt.
Shannon "Poz" Posniewski happened upon the room as Pete was
finishing the basic program and, with the help of Dan "Frodo"
Wiesen, Iwan "Spokes" Axt, and Scott "Monkeyboy" Macneil came up
with and coded a veritable plethora of enhancements. (Cotton
candy, some called it.) Since it was a little too early to head
down to their favorite downtown watering hole, Holmes and Watson
Ltd. (simply "H&W's" to aficionados) they hammered out over 500
lines of not so spiffy code. (It did spiffy things, but it wasn't
pretty.) Over the next couple days, the menus and "zoom" code was
hammered out by Poz, Pete, and Frodo. This 800+ lines of much
sweeter code is what was released as Version 0.8.

Some thought this was to be the end of the story. Much to their
surprise (and disgust), Poz took the QuickBASIC program, casually
threw away the reams of code and began work on a Turbo C version.
The reason for the change in language (besides the obvious) was for
an increase in speed. If you have a pre-2.0 version and compare it
to this one you know what I mean. In any case, enough cotton candy
was added to make even the most iron-stomached 12 year old sick and
is now presented to you as Version 2.0. (Version 1.0 was a
short-lived Turbo C cut.)

Pete, Poz, Frodo, Spokes, and Scott are all members of the Delta
Phi Chapter of the Alpha Chi Rho Fraternity at Rensselaer
Polytechnic Institute in Troy, NY. The original version (0.8) was
written, unsurprisingly, during the two weeks prior to Finals week,
Spring 1989. The Turbo C version (2.0) was worked on from the week
after Finals until mid-June 1989.

The Program:

The original program represented over 100 man-hours of coding. It
was programmed in Microsoft QuickBASIC. "For God's sake, why?" you
ask. Well, it seems that BASIC was the only language that we all
knew fairly well (read: lowest common denominator.) The original
version was written and run on a DTK 286/10 AT compatible running
at 10 MHz with a Fountain EGA card and a NEC Multisync II monitor.

The Turbo C version (2.0) represents well over 400 man-hours of
coding. It takes full advantage of the Borland Graphic Interface
routines, which should allow the program to be run on any graphics
card supported by Borland's BGI. It was written on a Standard
(yes, that's a brand name) 286 AT compatible running at 8 MHz with
a Standard EGA card and a Samsung EGA monitor. It was tested on a
386 machine running at 16MHz with a Paradise VGA card. It is
reeeaaally fast on the 386.

The documentation was written using Enable, by The Software Group.


And Now, the Inevitable:

The authors would appreciate a donation of $15.00 so that they can
pay for more beer to program with. Make it payable to Pete Oehler
and send it to:

AXP Programming Cooperative
Attn: Pete Oehler
1621 Tibbits Avenue
Troy, NY 12180

With your magical donation, you will receive, free of charge, an
upgrade to the next version of BUGS, in-depth documentation, the
QuickBASIC source code, the Turbo C source code, the knowledge that
you have made an ethically correct decision, and last (but not
least) a registration number to disable the annoying reminder.

If you can't afford the $15.00 then either send us a six-pack of
Dos Equis, a job offer, or whatever other money you have in your
wallet. You are free to send us anything else you like. Depending
on how much we like what you send us, you may get the services
mentioned above (but don't count on it).

By the way, this program is yours only on an "as-is" basis. There
are NO warranties.

That means:
1. If it doesn't work, tough.
2. If you lose money because of this program, tough.
3. If you have any other damages (including, but not
limited to, brain damage, loss of eyesight,
marital difficulties, catastrophic motherboard failure,
etc.) because of this program, tough.
4. If you don't like any of the above, tough.
5. Have a nice day.

But you should know this, since every piece of software you own has
this same statement on it. (Usually in some 3 point typeface and
filled with words seemingly CAPITALIZED randomly, ranting about
LIMITED warranties and that you LOSE if ANYTHING goes wrong. Some
SOFTWARE companies EVEN charge for BACKUPS, which can only be made
TOOTH FAIRY). In ANY case, BELIEVE me that all those AGREEMENTS
add up to the above, except that they may have a 90 DAY WARRANTY on
the DISKS.)



The bugs are very active during each cycle. They decide which
direction to move, move that direction, expend one unit of energy
and age by one unit. In addition to these mundane activities,
several conditions are checked.

Chow time:

If the bug has come upon a bacterium (food, quadro-triticale.), it
is consumed and the bug gains the associated energy times an
efficiency factor that decreases with age.

Just like taxes or pushing up the daisies:

If the bug's energy has fallen to zero the bug dies of starvation.
If the option for death by old age has been enabled, the bug's age
is checked against five times its spawning age. If the bug is
older, the bug dies and its body provides fertilizer for the

Like crazed weasels:

If a bug is mature (i.e., old enough to spawn) and has enough
energy to spawn, it will produce an offspring. One of the
offspring's movement genes may be altered (hence Carnivorous
MUTATING Tribbles From Hell) and up to two other genes may be
modified slightly. (Incidentally, the QuickBASIC version is
limited to 100 simultaneous bugs, if there are currently 100
survivors no spawning will occur until a bug dies. This problem
was remedied in the Turbo C version (2.0) where the number of bugs
is determined by the amount of free memory.)

Pigging out:

If a bug has eaten so much that its energy exceeds its obesity
factor, it explodes and provides more nutrients for the bugs.

Dog eat dog:

If a bug runs into another bug, a check is made to see if at least
one of them is in the predator phase. If this is the case, then a
conflict results. The victor is determined by which one has the
higher score as calculated by the formula age^2 * energy. If the
victor is a predator, it consumes the loser (hence CARNIVOROUS
Mutating Tribbles From Hell) and gains the associated energy. If
the victor is not a predator, it leaves the carcass for bacteria to
grow on.



Each bug has several attributes associated with it, that, in total,
constitute a unique individual. These characteristics are stored
in its genes. The genes are what determine how the bug is affected
by the environment.


The first six genes affect the bug's tendency to move in a
particular direction relative to its current position. Imagine
that there is a bug sitting on the documentation below. Before you
squash it, note that there are six directions which it can move.

Forward (G1)
(G6) Left | Right (G2)
\ /
\ * /
>-+-< Don't even THINK
>-+-< about laughing
/ >-+-< \ at the picture!
/ \
(G5) Hard Left | Hard Right (G3)
Backward (G4)

Each bug has a different propensity for moving in each of these
directions. This is represented by giving each direction a
"weighting", which corresponds to how often the bug will move that
direction. The higher the gene value, the higher the probability
the bug will move in the associated direction. The probability (P)
the bug will move forward, is calculated (obviously?) as follows:


(Which, through an unusual programming slight of hand, is
completely calculated as an integer.)

Terrible Teens:

The bugs pass through a stage of development where they will attack
and eat other bugs. The onset of this stage is determined by a
gene referred to as Young Predator age and terminated at the value
of Old Predator. A bug in this stage is still capable of eating
the vegetable matter on the screen. (Perhaps Young Omnivore might
have been more accurate.)


Spawn Age is the age (in cycles) at which a bug reaches maturity
and may reproduce. It may seem desirable to put this very low so
as to get lots of generations in a short time. However, keep in
mind three things: (1) If they reproduce too quickly, natural
selection may not take effect; (2) they have no energy stored in
case food levels drop and (3) with Death by Old Age enabled they
will die at five times their Spawn Age.



Spawn Energy is the minimum energy the bug needs to have in order
to reproduce. If a bug is of spawn age and its energy exceeds this
value, it will divide. This will effectively divide the bug's
energy by two, so a low spawn energy could be dangerous during
times of drought or famine.


Obesity is the maximum amount of energy a bug may metabolize before
it explodes in a shower of protoplasm. The original reason for
this gene was to keep bug energies from exceeding the variable size
we were using (the classic 32767 limit). The idea grew on us,
however, and we therefore kept it in the new version. Besides,
Frodo whined and argued arduously to keep his explosion routine, of
which he is quite fond. (Little did he know that it was scrapped
in the Turbo C version due to lack of time (and want) to

We've got Big Bugs:

There is also an option for bug Size. This value is the number of
pixels to the side of a bug. (Normally, the size is three.) Being
big has the advantage of being able to pick up more food in each
step. (There was a planned tradeoff between size, metabolism rate,
and speed, but it hasn't been worked in... yet.) The biggest
problem with using the size gene is that is slows down the program
LOTS. (See The Flags Menu).



The program opens with a title screen (DA NA! ... Drink!). If you
wish, you can just watch the bugs on this screen to get a feel for
how they move around, and so forth. When you press a key the
actual program will begin.

In a hurry?

If you want to see how it works NOW, read on.

After pressing any key, select the Options menu, then select Fill
Screen. Type a small number like 5. After the screen fills,
choose Add Random. Type how many "families" you'd like to start
with. 5 is pretty good.

Now, press the mouse's right button (or ) once. At this
point, you can examine a particular bug by moving the pointer to it
and hitting the mouse's left button ( or ). Press
the right button (or ) to exit this examination screen.

Press the right button (or ) again to set the bugs moving.

Of Mice and BUGS:

Bugs is mouse driven (Microsoft compatible). Be sure the mouse
driver is installed, either in CONFIG.SYS or as some program run
before Bugs. It has been tested with a number of mice, including
Logitech, Microsoft, and Genius brands.

If there is no mouse present, Bugs will emulate one for you. The
cursor keypad will be taken over by the KeyMouse routines. The
arrows move the cursor in the specified direction, and the diagonal
keys (Home, End, etc.) move diagonally.

The amount the cursor moves at each keypress can be changed using
the "+" and "-" keys (usually found conveniently on the keypad).
The "+" increases step size whereas the "-" decreases step size.

When the cursor is active, the (or ) key (also on
most keypads) is mapped to the left button, the right button being
the key.

Throughout the program, the left button chooses an option or is
used to point something out. The right button serves as an
"Escape" or "Back up" function, allowing you to back out of a menu
or option.

Soup du Jour:

The program is menu driven, meaning that the vast majority of
options are available through the menu. To access the menu while
bugs are roaming around the screen, press and hold the mouse's left
button until the stop moving (or press once) and the top
line is replaced by the menu.


To choose an option, move the cursor to the text of the option and
click the left button (or ). The execution of the menus and
the options therein should be fairly intuitive. Additionally,
typing the capital letter found in the option will choose that

If you are several levels deep in menus and wish to back out, click
the right button (or hit ). Each click will back out one

A toggle option is On when the circle before it is filled.

Other (Hidden) functions:

There are several keys defined at all times:

F1 - Toggles between the Trace/Graph screen and the Main screen.
F2 - Toggles the "Zooming" boxes when an event occurs.
F3 - Toggles "Flicker" mode. This mode automatically switches
between the Trace and Main screens. When less than 10 bugs
are on the screen, this gives a nice effect.
S - Saves your Flag changes in a Configuration File. (BUGS.CFG)
This file is automatically searched for and read when the
program is run.



The Main Menu:

This is the menu across the top of the screen.

If you are at the main menu and click the right button, the bugs
will become active again.

Clicking on any of the options will bring up the corresponding

When the main menu is active (and no others) you can examine a bug
by moving the cursor to it and clicking. (See The Doctor's

The Action Menu:

This menu has no real point as of yet. Your options are:

Stop - Stop the passage of time.
Go - Start the passage of time.
Quit - Quit the program.

You might be asking yourself, "But the bugs stop when the menu is
active anyway. What's the point?" The point, Virginia, is that I
would like (at some time in the infinitely far-off future, in a
land where humankind's quest for the meaning of life has just
been completed because we have finally... oops, got sidetracked.
Sorry.) to modify the program to allow the cursor to move around
while the program is running. (Like a Mac). (The mind boggles...)

If you choose Stop and exit from the main menu, you'll notice that
the bugs don't move. The function works, but there's no point to
it (yet).

Quit is identical to the Quit on the main menu.

The Flags Menu:

This menu allows you to configure Bugs the way you like it. Your
options are:

Death by Old Age - Shut this off for immortal bugs.
Non-Predators - Shut this off if a non-predator can collect the
energy of a predator that it killed.
Size - Turn this on if you want size to be an active
Obesity - Turn this off if you like big bugs.
Predator - If this is off, there is no predator phase.
Spawning - If this is off, all bugs have the same spawn age
(1500) and spawn energy (1000).
Debug - This will put leftover debug code into the
program. USE AT OWN RISK.


Graphing active - When this function is active, the spawn age and
spawn energy is graphed on the alternate screen.
The bug's family color is plotted at each
vertex. Spawn age is in red, Spawn energy in
yellow. Also, it will ask for a file name when
activated. If entered, this file will hold the
gene data for each bug born. (See Appendix A).
If this option is off, the trace screen can be

The Options Menu:

The bugs' lives are controlled through this menu. Your options:

add and Modify - This option will create a bug with random
attributes, but will automatically "throw-up"
the examine screen so you can change its
attributes to your liking.
Add random - This option will create a specified number of
bugs with random positions and gene values.
Kill bug - If you don't like a particular bug, you can
zorch the little guy.
Destroy all bugs - If something is wrong with a particular batch of
bugs, you can dispose of all of them. Sort of
like nuking the site from orbit, it's the only
way to be sure.
food Value - This option changes the amount of energy a bug
receives when it picks up a piece of food.
Refresh Rate - This option controls how many cycles the program
should wait before putting a new piece of food
on the screen.
Fill screen - The APPROXIMATE percentage of food (with
relation to empty space) is controlled here.

Some notes and ideas on food:

Pretty good values (found via painstaking and extensive
statistical analyses done on R.P.I.'s mainframe using the time
honored method of trial and error) for refresh rate, food value,
and screen percentages are (respectively) every 5 cycles, 20 units
per piece, and 5 percent.

If these values are too high, the bugs will spawn out of control,
filling the screen with hundreds of bugs, and slowing the computer
to a crawl. Like goldfish, do not overfeed.

Some notes and ideas about "Cities":

I have been able to get over 7000 bugs to live on my screen at
once. On the 286, it took 18 minutes to do a cycle. If each bug
starts with a minimum of 80 units of energy, about 1 day will
elapse before the first possible death, in which most kick off due
to starvation. Boring. (But still a heck of a lot more fun than
say, watching an LPGA tournament on TV. No letters for that
comment, please.)


Once you get more than a couple hundred on the screen, it slows
down a lot and doesn't really have any redeeming factor unless you
want to see if they build a thriving metropolis. (They won't.)

Also, I wouldn't suggest adding over 7000 bugs (on a 640K machine
with no TSRs) since it seems that a nasty (programming) bug is
creeping around when more than a certain amount of RAM is
allocated. You are free to try it if you like rebooting after a 20
minute period of watching colored specks appear on the screen.

Try turning on debug mode before adding lots of bugs randomly.

The Display Menu:

This menu controls the Trace screen, the Graph screen, and the
color of the bugs.

Color by Generation - Initially, the bugs are assigned a color
according to their "family". (i.e. All bugs
that are related are the same color.) When
this option is turned on, the bugs are
colored by generation. (i.e. All bugs that
are in the same generation are the same
Trace/Graph Options - Calls up the Trace or Graph menu.
Garden of Eden - Calls up the Garden of Eden menu.

Notes on Colors:

The colors (for the sake of programming convenience) are as

color gen color gen

Black 0 - DkGray 8 7
Blue 1 - LtBlue 9 8
Green 2 1 LtGreen 10 9
Cyan 3 2 LtCyan 11 10
Red 4 3 LtRed 12 11
Magenta 5 4 LtMagenta 13 12
Brown 6 5 Yellow 14 13
LtGray 7 6 White 15 14

Black (0) and Blue (1) are reserved for the background and the

Here's how to use the list:

If the bugs are colored by generation, and you see this healthy
looking brown bug scurrying around, you can say he is from the 5th

"Aha," you say, "but what about generations (and families) over
14?" Well, since the EGA only has these colors, I had to wrap them
around. Technically, brown could be generations 5, 19, 33, etc.
If you have a VGA, these colors may go higher (I dunno). On a CGA,
definitely lower.


The screen is used as a storage device, so this program mandates
the use of a graphics card which supports color. Your monitor can
be black and white, but the card must support color. Sorry
Hercules and compatibles. Also, I wouldn't suggest using a CGA
graphics card.

The Trace/Graph Menu:

These menus actually are the same functionally, but the text is
different. They control the second page, where the trace and graph
screens are kept. Your options:

Trace (Graph) screen active - When this option is shut off, the
trace or graph screen isn't updated,
speeding execution time slightly.
Clear Trace (Graph) screen - This erases the trace or graph screen
so that you can start with a fresh
slate. It's good after the trace
screen has been active for a while
and has filled with a lot of garbage.

Notes on Trace and Graph:

Trace originated accidentally when the program had a bug and didn't
erase the previous bug position. What we found was that the way
the bug moves (its style, if you will) was much easier to see
graphically than looking at its movement genes. The most efficient
and hence longest living bugs are those that cover the most area
with the least waste. (This, however, is NOT true when the playing
field is not more-or-less uniformly distributed. i.e. a couple
thousand cycles into the simulation. (Why?))

In the same vein, the graphing option was added so that genes that
are difficult to perceive over time can easily be watched.
Additionally, the logging option (which is activated when a
filename is entered when graphing is originally turned on) allows a
separate program to examine the data after the run. I have had
limited success using Reflex (also by Borland) examining this data.
A separate program could easily be written to do all sorts of neato
things to the gene information.

The Garden of Eden Menu:

The Garden of Eden is an optional area of the environment, where
the food refresh rate may be very much different. You can define
where and how much food to add. The options are:

Set garden boundaries - After selecting this option, you must
specify where the Garden will be, either by
clicking the mouse and dragging, or by
indicating two corners with the arrow keys
and .


Refresh Rate X at Y - The "X at Y" stands for X pieces of food
every Y cycles. This allows you to add a
lot more than one piece of food a cycle
(the limit for normal screen refresh).
When selected, you will be prompted for the
two values. Hit return to accept the
current value, or type in your change.

The Quit Menu:

This exits the program after asking if you are sure.

Status Quo:

The status line at the top of the screen is updated every 100
cycles. If the right button is pressed during the simulation, it
is updated every cycle (and slows the simulation down to a CRAWL).

The Doctor's Office:

When the main menu is active and you choose a bug with the cursor,
a box is brought up so that you may examine and modify the bug's
genes. This option allows you the chance to play God, or the
supreme being of your choice, by trying your hand at genetic

Nurse, Scalpel...

To change a particular gene, click on the number you wish to
change, a box will appear with the previous value in it. To accept
this value, hit , otherwise, type the new value and hit

You may change any value below the "Genes" line and the Coordinates
of the bug. To change the bug's position, click on the
"Coordinates" line and then click to the point on the screen where
you want the bug to be.

Unnecessary Surgery:

It's up to you decide whether or not it's "ethical" to play with
the lives (albeit simple lives) of the bugs. We use this option
to play a game. Each person is allowed to modify one bug as he
or she deems fit at the beginning of the simulation. Once the
simulation starts, each is forbidden to change the bugs. The
player who's bug survives the longest wins.



Adding Bugs
Add and Modify 10
Add Random 10
Alpha Chi Rho 2
Beer 3
Bio majors 1
Brain damage 3
Display modes 12
Maximum number of bugs 4
Clear Trace or Graph screen 12
In general 11
Color by Generation 11
Configuration 8
Cotton candy 2
Debug 9, 11
Dewdney 1
Directions 5
Doctor's Office 13
Dos Equis 3
Escape or Back up 7
Examining bugs 9, 13
Modifying bugs 13
Fill screen 10
Food Chow time 4
Food Value 10
Refresh Rate 10
Flags Menu 9
Saving 8
Game 13
Garden of Eden
In general 11
Set garden boundaries 12
Refresh Rate 13
In general 5
Directional 5
Obesity 4, 6, 9
Old Predator 5
Size 6, 9
Spawn Age 5
Spawn Energy 6
Young Predator 5
In general 10
Options 11
Have a nice day 3
In a hurry? 7
KeyMouse 7
Killing Bugs
Death by old age 4, 9
Destroy all bugs 10


Exploding 4
Kill bug 10
Obesity 4, 6, 9
Predator Phase 4
Starvation 4
Action Menu 9
Display Menu 11
Flags Menu 9
Garden of Eden Menu 12
Main Menu 9
Options Menu 10
Trace/Graph Menu 12
Quit Menu 13
Motion 5
In general 7
KeyMouse 7
Left Button 7
Right Button 7
Mutational Mitosis 1
Non-Predators 9
Obesity 4, 6, 9
Old Age, Death by 4, 9
Overview 1
Predator Phase
In general 4
Non-Predators 9
Probability 5
Protozoa 1
Quadro-triticale 1
Quit 9, 13
Refresh Rate
Screen 10
Garden of Eden 13
Registration 3
Santa Claus 3
Scientific American 1
Size 6, 9
In general 3, 9
Age 5
Energy 6
Starvation 4
Status Line 13
Toggling Options 8
Trace Options 11
Trekkies 1
Tribbles 1
0.8 2
2.0 2



  3 Responses to “Category : A Collection of Games for DOS and Windows
Archive   : BUGSIM2.ZIP
Filename : BUGS.DOC

  1. Very nice! Thank you for this wonderful archive. I wonder why I found it only now. Long live the BBS file archives!

  2. This is so awesome! 😀 I’d be cool if you could download an entire archive of this at once, though.

  3. But one thing that puzzles me is the “mtswslnkmcjklsdlsbdmMICROSOFT” string. There is an article about it here. It is definitely worth a read: