Talk:WhiteWhale (robot)

This is not a new idea, however it was generally agreed that this was a direction in development that shouldn't be pursued as it's tantamount to cheating. It's very cool that you got it working in practice and I'm all for trying new experiments on stuff like this outside the rumble, but weight classes in competition exist for a reason, and hiding the bytecode somewhere where codesize won't find it doesn't actually change the fact that you're using more code than the weight class allows for. Respectfully, I'd very much like to see this bot removed from the rumble. -- Kuuran 02:12, 3 October 2009 (UTC)

What is it doing, exactly? And have you looked at LittleBlackBook? It's also doing something that kind of puts it in a separate class from other NanoBots, though I'm not sure how they compare... --Voidious 02:21, 3 October 2009 (UTC)

If I understand your bot correctly, LBB is a little different... it uses preloaded information on the bots in a String (of GF's and what type of movement is best against the bot) but still uses normal code to execute that movement and to target that GF. I think it's a little more fair (although still a little debatable, especially after its success), because it will fail against any decent adaptive movement in a bot. I hope nanoland doesn't turn into only tricks and gimmicks to evading the code size calculuator :( But your bot is still cool, congrats on getting such a high score! --Spinnercat 02:52, 3 October 2009 (UTC)

(Edit conflict) Well, I just looked into it a bit. (Sorry if someone's typing a long response to me above... Spinnercat. =)) This does seem a bit unfair to me, too, as it is quite directly packing more execution code in a hidden way. And it would force a situation where the only way to compete is to use the interpreter. Preloaded data (like LittleBlackBook) also seems unfair to me, actually, but at least you can say that the actual code size is still within the NanoBot limits (if not the actual intelligence behind it). For what it's worth, I already view LBB in a different light when I look at the NanoRumble rankings, so if this were to stay in the NanoRumble, it would have a similar status in my mind... But hopefully we can come to a consensus on it, as I'm not keen on removing somebody else's bot. --Voidious 02:57, 3 October 2009 (UTC)

I also have little intention of removing someone else's work. Clearly coding this bot was not a simple task and is a big accomplishment, so I want to recognize that up front. But just like some other techniques were banned (anyone remember the teleportation bug? Or the bot I wrote that crashed against its ProblemBots so that those scores could never be recorded?) in RR@H I think this one also needs to be looked at. I had a conversation maybe 5 years ago with a few people that were active then on this topic, and the conclusion was that we'd cross that bridge when it comes. So I guess it's time to cross it.

LBB is personally something I wouldn't do, but I don't find it unreasonable. Basically when we code nanobots we code a lot of magic constants into them to determine how they move and how they shoot, the intelligence behind these constants is not inside the bot either. I might spend a few days poring over graphs from FloodGrapher to find the flattest profile for a bot, then just insert the movement that met the criteria. LBB takes this idea and basically just adds code to swap these constants out based on pre-loaded data. The code itself is still inside the bot. To me that's basically equivalent of including save data in a package for a bot which is capable of saving and loading data. Several years ago there was a vote on this and virtually everyone agreed that save data was okay, so LBB is in the clear in my view.

This is taking things a step further. If you go back a guy named Sin Varg came up with a similar approach that let him directly compile any arbitrary MegaBot into a MicroBot interpreter. It was a cool experiment, but to the best of my knowledge he never actually used it in competition. David Alves said it would be 'discouraged' but probably not outright banned, and I probably have to agree with him there.

My main problem with this is that it essentially takes the codesize limited classes from being a subset of all possible bots to being equal to all possible bots. It pretty much takes away the point of competing with codesize limitations to begin with. As someone who has never made a MegaBot and likely never will, I'd like to be able to continue playing this game without having to resort to writing pseudo-MegaBots for the NanoInterpreter to execute. -- Kuuran 03:35, 3 October 2009 (UTC)

I have to agree that this robot is very different from the other nanos and stretches the concept of using Strings as a cheap codesize trick. There are many reasonable arguments for whether this is legal or not and if there is a consensus on some clear boundary I definitely do not mind removing this from the rumble, after all, my motivation for this project has been from everything but writing the actual robot logic (which is probably why it has not performed as well as it could have done). Kinsen 04:07, 3 October 2009 (UTC)

Most things I'd have to say have already been said expect this: While I think codesize-restricted bots with interpereters, or bots with large amounts of pre-loaded data are fair game to remain in rumble, I feel that that they should perhaps be marked as such (colour coding perhaps?) and perhaps skipped in the numeric rankings when viewing the rumble results. That however would require some way of having metadata marking that for the rumble server to understand, and would also involve more work for Darkcanuck, so I'm not sure that would be practical, even if it's what I'd consider ideal. --Rednaxela 04:29, 3 October 2009 (UTC)

I think all bots in the same competition should follow the same rules, without "special cases". This bot does follow the rules, although I agree with others on this page that it violates the spirit of the nanorumble: writing a competitive bot with the least amount of code. An honourable way of keeping this bot in the rumble longer term might be to pad the codesize so that it falls into a more appropriate weight class. As a proof of concept it's very cool, but it's not really fair to other nano authors who've squeezed blood from a stone trying to get to the top of the rankings. --Darkcanuck 21:12, 3 October 2009 (UTC)

Sorry that I forgot to say congrats on this little monster. =) As for a clear boundary, my own thought process is basically Kantian (much like Kuuran's): if this is allowed, then the only way to compete at the NanoBot level will be to write larger robots into a NanoBot interpreter, at which point the weight class ceases to really exist at all.

I also can't help but think of David Sirlin's What Should Be Banned?, which says that a banned tactic should be enforceable, warranted, and discrete. I'm having trouble thinking of a boundary that would fit all of those criteria. If we agree the ban is warranted, a reasonable and discrete boundary may be the use of java.lang.Class. But is that enforceable without requiring NanoBots to be open source? Then again, enforceable may not be as big an issue in this generally open and honorable community. I'd like to add that if we do create a boundary that would ban this tactic, I'd personally still be OK with you entering it on a temporary basis to test its strength when you have a new version.

--Voidious 19:23, 3 October 2009 (UTC)

Great article Voidious! Obviously, the tactics and constants used are in essence a form of preloaded data. If one wanted to technically ban this, I think the easiest and smart-guy-proof solution would be to put a size limit on the whole .jar file. Otherwise (at least outside of nano), people would still be able to hide interpretable data in files or in the filenames of 0-byte files. :) --Positive 21:44, 3 October 2009 (UTC)