Looking through the code, yep, my simulation criteria were so conservative that I only simulated the PasswordBots. OscillatingTwoThreeBot was oh so close to only having two open parentheses but it used a decorative set of parentheses in the class definition (as did many others) Looks like I didn’t need simulation anyway.
I am somewhat interested in using the code to explore alternate timelines. Who wins without me? Who wins the clone showdown if it’s allowed to happen? What happens if you start the game at round 90 and make the smart bots use their endgame strategies in a pool full of silly bots? What happens if you remove npc bots and have a pool of only players? Does anything interesting happen if the number of turns per round is 101 rather than 100? I’m probably not interested enough to commit to doing this in a timely manner though.
What marginal submission would win in this pool? Probably just a MimicBot with Measure’s opening game. Using simulation, especially hy-compatible simulation, could make you win more as long as you didn’t simulate MeasureBot, or only simulated it in a separate thread.
It’s been a great ride. Thanks for running the game, lsusr.
Why did you have your password bots:
A. Look at the opponent’s plays, rather than opponent’s source code for the password?
B. Return 2 when friendly instead of 0?
C. Return 3 against the field instead of trying to cooperate?
A: EarlyBirdMimicBot is extremely restrictive about what it simulates, because I was worried about malware. MeasureBot confirmed this fear, though I could have been less restrictive and still avoided it. Therefore, PasswordBot cannot look at its opponent’s source code if it wants EarlyBirdMimicBot to simulate it.
B: EarlyBirdMimicBot’s simulation strategy is brute force, looking at the result of every possible sequence of the next N moves. lsusr required bots to make their moves quickly, so to save on time I only considered the moves 2 and 3 when simulating.
I could have addressed this by simply having a special case behavior against PasswordBots instead of simulating them, but I didn’t think of that.
C: I was actually planning to do this but screwed it up and did not check it properly before uploading. It would have been tit-for-tat against the field if I did it right.
Ah, but the beauty of collusion is that you don’t have to be robust. Having thought about this for a month, I would have just had the poor bots check opp source code for a password, and play all 0 against you (and perfect cooperation vs each-other). Then you just check their source code for a password, and play all 5s against them as a special case.
Private keys are amazing things, as long as you can secure them. And unless lsusr was going to let people update their source code from within their program for subsequent rounds (navigate the file directory for your source file, write a new version, hope the game engine re-loads it between rounds) there’s nothing other bots could do to exploit it.
Looking through the code, yep, my simulation criteria were so conservative that I only simulated the PasswordBots. OscillatingTwoThreeBot was oh so close to only having two open parentheses but it used a decorative set of parentheses in the class definition (as did many others) Looks like I didn’t need simulation anyway.
I am somewhat interested in using the code to explore alternate timelines. Who wins without me? Who wins the clone showdown if it’s allowed to happen? What happens if you start the game at round 90 and make the smart bots use their endgame strategies in a pool full of silly bots? What happens if you remove npc bots and have a pool of only players? Does anything interesting happen if the number of turns per round is 101 rather than 100? I’m probably not interested enough to commit to doing this in a timely manner though.
What marginal submission would win in this pool? Probably just a MimicBot with Measure’s opening game. Using simulation, especially hy-compatible simulation, could make you win more as long as you didn’t simulate MeasureBot, or only simulated it in a separate thread.
It’s been a great ride. Thanks for running the game, lsusr.
Why did you have your password bots: A. Look at the opponent’s plays, rather than opponent’s source code for the password? B. Return 2 when friendly instead of 0? C. Return 3 against the field instead of trying to cooperate?
A: EarlyBirdMimicBot is extremely restrictive about what it simulates, because I was worried about malware. MeasureBot confirmed this fear, though I could have been less restrictive and still avoided it. Therefore, PasswordBot cannot look at its opponent’s source code if it wants EarlyBirdMimicBot to simulate it.
B: EarlyBirdMimicBot’s simulation strategy is brute force, looking at the result of every possible sequence of the next N moves. lsusr required bots to make their moves quickly, so to save on time I only considered the moves 2 and 3 when simulating.
I could have addressed this by simply having a special case behavior against PasswordBots instead of simulating them, but I didn’t think of that.
C: I was actually planning to do this but screwed it up and did not check it properly before uploading. It would have been tit-for-tat against the field if I did it right.
Ah, but the beauty of collusion is that you don’t have to be robust. Having thought about this for a month, I would have just had the poor bots check opp source code for a password, and play all 0 against you (and perfect cooperation vs each-other). Then you just check their source code for a password, and play all 5s against them as a special case. Private keys are amazing things, as long as you can secure them. And unless lsusr was going to let people update their source code from within their program for subsequent rounds (navigate the file directory for your source file, write a new version, hope the game engine re-loads it between rounds) there’s nothing other bots could do to exploit it.