18 September, 2025

#016x (Gaiden 01) - Animal: "Machine Learning" Taken Literally



Release Date: April 6, 1973

Platform: Mainframe

Genre: Non-game

Developer(s): Arthur Luehrmann, Nathan Teichholtz, Steve North

Publisher(s): Digital Equipment Corporation


And now for something... really different. I'm not even sure this qualifies as a game, to be completely honest. It's more like... artificial intelligence training

I'll explain what I mean. Animal is a guessing game, except the one doing the guessing is not the player, but rather the computer. Your role, as a "game master" of sorts, is to teach the computer new animals. You start by thinking of an animal, and then the computer will asks questions to try and guess the animal. It only knows two to start with - fish and bird - and only three questions, but you can teach it new animals, and to ask questions to distinguish between animals. 

The concept for Animal was developed at the home of BASIC, Dartmouth College, by Arthur Luehrmann. I found a substantial interview he did with Kevin Bunch at Atari Archive back in September, 2022 that gives plenty of background on Luehrmann's life and career. I rather enjoy a lot of Bunch's work, and it's a great interview. Luehrmann was a physics professor at Dartmouth from 1965 - 77, and was an early champion of BASIC, writing a few games other than Animal, including one called PotshotAnimal is briefly mentioned in the interview, but is not the main focus of the interview. Most the discussion they have on that game is on the need for a "filth filter" to parse out all the possible vulgarities college students might invent when given free reign to type whatever they like into a game. Animal just seemed to be another of the many experiments conducted with BASIC during its formative years.

I hope that's not how the computer pictures said animals...

Digital Equipment Corporation later got their hands on Animal, where it was modified by Nathan Teichholtz and included in 101 BASIC Computer Games. Steve North of Creative Computing (David Ahl's post-DEC organisation) would further modify the game when the microcomputer edition of the book released in 1978. One of the distinguishing features of the original game was its being one of - if not the very first game - to have a save feature. All of the information you taught the computer could be saved to be used next time the program was run. Theoretically, you could spend a couple of hours teaching the computer several animals, and then invite a friend to test what the computer had learned.

However, the save feature is not in the 1978 modification of the game, which also happens to be the version I have access to. The write-up claims that you could theoretically modify the game to allow for a form of saving, but that could only be done if your system allowed for it. Admittedly, I think this kind of defeats the purpose of Animal. You need to spend a decent amount of time teaching the computer various animals, and having nowhere to save that data spoils the fun.

The '78 edition page on Animal. Now with less scary monsters.

I know I've referred to Animal as a game throughout the article, but, after researching and playing it, it's not really a game at all, if I'm being blunt. My thoughts circulated into one summary point to describe Animal - and it's a weird one, so bear with me - which is that the program is essentially a flowchart creator. The computer asks you a question, like "does the animal swim?" and, based on your answer, it will ask another question (once you build up its database.) It's literally:

  • Ask question
  • If yes, then A
  • If no, then B
  • Repeat until animal is guessed

And you can expand the flowchart as much as you want. It's a novel idea, and, as the '78 edition of BASIC Computer Games suggests, it has potential use in an educational environment.

What? I like otters. They're cute.

All this is to say, that I'm making this my first Gaiden article. To recap, in case you haven't read the "My Process" page linked in the sidebar (which is probably due for a revision,) I have two main categories of articles: regular articles and "gaiden" articles (Japanese for "side story" - I shamelessly ripped this idea from Fire Emblem.) Regular articles are the main article, denoted by a number, and are simply all the games that my rules permit me to apply a score to. Gaiden articles are marked with an "x" after the number of the previous article, and are for games (or software, in this case) that I cannot in good conscience provide a score for. Usually this would be for multiplayer-only games, but also the odd non-game like Animal. They're also not counted in the game statistics in the sidebar.

So, I won't be scoring Animal. It's not a game - at least, it doesn't fit within my definition of a game. It's more of a historical curiosity; a glimpse into the infancy of artificial intelligence, and also a novel flowchart creator.

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

16 September, 2025

#016 - Slalom: It's All Fake Snow Up Here



Release Date: March 8, 1973

Platform: Mainframe

Genre: Sports

Developer(s): Jonathan Panek

Publisher(s):


[Ed. trying out some new colours on the blog - let me know what you think!]

We're re-entering the strange world of text-based sports games for this next entry. It's always seemed rather peculiar to me that early game developers thought that sports were suitable for text-based games, especially for more fast-paced sports like the one we're examining today. They seem diametrically opposed on the surface, but maybe, because of that, there's the making of an interesting game here? 

Slalom is a winter sports game, based on the slalom discipline of skiing. It's not exactly the first of its kind, as Magnavox's Odyssey console does have a ski game from 1972, creatively titled Ski (plus there's also its cancelled Ski Festival game.) But it is at least the first text-based attempt at a winter sport I know of.

The 1978 edition of BASIC Computer Games informs us that the author of Slalom, J. Panek, was a student at Dartmouth College when he wrote the game. Once again, this is a one-and-done author, though there is fortunately a good amount of information about him online. A quick search provides a LinkedIn profile of a Jonathan Panek, who fits the profile of scant information provided by the book and MobyGames. MobyGames adds that the J. Panek who wrote Slalom attended a St. Paul's school in 1977, which matches Jonathan Panek's LinkedIn profile. He also continued at Dartmouth College after St. Paul's School - in electrical engineering, no less, and later worked at Hewlett-Packard. From this information, I think it's a reasonable conclusion to say that this Jonathan Panek is the most likely author of Slalom.

Game description is savage. Maybe David Ahl didn't like skiing?

Dating the game might be confusing at first (it was for me,) as the source code in BASIC Computer Games has the game's setting as the 1976 Olympic Winter Games. Panek being at St. Paul's from 1971 - 1977 would also suggest that a later date may be likely (IMDB's entry for the game has it listed as a 1975 game.) However, the original source code is online, saved on the Sol-20 website, where it confirms the 1973 date. Panek tells us in the fourth line of the source code that his last work on the game was completed March 8, 1973. He also originally intended the game to be set at the '76 Winter Games, so that mystery is also solved. I do love it when all the data comes together neat and tidy like this.

Now, only one question remains: how do you simulate slalom skiing in a text-based game? The solution Jonathan Panek came up with was to have exclusive focus on one of the main controllable elements of skiing - speed. Slalom then, is all about speed management. At each gate of the slalom course, you have the choice of how much to speed up or slow down (or to maintain your current speed.) Go too slow, and you won't get a medal. Go too fast, and you'll hit a flag and crash out. Doesn't sound too bad, does it? You're even given to option to try and cheat by attempting to skip a flag, which got a chuckle out of me when I first saw it.

Slalom runs a little differently to most other text games I've covered so far. The first thing you do in game is not to look at the instructions. Radical game design. No, you first choose how many gates the slalom course you want to run will have. It can have as many as 25 gates, and as few as a single, lonely, solitary gate. I can't imagine one gate being much fun (spoilers: it isn't,) so I went for a moderate number for my first attempt: 10 gates.

Once you're done with that, then you can read the instructions. But, once again, Slalom does things a little differently. At this point. you've got three options:

  1. Read the instructions.
  2. View maximum speeds.
  3. Start the race.

1 and 3 are self-explanatory, but option 2 appears an odd one on the surface. Basically, this option tells you the approximate top speed for each gate. You'd theoretically want to aim to pass each gate at around this speed in order to get the best time, without going over it, which would risk you missing the gate or crashing. In practice, however, it really doesn't work like this. At all. More on this later.

If I - an Australian - am America's only hope, we're in big trouble...

So I get the maximum speed list for the gates, and off I go. Although, there is one more thing to do before you get to start the race: difficulty selection. The game asks you how good a skier you think you are, with 1 being "worst," and 3 being "best." These are, apparently, the difficulty modes. I'm assuming that 1 is easiest and it gets harder from there. I haven't attempted the harder modes as I write this part. I think this is the first game to have actual difficulty modes, though. Sure, some previous games have had customisation options that affect difficulty, but not actual difficulty modes.

Obviously, I selected 1 for my first go. I've literally never even seen snow before in my life, so you can be sure I've never skied before. With that, I was off on this perilous journey down the course. Gate 1's max speed was 14 MPH, and I started at 13 MPH, so I opted to select option 3 and speed up a "teensy" bit. I pass the gate at 14 MPH.

Gate 2's max is 18 MPH, so I figure I can speed up a bit more, and choose to speed up a "little." 17 MPH passing the gate. Things seem to be progressing smoothly so far. Before I choose what to do at Gate 3, I check my time: just over 29.34 seconds. I don't know if that's good or bad.

Gate 3 represents a big speed jump - I can take it at 26 MPH. I speed up a lot. Up to 25 MPH, to which the game comments, "Close one!" Got to risk it for the biscuit.

However, this risk fails to pay off any further. Gate 4 is at 29 MPH, so I keep speeding up. I snag a flag, and it's game over. Although, I must say I was very confused at this stage of the game. It told me I had gone over the maximum speed, but I had not. My speed at Gate 4 was only 28 MPH.

Err, no I didn't. I want to speak to an official.

The game allows you to try again, and so I did. Same thing happened again, only at Gate 3. The maximum speed was 26 MPH, but this time I was only going 21 MPH and was told I went too fast. I played a fair bit safer on my next attempt, and got to Gate 8 before the same thing occurred. Its max speed was 32 MPH and I crashed out at only 28 MPH.

I then went for another attempt and... something very strange happened. The game printed its race start line, and then I was greeted with the message, "!OUT OF DATA IN LINE 540," and then the game stopped.

This time, the game wiped out.

Did it just crash on me? Several more attempts ended in the same fashion, so it appears to be a bug in the game. There was also a typo I noticed, where "MAXIMUM" was sometimes misspelled "NAXIMUM." What's weird about this typo, however, is that it isn't in either the original source code or the BASIC Computer Games revised code. Both of them abbreviate the word "MAXIMUM" as "MAX." so I have no idea where this error comes from. In fact, the entire line saying you've gone over max speed has been entirely re-written in the version I got from Vintage BASIC. Who did this and when is a complete mystery. I won't be holding this against the game in scoring, and I in fact went into the game code and fixed the spelling, just so that I wouldn't have to think about it anymore.

Right, with that out of the way, back to the game. I had an overnight think about the strange stuff going on with the max speeds not lining up, and decided to do a test on the game. I started with a 1 gate race, and played it several times over to get an idea of what was going on in the game, repeating the process with 2 gate, 3 gate races, and so on. This is Obsessive Gaming Chronology, after all, I'm gonna do deep into these games. 

What I discovered is that I have no idea how anything in this game works, and it all seems mostly random and inconsistent. Fun!

First, I can't tell if the difficulty modes actually do anything. I was able to get bronze, silver and gold medals on all modes, so I really don't know what difference the choice makes.

Second, your end results - if you don't crash out - appear to be mostly random. And wildly random at that. The same race I got a gold medal time in, I can get a time up to 20 seconds slower, even if I use the same inputs. On top of this, you can actually become a time traveler in Slalom, because you can crash out of a race with a negative time. 

I found a rift in the space-time continuum.

The third thing, and something I alluded to earlier, is that the max speed chart lies to you. I discovered from doing 4 gate races that what that chart tells you (the values are static) is either misleading at best or blatantly incorrect at worst. Gate 4 is always set at a max speed of 29 MPH, but you'll always crash if you get anywhere near that speed at this gate. You actually need to slow down to have a chance to pass this gate cleanly, after the first three gates often allowing you to go at full pelt.

What this means is that you actually need to play more reactively than you'd think. The random nature of game results, and the variability of your starting speed and speed gains means that what you actually need to do to have a successful run is to listen to what the game tells you. This is the most likely way you'll get a medal. If it tells you that you went over speed at a gate, it's probably best to slow down a bit for the next one - same if it says "CLOSE ONE!" If you consistently wipe out at one particular gate, you probably need to slow down more at it in future attempts. It's honestly not how I expected the game to play at all coming into it. I also find it very frustrating, as I feel like my success in game is more reliant on luck than skill. Everything is just too random.

And yet, I press on. The other point of me putting the word "obsessive" in the blog title is that I'm a completionist - I'm usually not satisfied just beating a game - I need to master it. Every collectible, every difficulty mode, every achievement... I leave no stone unturned in exploring any game I play. There hasn't been much opportunity with previous games to lean into this tendency of mine, but there is with Slalom

But, how do I even determine completion of Slalom? The difficulty modes don't do anything discernable, and I don't even know which one is supposed to be the "hardest" one, so there's no point in using that as a metric. That just leaves the race length. 25 gates is the longest a race can be in Slalom, so that's my goal: get a gold medal on a 25 gate race. The successful attempt will be added in a video at the top of the article, if and when I do so. [Ed. video is up now.] The releases of article and video will likely become desynched the longer and more complex games become, especially because I want the videos to be of a high gameplay standard. Eventually I want to start live-streaming all my gameplay, but that simply isn't viable for me at the current time.

[Ed. Update on Slalom progress: Look, folks... I think it's impossible. I managed to snag a Silver medal on the 25 gate race, after about half an hour and several Bronzes in a row, and switching from mode 3 to 1. Which was great - I though Gold couldn't be far off. I also thought now, maybe the difficulty modes made a difference... I eventually went back to mode 3, and got another Silver. And another. And another. So, maybe they do, only in the opposite direction. Mode 3 might actually allow to get faster times, as my first mode 3 Silver time was over 20 seconds faster than the first Silver. I went from 64 seconds to 42 seconds.

So... what does it take to get Gold, then? I assume under 40 seconds. So I kept trying for over an hour. Nothing better than the 42 seconds. In fact, I didn't even come close to beating that time. I even tried the cheat option - which worked once, and never again - but no, nothing remotely close. It's so frustrating because I'm not in control of the outcome. I feel like I'm doing Gran Turismo license tests again, except I can only suggest to the car what it should do.

Therefore, I think I have to call it here for Slalom. Whether or not the Gold time is possible, I don't know. I don't think it is, and I don't care to find out anymore.]

All that's left to do now is score Slalom. Is it in the running for a podium finish? Probably not, but let's find out, anyway.


Time Played: 2 hours (most of which was spent attempting to get gold in the 25 gate race...)

Difficulty: 6/10 (Challenging)
It's difficult (irony) to rank Slalom's difficulty on account of the randomness built into the game. This makes it hard to tell how well you're doing, and sometimes you can fail without warning. Learning the game isn't particularly difficult, and is just a matter of knowing what to do at each gate. The in-game difficulty modes have no discernable bearing on the game, so I've not factored them into this score.

[Ed. I've increased the difficulty score 2 points after my failed attempt to get the 25 gate Gold medal.]

Gameplay: 6/20
There's a lot of problems with Slalom, but also some meritorious gameplay. The foundation of the game is good, and I appreciate the range of choices it gives you that allow for more precision (even letting you cheat, which I've never seen be successful to date.) Managing your speed requires learning the course, knowing when to speed up and when to slow down. The game also does a reasonable job of warning you when you're going too fast, allowing you to react accordingly.

Slalom's chief issue is its sheer inconsistency. The game can just fail you at any moment. You might've gotten through that gate at that speed with no complaints from the game last time - but not this time. The speed gains and slow downs are somewhat unpredictable, and the actual time you earn at the end of the course can fluctuate wildly without reason.

Other issues include the max speed chart the game provides being very deceptive, as closing in on the reported max speed will often result in a crash. It ends up being better to learn by ear what each gate requires, and reacting to the randomness of the game accordingly. I also can't tell if the "rate yourself as a skier" difficulty modes actually do anything.

Controls: 5/10
Aside from the commands at the start of the game, the rest is your standard single-key inputs. Makes sense and does the job it needs to do.

Visual: 6/10
I will give Slalom props for doing a very good job with its formatting and presentation. It's clear to me that some consideration was given to ensuring that the game is neatly presented, and with some writing charm, to boot. The race start text, and even the instructions are good examples of the writing and neatness, respectively. Even the little indenting of the speed text at each gate is a detail that elevates the game presentation. 

Functionality: 4/5
Obviously it loses a point for the "out of data" bug that causes the game to crash. Fortunately, it doesn't directly impact gameplay and takes a while to show up.

Pro tip: when doing a 25 gate race, don't pull up the instructions and max speed chart. The game will crash immediately upon trying to start a race. Starting the race immediately will not cause this issue.

Accessibility: 3/5
It's fairly standard for a text-based game. A decent level of reading proficiency is needed.

Fun Factor: 5/20
Look, the game has some merit to it, despite the raft of flaws. There is a degree of skill and learning of the game required to do well, which encourages replaying. However, once you learn the game, its extreme randomness results in a "grind until the game lets you win" type of situation. Then it becomes more work than fun if you actually want to "complete" the game (by my standard of completion, anyway.)

This one was an interesting, but tricky game to rate. I don't think I've encountered a game on the blog so far that's had so many aspects, both positive and negative, to consider. Then end result is a middling, but appropriate score of 29, which puts Slalom very far away from a podium finish (11th overall,) near the bottom of D-tier, just ahead of Warfish. The result is another proof of my scoring system working, as Warfish was the game I ended up comparing Slalom to the most in terms of where and how to grade it. That, at least, is quite satisfying.


Before closing out this article, I have a couple of updates to share:

For anyone wondering, the PLATO article is still in progress. The development history segment is complete, and I'm in the process of recording game footage for the game library section. If you don't know PLATO, you're mind's gonna be blown at what's on that system.

Also, by way of reminder, there's now an OGC Discord and Patreon where you can get involved in the growing community and support the work I do here. Links are in the sidebar.

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

12 September, 2025

Update: Good News Everyone! I Have A Discord Server and Patreon Now!

Good or bad, depending on your point of view, I suppose.

This is quite the significant update for the blog. I had been contemplating doing this for quite some time, but was hesitant on whether anyone would actually be interested in supporting what I do here.

I'm still not sure about that, but I'm jumping into this regardless. Better to try and know, rather than never try and not know.

First, I have established a Discord server, Chronology Club, for you lovely readers to join. It may be an easier method for communicating with me, and for building this community up, by enabling you all to participate with me in this strange little endeavour of mine. It's free to join, too, so that's nice.

Secondly, I also have a Patreon now. For any of my regular readers who desire to support the work that I do - you now can! I have two tiers set up currently that allow you to support me, and they also get you access to special channels in the Discord server - namely the V.I.P. Archaeology Team text and voice chats. The higher tier also permits access to video chat, in case you want to see my ugly face for whatever reason (disclaimer: not likely to happen, I'd prefer to keep my identity anonymous for now. I'm a naturally private, deeply introverted person.)

Discord link is here, Patreon here. Both will also be linked in the blog sidebar.

If you do decide to support me financially, know that I am incredibly grateful for it, and you kindness will not be forgotten.

God bless.

11 September, 2025

#015 - The Game of Chomp (Not of the Chain Variety)



Release Date: February 1973

Platform: Mainframe

Genre: Puzzle

Developer(s): David Gale, Peter Sessions

Publisher(s): People's Computer Company


It's not this Chomp either, sadly (but the concept is strangely related.)

You know, when I thought of this joke, I didn't realise that it's oddly appropriate for The Game of Chomp - a game about eating (this might also be the first food-themed game, come to think of it...)

The Game of Chomp is yet another game that comes to us from the same People's Computer Company February 1973 newsletter as Mugwump and Hurkle, only on the next page over. Like those two, it's also an adaptation from previous source material, and not an original PCC game. 

Unlike Hurkle and Mugwump, Chomp gets an entire page dedicated to it.

Chomp, as it was originally called, was invented by David Gale, mathematician and economist who worked at the University of California in Berkeley (Gale also invented a board game in 1960 called Bridg-it, as a side note.) The concept of Chomp was first described in the January 1973 edition of Scientific American, in the "Mathematical Games" section. Originally, it was conceived as a pen & paper or tabletop game that could be played with counters. It's somewhat reminiscent of Nim-like games, as it's a game where players take turns removing objects from a pile - or, in this case, a grid. The objective was to force your opponent to take the last object, which was in the bottom-left corner.

The reason the game got the name Chomp was from the rules governing the removal of counters from the grid. Every counter within the north-east right angle of the selected counter get removed from the field. The analogy given in Scientific American is like taking a bite out of a cracker, if biting from the north-east corner of the cracker. Hence, Chomp.

PCC took this and modified the game slightly. In their rendition, written by Peter Sessions, the grid is a cookie, and the players take turns taking bites out of the cookie. Yes, this is a multiplayer game - though it can be played solo (the computer doesn't play against you, it only keeps score.) The objective is to avoid the top-left square (instead of bottom-left; the right angle system was also adjusted to suit) of the cookie, because it's poisoned. This is the most high-stakes, gladiatorial eating competition out there, folks.

I suppose the question now is: since this is a multiplayer game, how am I playing it? My rules for the blog do permit me to skip multiplayer-only games. 

Well, that last phrase is the key here: multiplayer-only. Technically, this isn't exclusively a multiplayer game. Singleplayer is an option in-game, even if, technically, the game is meant to be played with multiple people. So, what I can do is select to have two players, and I choose which of the two I want to win, and play accordingly.

Did ya get all that?

For the first, tester round, I didn't do this. I only decided on the above standard after testing the game with one player. The game's instructions are slightly unclear in some respects. I was unsure whether the game saying that "No fair chomping squares that have already been chomped" meant that I couldn't make any moves that involved previously removed squares. So I umm-ed and ahh-ed a bit before realising that the game would probably be impossible to play if that were the case, and continued on as normal. There's nothing else of interest to report from the tester run.

Congratulations, you just played yourself.

So for the second round, I selected a two-player game, and I wanted Player 1 to win. I was successful in this goal, though I felt as if I had no idea what I was doing throughout. It was a lot of back-and-forth, semi-randomly selecting sections of the cookie to remove, until it got closer to the end, where I tried to be more intentionally strategic. Well, as much as I could be, at least.

I got caught out trying to cheat at one point.

I'm aware that the game's Scientific American article explains some strategies, but I'm not really interested in reading it, to be honest. For this game, it's not worth it. It's not compelling enough.

At this stage, I'm stumped. I'm struggling to come up with anything else to say. Even doing up the scores for Chomp, I had a hard time thinking of what can be said about this game.

Time Played: 5 minutes

Difficulty: N/A
I'm throwing an N/A on this because it's technically multiplayer, so the challenge is theoretically variable; only equal to your own skill vs. your opponent's skill.

Gameplay: 2/20
In reality, Chomp is just "visual Nim," i.e. remove objects from a pile, but with an extra step. The extra step doesn't really add much to the base Nim experience. It's nice that there's a small amount of customisation for grid size, but it's mostly superfluous.

Controls: 5/10
As expected for a grid-based game.

Visual: 5/10
You'd expect for Chomp to have the grid visible on-screen, and it does. Good. Does it make the effort to make it look more than basic? No.

Functionality: 5/5
Nothing to see here. Vintage BASIC's version's "play again?" bit at the end doesn't work, but that's (probably) not the game's fault.

Accessibility: 2/5
It's problematic that Chomp is best enjoyed with multiple players. Finding someone else who'd actually want to play this with you seems highly unlikely.

Fun Factor: 0/20
Nah. I don't like it. It was a dreary, aimless experience.

So, after a pair of decent games, we're back down in the dumps again. The Game of Chomp earns a pitiful score of 19, which banishes it to the depths of the E-tier, alongside Digits and Letter. Chomp splits the two on the tie-breaker, and lands in 26th spot overall. That's 26th out of 32, for reference to how poorly this game did.

We're off the People's Computer Company train for the next couple of games. The next one, Slalom, is an odd concept for a text-based game. Maybe it'll make for a good game? Only if it can ski between the flags, I guess.

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

06 September, 2025

#014: Hurkle - The Solitary Relative of the Mugwump



Release Date: February 1972

Platform: Mainframe

Genre: Puzzle

Developer(s): Bob Albrecht

Publisher(s): People's Computer Company


Nobody knows what a Mugwump is - much less a Hurkle. According to BASIC Computer Games, a Hurkle is an alien creature created by author Theodore Sturgeon for a story his book, A Way Home.

Why are we seeking the Hurkle? How did we even get to the planet it lives on?

In seriousness, this is going to be a pretty short article that functions almost as a companion to the Mugwump article.

For instance, both share the exact same historical data. All of the authorship and dating details relating to Hurkle are as covered in the Mugwump article. As such, I won't be going into detail here, but I'll summarise in case you haven't read Mugwump's article. Hurkle was created by Bob Albrecht, and published in the February 1972 edition of the People's Computer Company newsletter alongside Mugwump. Both games are derived from an earlier, educational game called Hide and Seek, written by school teacher Martin "Bud" Valenti and his students as part of Project SOLO, an educational program created by the University of Pittsburgh designed to explore the use of computers in education.

So, obviously Hurkle is going to be directly compared to Mugwump throughout. Which one is superior? Or do both have their own merits?

While Mugwump is almost identical to the source material, Hurkle differs more significantly. There are multiple gameplay differences, which I've summarised in this handy-dandy table:

I've just discovered that I can paste in tables I make in LibreOffice, and I love it. You can be sure I'll be making plenty good use of this in the future.

I think most of these differences are self-explanatory. For the guesses, instead of providing the distance of the Mugwumps from a guess in units, Hurkle just gives you the direction the Hurkle is in. It literally just tells you "GO NORTH" or "GO EAST."

I got into a spot of bother with this on my first attempt at the game. I carried over my winning strategy from Mugwump, thinking it would work just as well - or at least it would be a solid base to start from. Starting from 0,0, I was told to "GO NORTHEAST." Here, I realised that the directional clues are laid out backwards compared to the co-ordinate system. North - the y-axis - is first, whereas the first co-ordinate number is the x-axis. My mind tricked me into assuming that the first co-ordinate was the y-axis, and so I ended going in the complete opposite direction to the clues.

Yeah, they meant your other northwest, mate.

I figured out what I was doing wrong on my second attempt, which was more of a "feeling things out" type of round. However, this issue persisted throughout my entire time playing the game for this article. I just could not wrap my head around it - it was like playing a platformer with the controls reversed - disorienting and making me feel very, very silly.

Slowly figuring it out.

On my third attempt, I managed to score a win on a relatively easy round. I started at 0,0, and the game kept telling me to go north-east, which I did until I found the Hurkle at 6,6 on my fourth guess.

There we go. Found the mongrel.

I wasn't particularly satisfied with this win, so I kept playing. I fell agonisingly short of the target in my fourth attempt, before earning a more satisfying win with my final guess in my fifth game.

This thing isn't easy to find.

When I came back the following day to get a good round for the final recording, I became increasingly more frustrated with the game. As I said before, this disconnect between the clues and input kept scrambling my mind, and I wasn't having a good time.

One strategic change I made in the end was to go back to my original Mugwump strategy of starting at 5,5. The thinking was that it would actually be better to have all directions available, but less distance in those directions. The guessing strategy from there was one similar to playing a number-guessing game. If the game said to go south-west, I'd go as far as was possible in that direction, while still leaving one space in case I needed to keep going. For example, if starting at 5,5, the game said to go south-west, I'd want to move to 1,1. It's likely that the game would tell me to go back north-east, and so I'd go back to 3,3, and so on and so forth until the game gave me a different clue or I found the Hurkle. That was the theory, in practice I had a hard time with it.

I asked the question at the beginning of the article of which of the two - Mugwump or Hurkle - would end up the superior game. I think that the answer's fairly obvious to you all by now, but let's see anyway.


Time Played: 20 minutes (approx.)

Difficulty: 5/10 (Low-Moderate)
I rate Hurkle a point higher than Mugwump on difficulty because of the clues-versus-input disorientation.

Gameplay: 5/20
-3 compared to Mugwump. It's amazing how small changes make a huge difference in how a game plays. Most notably is the change in the clues, which I won't keep talking about. There's far less strategy and room for taking informed risks in Hurkle due to the changes, and the game suffers greatly as a result. It's far less interesting and engaging than its counterpart.

Controls: 5/10
Exactly the same as Mugwump; and thus just as appropriate.

Visual: 5/10
Functionally the same as Mugwump, too. I prefer Mugwump, but there's not enough difference between the two for Hurkle to lose a point.

Functionality: 5/5
No problems.

Accessibility: 2/5
I think Hurkle is likely a harder game to process for most, as cardinal directions don't always come easy. The lack of any visual aid provided by the game accentuates the issue, and certainly the potential disconnect between clues and input factors into it as well. 

Fun Factor: 2/20
The more I played, the more I hated the game in all honesty. I constantly struggled with the clues, and it made me feel like an idiot. Could just be a me thing in this instance, but remember these scores are based on my own personal experience with the game.

So how does Hurkle compare to Mugwump in the final analysis? Mugwump ended with a score of 36. Hurkle... well, it only got 24. Two little gameplay changes result in a swing of minus twelve. Ouch. That puts Hurkle a full tier lower than Mugwump, sitting near the top of the E-tier, just behind Dartmouth Championship Football in the 13th overall position as it stands now.

We're done with the mythical-animal-hunting games for a bit now. But we're not done with People's Computer Company games.


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

03 September, 2025

#013: Mugwump



Release Date: February 1973

Platform: Mainframe

Genre: Puzzle, Educational

Developer(s): Bob Albrecht, Martin "Bud" Valenti (and students)

Publisher(s): People's Computer Company


Our next entry is one that's potentially a predecessor of one of the more famous early text games, Hunt the Wumpus - an early progenitor of the text-based adventure genre (pretty much the only style of game anyone thinks of when it comes to text-based games these days.) Mugwump finds its roots, like so many other early video games, in experiments with computers in educational settings - with maybe a little bit of Battleship thrown in for good measure.

Authorship is, fortunately, a fairly simple case for Mugwump (and its successor, Hurkle, for that matter.) Mugwump is attributed to Bob Albrecht, and was published in his People's Computer Company newsletter for February 1973. 

Mugwump (and Hurkle) are in the top right of this... interesting looking page.

This presents a bit of a dilemma, however. Upon doing my research for the game, I discovered that MobyGames' release date for Mugwump is incorrect. Over there, Mugwump is listed as a May 1973 release. However, as just stated, Mugwump and its successor, Hurkle, both featured in the February 1973 edition of the People's Computer Company Newsletter. The games' section of the newsletter also states that,

"HURKLE was inspired my MUGWUMP." 

Straight from the horse's mouth. The publisher makes a clear statement that Mugwump preceded Hurkle, which MobyGames lists correctly as a February 1973 release. This is why I'm going against my usual pattern of doing games with shared release months in alphabetical order. If I hadn't found this information, we'd be discussing Hurkle right now. While our online databases are wonderful, they're not perfect. I've submitted a correction, for anyone wondering.

The newsletter also states that Mugwump was inspired by a "Project SOLO," run by the University of Pittsburgh. This project, according to one of their newsletters,

"...is an experimental program concerned with exploring the potential of computers in the hands of high school students and teachers."

The antecedent of Mugwump was a direct result of Project SOLO, developed by the students of Martin "Bud" Valenti, a WWII veteran and public school mathematics teacher. This game Mugwump is based on can be found in the June 1972 edition of the Project SOLO newsletter, and is titled Hide and Seek. Its original purpose was to be a game used to help students learn about Cartesian co-ordinates (with compass included.) Compared to Mugwump, it turns out Albrecht changed very little about the game, only changing the four players to the titular Mugwumps, and the ending text. It's unknown how Albrecht got access to Hide and Seek.

Hide and Seek in the Project SOLO newsletter. Graph paper and a compass were recommended assistants for this game.

With all that out of the way, let's get into the game itself. The most critical question we must ask at this juncture is:

Just what is a Mugwump?

Even the PCC newsletter asks the same question. They understand. This type of question is of vital importance to our understanding of the cosmos. Unfortunately, it's also the type of question that doesn't have an answer. It's a shame, really.

Upon opening the game, I noticed that it bucks the trend of early text-based games in that it doesn't bother asking if you want the instructions - it just gives them to you. I'm told that the objective is to find four Mugwumps hiding themselves in a 10x10 grid. Why they limit themselves to such a small space, I'll never know.

I mentioned the board game Battleship at the start, because the process of finding the Mugwumps is much the same as choosing a co-ordinate in that classic game (or even Battle, for a prior video game example. Mugwump shares much in common with Battle, as it turns out.) Co-ordinate 0,0 is in the bottom left of the grid, and follows the typical grid system of the first digit being the horizontal x-axis, and the second the vertical y-axis.

You also only get 10 guesses. Good luck.

Also explained in the instructions is the clue system the game provides. I'm glad I don't have to go in blind, just wildly guessing without any reference points. After the first guess, the game will give you a clue as to the location of each uncaught Mugwump in relation to your guess. It does this in "units," which aren't always a round integer. Decimals signify the location being on a diagonal. Apparently, this is where a compass and graph paper are useful. I have graph paper (for dungeon mapping in future RPGs), but this is 2025, not 1973 - nobody uses compasses in the future.

For my first couple of goes at the game, my strategy was to have my first guess directly in the centre of the grid - co-ordinate 5,5. In hindsight, this was probably a terrible idea, as the clues only tell you distance, not direction. It's probably best to stick to the margins - less possible directions to consider.

This was a terrible idea.

The clues didn't really help me on account of deciding to plonk myself in the middle of the field. I made a somewhat educated second guess of 3,3. This provided much better results, as I had two of the Mugwumps either directly up or across from my location.

My next guess was 8,3, which resulted in one caught Mugwump! This guess also happened to be a solid anchor point for every other Mugwump, as they were all in straight directions from 8,3.

Got 'em.

The next most logical spot to guess was 9,3, as guess 2 had the fourth Mugwump one unit further away from the third Mugwump. I was correct, and now there was only two Mugwumps left.

Making solid progress.

Based on guess 3, the other two Mugwumps were either left or right three spaces - take your pick. I did, and picked wrongly, going right to 8,6 when I should've gone left to 8,0. 

Upon rectifying this error, I was greeted with the final two Mugwumps hiding in the same space! I'm surprised the game allows this to occur, but it's also likely a rare occurrence. My first game of Mugwump resulted in successfully finding all four Mugwumps in only six guesses - the number of guesses the game's writeups suggest is a good score... when using a compass. See, I told you it was unnecessary.

So what do I do with the Mugwumps after I catch them?

This is one of those games that starts a new round immediately, so I decided to have another go around. I didn't mind the first round, so going a second time wasn't a hard choice.

This round was... less successful. I went with the same strategy, and the folly of it showed this time. I was only able to catch three of the four Mugwumps, and found it considerably more difficult to ascertain their locations.

Tch. Knew I should've taken that left turn at Albuquerque...

Naturally, I had to play again after reconsidering my strategy. It turns out the game is a fair bit harder than I first thought. The strategy for the next handful of games was to start at 1,1, but none of those attempts were successful.

Eventually, I tried 0,0 as the starting move, and this proved far more effective. I found all Mugwumps in six turns again. What I learned during that attempt is that when the distance is listed as a round integer ("x units; no decimal point), it doesn't always mean that the Mugwump is in the same row/column as your guess. Often, it's one over, as can be seen from this screenshot:

Not always straight ahead.

My first guess was 0,0. This generated a clue for Mugwump 4 being 8 units away. Naturally, my next guess was in line - 8,0. The Mugwump was still 1 unit away, somehow. The only logical place to go next was 8,1 - exactly where the Mugwump was hiding. When the angles get very narrow, the game seems to round down, as sometimes it will use a .1 to signify something like this, other times it does not.

The 0,0 strategy resulted in two wins in a row for me, which I think proves it to be the best of the three strategies I tried for the game. You'd probably have the same success starting in any of the corners, however. Let's coin it the "corner" strategy. Both my recording attempts were also successful using this strategy. I found in my dumped attempt that, if 0,0 doesn't give good clues, you can just go to a different corner.

In case you couldn't tell, I rather enjoyed myself with this game, which will be reflected in the scores. This is also an attempt at finding more interesting ways to say "on to the scores." One of my writing goals is to be more creative with my segues.


Time Played: 20 minutes (approx.)

Difficulty: 4/10 (Mild)
There is a bit of challenge here in deciphering the clues and figuring out the best way to proceed. The random dispersion of the Mugwumps always kept me on my toes, and failure is possible if the clues aren't interpreted correctly.


Gameplay: 8/20
I'd say Mugwump is comparable to Battle in gameplay. Both are co-ordinate guessing games with clue systems. Mugwump is more on the simple side, but is no less interesting. Even on a basic level, I had space to develop strategies to give myself the best chance of success. The clue system takes a little bit of time to learn as well, but can give a satisfying payoff when a risky, educated guess comes off.

On the flipside, clues aren't always as clear as they could be (i.e. the previously mentioned issue of round integers not always representing a straight line.) The suggestion of needing to use graph paper and a flippin' compass is rather ludicrous, also. Ultimately, Mugwump is still a very primitive game, and provides limited gameplay value, hence why it isn't rated higher, despite my praise of it.

Controls: 5/10
As standard - I think they're about as appropriate as they could be for this type of game. I initially used "good" instead of "appropriate" before realising the latter was a more effective word for describing the controls.

Visual: 5/10
I'm going to use the same word here - appropriate. The formatting is as should be expected, resulting in a clear and readable game. Games shouldn't get brownie points for doing merely what they ought to do.

Functionality: 5/5
No problems here.

Accessibility: 3/5
Fortunately the graph paper and compass are only suggestions. Like, come on, we're not playing a CRPG here. Otherwise this score would drop to a 1 because, you know, everyone just happens to have a compass on hand these days. I can see some people benefitting from the visual aid of graph paper, however (or an Excel spreadsheet.)
 
Accessibility is otherwise fairly standard for a text-based game - points off for requiring a certain level of English reading proficiency.

Fun Factor: 10/20
Yeah, a surprise higher score for Mugwump. Much like Battle, I really did find enjoyment and intellectual stimulation in having the space to make strategic decisions and interpret clues. While the random dispersion of Mugwumps assist in giving the game some replay value, it's still not exactly something I'd seek out in my own time.


1973 continues to impress (compared to previous years, anyway), with Mugwump earning a score of 36, giving it a percentage equal to Hamurabi (51.42%), and thus a spot high in the D-tier. Mugwump just beats out Hamurabi in the Fun Factor tiebreaker, taking 5th place on the tier list as it stands at the time of writing. 

Next time we have Mugwump's sister game, Hurkle to tackle. I think that's going to be an interesting comparison, as both games are near identical, with one small difference that could have huge gameplay ramifications.

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