#040: Fur Trader - The Ontario Trail

Release Date: July 1973

Platform: Mainframe (BASIC type-in)

Genre(s): Management Simulation

Developer(s): Dan G. Bachor

Publisher(s): Digital Equipment Corporation

This week's game is quite a fascinating one. Fur Trader is a historical-educational game of several firsts: the first Canadian-made video game, the first business simulation game... there's also some adventure game characteristics, and aspects reminiscent of The Oregon Trail, which Fur Trader also happens to have an interesting connection to... come join the fur trading expedition!

History

Authorship here is attributed to Dan G. Bachor (via Ann Brebner), of the Department of Psychology at the University of Calgary, in Calgary, Alberta, Canada. This also happens to be his only game credit, which is curious to me, as fur trading seems an odd topic for a psychology professor to make a game on. A brief scan of his available academic works also reveal that they have very little, if anything to do with the content of his game, so there's no help there in determining why he chose to make a game about fur trading. Currently, Dan Bachor is on staff at the University of Victoria in British Columbia.

As far as my list is concerned, this is only the second game from Canada - the first being Bertie the Brain, all the way back in 1950. Arguably, it's not technically a video game, meaning that Fur Trader is potentially the first ever Canadian-made video game. And fitting too, considering the game's content is distinctly Canadian.

I'm not really sure what's going on in the cartoon...

After this game was included in Ahl's 101 BASIC Computer Games, it was ported both to the Sol-20 and Commodore PET computers, the latter by Ahl's Creative Computing, and the former, interestingly, by MECC. For those who aren't clued in, MECC is the Minnesota Educational Computing Consortium - the company responsible for developing the commercial version of The Oregon Trail. Fitting, as Fur Trader bears some slight similarities to The Oregon Trail. Outside of that info, crickets, though real-life fur trading role-playing games (furs not included) still appear to be rather popular in Canada as a means of teaching Canadian history to youngsters.

The Game

Fur Trader stands out initially as a type of game we haven't really seen much of up to this point in history: management simulation. There are some lost games that could potentially fall under the umbrella of business/management sims, but the closest games I've played to this would be Civil War and Hamurabi. Fur Trader still remains distinct from those two in that this is a game strictly about running a business and turning a profit. Those other two games certainly involve management, but as a means for a different purpose, rather than the management itself be the purpose of the game.

We ain't buying your clanker junk!

As I've been mentioning throughout the article, this game is also primarily concerned with Canadian history, also serving as something of an educational title. Fur Trader is set in the year 1776, and you play as the leader of a French Fur Trading expedition in the region surrounding Lake Ontario. This year's expedition has been declared a great success, and you are now returning to sell your wares at a select destination. There are three destination forts to choose from, each varying in several ways:

1. The first fort is Fort Hochelaga, in Montreal, and is the "easy" route of the game. The journey is a safe one, with the fort under the French Army's protection. On account of the ease of the return trip here, your furs sell for the least amount of the three forts, and the supply cost is the highest - no doubt to pay for the hungry soldiers.
2. The second fort is Fort Stadacona, in Quebec. This is the "medium" route. The fort here is also under the Army's protection, however the road there is more perilous, requiring your troop to make a portage and cross the Lachine Rapids. The value of your furs here is a middle ground between the other two forts, as is the cost of supplies. The soldiers must be more well-disciplined and less prone to gorging themselves on the available rations here.
3. The third and final fort is Fort New York. This is the game's "hard" route, with the Dutch controlling the fort, and the route necessitating traversing the lands of the Iroquois. One the flipside, this route gives the highest payout for furs, and has the cheapest supplies.

At these forts, your expedition has 190 furs to sell. You get to select how these 190 are distributed between the four different pelts: mink, beaver, ermine and fox. Each appears to have a different value, but the exactness of their value is something that the player can only figure out through doing some external calculations. My initial assumption was that mink would likely be the most valuable, which is generally in line with my playing experience - beaver also tends to sell quite well, while ermine was generally the poorest performing fur during my playtime. Fox pelts tended to have the most variance in value - sometimes as valuable as mink and beaver, and sometimes performing as poorly as ermine.

The starting situation.

On this, I also noticed that there seemed to be a vague formula the game uses to determine how much you get for your furs at each fort. This is purely anecdotal, so take it with a grain of salt, but it appeared to rely on the total amount of each fur selected, and (like the game suggests) the route chosen. At the easiest route (Fort Hochelaga), I tended to get paid around 66 - 75% of the total of each pelt I had, while at the hardest (New York), it tended to be 90 - 110% of the number of each pelt (again, with ermine typically being the worst performing). The middle route (Fort Stadacona) tended to have the most variance, with each fur netting between 75 - 110% of its total number - mink and beaver being the best performing.

No! My precious beaver pelts!

All this discussing furs a their value is well and good, but it doesn't mean much if you can't actually get them to their destination. Fur Trader makes the difficulty distinction between routes evident by having random events that can occur on each separate route that can cause harm to the year's expedition. Events can affect your overall expedition, or can be specific to one type of fur. For instance, at Fort Stadacona, there is a chance your beaver pelts may be too heavy to make the rapid crossing. Alternatively, your canoe might flip during the crossing, causing you to lose all your furs. At the most extreme point, your game can end early if, on the Fort New York route, your party is ambushed and killed by an Iroquois raiding party. Game over. Yikes. That certainly raises the stakes a bit, eh?

I'll admit, I didn't come across that event on my first playthrough, and it came through experimenting with the different routes, seeing what could potentially happen on each. From my testing, it seems that nothing bad ever happens on the easy route (Hochelaga), and the risk increases from there. The other two routes seem to have two, maybe three bad events that can occur - I'm not sure if I saw them all. One thing I did see was a random game crash, though, and that's also a bad event, but an unintended one.

RIP. Game over.

It's an intriguing game, is Fur Trader. As mentioned earlier, there's definitely some similarities to The Oregon Trail. Perilous river crossings, the threat of native raiding parties... although, Fur Trader is far more simplistic in its gameplay, by obvious comparison. I also detect within some nascent adventure game elements, with the game being more narrative driven than gameplay driven, in some sense. There isn't really a story here, though. It's more a historical setting in which your own story can develop - or, at least, that's what the idea seems to be. That's a gameplay-narrative integration concept that will be more fully explored later down the road, but we can see the seeds of the concept being sown here in Fur Trader.

Anyway, that's a lot of chat for what I've been regularly describing as a "simple" game. There just so happens to be a lot to talk about with Fur Trader, which is a nice change of pace. We still have the scores to talk about, too, so let's do that.

Scores

Time Played: 30 minutes

Difficulty: N/A (Variable)

More or less determined by the player and what fort they choose to go to, although the result of the choice of fort is random to some degree.

Gameplay: 2/20
I can only give Fur Trader a 2, unfortunately, as there's very, very little proper gameplay here, and much is reliant on the semi-random outcomes of your fort choice. The most "gameplay" aspect I can see is figuring out which of the furs has the best value and using that to determine how many of each you take each year. There's also no endgame to speak of, and no real point or objective to the game other than "make money". Unless you die, that is. You can also figure out fairly quickly which of the furs make the most money, and capitalise on them, which trivialises almost the entire point of the game.

I'm being slightly more generous with the score here, because I can give props to the game for its simple attempt at trying to immerse the player in a historical setting. I argued with myself as to whether the immersion constituted a story, and whether I should include the story metric for Fur Trader, but ultimately decided against it. Fur Trader seems more in-line with Civil War or Hamurabi in the sense that it's not exactly trying to tell a narrative, but has narrative elements built into the gameplay. If Fur Trader didn't have this narrative/immersion aspect, I'd probably have given it a 1, to be perfectly frank.

Controls: 5/10
Nothing unusual or out of the ordinary here.

Visual: 1/10
It's not formatted very well at all. There's large chunks of unformatted text that are cluttered and hard to read, like the descriptions of the different forts; the numbered list isn't formatted correctly. The code was ported over to the '78 edition of BASIC Computer Games, so the poor formatting suggests the author wasn't overly familiar with programming BASIC, as we've seen far more well-formatted games predating Fur Trader.

Functionality: 4/5
The game can randomly crash at certain points, but seems to be a rare occurrence.

Accessibility: 3/5
While a lot of reading is required, it's not overly wordy, and the game is intended somewhat for educational purposes. No actual knowledge of Canadian history is required to understand what's going on, either, so I'm comfortable with giving this a standard text-based game score.

Fun Factor: 3/20
I think there's some merit to exploring the possible outcomes the game provides for each fort, and for experimenting with how much of each pelt to take, so it has some replay value and interest beyond its incredibly basic gameplay. The historical setting also intrigues me, but I'm biased as a history nerd.

Overall, Fur Trader only ends up with a score of 18 - just enough to keep it out of the F-tier, and put it at the bottom of E-tier. I do feel kind of bad for the score, as a solid amount of effort has been put in to make something rather interesting. However, it just doesn't fare well from a game design perspective. There's little player agency, and there's just not really much point to the game outside of teaching some Canadian history. Feels like a lot of words for what I'd objectively call a "bad" game. At least it's an interesting kind of bad.

Next week is back to the simple, pen-and-paper type games - a common childhood game that, surprisingly, hadn't gotten the digital treatment as of 1973.

#039: Flip Flop - Xs and Os

Release Date: July 1973

Platform: Mainframe (BASIC type-in)

Genre: Puzzle

Developer(s): Michael Kass

Publisher(s): Digital Equipment Corporation

We're continuing in the realm of basic (ha) puzzle games today. Flip Flop, while it's an odd name, turns out to be a fairly straightforward logic puzzle.

History

Flip Flop continues our run in the original publication of David Ahl's 101 BASIC Computer Games. It's not a game of Ahl's own making, instead being submitted by a Michael Kass of New Hyde Park, New York. Unfortunately, I can't precisely identify this Michael Kass; even AI couldn't help me with this one. MobyGames lists him as attending Herricks High School, the major high school servicing the area, but after that the trail goes completely cold. Kass has no other known game credits, either, so nothing to go on from that end, either. There is a well-known computer scientist named Michael Kass, who worked on several Disney-Pixar films, but there simply aren't any tangible connections that can be made. Plus, that Michael Kass looks too young to be Flip Flop's creator.

These illustrations really are something, aren't they?

Flip Flop also received a couple of ports, one by Creative Computing itself for the Commodore PET in 1979, and a second done by the Association of Computer Experimenters for the RCA COSMAC in 1980. That's all the info I've got. I tried scanning the archive of Creative Computing Magazine as well, but found no mention of the game anywhere, despite CC doing their own port of the game. In some sense, I'm not surprised, considering how insignificant this game is in the overall scheme of computing history.

The Game

The nature of the puzzle of Flip Flop is, like the last game I did (Even Wins), hinted at in the game's title; something's getting flipped - fortunately it's not tables. No, the simple objective of Flip Flop is to turn a row of 10 Xs into Os. That's it. Not pulling your leg, that's literally all you have to do.

Here's how you "flip flop."

It's the how you flip the Xs where the puzzle element of the game comes in. Each X corresponds to a number - 10 Xs, 10 numbers. To flip the X, you simply input the corresponding number, and the X will turn into an O - just like a binary switch. However, there is a catch: some numbers don't always flip their corresponding X alone. Some of the numbers will also flip another, random X in the sequence. So 1 might flip itself and 5, or 4 might flip itself and 2; some of the flips are one-way, so 4 might flip 2, but 2 may not necessarily flip 4. It's up to the player to figure out how to make it all work together to flip the whole sequence. If you do happen to get stuck, there's two different ways provided to restart: type 0 to reset the current sequence to all Xs, or type 11 to start over with a new sequence.

An easy game.

On top of that, this isn't a one-and-done game with a single, set puzzle. No, each round the algorithms are randomised; no two rounds are the same. From a replay standpoint, it's great, but it's a double-edged sword. This mechanic also has the nasty side effect of making some rounds significantly harder than others. 101 BASIC Games states that you should be able to get the sequence flipped in 12-15 moves. In some cases, I could get it done in 8-9 moves because the sequence had no tricks. In other cases, the sequence was so confusing that I just gave up and started a new round. It would've been fun if there was a level structure that increased in difficulty more consistently, but we're not really at the point of game design yet where devs figured out that that was probably a good idea. Decimal Darts is really the only game I can think of that actually has a conventional difficulty curve up to this point in time. It's only a matter of time, though.

A not-so-easy game.

There's not a whole lot of sense in doing a play-by-play commentary for Flip Flop. It's not really the kind of game conducive to that style of writing and is probably better discussed within the context of my scores. so that's where we'll head now.

Scores

Time Played: 20 minutes

Difficulty: N/A (Variable)
Since the patterns change each round, the difficulty varies wildly. Some times it's incredibly easy and I win in 8 guesses - other times it seems impossible and I have to start over.

Gameplay: 2/20
If the algorithm wasn't randomised each round, this would get a 1. It's a double-edged sword, though; randomisation ups the replay value, but the rules are so simple that it ends up lacking the depth or interest to make it worth replaying. The randomisation also adds a severely fluctuating difficulty curve which I didn't appreciate.

The other way the game could've gone about the replay vs. depth problem is by upping the complexity of the algorithm, but make the puzzles more static. The numbers could flip up to 4 other numbers, for example, but the algorithm is set. Or, add difficulty levels; the easiest being 1-2 numbers change, then 3-4, then 5-6 for a hardest difficulty. That way, replay value is added from having more challenging levels, and depth is added through the levels gradually increasing the complexity of the puzzle. I know this is a 1973 game, and game devs didn't think like that yet, but a man can dream.

Controls: 5/10
As adequate as can be for a text-based game.

Visual: 1/10
The formatting is quite poor on this game. I would've liked to have seen more line breaks, as it feels very cluttered and is hard to read.

Functionality: 5/5
No issues found.

Accessibility: 3/5
Fairly standard for text-based games.

Fun Factor: 1/20
I didn't particularly enjoy this puzzle. Too simple, and too much variability. Not conducive to replayability, and I lost interest in it pretty quickly.

Overall, the scores don't make for great reading here: a final score of 17, earning a spot at the tippy-top of the F tier. These little throwaway games aren't really enthusing anybody these days. I wish I could get through them more quickly, but the current pace of life doesn't allow for that. Next week's game promises to be a little more interesting, at least.

#038x: Even Wins - Cybernetic Version

Release Date: July 1973

Platform: Mainframe (BASIC type-in)

Genre: Puzzle (Nim Variant)

Developer(s): Eric Peters

Publisher(s): Digital Equipment Corporation

Trust me, it sounds way cooler than it actually is.

History

This little side quest is a follow-up from last week's Even Wins article. As I stated there, 101 BASIC Computer Games has two versions of Even Wins. The one from last week's article is the original, which uses a conventional AI. This one, which is called EVEN1 and Game of Even Wins by the two versions of the book respectively, does something a little different with its AI: it learns.

This version of the game was written in-house at DEC by Eric Peters, who also developed the Lunar Lander variant, Rocket. MobyGames dubs his version of Even Wins the "Cybernetic Version" (I think based off of the game's description in-book), uses a different AI pattern that begins only knowing the basic rules of Even Wins, and progressively learns how to play the game better over successive rounds.

A quick refresher on Even Wins.

The whole idea of "machine learning" in this sense isn't new to the blog; we've previously seen this form of AI learning in a couple of previous programs. Animal is likely the most notable, although is different in the sense that the player was the one teaching the computer different questions and animals, instead of with games like Awari and this version of Even Wins, where the computer learns by itself. Animal, as a side, happens to be one of my most-read articles, though I honestly don't know why - it's not even a game. This is supposed to be a gaming blog!

The Game

Anyway, I said this was going to be a short one, so let's get into it.

Look familiar?

First of all, the game is almost entirely re-written from the original, and has significant differences as a result. Visually, the game presents the objects as chips instead of marbles. Mechanically is where the majority of changes are, however.

No longer is the pile of objects set at 27 - it's now a random, odd number. The game code suggests that a pile size of a single chip could be generated (there is failsafe code in place for this occurrence); in practice it tended to be between 7 - 21 chips.

The player does not have the choice of going first or second anymore. Instead, the computer always goes first. I find this a curious choice, with first being the advantaged position. However, it makes sense in the idea that it showcases how the AI begins squandering its advantaged position, but progressively learns the game and gets to the point where it can rarely be beaten.

Bro is pretty stupid.

On the note of the AI, it does indeed start out woefully bad at the game. It makes some truly bizarre and illogical choices, and continues in that pattern from quite some time. Sometimes it will completely blow a winning position, like being at 5, myself taking 1 chip, being on an even number, and it'll just take the whole pile like it's giving up.

...but he does get better. Eventually.

Eventually, it does start to get good, and did start taking game off me. However, I seemed to have found a flaw in its algorithm, as there was a particular strategy that it just couldn't figure out. I would force the pile, if I was on an even number, to 9 chips remaining. From there, the AI would always take 3 chips, putting me in a position I would always win from. It never learned how to beat this strategy - I must have beaten it 10 times in a row at least.

Closing Thoughts

No scores for Even Wins: Cybernetic Edition. For one, I think it's somewhat redundant as it's functionally the same game as the source. It's more of a showcase of AI programming, which is inherently interesting to me and worthwhile not skipping over just because of "redundancy." Every game matters.

#038: Even Wins - An Odd Duck in the Nim Family

Release Date: July 1973

Platform: Mainframe (BASIC type-in)

Genre: Puzzle (Nim)

Developer(s): Unknown

Publisher(s): Digital Equipment Corporation

History

101 BASIC Computer Games already has several variants of the ancient game of Nim. We've already seen Batnum (the 1970 version) and Nim (otherwise known as Gamnim), and now we've arrived at the final variant of the "piles of objects" games in the original version of the book - Even Wins.

Fittingly, there's an even number of games.

This is actually a pair of games, as there are two different versions of Even Wins present in the book, creatively named EVEN and EVEN1. The 1978 version of the book calls them Even Wins and Game of Even Wins, respectively. Here, I'm looking at the former of the two, which happens to also be the original version of the game.

What's the difference between the two games? It comes down to how the AI is programmed. In the former of the two, the AI runs with a set algorithm, essentially a "set" difficulty, whereas the latter leans more into the "machine learning" style of AI that's cropped up a few times before. This "Cybernetic Version," as MobyGames calls it, implements an AI similar to that present in a game like Awari, where the AI starts of not being very good at the game, but improves its play over multiple rounds as it "learns" how you play. 101 BASIC Games states that it'll take about 20 rounds for it to become "a challenge to beat." I'll be covering this latter version of Even Wins in the next article, probably as a Gaiden article next Tuesday, as it seems redundant to dedicate a full Friday release to the same game two weeks in a row.

This and the original are the only media I could find on Even Wins.

While we know who developed the EVEN1 version of the game, Eric Peters of DEC, the author of the original game is unknown. I even scoured through several computing magazines to see if there was any mention of the game or a possible original author, but to no avail. Neither PCC nor Creative Computing even make mention of the game.

The Game

So, what makes Even Wins different to the other Nim games? Hint: it's in the name. The same gameplay loop is present, of two players taking turns removing objects from a pile - a pile of 27 objects (marbles) in this case - no more, no less. How the victor is determined is the major difference. In the typical game of Nim, it's the person who takes the last object that wins or loses, depending on the ruleset. In Even Wins, however, it's the amount of marbles the players take the determines the winner. Whoever has an even-numbered pile of marbles when the last marble is taken wins. It's why the game starts with a pile of 27 - it has to be an odd-numbered pile for the game to work. The aim of each player then becomes to force the other into ending with the odd-numbered pile.

Here's how the game explains itself.

Forcing the AI opponent into losing is easier said than done. Unlike some of the other "solved" game AIs I've dealt with in the past (OXO, Batnum '67), Even Wins' AI presents a stiff challenge, but not an unbeatable one. 101 BASIC Games' take on the difficulty is "the computer... is impossible to beat if you don't know how to play the game." So tough - but not impossible.

In practice, I found this to be a very accurate assessment of the game's challenge. Unlike a game like Batnum '67, I wanted to try and beat the game without doing any sort of research into the winning algorithms. Naturally, I got stomped pretty badly the first ten times I played because I, like the book says, had no idea what I was doing. Once I got a handle on what I needed to do, by observing the way the computer played - that's when my progress in beating the game moved in a positive direction.

How most rounds end up.

I observed that the computer liked to try and force me into a position at the end of the game where there was 5-7 marbles remaining. That seemed to me to be the red zone where the winner is always determined; whoever forces their opponent to take marbles when 5-7 are remaining will always be the victor. So I looked over the previous matches and observed what moves the computer made - what numbers it liked to leave the pile on at the end of its turn, and how it responded to my moves - and tried to incorporate those moves into my own strategy.

After about 15 minutes worth of attempts, I had a win! I was able to manipulate the pile into a position where I had it end on 11 marbles - apparently a key position, which allows making the decisive move into that 5-7 range. Admittedly, I was quite chuffed about this - the computer really made me earn that win. I was also extremely relieved that this wasn't another one of those "impossible games" situations, where the AI is programmed to be perfect, mercilessly slaughtering all comers who would dare challenge its genius.

Victory!

However, I'll briefly note here that, from all my testing a playing, that the only position the player can win from is by going first. I was unable to win going second. This is typically the case in most early Nim variants and other solved games, that winning is only viable from a certain starting point. Some, it's going second, others, like here, it's going first. It seems that going first is the position of control and dictating the flow of the game.

A Brief Word on Difficulty

There's something to be said here about games and difficulty. It's apparent to me that balancing the challenge level of a game can have a vast effect on the overall quality of the playing experience. Take Batnum '67, for example (one of my favourite punching bags as of late). That game makes it nigh-on impossible to beat the AI outside of the deliberately programmed first round. The level of challenge is far too high, and it royally sours the experience, because I know I can't beat the game. What's the point in trying? LEM suffers the same fate, but more because that game is far too complicated for its own good.

On the opposite end, there's Batnum '70 - the younger brother of Batnum '67. That version allows for near-endless customisation of the game rules and settings, so much so that I can just manipulate the game state to where I'll always win - Bomber also has the same problem, for a more recent example. This also ruins the game experience, but at the opposite end of the scale, because I can basically cheat in a game-approved way to always win. And, like the near-impossible games: what's the point in playing?

Just some brief shower-thoughts for your consideration. If you have any thoughts, considerations or counter-arguments, I'd love to hear them in the comments. With that out of the way, let's score Even Wins.

Scores

Time Played: 13 minutes

Difficulty: 6 (Challenging)
It's like the book says: impossible to beat if you don't know what you're doing. I needed to play a few rounds to get a grip on how I needed to manipulate the numbers to get into a winning position. Watching what the computer was doing in response to my moves, and where it boxed me in helped to give me an idea of what I needed to do to beat it.

Gameplay: 4/20
This reminds me of Batnum '67 but better in the sense that the computer is beatable without the game having to do some weird programming nonsense to force the AI to make a mistake in the first round. Otherwise, Even Wins is more-or-less the same game, except with the difference of how to win, which did subtly change the way I played compared to the other Nim variants. It's got that going for it at least, and the computer being beatable presents a proper challenge to overcome, which I feel like I earnt over the course of playing the game. Even Batnum '70 doesn't feel as rewarding due to the customisation options of it permitting me to manipulate the starting parameters in my favour, hence why I think Even Wins is slightly better than it.

Controls: 5/10
It does that funny thing that Cube does where you have to use binary for yes (1) and no (0), but it doesn't feel as intrusive or unintuitive here as it did there.

Visual: 1/10
Even Wins is very rudimentary on the visual front. It's only text, no other formatting tricks like what we've seen in other text-based games from 1971 - 73.

Functionality: 5/5
No bugs present during normal gameplay.

Accessibility: 3/5
Putting this as standard for a text-based game.

Fun Factor: 5/20
There's nothing Earth-shattering here, just a simple puzzle game, but I actually did enjoy trying to beat the computer somewhat. It was a stiff enough challenge that didn't feel too far out of reach, so I enjoyed the process of trying to figure out how to beat the AI.

Overall, Even Wins earns a score of 23 - much better than what I was expecting coming into the game. It's tied with Dartmouth Championship Football in terms of total score, but Even Wins has the better gameplay and fun factor, so it wins the tiebreaker of which is the superior game.

Next up I'll be doing a short side article on the Cybernetic Edition of Even Wins, which will be coming on Tuesday. After that, we have a rather oddly-titled game for Friday's full release. 

As a side, I hope everyone is enjoying the new article on the origins of video games. I had been feeling quite dissatisfied with my early work on that period of time for a while, and felt a revisit was due. I'll likely do individual pieces on all of those early games periodically, in the lead up to revisiting some of my early articles. My writing and research is much improved from two years ago, and I'd like to give those games the respect due them. Thoughts and feedback are always appreciated - I'd like to hear from you readers what you'd like to see out the blog, and what improvements I could make.

Don't forget - if you enjoy my blog, be sure to leave a comment and hit the follow button so you don't miss any updates!

Where Did Video Games REALLY Start?

So, way back when I started the blog, I made the assertion that I believed that Christopher Strachey's Draughts was the first video game ever. My stance on that solidified as a result of watching Stuart Brown's (Ahoy) video essay on the subject of the definition of a "video game", and what, based on that definition, ought to be classified as the first "true" video game. Incidentally, I don't think you should really read those early posts - my writing and research was quite lazy. Putting multiple games in a single post was a mistake - a mistake I may potentially look to rectify in the near future.

I still agree with Ahoy's assessment that Draughts is the first true video game ever made. However, that's not a consensus opinion. Plenty of people would disagree with me. There's plenty of other takes on the "first video game", and games that predate Draughts that could be argued as the first. Some say it's OXO, others Tennis for Two, and some would even say Spacewar! or Pong is the first. Ralph Baer, of course, argued that his "Brown Box" that would become the Magnavox Odyssey was the first. Here in this article, I'm going to discuss those other contenders (except Pong and the Odyssey, because ignoring 25 years of prior history to them is absurd), and attempt to settle on a definite date for when the concept of the "video game" was born.

As I'm sure we're all aware of, especially if you've been around this blog for any length of time, the video game spawned out of the world of computer science. Computing technology had been slowly developing over about a century, starting with the mechanical computing devices invented in the 19th century - Charles Babbage being the chief instigator of that with his "Difference Engine," and later the "Analytical Engine." Calculators and other similar, mechanical and non-electronic devices continued development (we can't forget that the arcade existed, either) up until just prior to the outbreak of World War Two. 

The war seriously accelerated the progress of computer development, in the West especially to counter the advances of the Germans in their Enigma encryption technology. The Germans also had access to one of the world's first digital computers: Konrad Zuse's Z3. The Brits countered first with their "British Bombe" electro-mechanical codebreaker, and then with the Colossus computer in 1944 - the ultimate code breaking machine.

After the war, however, there was naturally less of a push for state-of-the-art defense technology, allowing for peacetime efforts in computing to be directed elsewhere, particularly games. For instance, Turing, in 1948, began experimenting with creating a Chess program, which he called "Turbochamp." He worked out the algorithms by hand and tested them against his colleagues, before getting to work programming it on a Ferranti Mark 1 computer - a task he would never finish. Despite him not finishing the program, it shows that there was interest in using computers for gaming purposes very early on in the minds of the great coding wizards.

Several other computer scientists experimented with games programming, though not initially for the sake of leisure, but more for the purposes of developing machine learning and artificial intelligence. Particular interest was given to what are called "solved" games - games that had a "perfect" way to play them, discoverable through use of computers calculating the algorithms. Chess and Checkers are such games, hence why there was much interest in them early on, but also Tic-Tac-Toe and Nim were also of interest as much simpler "solved" games. Some games were designed purely for recreational purposes, but those were much rarer across the early decades of video games (1940s - 1960s.)

Now that I've given more of a surface-level overview, we're going to zoom into a few examples of early computer games. Timing wise, I'm going to end off in 1952 with a revisit of Draughts and OXO. I'm only interested in the origins of the computer game here, so going beyond that point is unnecessary in such an introductory article. Each game will only be getting a brief summary, both to prevent this article from becoming a master's thesis, and to leave room for expanding this article into a "revisit" of my prehistory series. If I'm honest, I'm not totally satisfied with my early articles and the lacking research I did, so revisiting the series is something I'm strongly considering, both to fix my mistakes and refine my research methodology further.

Cathode Ray Tube Amusement Device (1947)

Patent schematic.

An electronic game designed by Thomas T. Goldsmith, Jr. and Estle Ray Mann. This is usually cited as the earliest example of a video game by most historians I've read. Personally, I don't think it really counts, as it was only ever a patent. Never was this device constructed, and I think that's important when discussing the "first video game." It's one thing to have the idea and the blueprint for it, but it's another thing to actually build the device to see if it works. 

However, the description of it may sound vaguely familiar. The player would sit in front of the CRT, presented with a game in which you fire artillery shells at designated targets painted on the CRT's screen. The shells, represented by a dot on the screen, were able to be manipulated by the player with a control knob. The player was to move the dots over targets painted on the CRT screen that represented aeroplanes, pushing a button to then fire the shell. If successful, the screen would simulate an explosion.

That does sound very much like an early arcade or second-generation console video game to me - part artillery game, part flight combat simulator. Considering what was to come after this patent was filed, this electronic game concept was quite ambitious and forward-thinking. Certainly not a "solved" game, like most of the other early examples of computer games. It does make one wonder what might have been if the thing was built, though...

Bertie the Brain (1950)

Comedian Danny Kaye was a fan.

Electronic game development goes quite for a couple of years after the CRT Amusement Device was patented. 1948 and 1949 don't see much progress in electronic game development, outside Alan Turing's previously mentioned Turbochamp Chess program, and some other computer scientists doing similar experiments that were strictly not intended for recreational purposes.

That leads us to a new decade - the 1950s - and the next milestone game: Bertie the Brain. Like the computer scientists' experiments, this machine wasn't entirely intended to just be a for-fun amusement. Its creator, Dr. Josef Kates, created it as a marketing ploy for his newest invention: Additron tubes. Kates intended for these tubes to replace the earlier, more fragile Thermionic valves. One Additron tube was equivalent to ten Thermionic valves!

With support from his former employer, radio and electronics company Rogers Majestic, Kates' went about constructing a machine to display the potential of his new invention. What he decided on was to make a device that was able to play Tic-Tac-Toe against a human opponent. The result was Bertie the Brain, a four-metre tall electronic box that offered passersby at the 1950 Canadian National Exhibition (where Bertie the Brain was put on display) a novel game of *Noughts & Crosses.

The display consisted of incandescent tubes that lit up with an X or O - not really a true "video" display if we're working with Ahoy's definition of a video game. The control panel was quite intuitive - nine buttons, one for each box of the game grid. What I find most interesting about Bertie the Brain from a game-design standpoint is that it had adjustable difficulty. Kates was able to adjust the level of challenge to suit whoever was playing at any given moment. Accommodating for a child, merciless and unbeatable for a skilled adult player. It's a clear forerunner to the varied DIP switches found on just about every single arcade video game from Pong onward.

Nimrod (1951)

Looks like the lair of an evil genius.

Across the Atlantic, something curiously similar to Bertie the Brain was being developed. British computer manufacturer Ferranti were gearing up for the 1951 Festival of Britain. However, their promise of preparing a new computer for the festival was seeming less and less likely to be fulfilled. That's when John M. Bennett, an Australian (hype!) computer scientist and employee of Ferranti suggested the idea of making a computer that played a single game: Nim. Bennett was inspired by a similar, electro-mechanical Nim-playing machine that had appeared a decade prior called the Nimatron.

Once again, however, the purpose of this "game" was not to simply be a game. Bennett wanted Nimrod to be a display on the basics of computer programming. Most onlookers were, according to Bennett himself, "quite happy to gawk at the flashing lights and be impressed." Some were more determined to try beat the artificial intelligence. Like Bertie the Brain, Nimrod used incandescent lamps to indicate game progress, and used a push-button panel as the control scheme. With the lack of video display, Nimrod also fails to perfectly meet the definition of a video game.

Nimrod also went on a small world tour, heading to Germany after the Festival of Britain exhibition concluded, and then after Germany to Canada. Also like Bertie the Brain, once Nimrod had fulfilled its purpose, it was sadly dismantled. This wouldn't end Ferranti's contributions to early video games, however.

Draughts (1952)

Recreation of what the game would've look like.

Now for my first true revisit on the blog. Christopher Strachey's Draughts was one of the very first games I covered on the blog. There wasn't a whole lot of depth to the research in that article, as I paired the game with A. S. Douglas' OXO. At the time, I thought it made more sense, since Draughts is a game lost to time, to pair it with another game to make the article more substantial. In retrospect, I think that was a mistake.

The story of Strachey's Draughts goes back into 1951, parallel with the time Nimrod was in active development. Strachey has just joined the National Physical Laboratory (NPL) in Teddington, England. Just prior, the NPL had completed the Pilot ACE - one of the country's first computers, based on an Alan Turing design. Strachey, wanting to familiarise himself with programming on the Pilot ACE, chose to create a Draughts (or Checkers, if you prefer) program.

However, his program was too much for the Pilot ACE, and totally consumed the system memory. This led him to look elsewhere for a more capable computer to run his game. Ferranti re-enters the scene, as they happened to have just the computer Strachey needed - the Manchester Mark 1. Incidentally, Stracey and Alan Turing were colleagues, and so Strachey was able to request that Turing send him the manuals for the Mark 1. By October of 1951, Strachey had transcribed the program, but it took until July 1952 to get the game fully functional.

By all definitions, Draughts is certainly a video game, and the first one that is purely software. It uses two CRT displays to show game progress, and the player inputs are through buttons. Strachey also programmed in various reactions the computer would give depending on player actions, such as telling them to hurry up or berating them for not playing properly. It's apparent to me now that this is where the trend I've seen of text-based games berating the player started. Also noteworthy is that Strachey included one of the earliest instances of computer-generated music in Draughts, where, upon the conclusion of a game, the computer would play a short piece of "God Save the King."

One final distinction earned by Draughts is that it's the first video game to directly inspire a future game. Back across the Atlantic, Arthur Lee Samuel created his own Checkers game for the IBM 701 computer, which became a pioneering work in machine learning, as the game's computer opponent could learn to improve its play.

OXO (1952)

A draw - again.

The final game in this overview of the beginnings of video games sees us staying in the United Kingdom. OXO is another software game developed for the EDSAC (Electronic Delay Storage Automatic Calculator - try saying that five times quickly), stationed at Cambridge University. Alexander Shafto Douglas was its creator, a computer scientist with particular interest in the relationship between humans and computers. Once again, this is a game that was not created just to be a game.

Like Draughts, OXO is one of the first games to use a graphical CRT display, making it, by my definition, a full video game. The control scheme is of particular interest, though, as it uses a rotary phone dial as the input. I bet some of you younger readers have no idea what a rotary phone dial is. Google it. Since Douglas' purpose for OXO was to be a part of a thesis on human-computer interactions, any sort of difficulty or gameplay wasn't considered; the computer plays a perfect game of Tic-Tac-Toe, meaning that the player can never win. The player was never intended to win.

Final Thoughts

If we want to answer the question posed by the article, there's two possible, more definite ways to answer it, in my opinion. The first is to just start at the very very start, saying that the Cathode Ray Tube Amusement Device is first, simply because it was the first video game concept ever created, despite the fact that it was never built.

Video games were invented: 25th of January, 1947.

The second, and this is where I land, is to find or develop a working definition of "video game," and determine what's first from there. As said at the start, I use Ahoy's definition, which sees Draughts and OXO as the first true video games. Although, it could be argued that these two games don't perfectly fit his definition, as his fourth point, "Be principally intended for entertainment", is not directly met by either. They weren't intended exclusively as entertainment, but as training (Draughts) or academic (OXO) exercises. Still, there's enough recreational merit in both to meet the definition of a video game, in my mind.

Video games were invented: 30th of July, 1952. 

There were some other games floating around at the same time, like Sheep & Gates, also on the EDSAC, which Ahoy also briefly mentions, but none of those caught much attention and continue to live in obscurity (perhaps something I will seek to remedy?)

That being said, answering the question is not really that simple. History is rarely ever simple. You could look at the pinball industry, or electro-mechanical arcades and say that the seeds of video games are present there, particularly when a computer game like Nimrod was directly influenced by a similar, electro-mechanical arcade game developed a decade prior. When electronics and technology advance, the effects eventually filter down into other industries, and that's what we see with the origins of video games. Computers become more advanced, then get incorporated into arcade games, etc., etc.

Personally, I always find the origins of things fascinating. There's always an opportunity to see the seeds of what was to come being planted. The curious thing with the origins of video games, is that just about every game is an island. They all exist in their own spaces, not influenced by each other, nor do they influence any future games. While Bertie the Brain and Nimrod were publicly displayed, they had no sequels, nor was anyone inspired to do something similar by them. Draughts and OXO were purely academic works, inaccessible to the public and created as part of personal projects - although Draughts did inspire one other Checkers game. The influence of these games lives far more in the realm of computer science than video games. We don't actually see any substantial video game "family trees" begin, per se, until Spacewar! and The Sumerian Game appear in the early 1960s.

What are your thoughts on the first video game? Do you agree with me? Or do you prefer a different game be labelled the "first"? Did I miss a game? I'd greatly appreciate it if you shared your thoughts in the comments. This is potentially the start of a "prehistory revisited" series that would feature more robust and well-researched articles. Let me know if that's something you would be interested in seeing from me.