Yeah, flaming sucks.

well I meant more on a code quality point of view. of course that part doesn't have to have a great value on total score. Maybe 1 or 2 points, but then there's still the issue about having a judge who knows every optimizing tricks discovered in TI-BASIC, which isn't my case, so I think coding quality will pretty much not be judged directly. The only way I think it will be judged is if the game causes err:memorys or runs extremly slow for what it does.

This is why I think we shouldn't judge too hard based on the program size and amount of subroutines either, because for some games many files are necessary (take Metroid II for example, which got 350 maps in the expansion set stored into matrices) and IMHO a game with many files/large size doesn't means it's not worth it. Plus, the contest has no rules limiting the game amount of content, except for the fact that if a game contains content that is innapropriate for the forums such as racism, porn and the like, it won't be released to the public on the forums.

Well, as I said, the major problem of judging the code is that we would need to find a judge who knows every single basic tricks in the world, which could be the case of one of our staff member, but does it means he would necessarly want to participate in judging entries?

After reading posts, I think the code shouldn't be judged directly, nor the game file size and amount of sub-programs. If the game has errors, including ERR:MEMORY resulting of bad coding or extremly slow speed then it should be judged under functionality or whatever it will be called

Else, I think it will suck if a super revolutionary BASIC game that runs fast without any error gets a much lower score than a slow BASIC game with few features and that runs slower, just because it has more files or that the author missed closing parhentesis at the line 244 of his 3rd sub program

Do you even know if there IS every basic trick?  o.O

Code size shouldn't be a major factor in judging, but there's probably a point where, even if the program runs decently, where the size is unreasonable.  If someone were to submit a 14 kilobyte nibbles game (even the most extensive ones can probably be done in well under 5kb), then their score should suffer a bit.

Code size shouldn't be a major factor in judging, but there's probably a point where, even if the program runs decently, where the size is unreasonable.  If someone were to submit a 14 kilobyte nibbles game (even the most extensive ones can probably be done in well under 5kb), then their score should suffer a bit.

Yes, there is a point. But that point is in such a gray area that I believe it shouldn't even be included. In your example, of course, it's obvious that the author may have been negligent, but in other more complex games, where do you draw the line? Simply put, you can't objectify it, thus I don't think it should even be included in the scoring.

Yes, there is a point. But that point is in such a gray area that I believe it shouldn't even be included. In your example, of course, it's obvious that the author may have been negligent, but in other more complex games, where do you draw the line? Simply put, you can't objectify it, thus I don't think it should even be included in the scoring.

True.  I was thinking more along the lines of truly absurd memory usage and code inflation. However, as you said, there no way to objectively evaluate where "large" meets "absurd", so I suppose it can't used as a reliable measure.