How do you determine who gets the first 3? Maybe lsusr will be kind enough to provide a symmetry-breaking bit in the “extra” package. (It would only be fair, given that bots playing themselves are automatically given max score.) If not, and you have to do things the hard way, do you compare source code alphabetically, and favour X over Y on even rounds and Y over X on odd rounds?
Also, it may be a good idea to make the level of defection against outsiders depend on the round number. i.e. cooperate at first to maximize points, then after some number of rounds, when you’re likely to be a larger proportion of the pool, switch to defecting to drive the remaining bots extinct more quickly.
do you compare source code alphabetically, and favour X over Y on even rounds and Y over X on odd rounds?
Great idea! I’ve updated the following heuristic using that.
There is one thing that is different between the programs: the code that you will add to be executed in the later rounds (the payload). As I said, CloneBot will ignore it when judging whether its opponent is a clone. But if the opponent is a clone, it will use this heuristic to decide who goes first:
compare both payloads lexicographically
if the difference in length is the same parity as the round, the shortest plays 3
otherwise, the longest plays 3
This is fair, deterministic, and needs 0 turn to communicate. There’s no point in tweaking your payload in the hope of starting with 3 more often. The only problem are ties, which are unllikely, and adding your name as a comment solves it.
Why also compare length? Because otherwise, the payloads of extreme length (very short or very long) would have very stable alternating priority, while the ones in the middle would be more subject to randomness. This way, it’s the same randomness for everybody.
Also, it may be a good idea to make the level of defection against outsiders depend on the round number. i.e. cooperate at first to maximize points, then after some number of rounds, when you’re likely to be a larger proportion of the pool, switch to defecting to drive the remaining bots extinct more quickly.
That seems reasonable. I’m just worried that we might let greedy or even cooperating bots take too much lead. Ideally, as soon as the clique reaches criticals mass, it should starve its opponents. The ‘as soon’ depends on what proportion of the pool we’ll initially be.
How do you determine who gets the first 3? Maybe lsusr will be kind enough to provide a symmetry-breaking bit in the “extra” package. (It would only be fair, given that bots playing themselves are automatically given max score.) If not, and you have to do things the hard way, do you compare source code alphabetically, and favour X over Y on even rounds and Y over X on odd rounds?
Also, it may be a good idea to make the level of defection against outsiders depend on the round number. i.e. cooperate at first to maximize points, then after some number of rounds, when you’re likely to be a larger proportion of the pool, switch to defecting to drive the remaining bots extinct more quickly.
I am neither kind nor fair-minded enough to provide a symmetry-breaking bit in the
extrapackage.Great idea! I’ve updated the following heuristic using that.
There is one thing that is different between the programs: the code that you will add to be executed in the later rounds (the payload). As I said, CloneBot will ignore it when judging whether its opponent is a clone. But if the opponent is a clone, it will use this heuristic to decide who goes first:
compare both payloads lexicographically
if the difference in length is the same parity as the round, the shortest plays 3
otherwise, the longest plays 3
This is fair, deterministic, and needs 0 turn to communicate. There’s no point in tweaking your payload in the hope of starting with 3 more often. The only problem are ties, which are unllikely, and adding your name as a comment solves it.
Why also compare length? Because otherwise, the payloads of extreme length (very short or very long) would have very stable alternating priority, while the ones in the middle would be more subject to randomness. This way, it’s the same randomness for everybody.
That seems reasonable. I’m just worried that we might let greedy or even cooperating bots take too much lead. Ideally, as soon as the clique reaches criticals mass, it should starve its opponents. The ‘as soon’ depends on what proportion of the pool we’ll initially be.