Getting Ready to Rock (Paper and Scissors)
We’re gearing up for something that I think will be truly exciting – but I’m getting ahead of myself. This is likely going to be a long series of posts, so let me start from the beginning.
About a year or so ago, at the Raleigh Code Camp, I stumbled into a coding competition that was run by James Avery and Nate Kohari during a few hours in the middle of the day. The concept was simple: write a program that plays “Rock, Paper, Scissors” – you would take your code, compiled as a DLL, and upload it to their machine via a website, and the site would run your “bot” against everyone else. Thus, a coding competition!
I was intrigued. During the first round, I didn’t quite get the competition aspect since return a random move of rock, paper, or scissors seems to be about the best strategy. Still, though, you start thinking, “What if my opponent was even more lazy and just throws rock all the time?” So you build in a little logic to detect that.
During round 2, though, things started getting interesting. In addition to the normal RPS moves, a new moved called Dynamite was introduced. Dynamite can beat RPS, but you only have a few to use per match. (In this case, a match is when two players square off – the first player to 1,000 points wins. You win a point by beating the other player in a single ‘throw.’ Each player has 100 dynamite per match.)
Clearly, your logic now is fairly important. Do you throw dynamite right away to gain the upper hand, or is that too predictable? Do you throw dynamite after you tie? All of a sudden, it’s no longer a game a chance.
Now enter round 3. In round 3, a new move, Water Balloon, is introduced. Water Balloon can defeat dynamite, but loses to everything else. So, if you can predict when your opponent is likely to throw dynamite, you can throw a water balloon and steal the point – albeit with a little risk.
This was a lot of fun, but I was intrigued by the back end that supported all of this – and, from a devious viewpoint, the security considerations which are enormous. James pointed me to the base of the project, available up on GitHub by Aaron Jensen, the author of the Compete framework (which is the underlying engine) and the Rock, Paper, Scissors game which uses the Compete engine.
You can download the project today and play around. At a couple of code camps in the months to come, I ran the same competition, and it went pretty well overall.
So, what does this have to do with anything, particularly Azure? Two things. First and foremost, I feel that Azure is a great platform for projects like this. If you download the code, you’ll realize there’s a little setup work involved. I admit it took me some time to get it working, dealing with IIS, paths, etc. If I wanted to run this for a code camp again, it would be far easier to take an Azure package at around 5mb, click deploy, and direct people that site. Leaving a small instance up for the day would be cheap. I like no hassle.
The other potential is using the project as a learning tool on Azure. You might remember that my colleague Jim and I did something similar last year with our Azure @Home series – we used Azure to contribute back to Stanford’s Folding@home project. It was a great way to do something fun, useful, and educational.
In the coming weeks, we’re rolling out a coding competition in Azure that plays RPS – the idea here is that as a participant, you can host your own bots in a sandbox for testing, and the main game engine can take these bots and continually play in the background. I’m hoping it’s a lot of fun, slightly competitive, and educational at the same time. We’ve invested a bit more into polishing this than we did with @home, and I’m getting excited at unveiling.
Over the next few posts, I’ll talk more about what we did, what we’ve learned, and how the project is progressing!