RB[0] on 2010/09/02 04:53:

Looking through it's svn, it has in-line documentation, and possibly other, didn't bother to look. It also is not just a game, game engine, etc. where you don't have to work out the actual game, it is a library.
Lastly, since it was mentioned on Pyweek in the past (really not even a necessity, as long as it was released one month at least prior to Pyweek) this is a completely legit library by every rule I have ever seen, and I've been around a while.

It is not there fault that you didn't see their announcement years ago, they don't have to keep making it for a project that hasn't even been updated for 2 years it looks like...
It is totally acceptable to use your own code-library (that is key, can't be a gobbit of game-play code, it's not, it looks like a 3d graphics engine to me), the only thing is it has to be documented and available for other users.

There is nothing I see even questionable about this project.
http://media.pyweek.org/static/rules.html#entries-are-to-be-written-from-scratch

This satisfies all three rules...

Cosmologicon on 2010/09/02 12:09:

If I take the 'gameplay' code from my current entry, it would be about fifty lines of code. How about if I remove those fifty lines, document the rest of the code as a game library, then build on top of that for the next pyweek?

Yeah, if your code base is useful enough and generic enough to be treated as a library, I definitely think you should do that. It needs to be more accessible than just being part of your pyweek entry. If you publish it as a Google code project, that should be good.

I think it might be a little more work than you're thinking, but if you go through with it, please tell us about it! :)

tartley on 2010/09/02 21:20:

Alright, thanks for talking it through with me, people.

I don't want people to take this the wrong way. I have nothing but respect and admiration for the authors of tdgl and Hextrap. However! It turns out that I *am* a nincompoop, because after thinking it through some more, this is where I've ended up:

I agree that converting my code into a reusable 'library' could be a lot of work. But on the other hand, that's work that's pretty much mostly done. I've already published a big presentation describing how the code works. My code is mediumly well-structured (nobody said it needs to be a *good* library.) I could add a few docstrings and bundle some examples, that would take a few days. As far as I'm concerned, it would then be documented more than adequately for someone else to use as a library, if they were so inclined. I already linked to its repo here on the PyWeek boards in the past, so I'm covered, right?

Then imagine this scenario: Now I go away and continue to work on that codebase for the next *five years*, improving it and expanding it here and there. Then one day, I show up to PyWeek 2015, and build a little game on top of that library.

I think competitors in pyweek2015 would be understandably miffed by me bringing a five-years-in-the-making body of personal code into the competition. Although no rules have technically been broken, I think it's a flagrant violation of the spirit of pyweek's "don't use pre-existing personal codebases" rule.

To me, this sounds like exactly like what has happened with tdgl. I understand if you don't agree. But I think it's up to us to police the rules, so I still feel like I have to vote according to my own opinion, which is still that this game DQ.

Scav and Threads, my most sincere apologies that I feel this way. I understand it is an honest difference of opinion, not any attempt to 'cheat', I know that, and clearly your interpretation of the rules is widely-held and in good company. Please be assured no personal animosity is intended. I for sure owe you a beer in recompense if ever we're in the same city.

Big hugs all round! Sorry for being such a wet-blanket downer!

PyTM30 on 2010/09/02 22:07:

tartley, does that mean you think someone who has contributed to pygame or pyglet, for example, should not be allowed to use that library in pyweek?

tartley on 2010/09/03 11:36:

@PyTM30. That's a great question. A agree with what I think is your implied point that it wouldn't be constructive to forbid contributors from using libraries like pyglet that they have contributed to. I realise that makes my position somewhat inconsistent.

I think that libraries like pyglet and pygame, and several others, can be made an exception for because:

a) They have a very high profile. I think I'm right in saying everyone taking part has heard of pyglet and pygame (especially since they are specifically linked to from the rules page & wiki.) If one of the goals of pyweek is to produce useable game libraries & tools, then raising the profile on the ones that people intend to use can't hurt.

b) They have a known high level of quality. It is feasible for me to consider using "someone else's" library when they are known to be of the high quality of pyglet and pygame. When a library is of lower quality (no offence intended, I know that tdgl is of higher quality than any such library I could produce) then other people are discouraged from using it, whereas the original author knows how to work around the deficiencies and produce something usable.

Maybe improving the profile of lesser-known libraries would encourage other people to use them, which would have an improving effect on their quality?

Cosmologicon's suggestion sounds like a good one to me, if it can be done without imposing too much beaurocracy on participants. It has the problem that someone cannot change their mind partway through a pyweek, and decide to use some other library or tool, unless it has already been registered. Maybe that is not a problem, I'm not sure.

tartley on 2010/09/03 12:41:

@Cosmologicon. That's a fair point. I actually think that both sides of this debate embed an inconsistency, of differing kinds on each side. There is no right answer. That I can see, anyway. I presume people with more experience here than I have been round this block several times.

saluk on 2010/09/03 18:21:

To DQ someone for code that has been on sourceforge for 5 years is I think a gross misrepresentation of the rules. I will add that this one rule has been the most debated and caused the most confusion in pyweek, and questions like this do come up every time.

I definitely wouldn't want to have to register my library beforehand. That goes against the spirit of pyweek even more than using some old code does. It's meant to be a "from scratch" competition not to force people to rewrite some base code they always write, but to encourage people to experiment with new ideas. If you're not going to do anything new and different with the gui library itself, then just use albow (written during pyweek), and experiment in other areas.

Personally, I enjoy experimenting with the gui and other base code, so I don't use libraries for that kind of thing. But if someone else would rather get to the meat of the game by using something to jump start, I say go for it. As long as I had the same opportunity to take that same shortcut if I wanted to take it.

The real focus of the experimentation should be on the gameplay ideas, and the technical implementation of those game ideas.

But I guess it's a good idea for library users to put it http://wiki.python.org/moin/PythonGameLibraries so there is less argument/question about it.

scav on 2010/09/12 08:02:

Hi all.

As Cosmologicon says, the best way for me to push development of tdgl forward is to throw it at pyweek entries, shaving off the rough edges I find each time, so the library improves.  That's *why* it's been so long in development: it only improves for a few weeks every 6 months or a year :-)

Case in point, during this year's entry, I found a *lot* of bugs and things I wanted to refactor, and that process is going on.

tartley, it was only a matter of time, I thought, before someone would question the legitimacy of using a very obscure library I wrote myself. I'm not surprised and certainly don't take offence. Up to now I would only have argued that it was more of a handicap than a cheat :-). I'm glad the consensus is that it's OK.  I'll try to keep tdgl generic enough to still be allowed.

Oh, and you probably didn't see it on http://wiki.python.org/moin/PythonGameLibraries because it was there under its old name (tdlib) from when it wasn't based on top of pyglet. I've updated the page, and I am making a serious effort to update the documentation.

Maybe next year, someone else will have a go with it. Then I'll have twice as many bug reports to work from. I don't hold out much hope though.  Even Threads doesn't really want to use it. He never does for his solo entries, which do better than mine.

tartley on 2010/09/13 10:49:

s/If/I've