Proposing Rule Changes in the GitD?

64 posts

Flag Post

Man, the freshly concluded GitD #33 was really exciting, eh? The reaction of one of the participants to the contest brought to light certain issues on the GitD rules that we may want to consider changing or clarifying. I hope it isn’t out of my place to propose a few changes to the rules. Even if the final decision is to retain the rules as they are right now, I think the following issues are worth discussing at the very least.

1. Voters and Vote Solicitation

Are we allowed to ask friends and family to vote for our entries? I’ve never done it because my friends and family aren’t into these kinds of games, but evidently, other people have. Outside of the GitD, being able to solicit votes is considered a strong skill. Nobody wins public office by being the most qualified candidate. They win by being the most popular.

Nevertheless, the GitD is supposed to be a contest of skill, not popularity. We do want the best game to win, not the most popular one. On the other hand, it is natural for participants to try to promote their entries. I don’t think it would be fruitful to prevent them from doing so.

More to the point, we want to prevent contestants from using alts to vote for themselves. Whichever way you look at it, using alts is a form of cheating.

So how do we ensure that this is a contest of skill? Unfortunately, there are no easy answers that I can see. We could limit who gets to vote by saying that voters should have been members of Kong for at least a year prior to the start of the voting period and that they should be at least level 10, for instance. The purpose of this is to discourage the use of alts and to keep the GitD from being a contest of popularity, but even then, there are ways to go around this. I could create 15 alts and level up each of them at different Internet cafes so that they will have different IP addresses. A year from then, I can win the GitD competition by a landslide. It seems like a lot of effort just to win the GitD, but that’s the whole point. Hopefully, the effort alone will discourage contestants from making alts this way, and it will discourage participants from making the GitD a contest of popularity.

An alternative would be to appoint judges ahead of time. These judges should be known for their impartiality and their sense of what makes a good game. They should also not be allowed to enter a game in a GitD that they are judging. Unfortunately, if these judges happen to prefer platformers over puzzle games, there may be an unfair bias that not even the judges are aware of.

I’ve proposed two possible changes on this issue alone. There are other issues I’d like to discuss, but my post is already too long as it is. I’ll wait a day or so before posting my next proposal.

 
Flag Post

Just a thought but if you want to limit the number of people eligible to vote then you could allow only those directly participating in the GitD to vote as well as maybe other game developers? Although i guess not everyone has a game posted here on kong so maybe as long as you can link to a game you’ve made to UG or mossy or something. Just my 2 cents.

 
Flag Post

That’s not a bad proposal, Shake. That makes a third option that we may want to consider.

I’ve just thought of another option, one that’s easy to implement: Only votes that come with valid feedback on each entry will be counted. The disadvantage is that it may alienate a number of potential voters who don’t want to go through the trouble of writing mini reviews but who are otherwise legit. On the other hand, it discourages people who were press ganged into voting by their friends but don’t really care to play and seriously consider any of the other entries.

 
Flag Post

The problem seemed to have arisen when Dev’s friend was accused of being an alt. I feel the best solution for future GiTD’s is to simply restrict any and all voting to Kong-only. While it’s perfectly valid to promote your game or any other game for the sake of publicity, turning a competition based on making a great game quickly into a popularity contest doesn’t really promote the competitive programming nature that I felt when I joined in. I feel as though this competition is challenging programmers to work quickly to make an interactive and fun game, and that voting should only be based on how well the programmer did. Turning it into a popularity contest might promote improper entries in the future, like a guy using the bare minimum stencyl tools to make a not-a-real-game game (like a game that just prints “Hello world!” onto the screen), and then tells his 50000 facebook friends to vote for him.

TL;DR Only the innermost members of the Kong-cult should be allowed to vote. Ostracize outsiders.

 
Flag Post

I hadn’t accused them of being an alt, but I was fundamentally against the admission of the vote in the first place should it have been an actual winning vote. The rest of the situation just added to that decision.

 
Flag Post

I think voting should be restricted, simply because GiTD is meant to be a small, fun contest, where taking part is more important than whatever the prize happens to be. It’s pretty clear that if everyone then went campaigning for votes, some members would have a huge advantage over others – someone like Senekis, for example, could easily ask users of his badge app to come vote, and would probably end up with a couple of hundred votes as a result. Until a couple of GiTD’s ago, I don’t remember anyone recruiting people from outside of Kongregate to vote for them, but it’s a trend that’s been allowed to pick up steam recently. I think that that, at least, should be stopped – no new member voting. Otherwise I think the contest will end up ruined for everyone when someone decides to put more time into getting votes from their friends than on making their game – nobody will be able to tell if they’re alts, and even if they aren’t, it won’t feel like a fair result.

 
Flag Post

[…]to UG or mossy[…]

To clarify my position in relation to GiTD, Mossy will be handling all of the GiTD stuff from now on. I’ll be refraining from offering my opinion on matters. ;)

 
Flag Post

I sincerely agree. After this embarrassing debacle, I think it’s finally time to recognize the official rules of GiTD.

1st Rule: You do not talk about GiTD.

2nd Rule: You DO NOT talk about GiTD.

3rd Rule: If someone says “I’m out” or “I can’t finish the game in time”, their fight is over.

4th Rule: Only game developers in the fight.

5th Rule: One GiTD at a time.

6th Rule: No scripts, no sprites.

7th Rule: Games will be as long as they have to.

8th Rule: If you are fighting in GiTD, you HAVE TO vote.

 
Flag Post

I am very partial to the ‘jury of your peers’ idea, letting only other entrants vote in the contest. Of course, it’s not foolproof. It opens the door to strategic voting (not voting for my direct competitor even if I think their game is the best, so as to improve my own chances), and dummy entries (you are mistaken, my game ‘Black Screen’ not only fits the theme perfectly, but it’s a very clever commentary on the vacuity of modern games, and modern life in general). But overall it seems to me better than the alternatives.

When it comes to the question of starting work on the game before the theme is announced, I only see one possible remedy: Stronger enforcement of better themes. Namely, very specific themes that require careful thought and planning, and enforcement on the part of the voters that the game be built literally around the theme. That is, that you cannot take the theme from the game and still have a game. That if you ask someone who hasn’t seen the contest theme what the game is about, they will name the theme in one of their first three answers.

 
Flag Post
Originally posted by Elyzius:

I’ve just thought of another option, one that’s easy to implement: Only votes that come with valid feedback on each entry will be counted. The disadvantage is that it may alienate a number of potential voters who don’t want to go through the trouble of writing mini reviews but who are otherwise legit. On the other hand, it discourages people who were press ganged into voting by their friends but don’t really care to play and seriously consider any of the other entries.

I like that idea. It’s true that obligation of writing reviews may disencourage someone (including myself, since I’m not a native English speaker), but it will wipe out dummy votes.

Originally posted by Shake_N_Baker:

Just a thought but if you want to limit the number of people eligible to vote then you could allow only those directly participating in the GitD to vote as well as maybe other game developers? Although i guess not everyone has a game posted here on kong so maybe as long as you can link to a game you’ve made to UG or mossy or something. Just my 2 cents.

I disagree. Apart of the already mentioned strategic voting, games aren’t only for developers, are they? And that links with the other question: Is it allowed to invite family and friends to vote in the contest? If the writing reviews rule is considered, more voters means more feedback. And more popularity of the contest itself means more developers submitting their games. On the other hand, asking friends and family to vote will probably result in biased votes, and that is not desirable.

And when there’s a prize, you can’t pretend it’s a small, fun contest where the most important thing is to participate and that happy rainbows stuff.

 
Flag Post

I think we should have a couple judges; but not appoint them. Let users vote!

 
Flag Post

I’m not sure there needs to be much changed. This is possibly an overreaction to what is just someone whining that they lost (& in general).
Possibly a few rules that should be firmed up and made clear…..no solicitation, no votes withing having been willing to play all games (but .exe, or not having the plugin, or long download are valid reasons for not…just stop people only playing two games & voting due to knowing the users that made them), not allowed to vote if you joined after contest started, no accounts just for voting, no alts, no voting for non-gaming considerations (this developer once sent me cookies).

 
Flag Post
Originally posted by Ace_Blue:

When it comes to the question of starting work on the game before the theme is announced, I only see one possible remedy: Stronger enforcement of better themes. Namely, very specific themes that require careful thought and planning, and enforcement on the part of the voters that the game be built literally around the theme.

The problem with that is many people prefer the less-specific themes because it’s easier for them to come up with an idea that incorporates them – just look at GiTD #28 with ____ Or Die. Being too specific may lead to even fewer entries because people don’t want to make a game if they feel it will be too similar to other entries.

Perhaps it might be an idea to upload an image of a character, building, item or environment that the developer must incorporate into their game heavily instead of a written theme if we want to make the foundation for voting more solid. Entries won’t have to use that specific image – they can modify it to fit their art style ( i.e, a photo turned into vector or pixel art ) but the underlying themes from the image should be clear in the game. I.e. A picture of the USS Enterprise moving through space could dictate games have a space theme, or alternatively entrants may use the massive ship as the character/vehicle in their terrestrial war game. Or use a mix of images to further narrow down the overall judging criteria among the theme. A picture of Gemcraft TD? A picture of a monkey? A picture of a Balloon? … You could go as far as a reference/mood board and have players list a quick summary of how and what they’ve incorporated from each image when they submit their entry and let voters decide how well they’re implemented into the game.

As long as devs clearly use the reference within the game I think it might entice more people to join and get more creative ideas than sticking to a written theme such as ‘Bounce’ or ‘Exploration’.

 
Flag Post
Originally posted by Halysia:

The problem with that is many people prefer the less-specific themes because it’s easier for them to come up with an idea that incorporates them – just look at GiTD #28 with ____ Or Die. Being too specific may lead to even fewer entries because people don’t want to make a game if they feel it will be too similar to other entries.

I know, and I agree. And yet, ironically, those ‘easy’ themes yield a crop of highly similar games. We had a bunch of platformers for ‘only one level’, a bunch of dungeon crawls and top-down mazes for ‘exploration’, etc… On the other hand, even very general themes like ‘the ocean’ can yield a highly diverse set of entries (people complained a lot about that theme at the time, but it was a good one for diversity).

In general, I’d stay away from any theme that hints at a particular game genre. Even something seemingly neutral like, say, ‘Egypt’, can have a lot of game baggage. (if the first image that came to your mind was a platformer with an Indiana Jones lookalike wandering in a pyramid, I’m sure you’re not alone.) Picking a good theme is not easy.

 
Flag Post
Originally posted by Halysia:

Perhaps it might be an idea to upload an image of a character, building, item or environment that the developer must incorporate into their game heavily instead of a written theme if we want to make the foundation for voting more solid.

[…]

As long as devs clearly use the reference within the game I think it might entice more people to join and get more creative ideas than sticking to a written theme such as ‘Bounce’ or ‘Exploration’.

Amazing idea in my opinion and I think it could be seriously taken into consideration for future GitDs.

 
Flag Post

We’ll explore all the ideas we can.

How about we pool favorite ideas, and vote on those? It may sound counterproductive, but the ONLY people who would be allowed to vote in this instance are kong members in the first place.

 
Flag Post

Judges will obviously have to be appointed or made of volunteers. And the judges can’t participate in GiTD.
And there’s got to be some kind of criteria to judge by, because judging by popularity alone makes the competition meaningless.

 
Flag Post

I like the idea of votes requiring a mini-review of each game. GiTD isn’t just about prizes and winning, it’s about getting feedback and improving one’s own development skills, and votes with reviews really help that.

 
Flag Post

I propose the following:

No valuable prizes. Have someone make up a victory icon and music snippet or something, like a virtual plastic trophy. Since this isn’t a well-known contest, that alone would probably do more to eliminate any probable cheating (that you can eliminate) than anything else. Since this contest isn’t about prizes, no one should have too strong of an objection, right?

Break winners into categories (you should have virtual trophies for each, then, though): Best theme use, most original theme use, most fun to play, that sort of thing… More work for the voters, obviously, but I think it would serve better.

Since a) you can’t vote for yourself and b) this is a small contest using the honour system, I don’t see a problem with judges being entrants. This is just for fun and self-improvement, after all.

…Isn’t it?

 
Flag Post
Originally posted by dragon_of_celts:

I propose the following:

No valuable prizes. Have someone make up a victory icon and music snippet or something, like a virtual plastic trophy.

Perhaps a:
[GiTD #00]
1st Place

forum avatar would suffice?

Also I like the small donation rewards – it’s an extra incentive enough to motivate me to attempt an entry, but at the same time it’s not nearly large enough reward for me to really care; perhaps it’s the same for many others.

 
Flag Post

Well, in this case we had a small donation reward. Having Kreds as a prize doesn’t motivate me at all; for others it may be very desirable. Any reward’s value (even the virtual trophies or actual, world-usable currency) is going to vary by individual.

Anyway, it is only half of the picture to say that it would help keep people that would cheat from bothering. The other half is that it would help the rest of the people from being paranoid about cheating and from giving so much gravity to the offense that it disrupts everything when they believe it has occurred.

I don’t know if the entrant in question was doing anything unseemly or not (neither, I suspect, do most others here*), but let us say, for the sake of argument, that she was. It can’t be proven, merely guessed at (even if they are “educated guesses”). The honour system will always have such possibilities. Turning away from the honour system involves such numerous and convoluted measures that it hardly seems worth it to me (as much as I dislike unscrupulous people).

* Let me point out that her reaction is not necessarily an indicator of guilt. No one always reacts in the best way to everything, even if they usually do.

 
Flag Post

I had two main problems over this competition. The first was that I think that Deviever started her game prior to the competition, the second is that I had a gamebreaking function that I could not update.

I don’t really know how we can ever be sure that someone has started their game on the first day of the competition. However if other contestants did the kind of thing that I did over the competition and post an update about the progress on their respectives games every day or two by uploading a link to a site like fastSWF, then everyone could see the game being built from the ground up. Personally I did it over the competition to get feedback throughout my games development because I knew there would be no time to test for bugs, and did get some feedback like someone asking to make holding the mouse button down fire, instead of having to click. From what I have seen I think that if the competition is really about making the BEST GAME YOU CAN, in TEN DAYS then this will ensure that everyone not only is making their game in 10 days but is also making a game that will be fun to play.

As for updating after the competition is over, I think that people should be allowed to fix problems that would fundamentally break their game. So long as the contestants are not adding anything new to the game it should not be a problem. There’s no way to really enforce this, but there is such a small group of competitors that already use the honor system in not making extra accounts or cheating in other ways, I think this could be acceptable.

 
Flag Post
Originally posted by MossyStump:

How about we pool favorite ideas, and vote on those? It may sound counterproductive, but the ONLY people who would be allowed to vote in this instance are kong members in the first place.

Agreed. I suggest that we discuss all the issues and proposed changes regarding the GitD rules first because changes to one set of rules may affect other proposed rules. Perhaps we can have a separate thread later to vote on these proposals.

It’s been about a day since I first created this thread, and so far, there is a clear consensus that we have to limit who can vote. Even Amibtious said that no accounts should be created just for voting, which is effectively a proposed rule. Since there have been no clear rules on who can vote thus far other than the prohibition on alts, no one can prevent new accounts from voting, even though the community looks at them with suspicion as possible alts or friends of contest participants.

To sum up, here are the proposals so far. Please let me know if I missed any.


Issue # 1: Voters

1. Voters should have been members of Kongregate for at least three months prior to the start of the voting period, and they should be at least level 3.
Pros: Discourages the use of alts and prevents the creation of new accounts for voting.

Cons: The exact parameters may either be too strict or not strict enough, so other suggestions for determining valid GitD voters are welcome. Also, this rule only discourages the creation of alts but does not prevent it entirely. Finally, if this rule is strictly adhered to, some contest participants may be ineligible to vote unless a clause is added to give voting privileges to participants.

2. Restrict voting to Kong members only. No new members are allowed to vote. This is a broader version of the above proposal.
Pros: May discourage the use of alts and the creation of new accounts for voting.

Cons: The question is, how do you define a Kong member? How old must an account be before the person owning it may vote? Besides, it’s still possible for old accounts to be alts of a main account. Established accounts named “qwerber,” “qwerberber,” and “qwerberberber” are obvious, but other accounts may not be. This suggestion needs fine-tuning.

3. Appoint or elect judges ahead of time. Judges should be known for their impartiality and their sense of what makes a good game. They should also not be allowed to enter a game in a GitD that they are judging. They may be elected into position or chosen by the GitD organizer, possibly from a list of volunteers.
Pros: Absolutely prevents alts and new accounts from voting.

Cons: The chosen judges may not accurately reflect the general consensus on which entry is the best game. Their choice is effectively the choice of a few. The exact method of how judges are chosen is not clear. Will they be appointed through a vote or chosen by the contest organizer? If they are elected into position for the current GitD, who gets to vote for them? Can new accounts be created to vote for judges?

4. Only votes that come with valid feedback on each entry will be counted. If this rule is upheld strictly, voters who fail to give valid feedback on a single entry will not have their votes counted.
Pros: Discourages the use of alts. Encourages giving feedback on the entries, which helps improve participants’ development skills.

Cons: May disenfranchise established Kong members who would have wanted to vote but do not want to write mini reviews. Does not discourage the participation of new accounts, but as long as valid feedback is given on every entry, that may not be a bad thing… unless the new account is actually an alt. Hmm.

5. Only known game developers and those participating in the GitD may vote.
Pros: Those with some game development experience may have a better sense of what makes a good game. May prevent the use of alts and participation of new accounts if this rule can be fine-tuned adequately to define who the known game developers are.

Cons: It’s not entirely clear what constitutes known game developers. If a new account is created, and the person owning it claims to have been one of the people who developed Mass Effect, does he count as a known game developer? This rule may need fine tuning. Also, it is possible for a person to own two accounts, both of which have the “D” badge on it, so this rule won’t prevent the use of alts, although it may discourage it. (See also the cons below.)

6. Only those participating in the current GitD may vote. This is a stricter variation of the above proposed rule.
Pros: Discourages the use of alts and the participation of new accounts that are created just for voting. All the voters would have had some game development experience and may have a better sense of what makes a good game.

Cons: May encourage strategic voting, wherein participants try to improve their chances of winning by not voting for their direct competitors, even if theirs are the better games. Also, alts may still be created, entering the GitD with a dummy entry just so they can vote for their main account’s entry.

7. Past and present participants to the GitD may vote without being questioned, but all others may have their votes rejected by the GitD organizer and/or past and present GitD participants if those votes are deemed unfit.
Pros: There is considerable flexibility in determining whether a vote is acceptable or not. Hence, the need for Byzantine rules on what votes to allow or reject is eliminated.

Cons: Without a clear set of rules or guidelines on who may vote, the decision on whose votes to reject may be subject to the whims of the GitD organizer and participants. Some GitD participants may feel cheated of victory if the rejected votes could have swung the results in their favor. Also, conflict may arise if the GitD organizer and participants are split on whether to reject a particular vote.


That’s what we have so far on voters. We’ll be introducing new issues as we go along, but the floor will always be open for proposals on any issue until we start the referendum.

Originally posted by dragon_of_celts:

I propose the following:

No valuable prizes.

That brings the number of issues to discuss to five. I had originally thought of discussing only four issues. If others want to discuss other issues, the floor is also open for those.

Edited to relax the requirements in the first option.
Edited again to add a 7th option.
Edited to amend the 3rd option to indicate that judges may be chosen from a list of volunteers.

 
Flag Post

Just keep the ideas coming, I’m up to try any ideas that you guys think will help GiTD!

 
Flag Post

I’d like to discuss the next two issues together because one issue affects the other. I originally intended to discuss them last, but seeing that Ace_Blue seems to have anticipated my proposals already, I may as well discuss them now.

Issue # 2: Ten days to make a game.

As this is a ten-day game jam, it has long been an established rule that “you have 10 days to create a game based on the chosen theme.” At the same time, the rules state that “using an engine (made by someone else) is acceptable as long as the person submitting (the entry) creates the majority of the game.” Clearly, if you create your own engine, then you should be allowed to use it as well. It has also been established that it’s okay to use your own library code as long as you’re not building off a game that you already created prior to the contest.

Nevertheless, as participants’ library of code grows, the games that they can create become more and more sophisticated to the point that a voter may insinuate that participants put more than ten days worth of effort into their entries. When one has a large code library, it is clear that this person put in more than ten days worth of coding into the game, but the rules don’t prevent their use. Neither should the rules prevent the use of library code because almost no one enters a game jam with no library code in hand (except for poor fools like me at my first GitD). Still, when one produces a sophisticated entry, it becomes difficult to dispel the suspicion that development of the entry was started long before the GitD theme is announced.

I anticipate that with component-based programming, game jam entries can only become even more sophisticated. With a large library of components, creating a new game becomes a snap, kind of like how putting Lego pieces together is a snap. How can a participant armed with a large library of components dispel the insinuation that he started game development before the contest? He can’t.

So here’s my radical proposal: As long as a contestant submits an entry made by them that fits the contest theme and has not been published prior to the contest, allow that entry to be voted on regardless of how long that entry may have been in the works. Contestants should not be punished for their skill in using a large code library. If someone submits a highly polished game before the deadline, he should be lauded, not looked at with suspicion.

But this is supposed to be a ten-day game jam. How do we know that an entry really was put together in ten days with or without a code library? This brings me to the next issue at hand:


Issue # 3: Theme selection.

As long as broad contest themes are selected, it will be easy to adapt a game that may have been in the works for some time as a contest entry. We do want contest themes to be broad enough that a wide variety of games can be created around them, but we don’t want them to be so broad that old games can be given new skins and entered into the contest. Ace_Blue put it very well when he said:

Originally posted by Ace_Blue:

When it comes to the question of starting work on the game before the theme is announced, I only see one possible remedy: Stronger enforcement of better themes. Namely, very specific themes that require careful thought and planning, and enforcement on the part of the voters that the game be built literally around the theme. That is, that you cannot take the theme from the game and still have a game.

(Emphasis mine.)

Look at some of the themes chosen in past Ludum Dare challenges and see how they are narrow enough that adapting an old game around the theme may be difficult. At the same time, these themes are broad enough to invite a wide variety of possible games:

  • Indirect Interaction
  • Build the level you play
  • Advancing Walls of Doom
  • Enemies as Weapons

There are disadvantages to this as Halysia mentioned. Some themes may draw blanks in would-be participants’ heads when they try to think of a game they can make out of it. Nevertheless, isn’t the contest as much a test of creativity as it is a test of technical prowess? A game isn’t just a bunch of code. It’s a work of art.

Halysia’s idea of uploading a specific image that needs to be used heavily in the contest sounds like it might work, although there’s always the danger that the image will only be used for re-skinning an old game.


Anyhow, let’s hear what everyone has to say about these issues.