8
\$\begingroup\$

The King of the Hill tag could use a "Suggestions" section to help posters avoid pitfalls that are KotH specific. It could also use a tip on what does NOT constitute a KotH challenge, since I have seen newbies using it incorrectly.

Note that just because all submissions are competing against each other does not make it a King of the Hill challenge. The submissions must interact. For example, a challenge where are submissions are all competing for smallest code size would be a challenge, not King of the Hill.

Suggestions for a Smoother Competition

Unless you want participants to abuse a particular aspect of the challenge (which is often the case), consider using the following restrictions to close loopholes that are specific to King of the Hill challenges. See <insert help page here> for suggestions that apply to all challenges.

  1. Allow one submission per user.
  2. Restrict access to other submissions and any data they may generate.
  3. Restrict modifications to standard libraries.

Explanation:

If multiple submissions come from a single user, then the challenge can degrade to "Who can submit the most answers". It is in the user's best interest to write many submissions that help him achieve his goal of winning.

Submissions can cripple other submissions if given access to their code, their data, or the standard library. You might argue that other submissions could react, but then it really boils down to whose code gets run first. If I go first, then I win by stealing your strategy. If changing the order of the submissions also changes the results, then your spec has a serious problem.

Another argument might be, "A perfect controller program would enforce these restrictions in code." The counterargument is that a perfect controller can only be written by a perfect programmer. The point of King of the Hill is not to pit the author against the masses.

Things I don't know how to address:

I do not know how to objectively stop multiple users from collaborating, or one user with multiple accounts. Does anyone have a suggestion that would allow someone to objectively determine whether a submissions was collaborating? Is this even a fixable problem? Let's see what the Game Development people think.

\$\endgroup\$

1 Answer 1

Reset to default
-1
\$\begingroup\$

In those games where there is a order of play (the iterated prisoner's dilemma and similar situations do not have an order of play) the strategy stealing argument can be broken play playing not just all unique pairing but all (unique pairing)x(orders of play), and I would argue that the controller is ill-designed if it does not do so.

The multiple supporting entries business is perhaps more interesting---the iterated prisoner's dilemma is a game where "cooperating" strategies can re-enforce one another and defecting strategies risk sabotaging each other, but a lone wolf among the sheep can really clean up---but have we actually had a problem with that?

Not that I am discouraging you from offering a edit to the tag-wiki, but I think the solution to the order-of-play issue is clear and well defined and the other has not yet been an issue.

\$\endgroup\$
6
  • 2
    \$\begingroup\$ I recently wrote a KotH challenge where all players were on the same board and moved simultaneously. There was no "order of play". One of the Wolves tried to modify the Java standard library such that Random.nextDouble() always returned 1.0. Another submission attempted to modify the private variables of other submissions using reflection. If they had succeeded, then the challenge would degrade to "Which class will the JVM decide to load first?" It simply can't be determined without some serious knowledge of the inner working of the JVM. (cont) \$\endgroup\$
    – Rainbolt
    Apr 10, 2014 at 19:51
  • 2
    \$\begingroup\$ I preempted your "ill-designed controller" argument in the original post. Only a perfect person can write a perfect controller. You have to take extreme measures to write a controller that protects against stuff like java-performance.info/updating-final-and-static-final-fields . Why can't the author just say "Don't do it."? Don't you think that your idea of "ill-designed" is subjective? \$\endgroup\$
    – Rainbolt
    Apr 10, 2014 at 19:54
  • 1
    \$\begingroup\$ Sorry for the serial comments, but here's another thought. Assume a challenge has 50 submissions (my recently posted one is going to probably get that many soon). How many possible orderings of 50 wolves exist? The answer is 50! (50 factorial) and that is a huge number. \$\endgroup\$
    – Rainbolt
    Apr 10, 2014 at 20:04
  • 2
    \$\begingroup\$ Certainly the author can say "just don't do it". But if you don't enforce it, then you still have to be on the look-out for it. In any case, I wondered at your decision to run the entries in the same context as the controller in the first place because it seemed to be a security issue but (1) I don't know java and (2) I figured that was your lookout. Personally, I wouldn't include the cheaters either; but I'm not going to tell people that they can not criticize that decision. \$\endgroup\$
    – dmckee --- ex-moderator kitten
    Apr 10, 2014 at 22:51
  • \$\begingroup\$ @dmckee That's why KOTH aren't also code-golf. The author can require KOTH entries to be easy to read if he so chooses. If some code is so complex that it cannot be understood after cursory inspection, then an explanation should be provided. Hopefully any malicious intent would be easy to spot in such circumstances. \$\endgroup\$
    – mbomb007
    Apr 4, 2016 at 21:12
  • \$\begingroup\$ System.setSecurityManager(new SecurityManager()) \$\endgroup\$
    – The Fifth Marshal
    Apr 12, 2017 at 0:37

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .