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%)
