Lessons Learned, part II: Rules

Continuing my over-analysis of TWIFcomp, which is now several times longer than all of the code in the competition combined, I thought I’d take a look back on the rules and see how they panned out. I thought that a comp about short works should have a short list of rules, that they should be posted quickly, and that they should not drift during the competition. I did get the rules up in 24 hours, and for the most part they didn’t change over the course of the competition, except by additions where clarifications were necessary. Obviously, I didn’t plug every loop hole.

Rule 1: Dates

For such a small comp, I didn’t require any declaraction of entry. It wouldn’t have really helped me anyhow. If no one entered, I was up a roll of duct tape and a package of noodles. Conversely, if it was wildly popular, I have a closet full of duct tape and noodles, so no big loss (actually, they are kept in separate closets, but still). Times: GMT confused some people, but in the same way that you don’t deserve to rule the world if you can’t stick the megabucks stickers on the poker chips, a little technical darwinism never hurt anyone. The announcement of results excluseively by tweet was a gimmick specific to the TWIFcomp, but for future comps, it couldn’t hurt to push out the results by various feeds. Actually, this is probably something that would happen anyhow, with or without the involvement of the organizer.

Rule 2: Games

Any programming language, any human language, white space doesn’t count, has to be interactive.  I had anticipated that the definition of interactivity would have been debated, but it was the white space rule that got the most discussion. I really appreciate that some of the participants were purists and held to an absolute 140 byte limit. However, with different encoding schemes, operating systems, etc., length is a slippery concept. Also, you can’t tweet a tab or carriage return. I believe that the most tweetable entry, as submitted, would be Doug Orlean’s Manifest Destiny, written in PLT Scheme. Even with spaces, it fit the length limit, and it had no white space other than single spaces. So, bravo, Doug.

Now, regarding the white space. Here, I realized that I was giving authors a loophole, but it was a non-trivial one. I figured that if someone really could make clever use of white space, that in itself would be a worthy goal. I’m only one vote, though, so if other people didn’t agree, that would have been reflected in the voting. It is obvious from the results of the competition, that people appreciated Adam Thornton’s ingenuity in turning a game of less than 140 characters into a half-gigabyte monstrosity (and I say that affectionately). In the first comment on TWIFcomp, someone had joked about writing a game in white space, and I countered with a dare to write a z-machine. Adam went one step further, squishing the entire inform development system into the invisible world between printable characters.

Conclusion: Some rules are made to be cleverly interpreted.

Rule 3: Submission

Nothing special here. Everyone sent their game in, and I didn’t get a lot of requests to update games during the comp (which is good, since the submission by email system was a little unwieldy). I guess not many people felt much urge to update a 140 character game (although I notice that Alexandre Muniz came out with a revised “Make All Sad” that manages to shave off enough characters to allow addition of new features.

Rule 4: Behavior during the comp.

The rules explicitly allowed discussion of anything during the competition, and I didn’t even care if people posted the games on their own sites as long as they pointed people towards the version on the TWIFcomp site as the canonical version for judging. I did not have time to set up an Author’s Club, as had been done for the last two years for IFcomp — it seemed like overkill for such a short competition. Even so, some author-to-author discussion took place in blog space.

I was happy to find that during the entire comp, I didn’t see any flame wars, insulting posts, etc., on any forum. It was downright civil.

Rule 5: Voting.

I had hoped for a stronger showing in terms of votes, mostly because I was afraid that some games would not get enough votes to make the average reliable, and that one outlier could strongly skew the results. The game with the least number of votes received five, and the game with the most received 15. The votes were relatively consistent, particularly for the top-placing games.  Everyone recused themselves appropriately, and I did not detect any kind of cheating or favoritism in the voting. So, quantitatively poor, but qualitatively good.  I had considered setting a threshold number of votes below which a game would not be evaluated, but given the low numbers and consistency of voting, I went with a simple average.

Rule 6: Prizes.

From duct tape to pokemon. I was very pleased to see enthusiasm for a comp that did not offer cash prizes. I’m sure part of this is that the games were so short, and so little time was invested in writing. On the other hand, in the bigger comps, the amount of the cash prize cannot possibly compensate people for the time they sink into those projects. It is clear from TWIFcomp that peer recognition can be a substantial motivator for online competitions.

Rule 7: Intellectual property.

This was mainly a “I don’t want to get sued rule.” The more the comp went along and people asked if me if their code could be considered as infringing on someone else’s IP, the more I realized that it would be very hard to do so in 140 characters. Even if someone lifted text verbatim out of some other work, it would be a very short quote and probably fair use. Most instances also would have been considered a parody of the original work.  Since there was no way of making any kind of profit in TWIFcomp, I would assume that the waters are not sufficiently chummed to attract lawyers.

The mega-supplemental rule about libraries. This arose as a FAQ, and was tweaked a couple times. This rules was a distant second to the whitespace rule in terms of abuse. The prime offender (and most entertaining example) was Adventiture which took the entire original adventure game as a library. The library had been published before the comp, was online, and freely available, so I have to say that this was entirely within the rules. I am a little surprised that this was not abused by more authors, actually.  If I were to run something like TWIFcomp again, I would probably not allow external libraries in the same way, but restrict the entry to “core” tools for each language (either defining them explicitly or requiring that entrants run their proposed tools by me for approval).

OK, I will now stop obsessing about TWIFcomp. No, really.

3 thoughts on “Lessons Learned, part II: Rules”

  1. Hi Jack, I appreciate the post-comp analysis, and thanks for the shout-out. I will note that several other games were 140 chars including whitespace, including Johnicholas Hines’s two games in sed and awk, Jesse McGrew’s game Paradox in ZIL, and Matt Weiner’s three (actually eight!) Sin games in I7, although you’re right that not all of these are tweetable due to newlines being significant (though not in ZIL, and I think not in awk). Personally I did give slightly higher marks for 140-chars-including-whitespace games, and rather lower marks for games that obeyed the letter but not the spirit of the rules, but I guess I was in the minority there. (I quite enjoyed the audio in “SHOOT YOUR EVIL TWIN…”, but I still rated it rather low– allowing external multimedia made no sense to me.)

    About voting, I know at least one author did not vote because he misunderstood the rule about not voting for your own game to mean that authors couldn’t vote at all. So that may have contributed slightly to the lowish turnout. But mainly I think it was just the hassle of filling out a spreadsheet, as opposed to just clicking stars like in the JIGcomp (although, I guess the star ratings there were separate from the official voting). Still, I think the number of voters was enough to make the results seem like a consensus, and I’m happy with that.

  2. Thanks for noting the other truly tweetable entries. Because the I7 games rely on python-like whitespace (e.g., tabs, newlines) for definition of logical blocks, I think they would not survive tweeting as well as the others you mentioned. Still, I agree with the sentiment that shorter length should count for something in a competition like this. I am sure that at least some of the voters took this into consideration in awarding their composite scores.

    I’m not really planning on running another TWIFcomp — it was meant as a one shot idea, although I can’t rule out some other strange comp at some point in the future. If I were to do it again, I’d absolutely use some kind of user registration system and find some nice voting module to add to the website. I think I’d prefer that the votes not show up until the end of the comp, though.

Leave a Reply

Your email address will not be published. Required fields are marked *