BUGBURST
by Colin Hogg & Dave Rogers
from Your Computer Oct'84

WE CALLED THIS GAME Bugburst because the bugs all originate from a
point in the middle of the screen, from where they appear to burst
forth in increasingly annoying numbers throughout the game.

Speed is maintained with machine code and there is a total of 15
different screens. These are produced by multiplying small seed
strings up into full-screen-sized-lumps, thereby achieving great
compression and reducing the program length and hence the typing
effort. The common objective to all the screens is to get rid of or
paint over anything that is seen to be flashing by guiding your man
across it.

There are, of course, many obstacles to make this task more
interesting! We feel that the game benefits from the same underlying
psychology that contributes to the evergreen appeal of Pac-Man, this
being the part of human nature that compels one to tidy things up,
whether by gobbling up dots or by filling- things-in to give a nice
even appearance.

The bugs are not guided towards the player, nor do they follow fixed
paths, but they do have certain habits which you may be able to detect
and pick up as you play, although even these vary between screens.

To facilitate the movement of many bugs by the machine code, a
direction table is used. This holds preset values which, when added to
a bugs present screen position, will move the bug in any of eight
directions. The values are as in table 1.

Table 1.

  -34 -33 -32
    \  |  /
      \|/
-1 <---+---> 1
      /|\
    /  |  \
   32  33  34

Each bug is well looked after, with its own personal store which
includes a pointer to keep track of its present position along the
direction table. After a certain number of bug moves in a given
direction this pointer gets shifted along the table by a random number
of steps thereby changing the bugs' direction - the shifts are modulo
eight i.e., a shift beyond position made before a bug's direction gets
changed is controllable from Basic. For example, on screen 8 it is set
to 99 and, since the screen width is far less than this, the bugs tend
to travel in straight lines and only change direction when they hit a
wall or another bug, whereas on screen [?] the bugs change direction
after only four moves and therefore show a more unpredictable
behaviour.

The limiting condition is reached on screen 7 where the bugs change
direction every time they move, so although they don't disperse quite
as quickly, they are highly dangerous to be anywhere near!

If, instead of being randomly stepped, the direction pointers are
scanned along the table in fixed steps, then synchronised movement
patterns can be produced for large numbers of bugs, and this fact is
made good use of in the intro-screen displays, or 'Bugdances' as we've
called them. These consist of 10 different pre- selected dances which
are normally displayed in sequence, but keys 0 to 9 let you watch any
particular one.

We found that the most organised-looking dances were produced when
both the "dance floor" and the number of bugs taking part were square
- by a square number we mean 4, 16, etc - and all bugs were started
off in the exact centre. Some of the patterns remain infinitely stable
and repeating, but others remain symmetrical only for a while and then
decay into apparent chaos - such is entropy.


Similar to barndances

Some are vaguely reminiscent of Barn- dances, while in dance number
two for some reason one bug gets thrown out of the main pattern and
circles dejectedly on its own in a corner! All this illustrates how
unexpectedly complex behaviours can evolve out of relatively simple
rules, in a similar - though infinitely less lengthy - way that
organisms have arisen from fundamental chemistry.

Addresses summary - or where things live in the program:
The Peeks, Pokes, Usr calls and other uses of memory in this program
fall into groups.
Spare memory locations being used as "variables" because the parameter
represented is used by both the Basic and the machine code: Being at a
fixed address allows easier access by the machine code rather than
having to search through for variables.

Parameter       Intermediate    Poked into
                Variable        address
---------       ------------    ----------
Flash
characters      F1/F2           16507/16508
No. of active
bugs            BN              16417
Bug turning
distance        BT              16703
Bug 'stopped'
character       BSK             16708
Chr$ replaced
after player    -               16438
Score ripple
count          (initialised by
                line 6050)      16439

Machine-code subroutines: The machine code starts at 16514 and ends at 16770.
USR 165514 Sets up all bugs at the start position, centre of screen.
USR 16721 screen - formats with leading zeros and also scans along the
word "score" to give ripple effect.
USR 16545 Main bug-move routines (a) Moves all active bugs once. Bugs
can move onto any characters except spaces (0) or inverses - greater
than 127. (b) Scans screen for characters "F1/F2" and swaps one for
the other to produce animation. If none of either character are found
then returns to Basic with '300' thereby routing the program to the
'cleared screen routine. (c) If any of the bugs has hit the player's
character, then returns to Basic with 600. (d) Otherwise returns to
line 10 to continue main loop.

Direction table: From 16771 to 16786. Sixteen bytes, holding eight
two-byte numbers.

Individual bugstores: From 16800 to 17000. Two hundred bytes,
consisting of 5 bytes of information on each of 40 bugs. Each store is
arranged in the order:- Move count - so as to know when to turn -
replacement Chr$, direction pointers, and finally, screen position - 2
byte number.
Information on one bug gets moved from its store onto a workspace
where the main bug- move routine operates on it, moves the bug, then
replaces the new values of bug position, etc, back into that bug's
store, ready for the next time it gets moved. This procedure is then
repeated for as many bugs as are active at the time.

Pokes to actually alter instructions within the machine code:
Poke 16712, 198         253
Poke 16713, 1 to 8      134
Poke 16714, 0           52
            For fixed   For pseudo-
            bugstep     random bugstep

ZX-81 System variables:
Peek 16396/7 Finds address of display file.
Poke 16418,0 Sets up 24-line screen.
Poke 16511/2 Turns the five short Rems initially typed-in into one
long Rem - to hold the machine code - by changing the "line length"
indicator bytes.
Poke 16510,0 Makes this line unerasable and secure.
Poke 16513,118 Prevents the unstoppable "endless-listing" crash that
afflicts the ZX-81 when the first Rem line is very long.

Checks: Peek 17038 checks that the first five Rems are of correct
overall length before the program attempts to poke things into them -
looks at where there should be a Newline character at the end of the
fifth Rem line. Peek 16799 Looks at the last byte where there should
be machine code, to see if it has all been Poked-in yet, if not then
Runs the hexloader - the latter may need to be Run several times so as
to uncover errors in the data.

Although this is an all-in-one listing that can simply be typed in and
Run, we cannot recommend too highly that you still work in stages, by
typing in say 50 lines then saving onto tape, type in the next 50,
save again without rewinding and so on. This way, if a mains supply
spike or other gremlin causes a crash you will always have the
previous stage available from tape, and will thereby avoid much
swearing, frustration and kicking-of- the-cat.

The Rems for the machine code must be entered by typing in line 1 plus
exactly 100 characters, then editing its line number to 2, 3, 4 and 5,
resulting in five identical lines.

All grey characters are Graphic-Shift-A. The one exception is line
1110 where the grey on key H is used.

Line 520 Inverse colon, greys.
Line 640 All graphic shift: 6,7,6,G,F,G,F,J, four inverse spaces.
Line 870 Nine greys.
Line 880 32 Inverse colons.
Line 890 Inverse colon, three greys, inverse colon.
Line 2520 Words 'Bug Burst' (parts inverse).
Line 6040 Inverse space, inverse word 'Score', inverse colon,
	six inverse zeros, inverse spaces.
	Second string is: Inverse space, inverse word 'Lives', inverse
	colon, eight ' (two inverse spaces, inverse X), inverse space.

Take great care entering lines 1000 to 1150, count all spaces and
numbers of greys carefully. Each of these lines contains all the
information that is needed to produce a particular screen of the game.
In case you can't read the inverse screen titles, they are as follows
- each has some logical bearing on the screen or its animation:
Domineering, Seasick, Gridscreen, Stairtapper, Octodrop, Clappertrap,
Medieval, Squasiboxes, Escalation, Grey Lagoon, Pac Who?, Grateplanez,
Sgts. Steps, Wheelies, Lazy Doms.

Line 1020 includes graphic-shifted S and D.
Line 1030 includes graphic-shifted 6 and D.
Line 1090 includes graphic-shifted W and Q.
Line 1100 includes graphic-shifted F and G.
Line 1120 includes graphic-shifted E and R.
Line 1130 includes graphic-shifted N and M.
Line 1070 includes inverse X's.

When the program is Run for the first time, the hexloader will Poke
the machine code into the Rems. If necessary you must correct any
mistakes as indicated by the error messages and Run again until
eventually a Run produces the message 'O.K.', whereupon you should
immediately make some back-up copies before Running again, this time
to debug the Basic. Once absolutely sure that all is well you can
erase the hexloader - lines 8000-8210 - and make several "final"
copies, this time using the Autosave - Go to 9000.

