Skip to main content

Paper Rock Scissors: Day 3

Now we're demonstrating how fun interfaces can be built without the use of Flash. This is a growing importance, as open web technologies like HTML5 and CSS3 become more supported and capable, and as devices like Android phones and Apple iPads are more widespread, where Flash is un- or under-supported and web technologies are increasingly useful for performance. The prototype of Paper Rock Scissors worked, but we need something that actually looks nice.



This is what I came up with a couple hours of messy around. It doesn't take much to clean up a web game, though it can take a lot more to make it really polish and appear shiny. That is true of any design.


The theme has a few threads that tie it together.

Your are represented by a blue glow, on your score and on your selections. The enemy is represented by a red glow, so the progress of the game is clear without overloading it with any textual messages or any heavy graphics. I've notched the selections, like cards pulled away to mark your choice. Thanks to new implementations of CSS3 transform rules, we have great possibilities we can employ. You really know when a selection lost.

Oh no! Their rock beat your scissors. Too bad.

The player doesn't even need any introduction or instructions. You won't know when the game first loads who is blue and who is red, but the first thing you'll see is you own click making a choice glow blue, and you'll know through experience. Learning by discovery trumps a rule book any day of the week. This is enforced when the scores start reflecting the game, and you can see who is who without any of the labels the game originally had.

I did need to put some more information into the game. Maybe you glanced away when the other player made their pick and missed the animation. You'll want some log of the moves that happened. Still, I didn't want this to clutter up the screen and the chatlog made the most obvious sense to put it, already being a sort of timeline. You probably want the last one or two game events that happened, not the older ones, so I think a nice looking solution was found: the game messages fade as they get older, and the chat content stays visible, uncluttered. The result looks really nice after a few rounds of chat and play.

I'd rather play a game with a stranger while I chat. Maybe I've stumbled upon something more fun than Omegle.
Yesterday I wrote about the little tech-demo Paper Rock Scissors game I prototyped in the morning. Today, I've replaced its crude AJAX polling with a comet solution, cleaned up the UI, and added a real-time chat for the players, in about two hours this afternoon.
You can try it out with the other readers of the blog right now. Give it a try, if anyone else is around.

Give it a try and play with the other readers.



Comments

Popular posts from this blog

Respect and Code Reviews

Code Reviews in a development team only function best, or possible at all, when everyone approaches them with respect. That’s something I’ve usually taken for granted because I’ve had the opportunity to work with amazing developers who shine not just in their technical skills but in their interpersonal skills on a team. That isn’t always the case, so I’m going to put into words something that often exists just in assumptions.
You have to respect your code. This is first only because the nature and intent of code reviews are to safeguard the quality of your code, so even having code reviews demonstrates a baseline of respect for that code. But, maybe not everyone on the team has the same level of respect or entered a team with existing review traditions that they aren’t acquainted with.
There can be culture shock when you enter a team that’s really heavy on code reviews, but also if you enter a team or interact with a colleague who doesn’t share that level of respect for the process or…

CARDIAC: The Cardboard Computer

I am just so excited about this.


CARDIAC. The Cardboard Computer. How cool is that? This piece of history is amazing and better than that: it is extremely accessible. This fantastic design was built in 1969 by David Hagelbarger at Bell Labs to explain what computers were to those who would otherwise have no exposure to them. Miraculously, the CARDIAC (CARDboard Interactive Aid to Computation) was able to actually function as a slow and rudimentary computer. 
One of the most fascinating aspects of this gem is that at the time of its publication the scope it was able to demonstrate was actually useful in explaining what a computer was. Could you imagine trying to explain computers today with anything close to the CARDIAC?

It had 100 memory locations and only ten instructions. The memory held signed 3-digit numbers (-999 through 999) and instructions could be encoded such that the first digit was the instruction and the second two digits were the address of memory to operate on. The only re…

How To Care If BSD, MIT, or GPL Licenses Are Used

The two recent posts about some individuals' choice of GPL versus others' preference for BSD and MIT style licensing has caused a lot of debate and response. I've seen everything as an interesting combination of very important topics being taken far too seriously and far too personally. All involved need to take a few steps back.

For the uninitiated and as a clarifier for the initiated, we're dealing with (basically) three categories of licensing when someone releases software (and/or its code):
Closed Source. Easiest to explain, because you just get nothing.GPL. If you get the software, you get the source code, you get to change it, and anything you combine it with must be under the same terms.MIT and BSD. If you get the software, you might get the source code, you get to change it, and you have no obligations about anything else you combine it with.The situation gets stickier when we look at those combinations and the transitions between them.

Use GPL code with Closed S…