I think the concept of Tunneler was inspired by Combat for the Atari 2600 — two players fight it out in simultaneous battle.  (Note the blue & green tanks.)  I thought there weren’t enough concurrent two-player games for the IBM PC.  Tunneler was also an incremental step from a digging/mining game I had written for the TRS-80.

I wrote Tunneler in my spare time between 1989 and 1992 using my IBM PS/2 Model 30.  Tunneler was developed using Turbo Pascal 4 and some hand-coded assembly. No, I no longer have the source code — it was stored on floppy disks that were lost or damaged over the years.

Tunneler makes use of a little-known “low resolution” CGA graphics mode to achieve 16 color graphics with 160×100 pixels.

Tunneler also directly access the keyboard scancodes in order to read enough key presses for two players to simultaneously use the same keyboard.  This doesn’t work on all keyboards, as they are not designed to handle key presses combinations other than those pressed along with Shift, Alt, and Control.  I picked a set of keys that seemed to work well on most keyboards I had access to, but nonetheless some hardware keyboard matrices won’t support all Tunneler’s keys.  To work around this, I probably should have included a keyboard customization feature, or config file.

This was before the internet, so for distribution I simply uploaded Tunneler to a few BBSs with my modem, just as I had with a few other DOS game projects of mine. I only learned years later that Tunneler had become popular — when people started tracking me down on the internet.

The arena (“world”) was different for each match.  Generating this world could take a long time, especially on slow computers like the original 4.77 MHz IBM PC, so this task was performed in the background while the title page, instructions, info page, and get ready screens were being shown.

The low energy interference static that appears when a player’s tank energy low is not implemented using random noise.  The visual effect is actually just machine code pulled onto the display from a random location in ROM memory!  The machine code in ROM looks random enough that I did not have to generate or store a “random noise” image.