That time again...

RB[0] on 2009/08/17 13:19
— edited on 2009/08/17 13:20

Well, I'm not sure if I'll have a whole lot of time to work on a pyweek entry - but I'm gonna try.
May end up solo this year though, we'll see.
One thing I'd like to announce, for anyone planning on using PYGGEL (if anyone ;) ) there is a new release planned that *should* be released very soon - probably tomorrow or Wednesday.
There are a lot of new features, adn a lot of bug fixes, but I don't think backwards computability is broken on anything except where you would really be messing with the real guts of the library, which are not needed so much now...

To get a feel for the new version feel free to grab the SVN, otherwise, I'll post an announcement here when it's done :)
http://code.google.com/p/pyggel/source/checkout

Cheers all, and woot for another pyweek XD

(log in to comment)

Comments

Martin on 2009/08/17 14:10:

Isn't it a little past the library deadline for releases with lots of new features? Obviously bugfixes are great, but I think it's slightly short notice for new features.

RB[0] on 2009/08/17 22:10:

As long as it doesn't break backwards compatibility (it doesn't, unless you are really screwing with something oddly) then I was under the impression it was fine.
Especially considering that for some libraries people have opted to just grab the latest SVN version instead of the last official release (like pyglet a few comps back) - so if everyone just wants to get it from SVN they can, I figured a release would make it easier for others ;)

Martin on 2009/08/17 22:33:

Well, I guess the question is whether you intend to make use of the new features. In Pyglet's case, I'm pretty sure that people were simply using the new release for its bugfixes, and ignoring any new features.

Anyway, it's Richard's call.

adam on 2009/08/17 22:35:

The Pyweek rules are a little muddy on this, but the requirement is that "others may have reasonable opportunity of using the library", and I figure the implication is that the public get a month to familiarise themselves with any new features so that it's clear you're not just putting them in for your own benefit. I'm sure that there's no ulterior motive on your part, of course, and it's unlikely to be relevant since it's almost impossible to be disqualified from Pyweek anyway, but it might be nice to see the rules on libraries used in and released for Pyweek clarified a little - there seem to be an awful lot of libraries around these days.

RB[0] on 2009/08/18 02:25:

That is very true.
In PYGGEL's case, there is exactly one new feature developed within the last two months, everything else has been bug-fixes.
The new feature itself could be written by someone who knows what they're doing in about 2-4 hours anyways.
The fact is, there is no ulterior motive, but on the other hand, I know of no-one (including myself) who has used PYGGEL during pyweek, so this would probably only benefit me (in all likely-hood...)

If people are worried I'll just not make the new release, and people can look at the svn if they want those features...

As far as the rules being muddy - it seems to always be that way.
Judging from past experience I think the main rule is that you have to have at least one release a month before, and anything after that can't break backwards compatibility.
I think more restrictions than that are odd though - such as, if someone is making a library like this, does everyone expect them to stop working on it for the month preceding the competition? Otherwise the SVN is always there and people can use it if they want.

richard on 2009/08/18 04:06:

The month also gives people the opportunity to shop around to find something they like and then get comfortable with it. That's not really reasonable if releases are made during that month.

richard on 2009/08/18 04:08:

Sorry, that was a bit vague. Try "That's not really resonable if releases (that add cool new features that people might not then know about or have time to learn) are made during that month."

RB[0] on 2009/08/18 15:57:

So... new releases that add new features are no longer allowed within a month of the competition?
Personally I think that is odd as well, if they find a previous version of the library - they can still use that, or if there are new features they may decide to make use of them - either way the svn is still open so anyone could implement the changes from scratch if they were so inclined anyways...

adam on 2009/08/18 16:13:

I think this comes from the "level playing field" principle - it's to prevent a situation where I spend the month before Pyweek writing loads of amazing functionality, release it as a "new feature" of my existing library the day before Pyweek starts, and then incorporate it into my Pyweek entry. No-one else has a prayer of figuring any of it out in such a short time, and I effectively get five weeks to write my entry rather than one. I don't believe for a moment that anyone is actually trying to do this, but I figure that's the logic behind not allowing library functionality that's been around for less than a month in Pyweek. And that's always been the rule as I understand it, it's just that it's only become relevant recently with the sudden increase in the number of Pyweek participants who release parts of their code as libraries.

RB[0] on 2009/08/18 16:51:

Perhaps the rules should be re-written then, because looking at the "From scratch" part of the rules, it states that if you release a new version close to the time of the competition, you should make your best effort not to sabotage existing users, which, first, means that it really isn't a rule, but a guideline, how do you define best effort - and if your best effort isn't good enough then whatever...?
Second, this applies to not breaking backwards compatibility I think not new features...

I agree with your assessment, adam, but I think it is a little wrong. IE, if the library is legal it is hardly like they are taking 5 weeks instead of one to write their game, libraries cannot contain any game-logic or such. If anything you are spending 4 weeks building the tools (or rather, adding to them, at worst) to make your game.
Also, I don't know why it is relevant now and wasn't before, but it has been discussed/debated in almost every (I believe) competition I have been in.

richard on 2009/08/18 21:59:

RB[0]: I've actually never allowed new releases that add features before - I'm not sure where you get the idea that I have. In previous challenges people (including myself) have voluntarily disqualified themselves from judging because they were actively working on new library features in the month before the challenge (and then during).

RB[0] on 2009/08/19 01:51:

Umm, allowed or not it's been done...
As far as I know you've never specifically said it was against the rules ;)

I do know that for some libraries there was a new svn version that was not released but developers were using it in their entries anyways.
Now whether they were using any "new features" or just the bugfixes is anyone's guess.
Some examples being Pyglet and Pygame (I believe last competition there was a new release like 2 weeks before or something)

I'm not saying you've allowed it, but you haven't (clearly at least) laid out a rule on it either ;)
So, basically: if you make a lib, only releases for bugfixes are allowed within a month of the competition, anything else DQ's the library for usage. Is that correct?
It would be nice for clarity if that is made so, but I think it's a silly move itself. One of the goals of pyweek is "hopefully increase the public body of python game tools, code and expertise" - if that's the case, then it seems counter-productive to have everyone freeze development on anything that anyone might use in a game for two months out of the year (which also happen to be some of the biggest dev times around, judging from how many of these things pop up each competition ;) )...

But that's fine, I'm still working on the features as there was a bug, so I won't make a new release, whatever.
I dunno if I will enter or not, but if I do I will probably use the SVN version, so if anyone doesn't like it feel free to DQ me ;)

illume on 2009/08/19 10:02:

It seems people are working on game making tools leading up to pyweek, and they are allowed. Which kind of goes against the from scratch nature of the competition. Game makers(level editors etc) seem more unfair than library updates. However, some people are using $3k graphics or sound tools... so creating tools in that sense evens up the playing field.

Seems silly to disallow library feature work during pyweek on one hand, because so much can be gained from those library improvements during pyweek. On the other hand, it takes away the from-scratch nature of the competition (I would say that nature has long since gone).

I guess a cheater would add lots of new features one month before... and just work on bug fixes.

eg... class Movie(object):pass

Then the bug fixes would be to actually implement the class properly ;) Ok, there's lots of ways to technically cheat... but the people are only cheating themselves and the rest of the community.

I'm not sure if distinguishing between bug fixes and new features is fair or useful. Maybe just having a hard, and simple rule is better.

Some libraries seem to get a big burst of activity *only* near pyweek. So it's a hard one to balance. However, having games rely on half-baked features in libraries will probably make the games not work when the libraries are released... and freeze their APIs. So in that regard having libraries try and stabalise one month before is good...

However, people are still using 5 year old versions of some libraries(eg pygame 1.7.1 etc) So the people relying on newer versions of libraries have downsides too. Unless they are the only ones using their library... then there are only testing downsides - making sure their code works on different computers/versions of python.

Perhaps the limit should be changed to one week? Or make it a rule that at least one other entry must use the library if it's newer than one month old?

I think it'd be awesome if someone released some cool tech the day of the competition I could use. In fact every competition I try to use some new technology or techniques.

Personally, the last few competitions... I've just used what ever I wanted... to my own rules... and not even entered my entries. So I guess it only matters to those people who are interested in the competition part of it.

richard on 2009/08/20 01:37:

Yeah, I know all about the rush to develop just before PyWeek starts. Hell, I'm working on some extensions to Cocos2d at the moment! Maybe one month for existence of a library and then one week for any major changes (like new features)?

RB[0] on 2009/08/22 15:49:

Well, I think that is a good idea, personally, but whatever you do some will agree with it and others disagree - so just do what you think is correct - I just wanted the rule to be clearly defined, instead of a gray area :S

However it turns out, I just released the new version of PYGGEL, you can get it here:
http://code.google.com/p/pyggel/downloads/list
Pygame announcement: http://pygame.org/project/968/?release_id=2197

t on 2009/08/22 16:40:

A bit less than a month ago I decided I wanted to try my hands at PyGame. Now, at this point, I had a couple of libraries I'd been working on for a long time. A good example is a really awesome particle engine for pygame written in highly optimized C code. On my very old Core2 machine it updates and renders about 160.000 particles at 60 fps. I'd love to use it for PyWeek, and would gladly have released it with a permissive license if not for the fact that it was already too late for me or anyone else to use it for pygame.

And I would probably have written some other nice utilities or whatnot in the weeks leading up to pygame. With the really awesome rule that all libraries used must be released open source, that's even more potential goodness to benefit the python game community in general.

Thing is, I don't have the foresight or interest to work on libraries and tools for pygame, like, months before the actual contest. I try to have more important stuff to do. But now that I actually WOULD like to put some time into python game tols, I can't. In my opinion, the one month rule is more of a hindrance than a benefit. If people are motivated just before the competition to create tools, why not just LET THEM? As long as all such tools are released under an open license afterwards, the community gains. And as for the "from scratch" feeling? Well, that is a rule that can only be enforced by people's sense of honor anyway. If some nitwit writes 90% of their game code as "tools" under these new rules, then that's their problem. People without integrity doesn't have much talent anyway, so let them enjoy the mediocre placing gained by "not technically cheating".

How about we lessen the technical rules for what is considered cheating, and realize it will always be up to the integrity of the individual anyway? At least you guys missed out on a really awesome particle engine because of it. Maybe I'll take the time to document and release it in due time for the next pygame, but who knows what I'm up to then.

PyWeek is awesome for motivating the release of new tools, but I think they would be awesome-er if we just scrap the whole lackluster one-month clause. Replace it with an honor pledge. (Psychologists have shown over and over again that in circumstances when people CAN cheat without being caught, they will almost never do so if they sign some kind of pledge to not do so)

nitrofurano on 2009/08/22 19:21:

Just my humble oppinion:

Well, i think the purpose of this competition is to show what coders are able to do only with Python, and some few more libraries like Pygame or Pyglet, not everything else.

At least, from me, my main concern on coding my own games to this competition is being assure everyone - or almost everyone - can run it, on any operating system available (i'm trying my stuff only on Linux and OSX), without having to install much more external libraries for that. 'Less is More' and 'Keep it small and simple' are two rules i'm trying to follow...

But of course, if people don't care about that, and also think Pyweek is an interesting showing place to share oppinions, be welcome, but i think doing causes their predicted side effects, like having it hardly under-rated... (there are lots of Pyweek games, which seems awesome, but i couldn't play they yet... - i think this situation is very 'noisy' in this competition....)

Maybe a better place for games more python-independent is an Indie game development competition, not a Python competition...

Please comment! :)

Cosmologicon on 2009/08/22 21:12:

richard, whatever you decide, could you or somebody please update the rules to reflect it? I can just see, next competition, some people thinking it's okay to put out a new version one week before, because of your post here, and some people thinking it's not okay, because of what the rules say. It's unnecessarily confusing. I like to follow the rules as written, but I don't feel like I can count on them. They still say there are gold, silver and bronze medals for each of the three categories!

richard on 2009/08/22 23:22:

Yeah, I'll have to think about it...

richard on 2009/08/22 23:37:

This is what I'm thinking:
  1. no new library later than one month before the challenge, and
  2. no new feature release for an existing library later than one week before the challenge.
A goal of PyWeek is to foster game library development. I believe this is the fairest way to achieve that.

t on 2009/08/22 23:48:

Well, as I think I explained earlier, those rules may also HINDER library development.

I mean, any bozo can put their entire personal codebase on the net a month before PyWeek, write some weak documentation for it and proceed to use their entire arsenal of tools in the competition.

Just let people use whatever they want, even libraries they wrote days before the challenge, as long as it is released to the public afterwards. This would allow those of us that can't dedicate time far in advance of PyWeek to be on the same playing field as the guys maintaining personal libraries online.

Cosmologicon on 2009/08/23 00:23:

Given how variable your motivation seems to be, why should we believe that you'll follow through and take the time to release a version to the public after the competition's over? Just playing devil's advocate, here.