A bit of double vision going on here. It's awkward having to do what is effectively the same game twice in a row, but that's just how the chips have fallen with the recent discovery I discussed in the last post.
We have before us another rendition of the Batnum varation of the traditional game of Nim. The main difference between Batnum and Nim appears to be that Batnum typically seems to have only one pile of objects, whereas Nim has several piles. Otherwise they are pretty much the same game. I've explained how to play Batnum and Nim previously, so I'll spare you the details here and will proceed straight into the nuts and bolts of this version.
This version of Batnum is derived from David Ahl's 101 BASIC Games book, as have most games I've done recently. Fortunately for me, the game is identical between the original version of the book and the 1978 microcomputer edition. I'm glad to not have another Roulette problem on my hands here.
What is less fortunate is that the authorship is uncertain, unlike the 1967 version of Batnum. Determining the author of that version as John G. Kemeny, the inventor of BASIC, seemed rather unarguable to me. This 1970 version is definitively not the same game, meaning authorship is much harder to determine. The original version of Ahl's book credits the game to Kemeny, but the 1978 update alters the wording in its Batnum entry slightly, which could be read as implying that Kemeny was not the author of the version that appears in the book (however, it does still credit the game to Kemeny at the top of the page.)
That leaves us with two possible theories on this game's authorship:
This version of Batnum was not authored by Kemeny, but rather likely David Ahl or an associate who helped him compile the book, or,
Kemeny didauthor this version of Batnum, meaning this version is an updated and expanded version of his 1967 original.
The latter of these is probably the most likely, based on how authorship is almost always attributed where possible in both versions of the book (Ahl does not credit himself for his games in the first edition of the book, but he is credited in the 1978 edition.) All the evidence points to Kemeny as the author, so I must go with him as the most likely author, meaning that this game is, most likely, Kemeny's rewrite and expansion on his 1967 version of Batnum.
With that sorted, let's get into the actual game, shall we?
Batnum's initial setup is basically identical to Gamnim, which I played back in August. The game provides its instructions and asks for the object pile size (see screenshot above.)
Setting up the game.
Once the pile size is defined, the game takes you through the other setup options. You get to choose the win condition (either to take the last object or force your opponent to take it), the minimum and maximum number of objects that can be removed each turn, and who goes first. That's all the options the game has, which is a fairly standard amount when compared with Gamnim.
As far as playing the game goes, it's identical to the 1967 version of Batnum. The computer basically plays perfectly, so you can only win if you opt to go first and avoid taking the last object. I didn't try it, but I assume the game can be won with the inverse settings (going second taking the last object.) It feels far less fulfilling to win when you can just set the game up for yourself, so 1967 Batnum gets a point over this version in that regard.
I meant to win this one. Messed up the settings.
I played a few rounds, fiddling with the settings as I went. I got bored after about 3 minutes of play time, so I decided to do the one thing the game tells you not to do: type a zero. The instructions clearly state to not use zero when playing. So, naturally, I used zero.
You were warned.
Using zero is considered a forfeit by the game. I hoped it might have done something more dramatic than that, though I might be asking too much of a 1970 game.
Sadly, that's all there is to Batnum. That means we're already on to the scores.
Time Played: 3 minutes.
All that's needed to experience everything the game has to offer.
Difficulty: 0
Putting it as a zero as you can set your own difficulty.
Gameplay: 0
There's very little gameplay to begin with. It lacks any substance or any compelling reason to play it whatsoever.
Controls: 9
I'm docking a point because the game doesn't tell you that you need to put a comma in between the numbers when setting the minimum and maximum number of objects that can be removed per turn.
Visual: 1
There is nothing noteworthy to discuss with visuals - it's as basic as it gets, with no effort put in to make it look like anything other than plain text.
Functionality: 5
Everything works as intended, no issues giving it full marks here.
Accessibility: 3
It's a lot easier to run and access than 1967's Batnum, and is a simple enough game to understand.
Fun Factor: 0
I found no enjoyment playing this at all. Apologies for being so blunt, but there really isn't anything to say. This one felt like work.
1970's Batnum scores 18, which, with a percentage of 25.71% just barely keeps it out of the F-tier and at the very, very bottom of the E-tier. It only managed to score one point higher than the 1967 version due to the ease of accessibility this version possesses.
[Add.] Upon completing the rescore project, Batnum (1970) gained 2 points, going up to 20/70 (28.57%)
Fortunately, the Nim variants are behind me for now. Honestly, I dragged my feet with this post due to having to basically play the same game twice. There are some more interesting games coming up in 1970, which I aim to get through at a much quicker pace than the current one.
I'm always glad to be proven wrong in these instances.
As I'm writing this update, I've been preparing the next post in the Prehistory series, on the 1970 version of Batnum, a possible rewrite and expansion upon this game. While doing so, reading the game's entry in the 1978 edition of BASIC Computer Games, I came across something I missed before. That entry explains how Batnum is based on modulo arithmetic, and how to use it to your advantage.
The second paragraph is the one in question.
It explains you need to leave a stack of "1 modulo," which is the maximum number of objects you can take (M) + 1. I interpreted this as meaning that, whatever the computer takes, the amount I take will equal this M + 1 equation.
So, I tried this theory out, and...
Ha! Suck it, computer!
Victory!
On my first attempt using this logic, I won. The first turn strategy I went with was removing a single object from the pile. I tried this first game a second time later on with the same strategy, and the same result ensued, suggesting that this is a consistent strategy to win the initial game.
I continued on straight after winning the first game, with the randomised settings, and was overwhelmingly unsuccessful. I consistently lost, though I was able to win a second time eventually. The computer is ruthless after the initial game. It doesn't always follow the modulo logic on its first turn, which always results in it setting up the game for itself to win, but I don't understand the logic behind why it does what it does on the first move. All the explanations of modulo arithmetic I've found online are far too complicated for me to make sense of. Maybe if I start to learn BASIC, I'll be able to look into the code and understand better, who knows.
Here's my video, showing off what I've just described:
I'm just happy to take this off the impossible list.
Well this is exciting - the first time I have to go backwards, as a new discovery has been made! This comes courtesy of MyAbandonWare.com once again, and from the same user - Benedict - who unearthed The PDP-10 Timesharing World Series that I covered in Prehistory VII.
Here we have the earliest rendition of Batnum, a portmanteau of the phrase "battle of numbers." So fresh is this discovery that it isn't present on my databases. Despite this, there's a decent amount of information available. We have a precise date for this game's creation - February 22 - which is more than can be said for a lot of the games I've covered. This date comes from a scan of the book in which Benedict discovered the game's source code.
Source code. "Self-explanatory," apparently.
As far as authorship is concerned, Batnum was potentially programmed by the father of BASIC, John G. Kemeny. The source code (above picture) doesn't credit an author, so we only have secondary sources to work with. David Ahl's 1973 version of 101 BASIC Games, in its Batnum entry, credits Kemeny with creating "the original computer version." It would be fair to assume that this 1967 rendition is the original Ahl was referring to.
So what is this battle of numbers? Batnum is basically a Nim variant - where two players take turns removing objects from a pile. Rule variants determine whether the player to take the last object wins or loses. In this game, the rule is that the person to take the last object loses, and you play against the computer. It starts off with a pile totaling 79 - quite a large number, and allows between 1 and 6 objects from the pile to be removed per turn. The player always goes first, which, as I discovered in Prehistory XVI on Gamnim, is the disadvantaged position in Nim and variants. If, as I suspect, the computer plays perfectly, this'll be an unwinnable game.
We've got a unique piece of software for Batnum provided by the MyAbandonWare download: DTSS (acronym of Dartmouth Time Sharing System.) A brief spot of research suggests that this emulator of the original DTSS was developed back in the mid-2000s by John S. McGeachice, Steve Hobbs and Thomas E. Kurtz - the other half of the Kemeny - Kurtz duo that created the original system and BASIC itself!
As a side note, I wonder if the existence of this emulator would open up the possibility of playing more of these old BASIC games that I have listed as missing - now that would be wonderful.
Anyway, back to Batnum. Running it in DTSS is quite simple, simply type in 'OLD', press enter, type 'BATNUM.BAS', press enter, and finally type 'RUN', press enter, and the game will start.
Only after the first move do I get to know what the pile size is.
The first game always begins with the same setup as previously stated, but it doesn't tell you what size the pile is - you only find this out after the first round of moves. Successive games randomise the rules. I've had pile sizes less than 30, and the ability to take up to 14 objects out at once.
All that being said, after playing a few rounds I determined that my initial suspicion was correct. I do believe it's impossible to win on account of having to move first. Either that or I'm just clueless as to how the logic works. Either way it doesn't really seem to matter what I do, as the computer going second has complete control over the numbers, as it reacts and counters my every move perfectly.
[Ed. I came back after learning about how the logic works, and won a few rounds. The first round can always be won once you know the logic.]
A routine occurrence.
I tried again, and again, and again, but the result was the same each time: I lose. That's discouraging, but also put the writing on the wall that there was no point in continuing.
So what did I do from here? I investigated the source code image and realised that the line that displays the pile size had been omitted from the game file provided for some reason. So I went in and fixed that, and it worked all fine. Seems inexplicable that that line was removed, I assume it must have been an oversight. Doesn't change the fact that the game is unwinnable.
Now as it should be.
That's really all there is to say about Batnum. I find the software it runs on far more interesting than the game itself (by a significant margin at that), as it opens up the possibility of discovering more old games previously though missing.
Still, it's a scoreable game, so let's get on with it.
Time Played: 6 minutes is a fair estimation.
Difficulty: 0
I had two options here - either give it a 10 because it's impossible to win, or a 0 as there really is no difficulty if there is no possibility to win. The latter seemed more logical to me.
Gameplay: 0
I think I'm forced into giving this a 0 for gameplay simply because it fails to really be a true game as you have no chance of ever winning. [Ed. Having found a way to win doesn't change this score.]
Controls: 10
All you have to do is type a number in. It could not be easier.
Visual: 1
Excepting the banana background, there is really nothing to say about the presentation apart from that it wasn't considered at all, aside from the three asterisks that appear next to the "I WIN" message.
Functionality: 5
Very, very little can go wrong with such a small game. Heck, the source code fits on a single page. I'm giving the missing line of code a pass, as I put that down to the error of the person who uploaded the game to the internet, not the original author.
Accessibility: 1
It's a hard game to get into, considering what you need to do to obtain and run the game, on top of the fact of being unwinnable being a massive turn off.
Fun Factor: 0
I had more fun fixing the game code than playing it. What's the point if you can't win?
Batnum receives an utterly abysmal score of 17, which earns it 24.28% and a spot in the F-tier. Still scored better than Galaxy Game, which I think is hilarious. Both games are completely pointless (in a single-player context, that is.)
I'm probably going to do some experimenting with DTSS to see if I can get anything else to run on it. How this is going to play out is that I'll keep going forward with the list, coming back occasionally when (and if) I find games that work on DTSS to cover them. I suspect I'd have to manually type in the code, which I'd need to block out time for, as that'll take a while to do, depending on the game.
This is a weird one to cover. While it appears in both the original 1973 and updated 1978 versions of Ahl's 101 BASIC Computer Games, it is completely different in both books - the code and presentation of the games differ significantly, barring the description, which remains almost entirely untouched. All that was changed in the 1978 description is that the game simulates an American roulette wheel instead of a European one. It does make me wonder if these were completely different games to begin with.
As far as I know, that question cannot be definitively answered. The only credit we have for the game is W. C. Hoffer, who converted the program for its 1978 Compucolor I release, naming it European Roulette in Color, which will receive its own separate review. The 1973 101 BASIC Games description claims Roulette had been around for many years at that time, but that its original author was unknown. The 1978 edition of the book doesn't even bother including that much. I find it perplexing, as my databases don't list these two versions as separate games, despite them being completely different.
This abnormality presents me with a conundrum to solve: do I treat these as separate games, or deal with them in this one article? The fact that I'm writing this article should give away my decision - I'm covering both in this one article. Vintage BASIC's collection only contains the 1978 version of Roulette, so that's the version I'll be playing and basing my review on. The 1973 version appears to remain missing, sadly. To compensate, I'll be contrasting and comparing both versions of Roulette throughout where I can, so we can get an idea of how different the two games are. It's a bit tricky to do so since the 1973 release is missing, but there is enough information from its entry in the 1973 edition of 101 BASIC Games to facilitate the comparison.
For reference, from this point on I'll be referring to the version of Roulette in the 1973 edition of the book as the "original" version of the game for convenience - even if it may not be totally correct in saying that it's the original.
Upon booting up the 1978 version of Roulette, it asks for the current date. I find it amusing playing this game in 2024 when the example date the game provides in in 1979... It's an odd way to open the game - but it does have relevance later on. The original version of Roulette does not include asking for the date.
The 23rd of January, 1979 was a Tuesday.
The game then offers its instructions to you, first presenting a visual representation of the betting layout. The original has this graphic, too, but it's been simplified in the 1978 version. I much prefer how the original looked - some effort was put into making it look nice, whereas the 1978 version just feels a bit lazy, indicating the red numbers with an asterisk instead of having a nice table with the colour directly under the number.
Compare this...
To this. Much nicer. (Sourced from archive.org)
You may notice from these two pictures that the numbers themselves are slightly different, with the original having 0 - 36, and the 1978 version having 1 - 35 with 0 and 00 at the end of the table. As mentioned earlier in the article, the 1978 version of Roulette was changed from European-style roulette to American roulette, and this here is the key change between the two variants, according to the game's intro page in BASIC Games. Apparently the American version gives the house better odds, and was thus becoming the more popular variant of roulette. What a surprise...
The remainder of the instructions explain how to make bets, what bets are available, separated into groups based on payouts. Single number bets pay out 35:1, whereas the other two groups are either 2:1, or even.
All the standard betting options are here.
Absent from the original are the options to bet on number ranges: 1-12, 13-24, and so on. More choice is good, I suppose, and it makes things a little more realistic. That being said, it doesn't make much difference when it all comes down to luck. I feel like I've said that line a lot during this Prehistory series. Lack of player agency and irrelevant choices in wholly luck-based games is becoming a real pet peeve of mine.
I initially had some trouble inputting my bets. It asks for how many bets you want to make, which didn't immediately register with me, as the instructions don't mention the fact that you have to choose how many bets you want to make first before inputting said bets. Hence I tried inputting a bet with the required formula of [bet],[amount] with no spaces to repeated error messages until I realised my mistake. It would have been helpful for the instructions to specify that there was a step before putting a bet down.
I recreated the scenario just mentioned, and found an additional piece of text telling you off for trying to make the same bet twice.
Here above I recreated what happened in that first playthrough I didn't record. I noticed that the game then skipped asking me again and went straight to asking for bets. I decided to follow this through, as I wasn't sure what the game was doing at this point. In total it made me input 37 bets. What the game ends up doing is ignoring every input past the first number and accepts that as the number of bets to make. I selected 37 as the first number, and therefore it assumed I wanted to make 37 bets. Much to my amusement I actually made some money overall from that set.
Anyway, that was just a little aside. Eventually I figured out my mistake, and was able to input bets correctly.
This is how it's supposed to go.
The manual provides a "good strategy" in the form of what it calls "doubling" for how to bet effectively. This involves starting with the lowest amount possible on an even/odds bet (any of the even money bets), and doubling the amount you bet until you win, then reverting to the lowest amount and starting over. Oddly, the manual in the 1978 version was unchanged, instructing you to start with $1 despite the minimum bet in that version being $5. Small oversight, but it doesn't affect the strategy. It's a slow way of building up winnings, but it works. I slightly misremembered and did the strategy with the 2:1 bets, but it still works there.
You win some, you lose some.
I did experiment with making multiple bets at once, though I honestly didn't like it that much. You can't do it with the doubling strategy, as that needs to be controlled one bet at a time. It's nice that the option's there, even if I don't see myself using it.
I persisted with the doubling strategy, having a rather bad streak of luck where I almost lost all my money. I did not in that instance, but looking back later made me rather curious as to what happens when you do go bust.
So I loaded up the game again and quickly blew all the money I had to see what the game would do:
Game over.
Much akin to the other text games I've played, it humourously insults you for your failure. This is a very early example of a game over screen, reminiscent to me of Hamurabi ending your game early if you manage your resources poorly, resulting in your subjects all starving to death.
On the flipside, it also makes me very curious as to what happens if the player manages to break the bank. I imagine that would take a long time to do, with the bank starting with $100k, but I suspect it to be very possible. Within the code there appears to only be a single line of text that appears: "You broke the house!" So the developer probably anticipated it occurring. I'm tempted to put that down as the game's "completed" condition, but I'm not sure if I want to be bothered playing a 1978 text rendition of a roulette wheel for hours just to see one line of text.
The original game doesn't appear to address either situation, further solidifying my theory that these are totally different games. Simply comparing the code of both games should be enough to prove that these are different games.
After a couple more minutes of playing, I decided I'd had enough. If you say no when it asks if you want to bet again, it then asks for a name to make the check to. This is where the date inputted is relevant, as it appears on the check the game draws up for you.
Memory bank? Did I win memory bytes, not money? I feel ripped off.
It draws up a neat little representation of a physical check. I'm not sure what determines the "Check No." What I find odd is that, in the 1978 code, the location of the "Memory Bank" is Virginia, not New York. I wonder when and why that was changed in the version I have? The original does not have the check graphic.
And that is Roulette. I'm surprised I had so much to say about a simple casino game. What is not simple is its history. I'm fully convinced that the two versions I discussed are completely different games, and MobyGames is simply missing the 1978 version. It's far too removed from the 1970 original featured in the 1973 BASIC Games to be the same game in terms of code and overall design. It makes this frustrating for me, as this is a chronological blog, and here I'm somewhat going out of order. However, history is not always - if ever - simple and linear.
Now, onto the scores.
Time Played: 10 minutes
I think this is a fair estimation.
Difficulty: 0
Same as Horserace, no difficulty as it's a luck game.
Gameplay: 1
It gets a 1 purely in that there is at least some semblance of an end goal to work towards, and a sound method to get there provided by the manual. It's still an entirely luck-based game, but you can at least do something, unlike Horserace.
Controls: 10
As is the standard for most early text-based games - simple inputs make the game very playable.
Visual: 4
Fairly unremarkable as far as an early text game is concerned. I am disappointed by the apparent downgrade in the 1978 version compared to the original in terms of the effort put into the text graphics. Otherwise, the formatting is good and clear.
Functionality: 5
There was one thing that could potentially be a glitch with the "number of bets" question, though I think that's more related to a lack clarity in the instructions than an actual code error. So full marks here.
Accessibility: 3
It's not too bad as far as a text-based game is concerned. Again, there is a small issue with some missing clarity in the instructions surrounding the "number of bets" question. The game of roulette itself is not difficult to understand, so getting into a text adaptation of it is not difficult, either.
Fun Factor: 1
A small modicum of enjoyment was had finding the extra text, but otherwise this falls into the category of games I truly dislike for being purely based on luck. There isn't any substance to compensate for the randomness, which is another nail in its coffin.
Roulette gets a total score of 24/70 (34.28%), which sits it in the middle of the E tier at the current time, between PDP Basketball and Gamnim. Again another throwaway program, in essence, that seems to be more about testing the waters of what can be simulated within early BASIC rather than trying to make a compelling game.
[Add.] Upon completing the rescore project, Roulette's lost 4 points down to a 20/70 (28.57%)
Oh boy. Horse racing. If it's not my most hated sport, it's certainly up there. Seems to me to be a sport purely made up as an excuse for stupid hats, drinking profusely and gambling your life savings away. All for a race that lasts for what, a minute or two? I have far more respect for other equestrian events, as there's far less pretentiousness involved, and far more substance.
With that mini-rant done, it's time to look at Horserace, a BASIC horse racing simulation programmed by South Portland High School student Laurie Chevalier. It was included in the original 1973 version of Ahl's 101 BASIC Computer Games, and was carried over into the 1978 microcomputer edition. Curiously, the author was unknown when the 1973 version of the book was published. The 1978 version has been slightly revised from the original, including a visual representation of the horses racing down the track, whereas the original simply told you what position the horses were in at certain distances along the track. I'd prefer it if there wasn't this constant fiddling with these programs, as I'd rather play them in their original form. But, this is all that's available (as far as I'm aware), so I just have to deal with it.
What paper?
I'll be honest with Horserace - I'm really unimpressed by it. It's another one of these games that's barely a game at all, to be blunt about it. The only part of horse racing this game focuses on is the betting aspect. You have a list of 8 horses to choose from, with their randomised odds listed next to them. You can bet a maximum of $100,000, but only on one horse. The original version allowed you to place bets on multiple horses, and I don't know why this change was made. Not like it matters anyway, because the game doesn't keep track of your purse, only what you won if you made a successful bet. I assume the purse was to be managed the old-fashioned way. The one interesting thing is that this is technically a multiplayer game, supporting up to 10 punters at once. 10 players is quite a lot for 1970, so at least Horserace has a degree of innovation to its name.
Bet on the horse named "Horse." What could possibly go wrong?
That's what.
I tried a couple of rounds, failing to win most of them. I did win $450 on one, placing a bet on the favourite horse at 4.5:1 (I didn't record this win). That was more than enough for me. As a side note, the visual representation of the racetrack scrolled far to quickly when running Horserace through Vintage BASIC. It's not meant to run that fast, but I don't know of any way to slow the game down with that particular program.
The visual representation of the horses racing down the track. The finish line is just off screen.
So, that does it for Horserace. On to the scores.
Time Played: 5 minutes.
I threw down a handful of bets, which doesn't take terribly long, and had enough after that. There's nothing else to see here, so no reason to play for longer.
Difficulty: 0
There is no difficulty. It's all luck, anyway.
Game Design: 0
Barely even counts as a game, since what 'gameplay' there is consists of making a bet and seeing what the computer spits out. It could possibly be slightly more interesting if one made use of the multiplayer, but I only consider the singleplayer experience for my scores anyway.
Controls: 10
I can at least give Horserace full marks for controls - it's dead simple and the inputs are easy (not like there's that many needed to begin with).
Sound and Story are N/A, as per usual with these early text games.
Visual: 5
For an early-70s text game, it's not that bad. Everything is formatted nicely, the table of horses is clear and understandable, and it does also provide a very primitive depiction of the race itself.
Functionality: 5
Again, full marks here. Very little that could probably go wrong with a program like this in the first place.
Accessibility: 2
Really hinges on whether you like betting on the horse racing or not, I suppose. Once again, there's very little to access anyway, and it's not overly compelling, so I imagine most people wouldn't bother to begin with.
Fun Factor: 0
Putting aside my distaste for horse racing, this game really offers nothing whatsoever in terms of gameplay, and thus enjoyment. Or, really, anything for me to actually enjoy.
Horserace really is a bit of a throwaway program. A couple of bets, and you've seen everything the game has to offer. It therefore ends up with a rather miserable final score of 22, and percentage of 31.42%, giving it a placement low in the E tier of the tier list. It scored slightly better than Qubic and Digits, and was one point below PDP Basketball.
[Add.] Upon completing the rescore project, this game's score has been rightly revised down to a pathetic 17/70 (24.28%), relegating it to the shame of the F-tier.
Next up, we have Gamnim, or Nim as the game calls itself internally. This is another of the 3rd of September crew of games (of which there is a second Nim game). I've already covered one Nim game, the Polish Marienbad, though I couldn't play it, making this the first Nim video game to be played on OGC (and it definitely won't be the last).
Once again, the author is unknown. BASIC Computer Games suggests the game originated at Dartmouth College, but provides no author. A modified version would appear on the Sol-20 microcomputer in 1977, once again courtesy of Ralph E. Hopkins. That version appears to be where the Gamnim title comes from.
Completely free to set the game up the way you want.
I think this might be the first game with options to modify gameplay - the game setup is fully customisable! It asks first for the win condition you want to play by: either as taking the last object, or forcing your opponent into taking the last object. It might be a small detail taken for granted nowadays, but I think that's pretty neat compared to the text games I've played so far. Afterwards, it asks for the number of object piles you want to play with, and how many objects to be in each pile. Even better. BASIC Computer Games recommends the traditional setup of Nim, which is 4 piles with 7, 5, 3 and 1 objects respectively. So that's what I go with.
It's been a little while since I played Nim - I think the last time would've been the Fairchild Channel F's version, hunting RetroAchievements. Vaguely, I remember there being some trick to win concerning odd and even numbers - can't quite remember specifically.
Just a bit rusty... yeah, let's go with that. Rusty.
I lost the first game. I think I'm remembering the trick being to make sure the pile is on an odd number if you play with the traditional win condition (taking the last object). Anyway, I play a few more times, losing every single time while I try to remember how to win.
Eventually I had to go to the internet to refresh myself on the Nim strategy. There's this whole thing about the "Nim sum" and making sure that it equals zero at the end of your turn. I found the article that I used previously, and it makes decent sense of it. Other articles I looked at were a bunch of gobbledygook that overcomplicated things wildly, bringing binary multiplication and all sorts of other weird mathematical stuff in that I, frankly, don't care to read.
The most important thing that linked article notes is that, with the traditional setup, the player going first is disadvantaged. If you're playing a computer that is programmed to play perfectly, this means you'll always lose going first. It's the reverse of Tic-Tac-Toe, in that sense.
Having reminded myself of these facts about Nim, I won a game with the traditional settings going second. The "Nim sum" rule works the same way regardless of win condition, so going second will always net a win in this version if you play perfectly. I know because I tried the "avoid last object" win condition, thinking this would reverse the rule, but I quickly found out it doesn't.
It took me about 30 minutes until I decided to refresh myself on how to win Nim.
Winning a game with each win condition was good enough for me. So, I decided it was time to push the limits. I was wondering - how many piles can I have? And how high can the numbers go?
You'd have to be really keen on Nim to try this...
I discovered that you can have up to 100 piles of objects, with a maximum of 2000 objects in each. I cannot even begin to fathom why you'd want to play a game of Nim that massive, or how long it would take to complete (and I'm not intending to find out, either). It's there if you're an absolute die-hard Nim fan, though, and have a few hours to kill. That's all there is to Gamnim, so on to the scores.
Time Played: 40 minutes. I did something a little differently, recording my playthrough while simultaneously note-taking and researching Nim strategy, hence why this number is a little higher than previous games.
Difficulty: 5
It's really tricky to judge, since it's so heavily user-defined. Putting it in the middle is fair, based on that. Plus, you're going to have a hard time winning, since the computer always plays perfectly.
Game Design: 3
It's quite standard as a Nim simulation, and doesn't do anything apart from allow you to simulate various Nim scenarios. But, on that point, I do have to give the game props for allowing you so much choice in how you set up the game. No other game up to this point has allowed for customisation, so it gets bonus points for that. The other issue is that you can only play against a computer that plays perfectly; this would be perfect as a two-player game. It essentially means that, to make use of the customisation, you have to really enjoy Nim as a game already.
Controls: 9
Can't complain much, has those comma inputs, but is otherwise very simple.
Visual: 3
That paragraph of instructions is quite an ungainly mess. The game itself is presented quite plainly.
Functionality: 5
I had no issues with stability, nor were there any glitches.
Accessibility: 3
Fairly standard for a text-based game; helps that it's based on a simple game concept.
Fun Factor: 2
To be honest, it's not that enjoyable for me. I don't really care for Nim as it is, especially when I have to play against a perfect computer opponent. While the customisation options are neat, I don't see myself ever coming back to try them out. This would work much better as a two-player game.
That's a total score of 25/70 (35.71%), placing Gamnim in the E tier, between 1Queen and PDP 10 Timesharing Basketball. Sounds about right.
[Add.] Upon completing the rescore project, Gamnim took a bit of a hit to its score, losing 4 points down to 21/70 (30%)
Telling you right now, this is going to be a quick one. This barely counts as a game, to be honest with you.
I had to skip over Apawam and declare it lost, as the only seemingly surviving version of the game is one modified by Steve North for the 1978 edition of BASIC Computer Games, and from what I read from the descriptions of both games, North's version isn't so much a modification as it is a complete overhaul. I'll be treating that as a separate game.
Digits is one of about half-a-dozen titles with the same release date - 3rd of September, 1970. I don't know where MobyGames gets these dates from, but I'd love to know (possibly the DECUS program library?). The original author is unknown; all that is known is that the program originated at Dartmouth College - specifically the Kiewit Computation Center at the college (a project spearheaded by John Kemeny and Thomas Kurtz - the inventors of BASIC, which Digits was programmed for).
Digits presents a rather odd concept: you are to come up with a random string of 30 numbers between 0 and 2, and the computer will try to guess your numbers using something BASIC Computer Games called "pattern recognition techniques." These numbers are inputted 10 at a time, and to win, the computer must make less than 10 correct guesses (which the game claims it should be able to do "by pure luck"). That's the game. It's beyond simple.
The game's instructions. It's cute that it asks you to write on paper. Who does that these days?
I find it amusing that the author of the game writes the computer to speak in first person. It's endearing, somewhat. For my first attempt, I thought I'd have a laugh. I got my phone's notepad out, and randomly smashed the 0, 1 and 2 keys until I had at least 30 numbers. Inputting them was actually a bit annoying, as the game doesn't tell you how it wants the numbers inputted. The required syntax is to type the numbers in, with a comma after each number, but no spaces.
I confused the poor thing.
Eventually, after looking at the game's page in BASIC Computer Games, I managed to get the numbers in correctly.
There we go.
So it managed 4 correct guesses on that pass. Not the best start when I want it to guess less than 10.
Ugh, and there's still one set to go.
It got 6 right on the second set, so there goes that game.
My last set was an improvement, at least.
As a consolation, it only scored 2 correct guesses on the third and final set. I noticed that it didn't select 0 as a guess at all that round. I could've selected 0 30 times in a row and it wouldn't have got one right...
I decided I had to win, so another round was required. Taking what I learned from that first game, I took a different approach to choosing my numbers - I selected longer strings of the same number, interspersed with solitary numbers along the way. It seems to me like the computer prefers to guess long strings of one number.
I'll take that as a small victory.
My strategy appears to be paying off. It only guessed 3 right in the first round this time.
Ha! Some "pattern recognition techniques" these are...
Oh dear, the computer had a bit of a disaster on the second set. Only 1 correct. I noticed from the first round that it seemed to be preferring 2 this game, so I tried to avoid overusing it.
Maybe I should've done the all zeros thing.
I went a little silly on the last set, doing zero 5 times in a row. You'd think it'd catch on after maybe the third one, but it missed the whole lot! It got 4 of the last 5 right, but that only got it up to 8 correct guesses, so I win. There's nothing else to say, so score time.
Time Played: 6 minutes. That's how long the two rounds took.
Difficulty: 1
It's a guessing game, do you really expect any challenge? You just plonk in numbers and hope to computer doesn't guess them. All luck, no skill.
Game Design: 0
Barely a game at all; it's just a lucky guess simulator, so there is literally nothing to say about it.
Controls: 7
I'm knocking off points for the weird syntax stuff with commas, and because the game doesn't tell you that that's what you need to do. Otherwise, it's easy.
Visual: 5
It's presented decently. All the text is neatly formatted, no typos, and the guess spreadsheet is clear. The game is very polite, always saying please when asking for my numbers, so I can at least give it that.
Functionality: 4
Again, that syntax thing is silly, but it works fine otherwise.
Accessibility: 3
It's one of the more accessible text games thus far, due to its simpler-than-simple concept.
Fun Factor: 1
Yeah, there's nothing here for me. Plonk in some numbers and hope for the best. Next.
This gives Digits a score of 20. Percentage wise, it's - miraculously - not the worst game on the tier list. At 28.57%, it's above Qubic in the E-tier. While I hated Qubic, I'm not sure I'd agree with that result. Although I'd rather play neither, I think I would play Qubic ahead of this any day of the week. Perhaps a revision of Qubic may be needed in the future?
[Add.] Upon completing the rescore project, this game managed to get even worse, dropping to a 19/70 (27.14%).
In any case, I'm glad this one's over and done with. Gamnim is up next - one of many, many, many versions of Nim released across the 70s.
