This game was made entirely in css (no javascript) | Hacker News Reader

This game was made entirely in css (no javascript)

jsrun.it

170 pointsFeanim50 comments

How (I think) it works:

Basically it's a bunch of animations that play simultaneously. For example, there is no actual timer. Instead there is an animation of a bar filling up, and an animation of a "game over" screen doing nothing for a few seconds, and then sliding onto the screen. All of this is done with CSS keyframes.

Each of the alligators is actually a radio button styled to LOOK like an alligator, including an animation to move up and down in a fixed pattern. When you check the radio button, it changes the style (through CSS rules conditioned on the checked state), which changes the animation to take the alligator off the screen.

Now, the scoreboard: For each alligator radio button, there is a corresponding radio button in the scoreboard, paired up so that checking the alligator button unchecks the scoreboard button. The scoreboard buttons are stacked on top of each other, and unchecking them causes them to animate their height down to zero. This effectively computes the number of checked alligator-buttons and outputs it as the height of the element. At the bottom of the stack is a strip of images for scores 0, 1, 2, etc, so that as the buttons are unchecked, the right one moves up into the display area.

Finally, the "play again" link at the end just reloads the page.

... and the images for the lazy

http://imgur.com/a/UMERX

This is truly impressive. Any idea who the author is?

edit: to answer my own question: http://jsdo.it/GeckoTang

> There are more than 6000 lines of CSS behind this, but only the first 500 or so are actual CSS; the rest appears to be images encoded into text.

Why would you encode image to text??

It's done all the time, mostly to reduce the number of requests needed. It's similar to spriting, but can be even faster depending on the images you need.

Yes, there are fewer requests that way, but the cost is an increase in the total data size. Using a single sprite sheet for all the images would probably be faster in most cases. However, there is the matter of convenience (it's nice being able to have just a single file with no dependencies).

Base64-encoded images can't be cached, either.

... Why not? They'll be cached in the stylesheet or whatever source you're providing them from.

And when you change the stylesheet, you'll invalidate the cache on all your images.

gzipped base64-encoded data is about the same size as the original data, though. It only requires more processing to be done.

It depends on what you're doing with the image. You can't always tile a sprited image for example, which is a nice advantage for base64 encoding. Size wise they're pretty similar once you count gzipping, though you do have more overhead on base64 since each will have its own set of image headers vs just one for the sprite.

The best is a single sprite sheet encoded into the source file (I believe this is what the Cappuccino framework does for some of the images that make up some UI elements).

Why? So that you don't have the overhead of a http request and image download as each image is used.

I'm guessing sprites waste memory?

Encoding the images into the HTML file together with the rest of the game allows you to redistribute the entire thing pretty easily.

But I guess, the actual answer is the same as to why would you implement a game only in HTML and CSS: because you can.

If the game starts right away, maybe it's the best way to guarantee all images are loaded.

Your explanation is correct, only you got scoring direction mixed up: initialy radio buttons for scoring are checked and have zero height, when "enemy" is clicked, corresponding score input is unchecked, gets height set and pushed numbers panel down. I've made an illustration: http://jsfiddle.net/72bbx/ The difference is that there initial height is non zero—just to make radio buttons visible.

Doesn't work in Internet Explorer or Firefox for me.

Most likely because of things like

  @-webkit-keyframes gameover{

Was just going to post this. The game requires use of @-webkit-keyframes. As you can guess by the name of the deceleration, it's webkit only.

damn i hate those tags (being -moz or -webkit or any other, mind you)

such a way to break the way. need a different browser each time if the dev doesn't take the time to use every single tag there is (and its NOT the dev fault here)

What's a better way to introduce experimental (i.e. not yet standard) functionality?

ditto for Opera and Firefox on Ubuntu.

Firefox here, Windows XP with scripting enabled. I only see "Game Over, Replay".

How does the score counter work? The rest of the stuff seems quite straightforward, but this one I couldn't figure out with quick examination.

See geoffschmidt comment and also there: http://jsfiddle.net/72bbx/

Thanks a lot! Playing with the code explained it well.

I think geoffschmidt's otherwise great explanation explained the score calculation a wrong-way around: checked score radio buttons start with zero height and when they get unchecked they grow to their 93px height.

I learned a few new things that were necessary to understand this:

1) States of radio inputs can be connected by name attributes and connected inputs can have an inverse state to each other.

2) Transition effects can be connected to checked/unchecked states (at least with "all" property)

3) Using a wrapper div with overflow:hidden you can create "a window" to a larger content that moves "behind" the window. I've seen this in some scroller effects, but as my CSS skills are quite bad, I couldn't yet write one without googling for some help.

So is CSS Turing complete then?

You don't actually need a Turing-complete language to implement games. You can use finite state machines driven by keyboard/joystick input with images for each state.

Yes it is:

http://news.ycombinator.com/item?id=2300836

https://github.com/elitheeli/oddities/blob/master/rule110-gr...

in combination with HTML at least...

(Although as others have stated this game is really just a state machine)

Important detail: only in combination with an arbitrarily large HTML file, and only with arbitrarily many user interactions (i.e. the user needs to manually increment the state).

As such it's a pretty meaningless type of turing completeness. So, whereas in general it's undecidable whether a program completes (the Halting problem) if it's written in a turing complete language, for the case of HTML+CSS it may well be decidable for several reasons. Firstly; because the HTML file will be of limited (and in practice small) size, and secondly, because the interesting question is whether you can reason about the state _now_; not whether the document might reach arbitrarily many states were the user to perform infinitely many interactions.

Turing completeness makes hard to reason about a program; and indeed the weaker a language the easier it can be to reason about it - or, more practically - the easier it can be for the browser to determine boundary conditions and to simplify interpretation of the page. Indeed, ironically, Tim Berners-Lee points out the advantages of using weak languages: http://en.wikipedia.org/wiki/Rule_of_least_power

Saying that HTML+CSS is turing complete is kindof like saying finite state automatons are because the number of states is unbounded. That's entirely beside the point however; the point is that I can evaluate a _given_ FSA without turing completeness, not that an arbitrarily large FSA might take arbitrarily many execution resources (I mean, well duh).

Any given HTML+CSS combo is thus bounded in two ways; both by its own size, and by the fact that I don't care about eventual possible states reachable after infinite user interaction but just about the current state (or states very close to the current state).

This, besides websockets, is probably the coolest thing I've seen yet. I can' wait to get my mind wrapped around this so I can experiment with this concept. Perhaps, I can make something useful.

Webkit only? Works in Chromium, but not FF 9.0.1 (Linux)

Doesn't work on FF 9.0.1 running on a windows box either.

Possibly a dumb question but: who wrote this? I looked at the code and couldn't find any info on the author... Would love to get in touch with them and hear more about how they went about it, why they made certain choices...

I was certain there'd be /some/ kind of JS in there..! Rather impressive.

Indeed. I had to audit the source believe it, but this is actually legitimate.

Massive abuse of data url's and keyframes, but it works.

In what way is it abusing data urls? Carrying small images is a pretty popular use.

For sure! What is found at the end of the page is priceless, sophisticated humor: <script type="text/javascript">

</script>

I think it's automatically inserted by jsdo.it's backend.

Ask Author or Coomunity? Hold up, how does he listens to click events? There has to be javascript correct? I don't remember any pseudo classes handling click events?

Input elements can have :clicked states... :)

:checked pseudo-selector.

I wonder why some graphics are embedded in CSS and some not.

Looks to me like they're all base64. Jsdo allows file uploads, so I'm assuming that (outside of novelty), the animations may not execute properly if the images aren't loaded. Using base64 ensures the images are loaded before the keyframe anims are rendered.

For anyone that wants to see the full CSS easily:

https://gist.github.com/07c1a2c30ed556b66e97

For anyone that wants to change the CSS/HTML easily:

http://jsdo.it/GeckoTang/4rXg/ (click the fork button)

hm. this only means that css has overgrown its own idea (but still without bringing real gutenberg typography into web pages - columns, gutters, flows .. u name it).

at certain point c++ templates became turing complete, so one could calculate pi's digits in it. After which all other languages started to spawn... away from it.

Probably the least of most of everybody's concerns, but it doesn't look like you can get more than 10 points.

Heh, is that why I can't get it to run?

i used to love this game!! i played it with a real toy hammer and toy crocs when i was a kid :). it was a physical gaming machine! turning it into pure css! how far we have come!

Yet another repost: http://news.ycombinator.com/item?id=2636440

Reply on news.ycombinator.com