Javascript Game of Tron In 226 Bytes

Have you upgraded your hardware to play something beefier than 140-byte Tetris? New submitter alokmenghrajani writes with "a detailed view of how we size-optimized a game of Tron to just 226 bytes." It's also optimized for Chrome, and very fast.

Re:portability

[hobarrera]

It works on chrome and firefox. This isn't a portability issue: normally developers add huge amounts of code to support IE. If it needs tweaking for IE, it would probably be 50% larger.

Re:Damn.

[Anonymous Coward]

Under 226? instead of being a critical asshole, that "someone" who sits outside every event and just points, please post your code that does just that. Or, give people a fucking break and realize that pushing boundaries like this is what science, and computer science, is all about. Take off your cynical sunglasses and watch the world become so much more clear. Or not.

Even Shorter

[BrokenCube]

The current version of the code (on the linked site) is only 221 bytes long - and I've had a quick play with it and it can be reduced further to 219 bytes by swapping out the boolean ANDs "&&" for bitwise ANDs "&" twice.

Re:1KB Chess For The Sinclair

[Anonymous Coward]

And what about the 20 MB browser and all other cram below it? I can do a 3D FPS in 0 lines of code by just inserting a DVD into my PS3! Yay for me!

Re:This again...

[sco08y]

226 byte which I am sure include library calls, only runs on top of the multi megabyte of browser code, may use various other resources as well.

By this standard, I can write Tron in 1 bit.

1

There.
Call it the "Run Tron Bit". It runs on top of a full impletation of Tron.

Anything that has a display of some sort has library calls to control that display. If you were writing this on an old C-64, it had a comprehensive sprite library that performed collision detection and perfectly synchronized updates, without you doing more than setting a few registers carefully. If you were playing 6502 machine code golf, you could probably write this in half the bytes. Switching to a graphics mode was (IIRC) a single assignment, clearing the screen was a function provided by the BASIC interpreter, and polling for key events was a simple call. Updating the display, naturally, involved writing to a predesignated area of memory. You could even switch back to text mode to print out GAME OVER when you were done.

In this example, the library calls, which are deliberately designed to be fairly verbose in order to promote readability, chew up much of their byte budget with verbose keywords like onkeyup, getContext, fillRect, etc.

Also, since you're dealing with complex libraries that provide lots features, code has to turn off some of those features. In this case, they actually generate javascript errors and ignore them. They then have to go through handling key events, handling movement and such, and all with some very cleverly compressed techniques. For instance, they grab the mod of the keyvalue and use that as an index to an array of values to update the player's direction.

Re:2 player?

[Lorkki]

Nor is it really Tetris without tetraminoes or scoring. Not to berate the effort, but it's a lot easier to downsize something when you drop half of the main features.