If you’re participating in the contest and you want to win, I have a proposition for you:
Howdy! You’ve probably looked up Zvi’s past Darwin game that directly inspired this one. A group of players formed a clique who recognized each other, cooperated among themselves and defected on everyone else. They nearly wiped the board, but they were preyed upon by a member who played both sides.
What they missed was a way to guarantee that all members apply the decided strategy. They had no way to enforce it.
But we have a way.
I call it CloneBot: a bot who checks that its opponent has the exact same code as itself. No way to cheat that! It guarantees that every member of the clique does the same thing. Moreover, there’ll be a way to cooperate optimally, avoiding losing the first rounds to coordinate. The clique are gonna be the most efficient ccoperators.
But in the end we’re all gonna tie, it’s boring. I want to take a chance at winning!
So do I. This is why the clique are only going to collaborate until a predefined round. After we’ve eliminated the competition, we can have a dramatic showdown among ourselves. Cool, no? In the code, there’s gonna be a separate function that’s called only after a given round. The code checker will verify that the function is only called at the right time, but will ignore what is inside.
What will CloneBot do?
Depends on the proportion of clones. If we’re a big group, CloneBot will straight up defect against outsiders by playing 3. Otherwise, CloneBot will cooperate, but make sure opponent does not gain more than itself.
With its clones, CloneBot will cooperate by alternating 2-3. Who gets the first 3 will be determined fairly before the first turn starts.
Ok, but I don’t want to find myself in a small clique that’s going to lose.
You don’t have to commit to submitting CloneBot right away. All you need to do is contact me to say you’re in, conditional on the clique being large enough. By default, contact me privately. If you want, you can roll a D6, and if you roll 6, join me publicly right here.
A few days before the deadline, if we’re 5 or less, I’ll just announce that the critical mass was not reached. But if we’re more than 5, I will make public the names of all who contacted me to join the group and crush the competition. If I post your name at that moment, you must submit CloneBot.
I like the idea, but I wish X instead of Y.
Every detail is open to discussion for about 3 days. After that, this post will be updated, and every person who expressed their desire to join will be informed of the changes and asked to confirm their participation.
I don’t approve of this. Assuming that everyone who pledges to join the clique actually submits a CloneBot and nobody finds a way to beat the recognition code and defect from the clique, and assuming there isn’t a subtle bug in the code that disqualifies some or all of the clones, then the clone cohort can indeed eliminate the non-clone bots. At that point though, we’re right back where we started, and then what? Why not just let the best bot win in the first place?
If everyone goes through with this, then of course I’d be better off submitting a clone myself (again assuming no cheating/errors/etc. - I would certainly need to see the code myself before deciding to join), but this is a bit different from typical public-goods-type pledges. Typically, everyone wants the thing done but given that it is done would individually rather not contribute. Here everyone would rather the thing not be done, but given that it is done would individually rather contribute. This is a straightforward example of a bad equilibrium.
If you have pledged, or are thinking of pledging, consider:
How surprised would you be if a bug in the CloneBot code disqualified all the clones?
How surprised would you be if someone managed to bypass the code checking and defect from the group?
How surprised would you be if one or more people who pledged didn’t actually submit a CloneBot?
Is this the kind of equilibrium you want to encourage?
I get it that you don’t like that players join forces. I am not sure I’d allow coordination if I had a say on the rules. But per the rules coordination is part of the game. That’s it. For all we know, others are making cliques in secret.
I believe my scheme substantially increases our chances of winning, so I’ll go with that.
Admissions are closing soon. Good luck, whatever you decide :)
At least one member asked for a basic obfuscation measure. Publishing the code would defeat their purpose.
Also, from an insider’s perspective, publishing the code now would only slightly increase our chances to get another member before the end of admissions, while it would entail a significant risk of opponents adjusting their strategy against it. I should have decided on the publication earlier, but honestly it was never a priority.
It’s been an exciting week, I’ve had lots of fun, thanks everyone who shared ideas, and thanks lsusr for swiftly and kindly answering all my questions. Now is time for the final act.
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.
If you’re participating in the contest and you want to win, I have a proposition for you:
Howdy! You’ve probably looked up Zvi’s past Darwin game that directly inspired this one. A group of players formed a clique who recognized each other, cooperated among themselves and defected on everyone else. They nearly wiped the board, but they were preyed upon by a member who played both sides.
What they missed was a way to guarantee that all members apply the decided strategy. They had no way to enforce it.
But we have a way.
I call it CloneBot: a bot who checks that its opponent has the exact same code as itself. No way to cheat that! It guarantees that every member of the clique does the same thing. Moreover, there’ll be a way to cooperate optimally, avoiding losing the first rounds to coordinate. The clique are gonna be the most efficient ccoperators.
But in the end we’re all gonna tie, it’s boring. I want to take a chance at winning!
So do I. This is why the clique are only going to collaborate until a predefined round. After we’ve eliminated the competition, we can have a dramatic showdown among ourselves. Cool, no? In the code, there’s gonna be a separate function that’s called only after a given round. The code checker will verify that the function is only called at the right time, but will ignore what is inside.
What will CloneBot do?
Depends on the proportion of clones. If we’re a big group, CloneBot will straight up defect against outsiders by playing 3. Otherwise, CloneBot will cooperate, but make sure opponent does not gain more than itself.
With its clones, CloneBot will cooperate by alternating 2-3. Who gets the first 3 will be determined fairly before the first turn starts.
Ok, but I don’t want to find myself in a small clique that’s going to lose.
You don’t have to commit to submitting CloneBot right away. All you need to do is contact me to say you’re in, conditional on the clique being large enough. By default, contact me privately. If you want, you can roll a D6, and if you roll 6, join me publicly right here.
A few days before the deadline, if we’re 5 or less, I’ll just announce that the critical mass was not reached. But if we’re more than 5, I will make public the names of all who contacted me to join the group and crush the competition. If I post your name at that moment, you must submit CloneBot.
I like the idea, but I wish X instead of Y.
Every detail is open to discussion for about 3 days. After that, this post will be updated, and every person who expressed their desire to join will be informed of the changes and asked to confirm their participation.
Where do I find CloneBot?
I’m considering making the code public.
Let the best clique member win :)
I don’t approve of this. Assuming that everyone who pledges to join the clique actually submits a CloneBot and nobody finds a way to beat the recognition code and defect from the clique, and assuming there isn’t a subtle bug in the code that disqualifies some or all of the clones, then the clone cohort can indeed eliminate the non-clone bots. At that point though, we’re right back where we started, and then what? Why not just let the best bot win in the first place?
If everyone goes through with this, then of course I’d be better off submitting a clone myself (again assuming no cheating/errors/etc. - I would certainly need to see the code myself before deciding to join), but this is a bit different from typical public-goods-type pledges. Typically, everyone wants the thing done but given that it is done would individually rather not contribute. Here everyone would rather the thing not be done, but given that it is done would individually rather contribute. This is a straightforward example of a bad equilibrium.
If you have pledged, or are thinking of pledging, consider:
How surprised would you be if a bug in the CloneBot code disqualified all the clones?
How surprised would you be if someone managed to bypass the code checking and defect from the group?
How surprised would you be if one or more people who pledged didn’t actually submit a CloneBot?
Is this the kind of equilibrium you want to encourage?
I get it that you don’t like that players join forces. I am not sure I’d allow coordination if I had a say on the rules. But per the rules coordination is part of the game. That’s it. For all we know, others are making cliques in secret.
I believe my scheme substantially increases our chances of winning, so I’ll go with that.
Admissions are closing soon. Good luck, whatever you decide :)
I can’t say it’s not fair, and I do realize you’ve put a lot of work into this. Have you decided to make the clone code public?
At least one member asked for a basic obfuscation measure. Publishing the code would defeat their purpose.
Also, from an insider’s perspective, publishing the code now would only slightly increase our chances to get another member before the end of admissions, while it would entail a significant risk of opponents adjusting their strategy against it. I should have decided on the publication earlier, but honestly it was never a priority.
We were five hundred, but with swift support
Grew to three thousand as we reached the port
(Le Cid)
It’s been an exciting week, I’ve had lots of fun, thanks everyone who shared ideas, and thanks lsusr for swiftly and kindly answering all my questions. Now is time for the final act.
arxhy
DaemonicSigil
Emiya
frontier64
Lanrian
Multicore
philh
simon
Taleuntum
Vanilla_cabs
You will receive a personal message shortly.
That is all.
I pledge to join if there is at least 5 people total joined.
Pledging now to join if at least 8 do.
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.