Advent of Computing - Episode 76 - Star Trek the (Unofficial) Game

Episode Date: February 22, 2022

This episode we blast off at warp speed! We're looking at Star Trek, a game written in BASIC in 1971. Examining this game gives us some insight into the early spread of BASIC. Along the way we will see the issue with paper, why strings matter, and how software was distributed before the Internet. Selected Sources: https://web.archive.org/web/20181106092235/https://gamesoffame.wordpress.com/star-trek/ - Games of Fame article with a few interviews https://www.atariarchives.org/bcc1/showpage.php?page=275 - Super Star Trek! https://archive.org/details/d64_Star_Trek_1983_Jeff_Lewis - c64 version of Trek, good middle ground between the original and more fully featured versions

Computers are precision instruments designed for math, science, and research. And maybe on occasion some banking. To use them for anything else, well, that isn't just frivolous. It's a waste of precious resources. At least, I think that makes for a good cover story. Computers definitely started out as huge number crunchers. In the early days, their uses were pretty limited, to be fair, due in no small part to the fact that there were just so few computers in the world.

But as more machines were built and as better tools were made, number crunching started to become a pastime. It turns out that we like to entertain ourselves, we like games, and we like to find new ways to play. A watershed moment in this transition from aloof bean-counting machines to more fun computers was the development of BASIC. There have always been ways to write computer games, but BASIC opened up the floodgates. I think there's no better example of this shift than Star Trek. The game, not the series.

Written in 1971, it wouldn't be long until this game proliferated to nearly any machine that ran BASIC. Amazingly, or at least amazingly to me, it took just 25 years to go from the first programmable computers to sailing through a simulated galaxy at warp speed. Welcome back to Advent of Computing. I'm your host, Sean Haas, and this is Episode 76, Star Trek, the unofficial game. Today, I have on offer a bit of a fun episode. I think I've earned a few of these after my most recent research spirals. We're going to be looking at Star Trek, a 1971 game designed after the original TV series.

The game sees you take up command of the Enterprise, travel the galaxy, and hunt down Klingon birds of prey. All in all, it makes for a pretty fun afternoon in front of a terminal. But hey, this is Advent of Computing we're talking about. I always come with some ulterior motives. I think Star Trek will be a great way to examine some larger topics that I've been ruminating on for a while. One is something we've hit on before, that's the impacts of BASIC. Star Trek was written in a dialect of BASIC, and that would have really big implications on how the game was developed and how it spread. This episode, we're going to be spending some time looking at the role that this particular language played in this particular game. Star Trek also gives us an interesting opportunity

to look at how a medium can impact game design. This game was first written in 1971, but over the ensuing decades, it was ported and rewritten innumerable times. Each new version brought its own take on the formula. The earliest iterations lived out their lives on simple paper-feed teletypes, while later down the line, some versions had the luxury of a full-color CRT display. I think there's a lot to be said about how design restrictions, especially

changing restrictions, inform software. So there are some more high-minded goals here, but I also just want an excuse to play some more old games. Setting aside all the critical analysis, Star Trek is fun. I mean, it takes a little getting used to, there's definitely a learning curve, but once you get past that, I think there's a lot to like in this little old game. Do you remember a time in your life when computers still seemed magical? When you knew just enough about a machine to be dangerous, but not quite so much to be disenchanted?

For me, that was probably in middle school. One summer, I remember that I learned how to program crude beeps and boops on a computer. For whatever reason, this scratched some itch for me, and I spent months obsessed with making sounds come out of computers. In retrospect, I really think I spent months driving my folks crazy with weird digital sounds. I think most computer nerds, and definitely most programmers, have had some similar kind of experience.

For Mike Mayfield, an obsession set in during high school. To quote, Back in 1971, I was a senior in high school. My school didn't have any computers, but I had managed to use, read, steal an account on a Sigma 7 at the University of California, Irvine. I was trying to teach myself basic from a book. At the time, there was a program that ran on a vector The early 70s was an interesting era for BASIC. Maybe we could call it medieval. BASIC had already emerged from the primordial stew at Dartmouth, but it wasn't quite time for the home computing boom. The language has become emblematic of small home systems. Everything from the Commodore 64, even up to the IBM PC, could boot straight into

BASIC. In those machines, it was everything. A programming language, an environment for loading data, and a way to distribute code. But in the early 70s, the middle ages of BASIC, the language was cast in a subtly different role. There were two main ways to get your BASIC fix in this era. The old school way was by logging into a timesharing system that used BASIC as an interactive environment. The original, of course, was the Dartmouth timesharing system. That's what BASIC was first designed for. Other systems, like HP's timeshared BASIC, followed in this older mold. Once you logged in, you were ready to hammer out lines of code. For a user, these systems would have looked pretty close to the microcomputer basics of the 80s. You had a standard BASIC implementation, a way to edit your program,

plus some kind of extension on the language for BASIC file or peripheral handling. On the other side of the spectrum, you had application-level support for BASIC. This is where you'd first log into some sort of environment, usually a timeshared environment on a mainframe, and then load up BASIC. The difference here is that this form of BASIC was more similar to other programming language environments. You could edit files with a normal text editor, then pass your files off to be interpreted or, in some cases, even compiled. The system Mayfield snuck into was somewhere between these two options. It was called SDS

Basic, and it ran as an interpreted environment under a normal timesharing system. The key factor here is that Mayfield would cut his teeth on a very traditional basic environment while also having access to a more powerful mainframe full of other exciting programs. And there would be one program in particular that seemed magical. Space War. Now, this brings us to an interesting point. Space War, that's spelled with an exclamation mark, is often considered as the first video game. There is some contention over the timeline.

Spacewar! was written in 1962, and there are some earlier video game-like things that existed. You can make a bunch of technical arguments to make Spacewar! the first definitive game, but I think there's an easier route to go. Space War was the first game to spread, and the first game to start influencing other programmers. The original was written at MIT on a PDP-1. It would spread from there, seeing many multiple rewrites and ports. By 1971, it had become so ubiquitous that

even a high school kid in California would be exposed. That's the kind of influence that pre-Space War games just didn't have. There's no competition. So what was it about Space War that made the game so well-loved? It came down to graphics, gameplay, and, well, space. The game was fully graphical at a time when computer graphics were almost unheard of. On the PDP-1 version, you played using a vector display. The gameplay consisted of two spaceships that flew around a green and black screen. You and your opponent tried to shoot at each other while avoiding falling into a black hole at the center of the playing field. It's simple, but it's a fun and effective premise.

The space part, well, that added a certain cool factor to everything. The matter of ports here is something that I find particularly interesting. Of course, a Sigma-7 and a PDP-1 are pretty different computers. You couldn't just drop the original version of Space War on this newer machine and expect it to run. To further complicate things, Space War was written in assembly language. So you also couldn't, say, recompile it for a new platform. There was no compiler involved to begin with. The only option was to rewrite the game from scratch. Luckily, Spacewar! had the right fun-versus-complexity ratio to make this possible. The actual code for the game isn't very big, and its code was easy to come by.

Steve Russell, one of the game's developers, was happy to send a full source code listing to anyone who asked. The Sigma-7 that Mayfield had access to was connected up to at least one vector display. His recollections of early events are a little sparse. My guess is that someone at the university must have shown him Space War at some point, or maybe there was an open house. Of course, Mayfield would be enamored by the game. I can only imagine that the shiny vector display played a part in that process. You see, while Mayfield did have access to a computer, it was only a limited form of access. He could only connect to the Sigma-7 over a paper-feed teletype. And worse, his account didn't even have access to storage. This is definitely enough to get

a start with BASIC, but not enough to write your own version of Space War. But programmers, we tend to be a crafty bunch. I know few keyboard jockeys that would give up at the first hurdle. From Mayfield, quote, A bunch of my other geek friends from high school and I spent a lot of hours brainstorming what we could do if we didn't have a video terminal. Since I was the only one in the group that had any knowledge of computers, little as it was, we ended up coming up with a lot of unimplementable ideas. End quote. The big problem here comes down to how teletypes operated.

Really, I guess the main issue is paper. A teletype in this period amounts to an electric typewriter connected to a modem. It can talk to a computer and print outputs, but everything is displayed one line at a time on a paper printout. There were already well-established techniques to get around this shortcoming. For years, probably more like decades, teletypes were just the norm. Most user interfaces were designed around this as the default I-O method. Look no further than the command line. These interfaces are fully textual. Everything that goes into the computer or comes out is in the form of text.

Commands are entered character by character with an enter signifying the end of a command. You're sending data off to the computer one line at a time. The computer then responds one line at a time, all via text. I know this is one of those tiny, no-brainer kind of details, but I think it's worth articulating. The whole command line paradigm works the way it does thanks to teletypes and similar one-line-at-a-time terminals. This same approach would end up being applied to games. Once again, this isn't even a groundbreaking approach. It's THE approach that was available, you just don't get a choice in this era. Colossal Cave Adventure would take this tact,

using line-by-line descriptions to guide a player through an underground journey. Even earlier software like the Sumerian game did the same thing. Players entered commands or answered questions one line at a time, and the computer described the results in plain English. Now, this is a bit of a tangent, but I haven't had an excuse to bring this up in any other episode, so you get a tangent here. There were some even earlier computer games that didn't need teletypes.

Now, I gotta put a bunch of scare quotes around games. These aren't exactly fun. During the late 1950s, a handful of business games were developed by groups like RAND and IBM. There are a few other players, but those are the two main ones. These were management simulators used primarily to train employees and executives. The one I'm most familiar with was a little number developed at RAND in 1957. Instead of a terminal, the RAND game used punch cards for input. To play, a group of business folk would break into teams. Each team was tasked with allocating the budget for their simulated company.

Every turn, the team received a report from the computer, printed out in the form of a ledger. Each team adjusted their budget, then passed their updated plan off to a technician who would reduce the data to a punch card and feed it into a machine. I know, barrels of laughs. Little wonder these games didn't, you know, take off. Little wonder these games didn't, you know, take off The point here is that the Rand game actually did effectively get around the limitations of teletypes Just kind of in a dumb way The whole point was to simulate a business Suits in the 50s didn't spend their time cracking away at terminals

So the input method was devised to look more like a business meeting. The downside here is that you have to have staff to run the simulation, and it's not really a fun game per se, but it does offer an interesting way around traditional input options. Of course, Mayfield wasn't familiar with the unbridled joy of Rand's business game. Just as likely, he had never played a text-based adventure. Out of all the unworkable ideas that Mayfield and his friends dreamed up, there was one winner that could address the throughput problem. The big idea that would turn into Star Trek was printing out a small map

of the galaxy with simple characters. This was one of those diamond-in-the-rough ideas. Mayfield figured it would be possible to generate a tiny Asciiart map on a teletype. Now, this is where we're going to venture into some speculative territory, at least slightly. As near as I can tell, Mayfield only did one very short interview about Star Trek. The one I've been quoting from is from the website Games of Fame. While informative, it's pretty short, and it doesn't break into a lot of the technical detail. So what we're coming to next is a bit of extrapolation on my part. Mayfield started Star Trek on the Sigma-7, programming everything on teletyped. Since he didn't have any disk quota, he had to keep physical copies of the game's code on paper tape.

Paper is a theme here, primarily as a limited resource. primarily as a limited resource. Mayfield had incentive to keep the code compact, but also keep the actual outputs of the program relatively compact. So how do you fit an entire galaxy full of starships, space stations, and aliens behind a teletype? Well, Mayfield worked off a well-established template. He wanted his game to feel like Star Trek the TV show. The game's controls are modeled closely off how the fictional starship Enterprise is controlled. You see, you play as the captain, and that's key. It's never explicitly stated in the game, but come on,

we all know that we're taking up the mantle of James T. Kirk, captain of the USS Enterprise. In the series, Kirk doesn't command the Enterprise from a desk covered in dials. He sits in his comfy captain's chair and gives orders. Go to warp 6. Set course to 238 Mark II. Fire torpedoes. The bridge crew then carries out those orders, providing verbal feedback. Maybe Scotty barks back that the warp drives are fried, or Chekhov announces the torpedoes hit the mark. Right there, we have a line-by-line interface. In the show, it just happens that lines were acted out, and Mayfield adapted this rough premise so that each line was instead typed.

What I find really funny here is that Star Trek the TV series is, by and large, formulaic enough for this approach to work. At least when it comes to the actual parts where the show takes place on the bridge in space. I'm honestly kind of surprised that this didn't click for me sooner. I've watched a lot of Star Trek and I never thought of the bridge sequences as a command line input. Now, the bulk of Mayfield's game revolves around issuing these simple commands. It amounts to moving the ship, managing shields, and firing weapons. Outside of those commands, you have the scanner. This is the only visual element in the entire game. Mayfield had to be sparing with this kind of stuff, since everything does come over on a

paper feed. Normally, each command returns a simple line of text, but when you call up the short-range and long-range scan, the computer responds with a map of outer space. Now, it would be impractical to show these maps every time you take a turn. Imagine the waste of paper, not to mention the wasted time waiting for the teletype to hammer out characters. So, in the Mayfield original, you only get a map when you call up a scan. You play on an 8x8 quadrant map. And yeah, I know, quadrant isn't the right word here, that's just the nomenclature used in the game. A long-range scan will show a 3x3 section of that

grid. This is, by far, the least impressive map. It's just a grid of boxes drawn with dashes and spaces. Each box contains a cryptic three-digit number. In order, those digits show the number of Klingons in the quadrant, number of star bases, and number of stars. So a 2-1-2 quadrant means two enemies, one star base, and two stars. This is the game board for all intents and purposes. From this map, you can orient yourself, look for nearby enemies, and plot your next move. You move around this board by selecting a course and a warp factor. This is all done as simply as possible.

The course is just a number corresponding to 2D directions. One moves you to the right, two is up and to the right, three is straight up, and so on. It goes cyclically. Warp factor is how many quadrants to move in a turn. Once again, simple but effective. Once you land in the quadrant of interest, you can carry out a short range scan. Once you land in the Quadrant of Interest, you can carry out a short-range scan. This is where we get our second map, the Quadrant map. This, quite fittingly, shows a smaller-scale map of the particular quadrant the Enterprise is currently in. It's still a pretty small graphic, maybe 30 or so square characters,

but it's enough to give you an idea of what's going on. The map shows where you are inside the quadrant, plus the location of any Klingon ships, any stars, and any star bases. And, as always, this is all rendered in text. Klingon ships are just three plus signs. The Enterprise is a star inside two angle brackets. Stars are just, well, asterisks. We're looking at some really simple graphics, if we can even call them that, but the sum total here is relatively effective. Mayfield is squeezing just about as much out of a teletype as practically possible while dealing with the trade-offs between fancy ASCII art graphics and paper usage. Star Trek was initially developed on the Sigma-7, but that phase didn't last long. From Mayfield again, quote,

Late that summer, I bought HP's first programmable calculator, the HP-35. I ended up going down to the local sales office several times for help on the programming. One time, they mentioned that I could use their computer if I would convert my Star Trek program to their computer so that they could use it. End quote. It's hard to pass off authorized access, right? By 1972, Mayfield had converted Star Trek to run on HP's timeshared BASIC. Now, it's hard to say exactly how much of the game was completed on the old Sigma-7. I'd guess at least the map and BASIC movement, but that's all conjecture. However, once Star Trek came over to HP,

we move into the recorded history of the game. You see, we still have the very code that Mayfield wrote in that local HP sales office. So far, I've described the map and movement. That makes up most of the common actions you take during the game, but you can't win with warp drive and scanners alone. We're also now up to a point where we have living source code to go off, so I can be a little more specific. The Mayfield version plays out in a series of turns. Each turn, you choose from a handful of options. We've already met move, long range, and short range scans. Luckily, the 72 version of the game has a help message that explains all the options.

Luckily, the 72 version of the game has a help message that explains all the options. After scanners, we have weapons. Phasers and photon torpedoes. Both are viable options for hunting down aliens, but they come with some trade-offs. Under the hood, the Enterprise has surprisingly limited resources. The two values that matter are energy units and torpedoes. The latter is pretty simple. You can only carry so many photon torpedoes.

Once fired, that torpedo's gone. You don't reuse torpedoes. It's a non-refundable kind of deal. Energy units bring some added complexity to the game. Firing phasers uses energy units. Each time you shoot, you specify how many units to expend, basically how much oomph to put behind your laser. So there is some incentive to be economical with your energy. You don't want to use 600 units to kill a Klingon if 150 will do the same thing.

But you aren't just firing at dummy targets. Birds of Prey will gladly return fire, or as the help text puts it, quote, keep in mind that when you shoot at him, he gonna do it to you too, end quote. This is where shields come into the picture. When your shields are up, they will take the brunt of enemy attacks. Shields also use energy units. This is controlled in the same way as phasers. When you raise shields, you can specify how many units of energy to devote to defense. This gives us a simple but effective style of combat. If a Klingon ship fires with more energy units than your shield level, your ship takes damage. But returning fire also uses up energy.

So in every encounter, you have to balance your defense and your offense. Run out of energy and you're effectively dead in the water. Or I guess in this case, you could say you're dead in the vacuum. Torpedoes offer a way to instantly take out an enemy, but come with an added drawback. Not only do you have a limited number of torpedoes, you also have to target them manually. This uses the same course numbering system as movement. An interesting part here that I didn't actually figure out until I died a few times is that you can enter decimal values for your course. You aren't limited to whole numbers. This includes movement and firing. You can shoot down a bird of prey from anywhere on the screen,

as long as a star or starbase isn't blocking your line of sight. The complication here is figuring out the exact right course. It's easy if the Klingon ship lies on a simple course. If it's just to the right, then fire a torpedo on course one, and you're done. But that's rarely the case. Now, you could get a little fancy with it, pull out a protractor, or use some quick trigonometry, but Star Trek offers a solution. Besides barking orders at the crew, you can also shout at the ship's computer. The game calls it the library computer for some reason. It's a submenu that can give you a much-needed hand in your

adventure. From the computer, you can retrieve records of past scans which show the full 8x8 grid of the galaxy. You can get information on remaining Klingon ships, and, most importantly for our purposes, the library computer can be used to calculate torpedo courses. Just pull up the menu and the computer will gladly crunch the numbers for you. No tangents needed. That's the gist of the game. Fly around, raise shields, and go out guns blazing. The interface in the 72 version is admittedly basic.

Commands are selected by number, so you just have to remember that 4 is how you launch torpedoes. Small choices like this made the game relatively compact. It doesn't have to do any fancy string compares, for instance. The use of basic here is also important, or more specifically, the flavors of BASIC that Mayfield had access to play a key role in how Star Trek formed. The first and most obvious factor is that Mayfield was new to programming. BASIC made it a lot easier for him to learn and get off the ground in such a short time. We're talking less than a year between getting clandestine access to the Sigma 7 and a completed game. The availability and simplicity of BASIC, I'd argue, made that time

frame possible. Now, there are some more idiosyncrasies of BASIC that made Star Trek what it was. So, let's ease into it. A lot of this has to do with how data is handled. To start with, basic doesn't really do data types. Most forms of basic are implicitly typed, meaning data types are figured out once variables are assigned data. You don't have to explicitly say some variable is an integer. You just say x equals 1 and BASIC can have your back. It's a simplification that was intended to make BASIC easier for beginners. There are some tricks played on the

backend to make this happen, but for the programmer, there just might as well be no data types. This means that, in general, anywhere you can enter an integer in Star Trek, a floating point will do just as well. The most obvious case is course entry. You can 100% set a course with a decimal point. You can also, in theory, devote fractional energy units to phasers and shields, but that's kind of a waste of effort. Moving further off-spec, we get into the realm of strings. effort. Moving further off-spec, we get into the realm of strings. The creators of BASIC, Thomas Kurtz and John Kimony, had a word for versions of the language that deviated from the Dartmouth Standard. They called them street BASICs, or vulgar BASICs. Their rationale was

that these non-standard languages represented a degradation of the language. In practice, this just amounts to versions of BASIC with added features, nothing that dangerous. More features can be a good thing for sure, but the issue is they limit portability. Breaking from the standard means relying on a specific version of BASIC, which can trap code on a single platform. SDS BASIC, Mayfield's initial choice for Star Trek, was one such vulgar dialect. So too was HP's timeshared BASIC. Each had their own non-standard quirks, but one particular feature was crucial to the game. String slicing. Each of these variations on BASIC let you treat strings as lists of characters. I mean, that's really all a string is once we look under the hood a little bit.

But this all comes down to how these languages exposed that data. In latter versions of Dartmouth BASIC, the gold standard according to its creators, you could translate a string into an array of numeric values and vice versa. There were also some ways to do string concatenation that were standardized. That's all a little bit awkward, and over the years, specifics of this approach would change. But that was the standard, so to speak. The other complication is initially Dartmouth BASIC just didn't support strings. So new implementations of BASIC were kind of left out in the dark on how to deal with this data type.

SDS and HP just allowed strings to be treated nearly the same as a standard array. You want the int letter of a string? Easy. That's the same syntax as the int element of an array. No mess, no fuss, and no compatibility with the folk over at Dartmouth. Mayfield used this string slicing feature to construct maps in Star Trek, so early versions of the game were somewhat locked into basics that allowed for string slicing.

The final idiosyncrasy to contend with also has to do with variables. That's naming conventions. As per early Dartmouth Basic, variable names were a single letter followed by, optionally, a single number. Not exactly the best namespace. So while we do have the source for Mayfield's 72 version of Star Trek, it's pretty hard to read. the source for Mayfield's 72 version of Star Trek, it's pretty hard to read. Some brave souls have since done analysis of the source code, but that's a pretty tall task. BASIC may have been the best place for Star Trek to start, but it also led to some of these unique issues. The first public outing of the game came in HP's Contributed Software Library, listed under STTR1. The game was

attributed to Mike Mayfield of Centraline Engineering, an admittedly made-up company that Mayfield had dreams of eventually founding. This published version of the game is surprisingly small, just around 640 lines of BASIC, but it's also dense. It's, like I was saying, not the kind of code you can read as a leisure activity. The Contributed Software Library, or CSL if you're friends, was an interesting beast. This was a project started in 71 and initially managed by HP itself. Users were able to send in programs they had developed and published them through HP as public domain software. Once again, scare quotes around published, since this isn't exactly the kind of software publishing we're used to today. Basically, HP kept a crypt full of all this public domain source.

Catalogs of this archive were published and sent off to clients at regular intervals. Catalogs of this archive were published and sent off to clients at regular intervals. You could call up HP and order any program from that catalog for a relatively low fee. An article in a 1971 issue of the People's Computer Company newsletter states it cost just $10 to get a copy of STTR1 on paper tape. That fee included a full printout of the basic source code. For just $25, you could get the full basic library on magnetic tape. That's at least a few hundred programs. All things considered, it's a pretty good deal. We're starting to see buzz around the game, but there's still a limit to its spread at this point. For one, this is all HP-specific stuff. You have

to call up HP to get an HP-compatible paper tape to load into your HP computer running HP basic. In an era with such a fractured market, this kind of isolation would have mattered a whole lot. I mean, you couldn't run STTR1 on a Sigma-7 anymore. But this did open up some new opportunities. Crucially, the CSL effectively made Star Trek open source. Maybe not in the way we use open source today, but anyone could get the code. If you had $10 or knew someone who did, you could have your own copy of the source code. Getting it running on another platform might be a slog, but it wasn't out of the question. So, by whatever measure you want to use, by 1973, Star Trek, or at least its STTR-1 incarnation, had gone public. One of the many that would shell out for a copy of the game

was Dave Aul, a marketing consultant at DEC. At this point, Aul was the editor of DEC's EDU newsletter, a regular publication devoted to the educational uses of computers. EDU was an interesting mix of product placement and useful information. The newsletter was part of DEC's larger initiative to push into the education sector. So the central offering here is how to use DEC hardware and software to make your classroom better. But around that, you have more generally useful stuff. Basic was a prominent feature of All's newsletter. Each issue had a number of source code listings for programs. These were either provided by readers or direct from the deck staff. These programs

were often educational in nature. I mean, duh, that's the name of the newsletter. One issue carried a program for calculating forces between objects, just to give you an idea of the kind of stuff that went to print. The idea was that students could learn a thing or two from these programs and maybe even learn something from their source. It was during this period, while managing EDU, that All came into contact with STTR1. Of course, he didn't have any easy way to run the game. HP Timeshared Basic didn't exactly work on DEC hardware, so Al and Mary Cole, a coworker, set to work converting the game to a more DEC-ish dialect called BASIC+. Same general language, just some different caveats. BASIC+, was supposed to be

closer to Dartmouth BASIC, only adding functionality but not changing the core parts of the language. We'll get back to that in a minute. In July 73, Aal published a compilation of Basic games called, what else, 101 Basic Computer Games. This was drawn in part from submissions to EDU, plus other games that Aal could get his hands on. One of these games was Star Trek. Now, as near as I can tell, Star Trek fell into this latter category. I can't find it in the EDU newsletters that have been scanned, and Al doesn't mention it appearing in EDU prior to 101 games. With this iteration, we get more weirdness. The first thing to note is some name confusion. iteration, we get more weirdness. The first thing to note is some name confusion. In 101 Games, all label Star Trek as Space War, shortened to S-P-A-C-W-R in some cases. The entry in the book even says that Space War was based off Mayfield's Star Trek, further adding to this name maze.

Fields Star Trek, further adding to this name maze. The game's introduction says that, quote, this program is an incredibly complete version of Space War, end quote. Now, the cherry on top here comes from a later recollection from All. In an article for Creative Computing, All wrote, quote, many versions of Star Trek have been kicking around various college campuses since the late 60s. I recall playing one at Carnegie Mellon University in 1967 or 68, and a very different one at Berkeley. However, these were a far cry from the one written by Mike Mayfield of Centerline Engineering and or Custom Data. from the one written by Mike Mayfield of Centerline Engineering and or Custom Data. This was written for an HP 2000C and completed in October 1972. It became the standard Star Trek in February 1973 when it was put in the HP Contributed Program Library

and onto a number of HP data center machines. End quote. This is one of those lovely cases where having a source only leads to more questions. Later in the article, Aal does state that calling Star Trek Space War was, quote, in retrospect, an incorrect name, end quote. So I guess that part just comes down to some bad choices. But what's going on with the mini pre-1970s Star Trek games? Star Trek doesn't hit the scene in any way until early 1973. So what was all playing back in the late 60s? Name mixups are an established issue in 101 basic computer games. One example that I've

actually ran into on the show before is the Sumerian game. That was packaged up by All and renamed as Hammurabi. Normally, that's spelled with two M's, but the version in All's book only has one. So, naming inconsistencies are something of a pattern in this text. I think it's most likely that All was simply referring to Space War proper. All the games presented in 100 Games were designed for use with either teletypes or some other mainly textual I.O. device. It was assumed that users wouldn't have fancy vector graphic displays. So, consequently, there's no version of Space War in 101 games,

and you don't get any programs where you fly a ship in real time on a green, black, and white display. That said, it's just as likely that all was thinking of any number of space-themed games. Early mainframe games tended to fall into three categories. You had simulations of existing games, fantasy-themed, or space-themed games. This is one of those mysteries that I don't think will easily be solved, but we can pass over for now. be solved, but we can pass over for now. There's another source of strangeness in the 101 games version of Star Trek. Aal and Cole had ported STTR1 to Basic Plus, which in theory should have led to a pretty standardized version of the game. Here's the clincher. Basic Plus could run string operations exactly like Dartmouth Basic,

but it also had the option of manipulating strings directly as arrays of characters. All chose to use the latter option throughout 101 games. Street Basic strikes again. So, while the version of the code in 101 Basic computer games was usable by many versions of Basic, there were still some outliers. That said, Awe's publication would really get Star Trek up to the next level of notoriety. The book sold for just $7.50, making this by far the cheapest way to play Star Trek. Unlike EDU, this wasn't targeted at DEC users. Sure, it happened to be published by DEC, but the book didn't even have an order form for a PDP computer. 101 Games also seemed to drop the educational pretense, at least somewhat. The introduction

mentions that games can be powerful tools for education, but I don't think all games presented really work as those kinds of tools. Star Trek specifically is a pretty big program. The 101 games version is around 550 lines long, with the size reduction thanks to compound statements. Some lines of code do multiple assignments or multiple calculations in order to save space. Add in short variable names and we're left with, once again, a pretty tense program. Maybe not the best educational tool for school-aged children, but it would turn out to make a good puzzle for students of a different sort. One of the tragedies here is that Mayfield exits the picture pretty early. One of the tragedies here is that Mayfield exits the picture pretty early.

This is one of those byproducts of how Star Trek spread. Mayfield wasn't out publishing his own software directly, it was always behind HP's shield, and then eventually behind multiple layers of different ports of the program. So while his name was known, that was about the only connection after 1973. his name was known, that was about the only connection after 1973. The original author would become even more obscure as Star Trek sees some radical changes. In 1974, Bob Liedom was working as an engineer at Westinghouse. We're still at a point in time where no one really owns a personal computer. 74 would see the Altair 8800, but that's still a long way from a usable system. If you wanted to get some private computer time in, you had a few options. You could try and get some not-entirely-authorized access to a machine like Mayfield did, you could be a student at a

campus that happened to have a computer, or you could leverage unused computer time at your job. Lidom was able to take advantage of the easier of the three approaches. Quoting from an interview in Games of Fame, I started staying late at work to play with a Data General Nova 800 that wasn't being used after hours. It was the biggest computer any of us could imagine having available, with 30k words of memory. My big project was trying to get a game called Space War running on the Nova, end quote. It's basically free processor time just waiting to be used. Now, Space War here is spelled S-P-A-C-W-R.

In other words, we're talking All's version of Star Trek. Lidom had got his hands on a copy of 101 Basic Computer Games. I don't think I'd call a professional engineer a student in the traditional sense here. However, I think it's fair to say that most computer folk are always eager to learn. With Lidom's entrance to the Star Trek arena, we get yet another dialect of BASIC. Judging by the year and the platform, I'm fairly certain Lidom was using Data General's extended BASIC. The detail that matters here is, as always, string manipulation. As Lidom explained, quote,

Unfortunately, the program used a foreign version of BASIC, and I had to figure out the extensive string manipulation code and translate it to the data-general BASIC syntax. End quote. Now, my best guess is that a major contribution was string concatenation. Extended BASIC supported string slicing just like other BAS other basics we've seen in this episode. However, strings were concatenated using a comma instead of a plus. I think there were probably also other slight differences in how slices were handled.

Remember, slicing isn't standard, so there's not a standard way to do it. A further fun complication comes in BASIC's structure itself. Each line of a BASIC program starts with an explicit line number. These numbers are used for flow control. To run a subroutine, you call it by number. To jump, you reference a line number. Making changes to a program can often mess up line numbering. Let's say you need to add some code between lines 10 and 11.

Well, now line 11 needs to be pushed up to numbering. Let's say you need to add some code between lines 10 and 11. Well, now line 11 needs to be pushed up to line 12. The old line 12 now needs to be renumbered also, and so on down the list. Anything after line 11 that references a line number needs to be updated to jump to the new correct location. So you get into the situation where changes to a small portion of basic can lead to major refactors. The net result is that for Lidom to get Star Trek working, he had to get familiar with its code. That tends to be a dangerous course, since programmers like to fix things, and usually have a pretty liberal definition of what counts as broken. Once Star Trek was working, Lidom, spurred on by his friends and co-workers, started to make tweaks. This would lead to the fourth major version of the game so far,

Super Star Trek. This new iteration retains all the core gameplay of the original. Much like Street Basic, the differences are in new features and small upgrades. First off, Lidom did away with the awkward numeric menu system. Instead of remembering the number to navigate the Enterprise, Super Star Trek now accepted NAV. All top-level menu options were replaced with these three-letter commands. Not a huge difference, but definitely a quality-of-life improvement. The Nova was a pretty powerful system. It at least had a comfortable amount of RAM to work with. Program size wasn't really a concern like it was for Mayfield at certain points. Many changes made for Super Star Trek involved beefing up the game.

One fun upgrade was that Klingon ships could now move. Originally, Birds of Prey were just randomly placed stationary targets. As an article announcing the game in Creative Computing put it, quote, Klingons are non-stationary within their quadrant. If you try to maneuver on them, they will move and fire on you, End quote. This is a neat expansion on the older game. You see, some moves in the game don't actually advance the turn. Checking the computer is one example. It's an action you get to take for free. Normally, this distinction doesn't matter unless you're in a quadrant with a hostile ship. Back in the Mayfield version, Klingons would only return fire. But Lidom expanded that danger. Navigating around stars to set up a shot takes time,

so it gives Klingons an opportunity to counter your movement. That should be penalized just as much as missing a shot or leaving an enemy alive. Lidom also gave the in-game computer an upgrade. He added the ability to calculate any courses, not just firing tables. You can now enter the quadrant you want to go to and let the computer figure out the proper course and warp factor. It's another one of those quality-of-life things that I think is pretty nice. The last big improvement wasn't actually a functional change, but rather some new paint. actually a functional change, but rather some new paint. Initially, the 64 quadrants of Star Trek's universe were simply named by their location on a grid. You had such scenic locations as

Quadrant 3-1. I know, riveting. LIDAM added in names for chunks of the grid, thus creating new digital landmarks. Each named region was made up of four quadrants, a pretty apt number, each identified by a Roman numeral. Good ol' 3-1 was now Antares 3, just a warp away from Rigel 2. Rounding out the operation were more characters. Not playable characters, you're still assumed to be Captain Kirk, but Lidom did expand the roster. Since the original game, the Enterprise could get damaged. You get a short message about the broken system and lose some functionality. In most cases, you have to dock with a starbase to get repairs. In Super Star Trek, different members of the crew give you different reports.

Scotty can tell you that warp drives took a hit, or as the game puts it, Scott. I'm pretty sure it's a character limit thing. Super Star Trek wouldn't stay on Westinghouse's Nova for very long. At some point, Lidom started publicizing his new spin on the old game. I can't find the actual archived document, but sometime in late 74, Lidom wrote a letter to People's Computer Company detailing the new game and offering source code. This was a relatively common way for hobbyists to share their work in this era. It was a newer infrastructure that was just starting out when Mayfield's code was first shipped by HP. A software developer would write into a newsletter, like people's computing company,

and detail their new program. Maybe they'd include some example runs of the game, maybe even a chunk of code. The letter would end with an address where the author could be reached and a promise of free or usually at-cost code. Like I said, I can't find the original letter to PCC. It's probably just not scanned somewhere I can easily search. There are subsequent documents that outline the rest of the story. Lidom took to the pen again in the summer of 76, drafting another letter to PCC. Quote, If you recall, I wrote to you a couple of Septembers ago to tell of my extension to Mike Mayfield's Star Trek game. That led to Dave All's publication of my version in his great mag, Creative Computing,

which, in turn, led to me receiving much mail from computer game freaks of all ages from all over the country, plus England. End quote. And yes, Dave All enters the picture again. All got his hands on a copy of Super Star Trek, then, with Lee Dam's help, adapted it for print in Creative Computing. This was a newer computer magazine that All had started in the years after 101 Basic Games hit the scene. This is the release version of Super Star Trek, if we can call it that. This is the release version of Super Star Trek, if we can call it that. Creative Computing carried a full source code listing for the game,

which took up four pages of tiny text. My best estimate is that this new version was somewhere north of a thousand lines of code. The other interesting piece here is we start to see a dialogue around Star Trek. Lidom's 76 letter isn't that long, but it has a lot of juicy details. We can back this up with other articles and letters in PCC. You see, Lidom wasn't the only person hacking on Star Trek. He points out another contributor, Bill Campbell, who had recently published his own Ultimate Star Trek via the magazine. Looking at various back catalog issues, we run into a number of other versions of Star

Trek. The game was really kidding around at this point. Newsletters and magazines formed this interesting venue for discussion and distribution of new versions of the game. It was around the same time that a seismic change was occurring. Super Star Trek has a touch of the game. It was around this same time that a seismic change was occurring. Super Star Trek has a touch of this shift. In the release notes in Creative Computing, Lidom mentions that he added support for a fancy CRT terminal feature. The release day code included a bell character, which, on compatible Westinghouse terminals, rendered flashing text. This was used to make the red in Red Alert and your current quadrant blink. I know, it's an exciting shift.

This is a really small change, I do admit, but it presages what's to come. Lidam mentions in his letter that he had been wanting to get a home computer, but I just can't bring myself to do it. Lidam mentions in his letter that he had been wanting to get a home computer, but Home systems were still a little too expensive for all hobbyists. Emphasis on the all there. In the same issue of PCC, there was an article titled Tiny Trek. Trek for your 8K Altair. Tiny here has a double meaning. This version of Star Trek is small in size, but also tailored for a dialect called Tiny Basic. Yet again, we're seeing a different version for a different platform in a different basic. We're starting to see the effects of the microcomputer

boom. The full effect is a little delayed, but it's still there. Versions like Tiny Trek were straight-up ports. At this point, it was still common for Alters to sport teletypes instead of glass terminals. As glass teletypes became more common, and especially as microcomputers started connecting to TVs, a new branch of Trek would emerge. This is where we get more visually stunning games. Well, at least a little visually stunning, a little bit more than classic terminal Trek. We also run into some issues with sourcing at this point. By the early 80s, there's a glut of Star Trek-themed microcomputer games. Some are, in fact, adaptations of Star Trek, while others are totally new games. Needless to say, this can make tracking down the finer details a bit of a

struggle, so we're going to be talking in pretty general terms here. One example of a Star Trek boldly going where no Trek had gone before was a 1983 version of the game written for the Commodore 64. This is still 100% text mode, but everything else is bumped up to the next level. Just about every line of text is a different color. Icons flash, and the game even opens with a chiptune rendition of the theme from the original series. In general, a lot of home computer adaptations took this approach. Call it a strict maximalist camp. A pretty close adaptation of the original game, with added color, sound, and effects.

A tiny detail with this particular release is that once the game loads, you start off with a short-range scan. The days of the teletype were finally gone. No more worrying about wasting paper or baud rates, just throw up as much data as you can fit on a screen. This particular Commodore version doesn't keep up a persistent map, but I think opening the game with the graphic is a sign. Things were different now. I want to close out our survey with just one more version of the game, the 1982 release of Star Trek for the ZX Spectrum, written by John Nixon. This takes us into the straight-up

maximalist branch. Total rewrites of Star Trek didn't start on microcomputers. There are earlier examples on mainframes and minis. There is, for instance, a port written in COBOL from 1979, if you can believe it. These distant ports and new fancy versions have one thing in common. They're no longer connected to Mayfield's work by actual code. Mayfield didn't write a single line of COBOL in 1972, and he definitely wasn't designing for a ZX Spectrum. The Spectrum version is notable because it shows the full break from Trek's traditional interface. The map stays on the screen. A decade after the first quadrant was hammered out on a teletype, we finally arrive at a more interactive display. We also see real graphics in the 82 version.

Your ship is represented by a little sprite of the USS Enterprise. Klingons are represented by tiny pixel drawings of birds of prey. It looks a lot more like a game than some interactive mainframe program. Controls have also changed along with the graphics, but not as much as you may think. The main difference is that turns are taken in real time, you have to react to the situation. Everything is still entered in three-letter commands, similar to those used in Super Star Trek. Now, why am I bringing up these latter additions, you may ask? I think it shows a family of games springing out

of Mayfield's creation. The direct lineage continues on for quite some time. As long as there were computers running BASIC, there were more or less direct ports of Star Trek kicking around. But we also see Trek-inspired games appear. Often these newer games still followed the same formula laid out by Mayfield in 72. The gameplay is fun, it's simple to learn, and it's simple to implement. What really changes between the branches of the family is how well their medium is exploited. Mayfield came up with a fun way to get the most out of a teletype. That approach was valid for a while, but it hit its limits pretty quick. Expressions like the ZX Spectrum port show how those bounds can be changed. The introduction of computers that could use color TVs as displays was a big deal.

In the micro view, it meant Star Trek didn't have to be stingy with maps. These kinds of small-scale changes, little inconsequential things, are an interesting bellwether for where things end up going. Sure, a fancier version of Star Trek wouldn't rock the world. But this changing use of computers would. Games like Trek just happen to be riding along the same waves of much larger innovations. Alright, that wraps up this episode. So, where do we land on Star Trek? Maybe that's a little bit harsh. This wasn't exactly the most hard-hitting and impactful topic we looked at.

I think it's more of a fun story with a few important morals. To start with, we've seen what Basic was actually good for. The early 70s were, in the grand scheme of things, still pretty early for Basic. It was finally out of Dartmouth and into the real world, but it had yet to explode into the home. Despite that, we still see Basic's character intact. For Mayfield, it was a fantastic way to learn to program. It was an easy introduction and an easy environment for getting off the ground. The particular shortcuts within the language, namely how Basic handles variables and strings, helped along the way. Once we get to Star Trek itself, we can see how quirks of the language, namely how BASIC handles variables and strings, helped along the way.

Once we get to Star Trek itself, we can see how quirks of the language became quirks of the game. From there, we get to see a few downsides to this new language. Adoption on many computers was spreading, but that was usually in the form of so-called street BASIC, mostly compatible dialects. that was usually in the form of so-called street BASIC, mostly compatible dialects. It's little wonder that the story of Star Trek involves so many ports and modifications just to get the program running. The saving grace here is that by BASIC's very nature, Star Trek was open source. BASIC programs had to be distributed as source code since, well, almost no versions of BASIC output compiled binaries. People were able to modify Trek to get it onto newer systems. That mutability meant programmers were able to

change the game itself. It didn't take long for new versions of Star Trek to hit the scene. The perfect environment was set up thanks to BASIC's limitations, newsletters, books, and programmers with too much free time. Once the limits of BASIC and teletypes were reached, and once newer technology came around, it was a no-brainer to port Trek over once again. Or, at least to port over the core gameplay of Star Trek. At the end of the day, Mayfield made a great game. It doesn't matter if you're playing it on a paper feed or a fancy flashing CRT. Thanks for listening to Adjunct of Computing.

I'll be back in two weeks' time with another piece of computing's past. And hey, if you like the show, there are a few ways you can support it. If you know someone else who'd be interested in the history of computing, then why not take a minute to share the show with them? You can also leave a review on Apple Podcasts. And if you want to be a super fan, you can support the show directly through Advent of Computing merch or signing up as a patron on Patreon.

Patrons get early access to episodes, polls for the direction of the show, and bonus content. You can find links to everything on my website, adventofcomputing.com. If you have any comments or suggestions for a future episode, then go ahead and shoot me a tweet. I'm at adventofcomp on Twitter. And as always, have a great rest of your day.