JavaScript game of Tron in 219 bytes(alokmenghrajani.github.com)
alokmenghrajani.github.com
JavaScript game of Tron in 219 bytes
http://alokmenghrajani.github.com/tron/
53 comments
Your version plays so much better, that was really not a good way to save 2 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.
Also it needs multiplayer, achievements and a story mode. No, but seriously, this was not a competition in making a playable game, they clearly specify the rules that they have set for themselves.
Perhaps there should be a competitive genre where the goal is not brevity or obfuscation, but being good.
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.
Rant aside, I actually do applaud them. Impressive bit of engineering here.
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 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 :)
That's why i can reach 1000 point. Its difficult to keydown and keyup immediately.
I think I see a way of shaving another byte:
instead of "0<x%n&", you should be able to do "x%n&&". Works for me on Chrome.
My goal is to shave 2 bytes, so you can change the key handler back to onkeydown. :P
instead of "0<x%n&", you should be able to do "x%n&&". Works for me on Chrome.
My goal is to shave 2 bytes, so you can change the key handler back to onkeydown. :P
There are 5 possible collisions: top edge, left edge, right edge, bottom edge and the tail.
Your proposal does not cover the top edge.
Your proposal does not cover the top edge.
[deleted]
Is this supposed to be Tron or Snake? I distinctly remember Tron being a multiplayer game, with the mechanics such that moving along a wall or trail increases your speed, putting you in position to cut off the other players and make them crash.
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
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
Calling it "Tron" saves a byte ;)
I would save 2 bytes by changing
I suppose you only start approximately in the center, though.
n=150,x=11325
n=632,x=1e6 (or similar)
I suppose you only start approximately in the center, though.
The code documentation part is a quite clever use of a slide tool. Very enlightening.
Encountered a bug: When I die, the game keeps counting score as my "dead" player keeps going across land behind the scenes.
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.
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.
Here's a question for you: how will this look on the new Mackbook Pro with Retina Display ? The tron line is 1px wide, and on that computer's screen the one pixel is too small to see.
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.
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.
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.
From what I have heard everything is up-scaled to match the native resolution so things that are not optimized for the new displays just looks kinda bad.
Images would be this way, but fonts, gradients, vectors, etc all look fine. (Unless the app itself hasn't been updated to render those in the new density. Safari works great)
Cool, but due to limitations of the human mind it's almost impossible to play without QWERTY.
It's really cool to see how you've come up with tron in just 219b.
You mention saving 11 bytes, bringing the total to 212. Then another 9 (seemingly making it 203). But go on to say you saved 2 more bytes, making it 219. I'm confused.
You mention saving 11 bytes, bringing the total to 212. Then another 9 (seemingly making it 203). But go on to say you saved 2 more bytes, making it 219. I'm confused.
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.
I can't see the white line in my browser, just a square of black. I know it's working because I get "game over" if I start the game with i, j, k or l. I'm on Firefox 14.0. Do fix it.
rules:
...the code need only run on Chrome 17.
Works fine on Chrome. Use it. And read the rules next time. :)
Works fine on Chrome. Use it. And read the rules next time. :)
Works fine for me on Firefox Nightly too.
Woops, my bad! I'll just skip it then...
works well on Opera 12
beautiful.
i once participated in a similar competition only that it was in x86 Assembly, my friends and I brought it down to 70 bytes and the winner from Finland did it in 48!
http://myweb.cableone.net/benlunt/hugi/compoold.htm#compo1
i once participated in a similar competition only that it was in x86 Assembly, my friends and I brought it down to 70 bytes and the winner from Finland did it in 48!
http://myweb.cableone.net/benlunt/hugi/compoold.htm#compo1
219b for a buggy Tron game. my score keeps going up on game over screen
so... we don't like Chrome? Bc it's not playable and I don't feel like opening FireFox.
In any case, this is really impressive. It's always fun to see the tricks people employ to get these tiny sizes (smaller than this comment!).