Breakout in 30 lines of JavaScript | Hacker News Reader

Breakout in 30 lines of JavaScript

jsfiddle.net

144 pointsaves44 comments

I feel like these posts lately haven't really been in the spirit of the "Excel-like spreadsheet in < 30 lines" post. These games lately have just been ultra-min'd versions of standard programs. The Excel-like program used full variable names and a clever trick to take advantage of the dynamic nature of JavaScript and some features of modern browsers.

True, but it's useful to have tiny toy but real programs for newbies to experiment with.

All these Thing in 30 lines posts would make an excellent collection for people to type in, debug, modify, debug, expand, debug, etc.

Someone could make an RPi friendly page and collate these. Maybe include some gentle competitive edge - code golfing or neatest added feature or somesuch.

I agree with your basic sentiment, but tiny toy programs for newbies to experiment with should DEFINITELY have readable variable names.

I've been programming for 15 years now and that Excel-like thinger taught me a thing or two, and it didn't take tearing it apart to figure out how it worked.

This game, and the Snake one from yesterday, didn't even go so far as to generate the DOM objects in a loop. That was another big part of how the Excel thinger worked, it wouldn't have been nearly as succinct without it.

Now, I can see using the HTML if there were significant text data you wanted to include, e.g. text-adventure room descriptions, but this just seems like they're focusing on the "30 lines" part of the challenge and not the "super-dynamic" part.

Have you looked at http://codegolf.stackexchange.com/ ? From what I understand, these are similar except it's more about doing things in the least amount of characters than lines.

For example, here's the 552 character Ruby code to print the lyrics of a song.

    i=44
    s="We; n7trangMsL8loT63Ke rules5s8d8I
    AJull commit4nt'sChatFKink: of6CHldn'tRetKisJrom<ny@Ruy-/A= if?<sk 42DS'tLE 4?;Lo8bli=L7ee..
    O,R1)O,R001)/-.."
    "
    I justCannaLE?2Gotta >u=Msta=.|
    Ng1Nlet? downNrun<rH=5desMt?N>cryNsayRoodbyeNtE< lie5hurt?|
    
    We'T3n each@Jor s8lSg6r hear9<ch: but6;Lo7hyL7BInsideCe both3Cha9Ro: S
    We3KeRa45we;QplB|1)O)NgiT, nPgiT
    (G|iT? up| howFJeel:
    | know|me|<= |
    YH|8s|o |t's been|ing|'re| a|nd|make? | yH| othM|A|ay it
    | w|D|ell| I'm|G|ou|I| f|Lh| t|er|
    NP|
    (Ooh|eTrQ|RSna | g|on|ve".scan(/[^|]+/){s.gsub!((i+=1).chr,$&)}
    puts s

I like the idea of the challenge, but some kind of standard formatting is needed, otherwise 30 lines is very arbitrary. I like the X bytes challenges as there's no ambiguity in what that means.

My problem (and I think a lot of other people's) is not with the arbitrariness of lines so much as the fact that you can run a longer program through a very dumb minifier and get a "short" program just by sacrificing readability. It's still very much the same program; we're just rewarding people for making it harder for us to read. This problem isn't solved by switching the requirement to bytes. I would sooner accept a token limit than a byte limit, because it's harder to elide tokens to the point of unreadability in most languages.

I think the fairest way to do it and keep readability is to have the minified code be the byte count and also provide the unminified version as well.

Similar to http://ioccc.org/ ?

Me, I'm looking forward to "Linux in 30 lines."

30 not counting the (block * lines) of HTML ;) If you're comparin' code size - my favourite was from the first JS1K comp - a nice looking platformer in 1K!: http://marijnhaverbeke.nl/js1k/

> 30 not counting the (block x lines) of HTML

+ CSS as well

It's still impressive to see. Though I did cheat; I set my lives to 99999 then let the game complete itself like a screen saver

little mod that makes the game look like it plays itself

http://jsfiddle.net/icodeforlove/Fq8F4/310/

it always gets stuck for me though :(

or change --lives to ++lives

Or just drop that line.

It would be nice if the norm for these "X in N lines of Y" posts didn't count comments toward the line count. (I also wish people would use more descriptive variable names, but I suppose that would make the code longer.) Compact code is a neat trick, but compact, easily readable code is something we can learn from.

Indeed... I mean, we could just "compile" it if we really wanted to optimize for line numbers. It's neat to see what can be done in tiny amounts of code, though.

Some contests count _tokens_ instead of chars. It fixes the problem nicely, but it doesn't have that charm of a block of magical code that fits on the back of a card.

TIL: DOM elements with IDs are automatically available as properties of window. (ball, paddle, etc.)

I was surprised too. I thought you would have to explicitly select it with getElementById()

Me too. Anyone know what browser support is like?

A couple of findings:

- This stackoverflow answer has a good back story on this: (TLDR, it's not standard... yet) http://stackoverflow.com/a/3434388/1339100

but it is in this HTML 5.1 draft: http://www.w3.org/html/wg/drafts/html/master/browsers.html#n...

- It's slower than document.getElementById, somehow: http://jsperf.com/implicit-dom-element-variables

I've always been fascinated by the collision detection behavior of various Breakout-like games. They always seem to have some idiosyncrasies, like the ball bouncing the wrong way when it hits a corner, or clipping through blocks when it's moving very fast and/or at the correct angle. I often wonder what a fully correct collision algorithm would look like.

There are many such algorithms, and it is an active area of research especially in the area of soft body physics (cloth, human tissue, etc) where precise collision handling is very important.

Most rigid body simulations use discrete collision detection with fixed time steps, so it only checks for collisions at specific points in time. This is fast, but can cause issues where fast moving objects passing through thin objects (such as a bullet through a pane of glass). The alternative is called Continuous Collision Detection in which you calculate exactly when two objects will collide (or have collided) and can then simulate up to that point (or roll back to that point) and deal with the collision. One naive technique to do this is after integrating your simulation forwards, you use the volume each object swept out in that time step as its collision geometry instead of just the shape of the object at its new position. This solution has issues; it doesn't tell you when two objects collided and it can give false positives, but it works ok for rigid body simulations.

Some recent papers on the subject with more exact (and complicated) techniques:

http://www.cs.columbia.edu/cg/ACM/

http://www.cs.ubc.ca/~rbridson/docs/brochu-siggraph2012-ccd....

It would seem that Breakout-type games present an especially simple case for collision detection. The ball always continues in a straight line, and all the blocks are stationary. I would think that in these conditions, the game could really compute exactly when and where the next collision would happen. The paddle it'd slightly harder, but its motion is still constrained to an axis, so you could compute the ball's collision time with that axis and then decide what to do based on where the paddle is at that time.

Edit: To put it more simply, as soon as the ball leaves the paddle, isn't it immediately possible to exactly compute its complete path up to the next contact with the paddle "axis"? Do any Breakout games do this?

Original: http://habrahabr.ru/post/202530/

Why don't any of these breakout clones bother to get the gameplay right?

Breakout doesn't even pretend to use real-world physics: The ball bounces vertically off of the bricks and ceiling and horizontally off of the walls. After hitting one brick, it ignores and passes through all others until it hits either the ceiling or the paddle; together, these make the ball much less chaotic, which enables faster speeds and longer runs.

There are other nuances too. Such as the number of angles available after hitting the paddle, and speed of the ball based on what color brick is hit. This classic video explains it all pretty well: https://www.youtube.com/watch?v=JRAPnuwnpRs

Probably because that doesn't sound fun at all. City41's video makes it sound even worse. The bounce angle depends on the number of bounces since the start of the round? Sometimes the ball just passes through the last brick 8 or 10 times for no obvious reason? No thank you.

HaxX mode: http://jsfiddle.net/Fq8F4/265/

*HN edition http://jsfiddle.net/Fq8F4/275/

[well-known-trivial-app] in [substantially-small-number] lines of [any-high-level-script-language-with-graphics-libs]

Neat! I'm finishing up a course for Pluralsight on "Game programming with Python and PyGame" that will be released soon and the goal of the course is to create a basic 2D game and I choose to do Breakout as it's fun creating when learning a new programming language!

That's Breakout not Arkanoid.

Thanks! Corrected.

Indeed. Arkanoid had better graphics and sound.

This is neat and all, but I personally don't think it's that impressive since it also has 120 lines of CSS and 57 lines of html.

So which is more impressive Breakout or Excel?

I like the Excel example b/c of its simplicity http://jsfiddle.net/ondras/hYfN3/

I also like it more because it's more readable and is not compacting all the blocks into one line.

Breakout IN Excel. =p

Very cool!

But the title doesn't mention that there are also 57 lines of HTML and 121 lines of CSS (with some line breaks).

Still amazing though. =)

Not working really well here (Firefox 25). The balls sometimes touches the floor and the game keep going.

Pretty cool btw.

That decrements your lives. You have three of them so you won't die until it touches the ground the third time.

Reply on news.ycombinator.com