Thursday, February 21, 2019

Game 47: 3-D Tic-Tac-Toe

Buy 3-D Tic-Tac-Toe and about 90 other Atari games in the Atari Vault on Steam:
http://store.steampowered.com/app/400020/Atari_Vault/

Read the manual at AtariAge:
https://atariage.com/manual_thumbs.php?SoftwareID=798


Figuring out the chronology of this game was tricky, but from the looks of things, freshman Atari programmer Carol Shaw began work on the VCS version in late 1978, finished in 1979, and made an enhanced port for the new Atari 400/800 computers the same year. The strongest clue for this was an inventory of Carol Shaw related items archived at the National Museum of Play, including dated printouts of code for “Qubic” and “Colleen Qubic.” As “Colleen” was the development name for Atari’s computer systems, this would indicate the VCS version was the original, despite the fact that the 400/800 version was more fully-featured, may have been released first, and that the much weaker VCS simply was not up to the task of playing this game at a high level.

This variant of Tic-Tac-Toe was first popularized by Parker Bros. in 1965 as the board game Qubic. With a 4x4x4 grid for a total of 64 squares and 76 possible winning plays, most human players aren’t capable of mastering it to the degree that young children are capable of mastering conventional 3x3 Tic-Tac-Toe. To win, you must get four of your symbols in a row or diagonal, which can be difficult to visualize when the diagonals span multiple planes. Casual observation suggests an upper boundary of {64!} possible games, which is a much larger number than there have been Planck seconds in the history of the universe, let alone something the VCS could calculate in a reasonable amount of time, or hold in its 128 bytes of memory.

The AI plays a strong game at the highest level, but at a price. It plays semi-randomly at first, putting O’s exclusively on the eight corners of the cube and the eight spaces in the middle, without a clear pattern for the first few moves. Then, at some point, it decides it’s done playing around, and the screen goes haywire, as it starts developing an elaborate plan to beat you. At this point, it can take minutes for the AI to make its move. During this midgame, it will skillfully place complex networks of two-in-a-rows across multiple planes, until it suddenly makes an alarmingly quick move and you notice it has placed a third O in a row. Now you’re screwed; you have no choice but to block the fourth space, and it will continue forcing you down a sequence of blocking moves that ends with the AI creating a forking pair of three-in-a-rows. Since you can only block one of them, you will lose on the next turn.

The manual claims the AI can look up to nine moves ahead and can take up to 20 minutes, but I don’t think I ever saw it take more than three. That’s still a long wait, even with warp speed emulation.



I did eventually beat the AI on its hardest setting, but it took many tries, and felt kind of like trial and error. Playing first was key; the AI plays first by default, which is to its advantage. By losing enough, I got a feel for how it constructs its multiplanar traps, and was able to construct one of my own while also blocking the AI’s own trap before it could be sprung. During the above game, the AI was cooperative in not blocking my trap, and I was able to force it down a sequence of blocking moves until I was able to force a victory.

The Atari 400 version, which may have been released before the VCS version but appears to have been developed later, is a general improvement. It features an AI at least twice as fast, doesn’t glitch out the screen while thinking, and has several more gameplay options. Among them is an alternate mode called “Bottom-Up” which only allows you to place your marks on the bottom grid or on a square directly above an occupied space, sort of like a 3D Connect Four.

One last thing that I found interesting. This isn’t the first 3D Tic-Tac-Toe computer game. Mobygames has versions as early as 1962, several of them even called “Qubic.” But one version that predates this Atari version is for the TRS-80, released by Adventure International in 1978.



Big deal, right? Well, they later ported it to the Atari 400, and this is how it looked there:



And the box art even looks suspiciously familiar.

Scan by Giantbomb

Scan by Atarimania

4 comments:

  1. Seeing "AI" and "Atari 2600" together in the same sentence is a bit of a novelty!

    I'm looking forward to your Star Trek and Star Raiders posts listed on the upcoming posts. We played these quite a bit on the old 2600. Star Trek was also available at the local Aladdin's Castle, but we had a fairly restricted access there, mainly due to having to pay up with our own hard earned cash!

    Have you read "Racing the Beam" by Monfort and Bogast? It's a very interesting book on the 2600. Some parts are beyond my computer knowledge, but I give it a thumbs up.

    ReplyDelete
    Replies
    1. I've got that book on Kindle! Haven't read it cover to cover yet, but I've read select chapters from it. It's a good read, if a bit heavy on impenetrable TIA stuff at times.

      Delete
    2. I did find some of the book quite dense and skimmed... unfortunately my programming knowledge these days is pretty much summed up by:

      10 PRINT "arthurdawg is awesome!"
      20 GOTO 10

      So much for all that BASIC programming and semesters of Turbo Pascal back in the day. I'm pretty sure we had "B" when I was in college, but "C" wasn't invented. Ha!


      Delete
  2. The reason the 2600 blanks the screen while thinking is that otherwise it would be spending ~80% of its processing power to just drawing the screen. The 2600 doesn't have a framebuffer (there isn't simply enough RAM!), the contents of the screen don't "exist" anywhere, they're completely ephemeral. As the CRT TV is scanning across the screen, the 2600 is generating the image on the fly using just a little of hardware to assist the CPU. (There are couple sprite registers that store just a few bits of graphics data, and those are constantly repositioned by the CPU as the beam scans past them.)

    So, mostly games did all their processing during the vertical blank period between each television frame. Rest of the time the CPU was 100% busy with literally drawing the screen.

    ReplyDelete