Ideas for next year.

This is not to say this year wasn’t absolutely brilliant (because it was, thanks Woogley and Judges). What could be done differently next year? I have in my head:

  1. A process during judging (if it remains) to allow authors to fix their games should any judge have problems running it (Xero this year would have been a prime candidate).

  2. A discussion about different judging strategies (though this isn’t possible without 3)

  3. A clear list of what the the games are going to be judged on, if at all. This would help with (2). Are the games judges just on being games, or is what you managed to fit into 4k? Is it the technical excellence of the graphics and sound, or is it simple how much fun the game is to play. If we knew these things up front we could really “compete”. This might also help us all decide together what judging strategy makes sense - if its just gameplay theres no point having developers judging, if its technical only then who cares what gamers think? :slight_smile:

Again, not intended to as afront to what was a tremendous competition this year!


maybe #3 could come into categories, each with its own ranking.

Anyway it’d help to have some common evaluation criteria to know where do you have push harder when designing your game.

Definitly need some way to divide games up by category.

The 4k concept is successful as it is, so I suggest minimal changes. One area that ought to be bottomed out before next year, is that if we allow Java 1.5, are we going to allow the use of pack200. It’s a contraversal area, which ought to be resolved well before the contest, so opinions can settle down.

I mentioned on a post on the judging thread that I think there is room to improve the scoring system. Basically some judges used the full range of the available scoring, while others were more generous, but therefore had a closer grouping of scores. This tended to emphasis the weighting of judges who used the full scoring range. Perhaps there should be a scoring guide for next year, to try to even this out a bit. Or just vote for preferred order of games (like Eurovision song contest). Alternatively carry on as now, but normalise each judges scoring before adding them up.

Other thoughts
I’ve been toying with the idea of writing games that work in the same virtual world. This would require a common (provided) network layer and a standard way of transmitting object definitions (maybe .obj format). Object definitions could be defined in each client for its avatar & any bullets. They would be transmitted and cached on the other clients on connection. Maybe have a fixed set of textures to avoid running out of bandwidth, although this would be a shame. Maybe also have a generic particle generator, which can be passed parameters to get some individuality. At this point I guess we would need an example renderer, although I would expect participants to be allowed to modify it. It probably run peer-peer with introducer. However this would allow people to write clients with god-like powers (kill all opponents within 50’ radius). I’m not sure how to deal this this, apart from provide guidelines on fire rates. I could probably write the necessary library code (not in the next couple of months though - too busy). There would be a basic example client as a starting point. However would there be any interest? Also how would one judge peoples entries. Any ideas on how to even out avatar abilities without being overly prescriptive. Maybe this last issue is too hard. Perhaps this is too much of a pipe dream. I’m almost awake now :slight_smile:



I don’t know if not using the full range of points was really a problem. It was noted in another thread that the relative scoring for each judge would not have changed, even if they used the full range.

You could do something like make the players request everything they want to do from the game API. So if they want to fire, then the call fire(100, CLIENT_ID) This will fire with a power of 100. Since they used such a high power, they can’t fire again while waiting for a long recharge. Conversly, lower power fire gives shorter recharge. The CLIENT_ID could be passed to the client’s constructor when it is created. Then the client has to pass this ID into all requests for the game to do. So everything that is done in the game is done via a request to the game API.

But exactly what is the concept? Its not really defined anywhere so everyone can be aiming at different things and the judges can all be judging against different criteris. What weight is put on:

a) Original game play
b) Technical achievement for 4k
c) Fun factor
d) Content and longetivity


While the other criteria apply in general to any game coding contest… this one is particularly important for a 4k contest. I don’t mean to insult the participants in any way, but to put it bluntly: In many ways most of the 4k games suck - even the ones that are somewhat addictive suck in some ways. E.g. tetris is a highly addictive game and can be done fairly easily in 4k… but it won’t likely have award winning graphics and sound… it will still be tetris and so people will still play it for hours. It’s old now so it probably won’t rate high… but imagine if no one had every seen tetris before the 4k comp… if it was a totally new concept… would it win? I think it would have a shot.

It’s the fact that the games are restricted to 4k that allows us to overlook so many of the factors that make the games, while quite possibly fun, lame. Very few of the games managed to pull it off such that they would still be impressive even if they were more than 4k.

the biggest thing missing wenn judging was how to interpert a target group. I mean some games where too simple for me but I gues kids will be having a blast. So is it a bad game cause I wouldn’t play it again? does that matther if it was written for ppl like me anyways?

Those that do should win. And they did. =)

Have a look at my latest topic “A Proposal For A New Rating System”

what i wouldn’t mind next year is prizes(physical prizes that is) for the top 10 ;D

nah, a litle pdf diploma is enough ::slight_smile: