Submission #9378: nymx & DrD2k9's C64 Scorpion II in 02:24.35

Scorpion II is a card game that has similarities to "Solitaire". Unlike many other forms of that game...all the cards are dealt, leaving no deck to deal with. With this version, there are five cards face-down in the center of the top row, three in the second, one in the third, and none in the fourth. Afterwards, the remaining cards dealt...will repeat the same pattern again, minus the last row.

The article for this game can be found on page 46 of Compute's Gazette Issue 64 (October 1988)

The continuation of TASing games from my all-time favorite magazine, Compute's Gazette. This makes my 87th TAS from this series.

This is a magazine that I can't forget. The game that caught my attention, was [5726] C64 Maze Master by nymx in 00:20.26...which I TASed at the end of 2023. Because of that game, I really didn't have interest in the other ones...as the names didn't appeal to me, nor did playing a computerized version of a card game. My thoughts were..."It looks boring". Woah! I was WRONG! This is a game that I missed out on, and now I'm enjoying it...especially the journey of TASing it

There is no difficulty setting. The ending is clear, as you will see all the cards collected at the bottom...only to be followed up by a "jingle". Then it goes back to the main menu.

Once I realized how this game operated, I immediately thought of BOTing. Only this time, I was going to port the operation of the game over to a C# application as I did with [6148] C64 Match Blox by nymx in 00:55.66. This would dramatically speed up the process and give me a more optimized game. The problem...is that I have to find the right seed, in order for this to stand. So, below is the process on how I approached this version:

This process took a bit of time to figure out, as I had to experiment on which layouts would yield the fastest times. I had originally thought of collecting up a large amount of "Card Layouts" and BOTIng each one...but the process of BOTing all of them would have taken a super long time (Maybe a few years?). So, I decided to scan for the best layouts; however, what would that look like? Well, I quickly discovered that it was necessary to have all the "Aces" available for quick picking. So I wrote a lua script to get the responses from the emulator until I got a few scenarios I wanted. To get this lua script working, I had to find the locations where these cards were being generated. The layout can be found in the following addresses:

Here is where most of my time was spent. When I started building out the C# code, I started to realize how much detail was needed to make this happen. After about 1 month of coding, I finally figured out a method that helped me to get a reasonably optimized solution for one layout in about 24 to 36 hours. This time was dramatically reduced by capping the amount of possibilities generated, once I realized that a full run was taking more time than I could wait. If I had to guess, it probably would have taken weeks to get the results. At this point of my BOTing, I hadn't fully figured out a good method for a true "Multi-Threaded" environment. You might wonder, how come I have a multi-BOTed solution for [4637] SNES F-Zero by nymx in 39:30.36, [4547] NES Tetris 2 by nymx in 37:35.82, and [5775] C64 Pegs "maximum score" by nymx in 00:25.54. Well, they were done differently where I ran multiple emulator instances, with affinity set. One of the instances was a controlling master, while the other were slave driven. Each instance was given an assignment that others were not. When one had success, it communicated back to force the master to re-sync all the instances with the new findings...only to start over again.

The end result of this process, was a set of instruction on what card to move. Because it takes time to move the "hand", I added in calculations to help me identify the frame count of each move. it's not always perfect, but it relatively helped me to narrow down the fastest one.

Here is the easiest part of the entire process. I took "card moves" and translated them to inputs. By doing so, I had to focus on controlling the "Selection Hand" with precision to minimize movement waste.

DrD2k9: Claiming for judging.

DrD2k9: Delaying pending improvements.

nymx: Uploading an improvement found by DrD2k9 (176 frames), plus an additional 4 found by myself on movement optimization.

DrD2k9: Unclaiming as I have been added as co-author. Current version is 286 frames faster than the original submission.