This topic is for the purpose of discussing #9448: eien86 & Chef_Stef's NES Arkanoid "warpless" in 10:20.61

Woah!! This is truly unexpected! I can't wait to dig into this!

There was a special controller for this dilogy? Wow! Watching this TAS makes me feel like the game has the easiest difficulty where you can't lose any ball Yes vote

Never knew Arkanoid allowed a special controller to be used instead of a regular NES controller. This was awesome. Definitely voting Yes :)

Great job. It's a yes vote for me. I was especially interested in the end-of-stage score tally. I recreated the graph from Post #522668 with this submission included. The graph, which shows the number of blocks remaining and the time required to tally the score for every frame in level 23, is attached below. To my surprise, this submission ties [5327] NES Arkanoid "warpless" by eien86 in 10:56.12 in level 23, taking 1588 frames. Both movies are 26 frames slower than [3943] NES Arkanoid "warpless" by Chef Stef in 11:11.18. If this submission takes the score tally into account, why is it that the optimizer did not find the faster solution? If I understand the submission notes correctly, it should be possible to teleport the paddle instantly to any required coordinate, and it should be possible to re-align the RNG sequence when earlier inputs change. Shouldn't it then be possible to import a known faster solution, even if it was not found automatically by the optimizer? Perhaps there is some important factor I am misunderstanding. I looked in the source code of QuickerArkBot to try and understand what was going on, but I may not have found the right places. I see UpdateScore, which does the tens-and-hundreds score tally logic on pendingScore. But I did not understand how it fits into determining when a level is finished. In the upstream arkbot, I see a place that checks for state.currentBlocks == 0 && state.pendingScore <= 0, but I did not find an analogous check in QuickerArkBot. I did not look at the code too hard, so it's possible I overlooked something. This is the graph that shows this submission and [5327] NES Arkanoid "warpless" by eien86 in 10:56.12 ultimately taking longer than [3943] NES Arkanoid "warpless" by Chef Stef in 11:11.18, even though they clear the final block faster, because they accumulate more pendingScore that takes time to burn down.

• arkanoid-score.lua
• arkanoid-score-3943M.csv
• arkanoid-score-5327M.csv
• arkanoid-score-9448S.csv
• arkanoid-score-3943M-5327M-9448S.r (code to make the graph)

Wait, all this time we were missing the fact that this game had a special NES controller that allowed for infinite-speed paddles AND better RNG manipulation? I'll be damned if I don't give this a yes vote for teaching me something new.

Glad you're liking the movie so far ;)

I was especially interested in the end-of-stage score tally. I recreated the graph from Post #522668 with this submission included.

Ah, stage 23, my arch-nemesis xD I was so sure I had solved this issue on all levels that I didn't even care to check. You're right in your analysis: now that we have full control over the RNG, we should be able to optimally solve this level, but still won't budge. Now in hindsight, the most probable explanation is a combination of: * The exploration space is not big enough. I am limited by the size of my server's RAM (384Gb at the time). It is possible that this stage has a pending score tail that lasts so long that I end up trimming the global optimum off the exploration tree. * The reward function doesn't consider pending score negatively enough. I should increase the penalty for it so that states with large pending scores are more likely to be discarded. I pledge to come back to this and fix it for good in the future, when I buy a new (at least 2x bigger and faster) server. Probably not this year ;)

I looked in the source code of QuickerArkBot to try and understand what was going on, but I may not have found the right places.

I have not yet made publicly available what you were looking for here. Here is the software stack I used: * JaffarPlus The generic breadth-first TASing bot * NES Arkanoid-specific state evaluation and finalization criteria for JaffarPlus (what you looked for, private for now) * QuickerArkBot The game-specific emulator and RNG finder Stay tuned!

Insane movie. The special controller allowing any paddle position is... convenient. I've never heard of this controller before.

I knew about the special Arkanoid controller but I didn't expect to see another big improvement to this game. 2025 started very well. Excellent job guys!

I like how the Arkanoid paddle controller actually improves the TAS. 1080p60 encode, with input display: Link to video I recommend viewing at 720p60 or above, since the "entertainment" effects don't show up on 30-fps settings.

I like how the Arkanoid paddle controller actually improves the TAS. 1080p60 encode, with input display: Link to video I recommend viewing at 720p60 or above, since the "entertainment" effects don't show up on 30-fps settings.

Omg this encode gave me life. You can see exactly the logic behind the entertainment inputs I added. I'll use it as official encode. Thanks!

I don't think it's fair that you can lie to us and call this "warpless" when your paddle is clearly teleporting. Easy yes vote, great job.

By the way, if you're wondering how I made the input display part of the encode (the left sidebar with the line-art paddle controller graphic), I generated the input display with a Lua script in BizHawk:

local joystick_posy=550
local fire_posy=300

local controller={}

gui.clearGraphics("emucore")
gui.clearGraphics("client")
gui.use_surface("client")

function circlebyradius(cx, cy, radius, col1, col2)
	gui.drawEllipse(cx-radius, cy-radius, 2*radius, 2*radius, col1, col2)
end

gui.drawBox(0,0,256,224,0xFF000000,0xFF000000,"emucore")

while true do
	console.clear()
	gui.drawBox(0,0,256,700, nil, 0xFF000040)
	gui.drawBox(20,220,256-20,700-20)
	gui.drawLine(123,220,123,0)
	gui.drawLine(133,220,133,0)
	circlebyradius(128,joystick_posy,80, nil, 0xFF000060)
	
	local prev_value=controller.Paddle
	local prev_fire=controller.Fire
	if not prev_value then
		prev_value=80
		prev_fire=nil
	end
	controller=joypad.getwithmovie(1)
	
	local pangle=(math.pi/180 * (180.5+(prev_value-80)*160/80))
	local angle=(math.pi/180 * (180.5+(controller.Paddle-80)*160/80))
	
	gui.drawLine(128,joystick_posy,128-80*math.sin(pangle),joystick_posy+80*math.cos(pangle), 0x40FFFFFF)
	gui.drawLine(128,joystick_posy,128-80*math.sin(angle),joystick_posy+80*math.cos(angle))
	gui.drawBox(127,joystick_posy+3,129,joystick_posy+77,0x8000FF00,0x8000FF00)	
	if controller.Fire then
		circlebyradius(128,fire_posy,30, 0xFFFF0000, 0xFFFF0000)
	elseif prev_fire then
		circlebyradius(128,fire_posy,30, 0xFFFF0000, 0x70FF0000)
	else
		circlebyradius(128,fire_posy,30, 0xFFFF0000, 0x20FF0000)
	end
	
	emu.frameadvance()
end

Then (separately from a normal encode of the TAS) record AVI with the options "Capture OSD" and "Capture Lua" enabled and do some editing with something like AviSynth. I didn't explore all the Lua gui options so there might be a better way to set this up.

This is very superhuman looking with the paddle teleporting all over the place and very fast clears. Despite that it seems to me that certain levels should be able to be done a little faster. Some levels look amazingly fast with all the balls zipping and bouncing off blocks rapidly and everything coming to a close about the same time. However a couple stages it seems the balls kind of struggle at the end to get the final block. Some levels also seem like it would be faster if more balls were shot through holes to bounce off the top of the map and the top of the blocks since the bouncing distance is less than the distance between the paddle and the nearest blocks on the bottom. I don't know if there is a way of directing the bot, but could be something to consider (or if improving is even possible). Still looks great though!