Personally, I like the size limit. Sure, people will whine and complain about it no matter how high it's set, but setting it low encourages participants to make their game lean and efficient, and not get carried away with too many bells and whistles.

As far as bandwidth goes, maybe iDevGames could host entries that are under a particular size, and require that entrants host them themselves if they're over the limit? Ideally with a provision that it must be a direct download link so that we don't get a whole bunch of submissions on ad-infested file hosting sites.

Github and/or Google code seems to be the best answer using free hosting. I don't like the idea of having to require entrants put their work in a 3rd party service like that (it requires they make an account etc), but it's not exactly evil either. I've made a plea to Amazon to help us out. We'll see. ~$1000 isn't much to them, but it is to us.

iDG hosting the ones which are small enough is fine. At first, everyone will need to host their own anyway. Up until the end of the coding period probably. Then that's the point I wanted to grab all officially submitted versions and host them so they couldn't be changed post-submission. With github/Google Code I imagine it's possible to link directly a specific revision?

Quote:I don't understand "For the six “peer” categories, each entrant will score every entry besides their own. However, the ﬁnal score for an entry is calculated by the average of each team’s score. A team’s score is
the average of the team members’ submitted scores" at all...

Each entrant votes once for every entry except their own. The scores from each member of a team for an entry are averaged together to create the team's score of that entry. The final resulting score for that entry is determined by the average of the team scores from all teams except the team which submitted entry.

I'd be fine with just one vote per team and the team has to figure out how it's going to vote. It's easier to understand and far simpler to implement. In fact, I'm going to make it so.

I dunno, I think a 40MB restriction is pretty reasonable. People are going to whine and complain, but we've shipped a number of large Unity games we made under a contracts that would sum up to less than 40MB if we added in the Unity runtime. They contain a ton of assets and don't look bad by any means.

Partly that is because it was intended as a web game so the size was an important factor in the initial design.

Dreamhost's bandwidth is "unlimited" whatever that means these days. http://www.dreamhost.com/hosting.html Even if you have to sign up for a year of service to get it, it's going to be a lot less than Amazon maybe.

Amazon's trial only allows 15 GB which isn't nearly enough. Dreamhost's "unlimited" is qualified by not being used for file hosting. So I don't know that it's really an option. I suppose we could ask them to sponsor us as well. I'm waiting on word from two others right now. There's at least another month to figure out the details of hosting files.

I agree with OSC that something like github makes a ton more sense than anything else. THey don't _have_ to use it for their development repository, but they have to have the complete game uploaded to github on the contest end date.
Solves bandwidth issues, solves source code issues, allows for more interactive use of the code after the contest... I don't see much of a downside, particularly now that XCode 4 treats git like an old friend.
I'm hoping to enter, and will use github as the repository for it through development.

This is good news, and I have forwarded it to a mailing list where I think I can find some people who may be interested. Concerning the teams/individuals rules, I considered being programmer in one team and OpenGL advisor for another (granted that these teams are formed). Unless you change that rule. (I can probably be OpenGL advisor for other teams anyway.)

Concerning bandwidth, can't that be helped by complementing the central archive with links to the developers sites, so they can be downloaded off both, encouraging taking it from the developers site?

(Jun 1, 2011 01:35 PM)Ingemar Wrote: Concerning the teams/individuals rules, I considered being programmer in one team and OpenGL advisor for another (granted that these teams are formed). Unless you change that rule. (I can probably be OpenGL advisor for other teams anyway.)

Yeah, no problems there.

Quote:Concerning bandwidth, can't that be helped by complementing the central archive with links to the developers sites, so they can be downloaded off both, encouraging taking it from the developers site?

That happened in the past, and some devs' accounts' bandwidth limit was reached. Just trying to avoid that.

AndyKorth Wrote:Download numbers from uDG 2009:

Pretty low, as JustinFic mentions: "This is a very small fraction compared to the dl's from 2004, though. I don't remember the exact numbers but it was around the 4000 dl range for the contest, and was up to 8-9k after a month or so."

I knew 2004 was that high, but I didn't remember 2008 was that low. Blocked out bad memories I guess. 2008 was really rushed, and I don't think got enough publicity. uDG 2011 should surely bump back up some. I don't know that it'll reach uDG 2004 because that was a different time different circumstances, but if we believe that this year does even 4x as well as 2008, then that appears to be within reason as far as cost. If it gets to 2004 levels, then that's getting pricey again.

As for calculating the results, I forgot about the whole median vs average vs truncated mean vs interquantum vapor capacitance methods.

Rereading most of that thread, it seems like the using a truncated mean was pretty well agreeable by the end. I'm ok with that, but the amount to truncate is debatable. I would lean towards using a low amount; maybe 10% off of the top and bottom, take the average of the rest. A simple poll should do for this.

I suppose another issue is what to do if a particular entry has so few votes that it dramatically changes the result to remove any votes at all? It can happen for the games at the lower end of the scoring range.