Thanks for the interview

Thank you! Jibb, you've got a great game out there.
"is it Possible to have less than 5KB of code but have several MB's of models?" Sure, the limit is set for the source code only.

George, are these the same rules as back in 2007 were you counted only semicolons and watched the file size of the main.c file in windows explorer?

Nice issue and fun contest!

Thank you for the kind words, Joozey!
Christian, the size of the file is crucial; otherwise, we'd have lots of projects with huge lines of code you'd never see in a normal application. Basically, with 200 lines of code x 25 characters each you will hit the 5KB limit.

As a GS newbie, it is necessary for me to thank the AUM's anthors for their uninterrupted efforts.
The big confusion is that how to position the AUM, I mean academic or commersial? Official or not?
IMHO, the Conitec should release a little more "amazing" demos with fantastic outlooking even without codes, which will definitely encourage more fans.

The problem was that comments, white lines, headers when split over multiple files, all the things that makes code readable eat up the most memory, and have nothing to do with the working of the code at all. So I could cramp everything on one line, remove all comments and spaces, and it would suffce. But then the code would be worthless as a contribution. So if we just count semicolons (less than 200), we can write proper looking code and are bound to write it efficient too.

I am suggesting the following 5 rules, because I agree totally with Joozey:

-------------

1) the submission contains a readme.txt with all necessary info, like your personal info and credits, license details, etc.

2) one folder called "\submission", which must be included. It contains the ninja-code submission as one (!) .c file; if it can be self-executed (like a game) it is called main.c, if it is not-self executable (see below) it is called code.c; this is useful in the case if someone writes a neat function that can be used as a component, like generating stuff or pathfinding or the like.

3) an optional (!) folder "\clean" contains the same content as "\submission", but with optional comments, whitespace, sidejokes, and so on; so that people can understand your ninja code

4) if under 2) a not-self executable .c file is provided, a folder "\demo" can be used to showcase the ninja-code. The demo runs from a single file "demo.c" and in this .c file, the "code.c" is included. The demo code has no restrictions and MUST NOT EXTEND the targetted functionality of the code.c (!!!).

5) If 4) applies and a clean version (see 3) was submitted, the files HAVE TO BE interchangable with the VERY EXACT SAME behaviour.

-------------

Sounds very limiting in the first place, but it just makes sure that everything is fine for both the contestants and the jury.

I think I don't have to say that a contestant has more chances to win if

- he makes very cool ninja-code with lots of wicked and sick tricks
- the result is overwhelming
- the comments are awesome and easy to follow
- and the demo (if any) is even more awesome!

@HeeIX: What counts for a line?



is the above foo, 4 lines? what if i do:


Greets
Rackscha

agreed, these contest ultimately help newbies and i remember back then when i tried looking into the knights on wheels source code... damn, "hgfkygfysGyukagkaw" was all i saw ^^