JavaScript game of Tron in 219 bytes

No wonder the "lag" feels so bad. Also, the area is way too tiny and it needs a way to restart without having to reload the page.

Your version plays so much better, that was really not a good way to save 2 bytes.

That's why i can reach 1000 point. Its difficult to keydown and keyup immediately.

I initially thought it was a cool way to "bend the rules" and save a few bytes, but lots of people told me the same thing! In hindsight I would have instead changed our rules to disallow this :)

Yes "who cares" means that they didn't care if the game was playable.

While acknowledging that the original post was an engineering exercise, the fact that your improvement required breaking the "rules" beautifully demonstrates how, too often, software designed for humans simply ignores how they really work.

I agree wholeheartedly. I would give it up to them for perfect purity if it weren't the fact that they weren't actually being perfectly pure. They gave up 9 bytes to show the score at the end because it was, in their words, "totally worth it". But then they decide it's a good idea t save 2 bytes at the cost of making the game completely frustratingly unresponsive to the point of unplayability? That's just silly. If you're going to be pure, be pure. If you're going to make concessions, make the ones that matter most first! I'd much rather have a playable game without score than an unplayable game with score.

Rant aside, I actually do applaud them. Impressive bit of engineering here.

There are 5 possible collisions: top edge, left edge, right edge, bottom edge and the tail.

Your proposal does not cover the top edge.

Calling it "Tron" saves a byte ;)

In the classic Snake game, the tail of the snake moves and the snake grows longer when you eat snakefood. In Tron, the light trail stays there and you try close in your opponents. So this game is definitely Tron, not Snake.

Tron is usually a multiplayer game and the speedup next to light trail you mentioned is missing.

Btw. back in the BBS days there was a Finnish freeware Tron-with-weapons game called "DeLuxe Moposota" (rough translation: moped wars). I have very nice memories of it. It works nicely DosBOX. Here's a youtube clip: http://www.youtube.com/watch?v=Gozt-1BgVrU

It's 219 bytes, it's not that clever! When you die it simply displays 'game over' along with incremented timer. Because the entire logic is inside a `setInterval` call it never gets stopped.

setInterval is set to update in 9 ms intervals - I assume because whilst it's probably more playable (easier) at higher intervals doing so would require additional bytes.

Most likely, 1px = 2 device pixels on the retina MBP, like on the the retina iPad and iPhone.

Surely that must have some sort of scaling by default for webpages. Otherwise I would guess nearly all websites appear miniature.

A retina display's claim that individual pixels are small to see means you're not supposed to be able to distinguish individual pixels in an image - so curved lines appear smooth without pixelation.

It doesn't mean that a 1 pixel-wide line is invisible, or that you won't see a single white pixel on a dark background.

LOL!

From 212 bytes, 9 bytes were added (not subtracted) to keep track of the score, making the total 221 bytes. Save 2 bytes and you get 219 bytes.

rules: ...the code need only run on Chrome 17.

Works fine on Chrome. Use it. And read the rules next time. :)

works well on Opera 12

thanks for pointing it out, fixed!

thanks for pointing things out, fixed!

the controls are absolute, with: j goes left l goes right k goes down i goes up.

If you are a vim user, you'll be confused and fell like things are reversed. Sorry :(

The game is still running in the background. It's just hidden.

not bugs; tradeoffs by design :)