Competition rules 2014
-
Size limits
In the classic and webgl compos, the max size of your demo cannot exceed 1024 bytes. In the ++ compo this is 2048 bytes.
Note that we're not counting in characters. JavaScript uses 16bit unicode values internally. The server will enforce this
restriction and reject your submission if you try to submit more anyways.
-
No externals
That means no linking, no including and so no using of any external resources. No use of other submissions in your submission. Your demo should run without
any required input, or come with an example if it does take keyboard input like some kind of seed. Your submissions should be able to be put in a single
script tag. In fact, see the shims (classic and ++, webgl). They should also run and work completely offline.
-
Different compos
As an experiment there will be three different compos this year. They are named "classic", "++", and "webgl". Classic is the regular JS1k competition
you're used to. As an experiment, ++ gives you more room (2k instead of 1k). The webgl compo is another experiment where you get a slightly bigger boilerplate
specifically for webgl. It's okay if the webgl compo turns into a shader contest. I will evaluate the new compos afterwards.
-
Deadline is some time in the future
The submission form automatically closes at March 31st 2014 (23:59 CET, which is midnight UTC+1)
-
Only classic competes for prizes
The ++ and webgl compos are experimental.
-
Only one submission will compete per person
But you are free to submit as many demo's or updates as you want
(try not to make me crazy please, I manually check and validate these submissions).
Judges can submit but their entries will not compete (they're aware :). The jury will only consider your
LAST submitted entry! And you obviously can't submit an entry after the deadline passes. Submissions to other
categories don't count for this rule.
-
Anything goes for golfing
Do not worry about Crockford's wrath. Your submission does not need to pass jslint, style guides or anything
like that. You may compress your submission in any way you can, as long as the result still runs in the target browsers.
It MUST run in the browser, in the provided shims (classic and ++, webgl).
That (and the other rules on this page) is pretty much the only restriction.
-
Your demo must work in two browsers
The target browsers are Firefox and Chrome. Your demo must run in both of them, without a problem. I will not allow a demo
if it flat out doesn't work on either of these browsers (I will contact you and tell you to fix the problem). Speed is not
my concern (but might be of the judges). Internet Explorer, Opera, and Safari are not included because their latest version
require a spefic OS (windows/osx). Specific versions in case it matters:
But really, your demo should just work in all browsers. Standardization has come a long way. When push comes to shove
the jury can apply browser versions for a verdict. These rules are in place to prevent dirty browser specific hacks.
I hope that the result will be a more "pure and generic" js demo. Not just something that works because one browser
implemented something nifty (like sharp variables in Firefox). Note that recently
Firefox started supporting element ids as auto-globals, so you don't have to getElementById anymore ;)
-
Your demo must work in the provided shims
And in case it matters, the demo must work when the shim is put in the frameset all demos are running in. The entire submission
will be put in the provided shim of that compo. All demo's do this so we're all on the same level.
The classic/++ shim gives you a fullscreen canvas element. It also
provides three variables and gives you a function to remove the canvas (in case you want to do something else).
The a variable contains a reference to the canvas element. Var b
contains a reference to document.body. c is the drawing context reference
(canvas.getContext('2d')) of the canvas in a. Calling d will delete the
canvas so you can use some html. The shim will also unprefix AudioContext and requestAnimationFrame.
I've intentially kept their original names since I only wanted to take away the burden of vendor prefixes.
The canvas will resize onresize and onorientationchange. You can limit the size of the canvas
by calling onresize(maxWidth, maxHeight) once yourself. This might help for performance sensitive demos.
The webgl shim is similar but contains a shim to bootstrap webgl, exposes the
drawing contact to variable g, and doesn't expose the delete function d since you
probably don't need it.
-
Your demo should just work
- Must not crash in either of these browsers (no syntax or DOM errors)
- Should behave approximately equal in both browsers
- Platform shouldn't really matter (especially since it should work in all browsers)
- Speed is not my concern, but might impact a jury verdict
-
Other things you should know
- Your demo does not need to be visually appealing (certainly not to be submitted and listed on the site!), but it tends to help... it must do something though because nobody cares about an idle demo
- Your entire submission will be put in the script tag in the provided shim (the above rules assume this)
- Your script may not mess with the frameset, break out of its frame, read/write anything that's not in its own frame, force a reload of the page or redirect the user to another site
- Your script may not "phone home". That includes saving high scores etc. The exception is a button/link to tweet, if you have room left for it
- Do not submit HTML soup. It will be rejected. Your entire submission should work inside script tags (don't try to be smart, you cannot use
</script>...<script> either)
- Test your minified script result in the (entire!) shim. There's a reason we provide it. Paste your script in the proper position before you do. The
a, b and c variables are fixed, so make sure tools like Closure don't change their name.
- Audio and video are in. WebGL and webRTC are out (except for WebGL in the webgl compo, of course). Be careful about codecs and target browsers...
- The theme "Here be dragons" is only a suggestion, it's not an actual requirement
-
I have a final say in things
I think I'm reasonable enough but I reserve the right to reject anything. This hasn't happened before and I don't think it will this time, so don't worry :)
-
Tips & Tricks
document.body will be available when your code executes! (Use b though ;))- New this year: you can access elements by id as auto-globals. This was prohibited previous years because Firefox didn't support it. Yet.
- New this year: your canvas will automatically be fullscreen.
document.body.children is shorter than document.body.childNodes ;)- When minifying, beware that the boiler plate variables must remain the same!
- You will see a preview of how your demo actually looks like when submitting, please ensure that it works there
- Don't give up too soon and just submit to ++.
