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.

Comments

1KB Chess For The Sinclair

[TheGoodNamesWereGone]

1KB Chess for the Sinclair still has that beat.

Re:1KB Chess For The Sinclair

[lobiusmoop]

Actually it was only 672 bytes - the 1024 byte memory had to include the screen memory also, much like shared video memory today - could take up to 768 of the 1024 bytes for a full 32x24 screen! (the chess game only used an 11-line screen for the board etc)

And it's even considered by some to be the greatest program ever written.

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: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.

[TheRaven64]

Works fine in Safari. That said, if you press a key other than ijkl it does something random. I assumed wasd would work, and was very confused until I read the instructions. It's also single player, so you basically drive around until you hit your own wall - there's no way of winning. It's more a drawing program with a crappy UI than a game. Making it only 226 bytes of source isn't that impressive, it's basically:

• Change direction if key is pressed
• Test if pixel next in that direction is white, if so exit
• If not, set it to white, set current location to that address
• Repeat.

I wouldn't be surprised if you could write the same game in under 226 bytes of Z80 or 6502 assembly, so doing it in a high-level language seems much less impressive.

2 player?

[Ambitwistor]

It's not really a game of Tron without a competing lightcycle. (Without fruit, it's not really a game of Snake either.)

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.

Calling this a game of "Tron" is a stretch

[readandburn]

It should be called "Drawing-A-Line-In-A-Tiny-Black-Square-With-Terrible-Controls".

Come to think of it, that might make a better movie than that last Tron.

This again...

[zAPPzAPP]

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.

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.

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:Controls?

[Anonymous Coward]

IJKL instead of WASD or arrow keys. It saves space because IJKL is actually in alphabetical order, which makes it a neat modulus away from being the four directions.

Same thing in x86 asm

[Juippi]

This was fun, because I got pretty much the same thing down to 56 bytes in x86 assembly some 15 years ago. I remember the best entry in the competition I wrote it for being around 48 bytes or so; I missed at least one trick for setting the graphics segment more efficiently, and also something related to either collision handling or keyboard input, don't remember which.
In any case, this is possibly the right version of the code. Should compile with NASM, and is even playable in Dosbox with arrow keys if you turn the emulation speed as low as it can go.

And how much supporting code?

[davidbrit2]

How many megabytes of supporting code are necessary to run those 226 bytes?

not tron

[eyenot]

I think there's a difference between Tron and Suicidal Etch-A-Sketch

Etch-A-Sketch

[tepples]

Suicidal Etch-A-Sketch

Please leave Governor Romney out of this.