The Intellivision 10, 2nd Edition Video Game System was one in a series of cheap plug and play systems featuring compilations of what I like to call "demastered" Intellivision games, and was actually licensed by Intellivision themselves. I don't know why they decided to go this route instead of just re-releasing some of the originals like they did later with the Intellivision Flashback. Too expensive at the time? Anyway, the systems consists of some stripped-down NES hardware, otherwise known as "Famiclone" or "NES-on-a-chip", all contained within the controller. It is not known who programmed the games on this plug and play system, although many speculate Nice Code Software had some involvement.

Crown of Kings is based on the Intellivision game Advanced Dungeons & Dragons: Cloudy Mountain. This port is good, but the slow movement while navigating the caves really takes away from the experience. Also, bats and spiders do not inconvenience the player at all in this version probably because their behaviors are bugged.

As many of you may realize by now, this is yet another installment in my quest to TAS the original Cloudy Mountain and all of its ports. If accepted, I think this would be the fifth such TAS on the site, and I even got an "all tools" version right behind this one. By the way, did you know there's a TI-89 version of Cloudy Mountain? BizHawk TI-89 support when? :P

The difficulty selected affects the speed of enemies and the number of arrows you get from quivers. This TAS played on the hardest difficulty, called "Hero" difficulty.

After analyzing all possible overworld map layouts, all of the fastest routes to Cloudy Mountain (the final mountain on the right) cross at least some river and forests. Therefore, we must first enter a blue mountain to pick up the boat to cross the rivers, then a red mountain to pick up the axe to traverse the forests, and finally head to Cloudy Mountain. The specific overworld layout we would manipulate is the first one which can make the complete traversal—blue mountain to red mountain to Cloudy Mountain—using only up-right, right, and down-right inputs on the map. This ensures that you're getting closer to Cloudy Mountain with every step since each would have a rightwards component. You can move one space on the overworld map every 8 frames so it is imperative we avoid any extraneous map movements.

It's easy to analyze the overworld map layouts via visual inspection, but what about the cave layouts? Well, I could write a script that would read the positions of the tools and ladders or crown halves upon entering a mountain, calculate the rectilinear distance between them, and then calculate the rectilinear distance from each to the player spawn point. Rectilinear distance would be used because it's the best approximation of true distance (which can be shorter if the player can move diagonally, or longer if corridor/chamber geometry doesn't allow a direct path from point A to point B). The minimum total rectilinear distance would then be calculated to decipher which cave layout(s) is/are optimal. This is exactly what I did and it worked better than expected. While there are a large yet finite number of cave layouts, there was only one CLEAR winner from the analysis.

The Lua script can be downloaded here

So to put numbers to things, the shortest total distance calculated of all cave layouts was 27 units. There were two of them. As I described earlier, calculating rectilinear total distance is merely an approximation, so I manually calculated the true distance for traversing all layouts which outputted distances of up to I believe 31. One of the 27-distance layouts was the CLEAR winner, being at least several units shorter than all others when measuring true distance. This is the very cave layout you see me traverse in all three mountains in the final movie.

OK, so how could we actually get this cave layout every time? Well, simply delaying a certain number of frames and/or changing the inputs made on the overworld layout prior to entering the mountain could change the next cave layout that is loaded. Even invalid map movements, which can be made at a rate of every 1-2 frames instead of every 8 can change the next layout. Depending on the situation, this can quickly grow into an unmanageable number of potential input and delay combinations to check, which is the second thing that the Lua script linked above can do. For a given input sequence, the script can check what cave layout occurs for every possible delay you could wait between each input—within a specified maximum frame the mountain should be entered on, of course. With this script, I was able to EXHAUSTIVELY test every single input/delay combination between each mountain that could be faster than the one in the final movie, and am highly confident that the final movie does indeed get the best cave layout with the smallest delay.

In the blue and red mountains, taking a death after collecting the tool then progressing to the ladder from the initial spawn point was only faster in the short term if you shot yourself with an arrow first before taking the final hit from an enemy. It is not faster in the long term because in Cloudy Mountain, it saves more time to go for the lower crown half first and survive, which you need to save all your arrows for.

nymx: Claiming for judging.

nymx: After I started analyzing this your inputs, I quickly realized that you are controlling RNG in the same way I do for many Commodore 64 that are written in machine language (non-cartridge related). This impresses me, as I completely understand the process that you went through to obtain this. As for the layouts, you certainly did your homework. Forcing the best possible map to come up will certainly prevent large chunks of frames to be found. In regards to my final analysis of your optimization...I can't see how any frame can be found. With the movement being so simple, you are left to traverse the best map layouts to solidly clinch an apparent optimal solution. Excellent job!

Accepting to Standard.

despoa: Processing...