Yes, you are right ventilator, it's a bit late. And I don't know what should count as one command. Probably 100 commands are too less, right. But having a restiction like 100 semicolons was a bigger fail, because you can see, it's a restiction which is easy to avoid - and the sense is loosing. That's why jcl did change it (did he?). Whatever, I absolutly understand the disturbance. The rules should have been clear from the beginning. But it wasn't also not that easy to see that you can cheat in that extreme way. Mad that it's so difficult to make rules for forbidding "cheating" - in this case the commands destriction makes the most sense. (Though I surely would easily exceed 100 commands..!!)

At the moment I'm finishing my project with the aim to complete it with max. 100 semis - using the only trick, that I'm having a function with parameters I wouldn't use if the semicolons desctiction wouldn't exist.
It's important now to hear really strict words about the contest and its rules from jcl - oltherwise it's going to perish.

it would only be a problem if there were no additional 10kb limit. the 10kb limit can't be overcome.

the only reason to forbid the ; tricks (they are no cheats!) is readability but if the sources are a mere 10kb it won't be hard at all to deobfuscate the code if you are interested in how it works.

in my opinion there should have been only the 10kb limit right from the beginning. that's a clear and simple rule without room for misunderstandings. with "100 commands" you can't achieve that. what is a command? will they be counted in the produced assembler/machine code? does it mean a7 function calls only? (you could again do tricks like inlining all vector calculations and so on...)

All restrictions invite some sort of "cheating". What we should have done for this contest, and what we'll do for the next such contest is working out a system of limitation of special characters like ;=(). For this context, it's too late for any precisely defined rule. We won't be too critical with the entries. If you manage to achieve the same with fewer commands and less "cheating", you'll just have a better chance of winning.

Sounds fair.
One last statement: In my oppinion is the 10kb limit one of the dumbest restriction (okay, in this case it's good that it limit the contest at all), because it just results in crypted, ureadable code! You could write a program, which shrink your code (e.g. replaces vars etc. with a-z,0-9 etc.). Thats probably an interesting project but makes no sense, because its the task of the compiler - ours is to show that it's possible to make a funny/good mini game/prog/screensaver/etc. with short/less (clever programmed) algorithms!

short and clever algorithms often are harder to read and understand (if they aren't documented well) than longer and not so clever algorithms. and what is obfuscation and what programming style?

if the goal is to get readable code for gamestudio users to learn from then it would have been better to put the limit on the exe size.

Lol, my exe size is ~120 kB. Not bad for a 10 kB source and, yeah, the source is only in parts readable.

Though, I don't like people complaining that they can't extract useful code from it. With a nice search and replace tool plus knowing how to resolve wrapped together functions and so on, you can retrieve the full source code - as Vent already said.

I guess that 90% of all the entries feature "casual" programming stuff. Nothing fancy. The real achievement is to find away to make it stable and usable in the smalles scope as possible. The way you have to go is to make a data driven application. E.g. through entities and their skills/strings set in WED, material color settings in MED (I dont mean embedded effect files), or abused model entities to store lots of numeric data, like cutscenes, audio volume information or even state transitions... there is so much room to discover.

So I am really looking forward to see the sneakiest programming hacks featuring a creative way to abuse the engine -- while providing an outstanding game/app/whatever.

Wasn't that the original intention of the contest? I think so.

With readable I do not mean "simple code -> easy to understand". I mean "good looking code -> easy to read".
My problem with the 10 KB size is: I will have to shrink my code by giving vars and functions shorter names and also delete some comments, at least shorten them.

If you wan't to gauge the quantity of a program you shouldn't count the number of characters in its code!
No sense in my oppinion. That's all.


Obvious that everyone found different intentions of the contest... But I would like to quote jcl (also if my interpretation of that english sentence may be bad)...

@JCL
Thank you for taking the work arounds into consideration. All of us knew exactly what you ment when you made the rules. I think just some of us try to cheat and then blame the rules for not being very clear. I had completely given up on my multiplayer project when I found everyone else was "working around" the rules. This is great knews for the rest of us not "working around". GL TO EVERYONE AND HF!

Another topic:
Why the 14th as deadline? It's a saturday! Don't misunderstand me, I guess I'm really good in time and won't come in trouble. I'm just wondering why a saturday when nobody works. "Before the 16th" would be plausible - so conitec have all entries till monday and can prepare/start the contest.
Another little bit more specific question: How will the contest be presented? I expect a new thread with all entries (compiled) ready to download and vote for. Do you already know when this will be up and how long the voting time will be?

The deadline isn't the 14th of June, but the 15th. We've got users from all over the world, so all the entries that arrive on the 15th of June are good to go for the contest. We will not accept entries that arrive on the 16th of June, even if it's in the morning.

We'll have a separate thread with all the entries; the voting will be disabled for a few days, in order to give all the participants the chance to fix their demos (if needed) and so on. We'll probably accept votes for 10-15 days.