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 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.
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/
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.
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:
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?
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.
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!
I'm a bit disappointed with all of the memes in HN comments lately. This comment (nor mine) add interesting information to the discussion. I don't mean to nitpick; jokes can be funny, but signal to noise ratio is important. Sorry for pointing out this personal sentiment if it seems inflamatory.
