#032 - Bug: Build-A-Bug

Release Date: July 1973

Platform: Mainframe (BASIC Type-In)

Genre: *shrugs*

Developer(s): Brian Leibowitz

Publisher(s): Digital Equipment Corporation

The 101 BASIC Computer Games train rolls on. We really do have a lot to thank David Ahl for when it comes to early video game development. He certainly inspired and facilitated kids to get into programming with both editions of the book, even more so the microcomputer edition. Once kids could get computers in their own homes, it was off to the races for gaming.

For now, in 1973, computer game development is still quite restricted, still limited to schools, universities and those who worked for computer manufacturers.

Such is the case for today's game, Bug. We have a high school student to thank for this one - Brian Leibowitz, of Harrison Jr-Sr High School in Harrison, New York. Brian was only in 7th grade when he made Bug. All the more impressive when we see that Bug has one of the earliest cracks at ASCII art. Leibowitz created a drawing of an undefined bug-like creature out of a text-based interface. There are games predating Bug that made attempts to produce graphics out of text: Mathdice, which drew simple dice faces, and - most notably - Mike Mayfield's Star Trek, which did all sorts of cool things to make a graphical representation of traveling through the galaxy. But none of them really tried to produce a creature, like what Leibowitz did with Bug. So for that, it has some significance.

Disclaimer: Artwork may not accurately represent in-game assets.

Leibowitz, sadly, has no other game credits to his name, according to MobyGames. Nor is there much concrete information on him after the fact. Plenty of guys with the same name out there, but finding out which one is the Bug Brian Leibowitz is likely close to impossible.

Evidently, Bug's graphical work impressed David Ahl enough for him to include the game in 101 BASIC Computer Games. A reminder that this game was produced in a time where teletype printers were a thing - the computer would print out the results of your inputs on paper, as monitors weren't what they are today (that's if the computer even had a monitor to begin with) - because, according to Ahl, Bug could consume voluminous amounts of teletype paper - "well over six-feet" - that's 1.8 metres for us metric users!

Disclaimer still applies.

Before I start with the gameplay section, I must state that Bug barely qualifies as a game. It qualifies because it has a defined gameplay loop with win/loss conditions. The "barely" comes in because it's entirely automated, with the player reduced to a mere passenger. It's kind of similar to PDP-10 Timesharing World Series from way back in 1965, where player input is minimal-to-nonexistent.

What is Bug's gameplay loop? Well, it's pretty simple, as you might imagine. You and the computer take turns rolling a die. Each number on the die corresponds to a part of the titular bug, and the game will draw that part when the number is rolled. Whoever's bug is fully drawn first wins.

Game rules.

That's the basic summary, but there's a few extra important rules. Certain parts of the bug must be present before other parts are allowed to be drawn. For instance, the body (1) must be drawn first before any other part can be drawn, and the neck (2) before the head (3). After each round where a body part is successfully drawn, you're asked if you want to see the pictures of what stage each bug is at.

It's not looking like much yet.

Keep in mind, all of the dice rolling is completely automated. It's difficult to get invested when what's happening in the game is completely out of your control. Even a prompt asking you to roll the die yourself would've helped give a little bit more agency back to the player (even if it's merely illusion of choice.) Also worth keeping in mind that the game would've run a whole lot slower on the hardware it was designed for - a detail we probably don't appreciate today. That might've had a better game feel, which I unfortunately cannot replicate (I could if the game ran through DOSBox...)

It's... hideous. I think I'll name it "Franken-bug."

I don't really feel that it's worth commentating on a playthrough. The game rolls the die for you, and you just sit back and hope that luck is on your side and your bug is fully constructed before the computer's. Scores!

Time Played: 5 minutes

Difficulty: 0

Player has no input, and is entirely RNG-based.

Gameplay: 0

I've already explained this in detail. Technically there is gameplay, but it's also fully automated, requiring no input from the player other than choosing to see the pictures of the bug's progress.

Controls: 5

The game does at least allow you to use Y/N for the picture prompt.

Visual: 2

Bug does at least get a couple of points for having a go at ASCII art. It's hideous, and doesn't really correlate to any real-world bug I know of, but at least Leibowitz had a go at it.

Functionality: 5

There's only one bug in this game, and it's meant to be there... ha.

Accessibility: 4

It's easier to get into and understand Bug thanks to its reliance on pictures, and lessened emphasis on reading.

Fun Factor: 0

I think this one is obvious. I don't actually do anything in game; it plays itself, basically. And that's no fun at all.

Guess you could say the lack of player input really bugs me. Hey, I gotta work on my dad jokes... 

Anyway, Bug gets a lousy score of 16, which rightly places it in the F-tier, alongside several other games. Based on my tie-breaker rules, Bug ends up at the bottom of this pile on account of its 0 gameplay score. Aside from the visual innovation, it's quite terrible.