We’re Ready to Rock…

… but there are some changes to Rock, Paper, Azure we need to discuss based on our test week.   First things first:  I highly recommend you download the latest Bot Lab and MyBot project here.  For the most part, old bots bots will continue to work, but since this was a test round anyway, I highly recommend you upgrade – there are a few edge cases that might break bots, or cases where a bot doesn’t do what you think it would.  Let’s discuss all of these changes we’ve made.  I’ll save the best for last. CanBeat and LosesTo – Don’t Use We re-scoped the CanBeat and LosesTo methods from the Move class to internal (from public).   Most people weren’t using them, and they weren’t really intended for outside consumption and we received a couple of questions on behavior.  The reason for the change is this – and some of this is historical:  the way the engine works is that it goes through a series of steps to determine a winner.   It will first look if a move can beat another move: 1: internal bool CanBeat(Move move) 2: { 3: if (!ValidMoves.Contains(GetType().Name)) 4: return false; 5:  6: if (!ValidMoves.Contains(move.GetType().Name)) 7: return true; 8:  9: return CanBeatLegalMove(move); 10: } So the RockMove implementation returns true if the move is scissors which is implemented in the RockMove class.  The original game had moves in different assemblies for multiple rounds, so the win determination path had to waterfall through, and examine rules to the game – such as whether or not you have any dynamite remaining.   The short answer here is there are cases where this will return unexpected results, so it’s best to just not expose them.  Performance wise, it’s better to have your own implementation, anyway.  If your bot is currently using this, sorry to say this is a breaking change. Game Summary At the top of the log file, you’ll now see a game summary that is helpful for info-at-a-glance.  It looks like this: Game Summary bhitney JohnSmith Points 953 (L) 1000 (W) Dynamite Used 45 100 Time Deciding (s) 0.04885 0.06507 Time deciding shows how much time your bot has used for the entire round.   This is interesting to see how your bot compares to others, but, it’s also useful for timeouts which is below.   Timeout   The server has some strict timeouts – we’re always tweaking the exact logic and we’re hesitant to give too much information because, in a multithreaded environment, the time slice each bot has isn’t exclusive.   But, your bot has a maximum of 1 second (subject to change) per match.  Typically that is no problem, as you can see in the game summary.  Once your bot crosses the 1 second timeout, your bot will stop making moves (essentially forfeiting the rest of the moves).   Server Messaging   In the log file, you’ll now see more clear messaging if something happened – for example, if a player threw dynamite but was out of dynamite, the log will indicate this next to the score.    ExceptionMove   We standardized the error moves to “ExceptionMove.”  If a player times-out or throws an exception, their last move will be an ExceptionMove.  This is visible in the log, and detectable like so:   if (opponent.LastMove is ExceptionMove){ //player threw an exception or timeout} This is a good time to mention that the opponent’s LastMove is null on the first move.  Also, if a player throws “illegal dynamite” (that is, throws dynamite when he/she is out) their last move will be Dynamite.  It’s up to you to figure out they were out of dynamite!   Fresh Upgrade   One of Azure’s strengths is flexibility in deployment – when deploying, you have an option for an in-place upgrade, or can deploy to staging and do a VIP (virtual IP) swap that allows you to seamlessly move a new deployment into production.    Because of the significant changes to our Bot Lab and new features, we recommend deleting the old deployment first, and then deploying the new package and not doing an in-place upgrade.   Player Log   And now the best part!  There’s a private player log you can write to.  This information will be appended to the bottom of the game log – but it’s only visible to you.  We’re still testing this feature, but it should be helpful in isolating issues with your bot.  To write to your log, you can do something like:   1: if (!you.HasDynamite) 2: { 3: you.Log.AppendLine("I'm out of dynamite!"); 4:  5: //opponent's log is always null! 6: if (opponent.Log == null) { } 7: }   Note:  Your opponent’s log is always null, so don’t try it!  Also, logs are limited to a total of 300k – this should be more than enough, but once the log passes this mark, the engine won’t write to the log (but no exception is raised).

RPA: Why is my Bot Rejected?

We’ve had a few people ask about getting the following message when submitting bots: Bot contains invalid calls. Please review the official rules for more information. In short, this message means the bot didn’t pass the static analysis tests.  On the About the Challenge page, you’ll see this: While this list is subject to change, we do not allow any classes/methods from System.IO, System.Net, System.Reflection, System.Threading, System.Diagnostics, or System.GC. That list is subject to change, and there are a few other red flags like P/Invoke or unsafe code.  Sometimes, these are caused by what would otherwise seem innocuous, such as calling GetType on an object – but that’s a reflection call, so would trigger the static analysis. Another occurrence:  analysis will look for the presence of such code, not if it’s reachable.  In one case, the code was never called but still present in the bot. So, if you’re getting the above message, look for those items and if you have any questions, leave a comment here or send us an note through the www.rockpaperazure.com site!

Rock, Paper, Azure: Why US Only?

Over the past few days, we’ve gotten many requests from those outside the United States who would like to play Rock, Paper, Azure.  Some have even said, “I don’t care about the prizes, I just want to play!”   So what’s the deal? If we could simply enable the contest to be worldwide, that would be awesome!    But, when prizes are involved, it’s not a simple matter.   There isn’t an easy mechanism by which to say, “it’s ok to enter, you just can’t win.”  Just to provide a little transparency here, there are legal hurdles and frankly, the team that put this together is only a few people doing something part time.   Because we’re in the U.S. subsidiary, our main focus (naturally) is on U.S. – not that we want to exclude anyone, of course.  So what’s next?  First, we’re working with our colleagues in other subsidiaries to enable this in more countries, if at all possible.  It won’t happen on week 1, but hopefully we’ll get there over time.   If you know your local DPE evangelism team, be sure to contact him or her and let him know you’d like to play – if you don’t know who that is, leave a comment here in my blog. 

Rock, Paper, Azure Deep Dive: Part 1

If you’re not sure what Rock, Paper, Azure (RPA) is all about, check out the website or look over some of my recent posts.   In this series of posts, I want to go into some of the technical nuts and bolts regarding the project. First, you can download Aaron’s original project on github (here and here).   The first project is the Compete framework, which is an extensible framework design to host games like Rock, Paper, Scissors Pro! (the second project).    The idea, of course, is that other games can be created to work within the framework. Aaron and the other contributors to the project (I remember Aaron telling me some others had helped with various pieces, but I don’t recall who did what) did a great job in assembling the solution.   When moving it to Windows Azure, we had a number of issues – the bottom line is, our core requirements were a bit different than what was in the original solution.   When I describe some of these changes in this and other posts, don’t mistake it for me being critical of Aaron’s project.   Obviously, having used it at code camps and the basis for RPA shows I have a high regard for the concept, and the implementation, in many parts, were quite impressive. So, if you download those two projects on github, the first challenge is getting it up and running.  You’ll see in a few locations there are references to a local path – by default, I believe this is “c:\compete”.  This is the local scratch folder for bots, games, the db4o database, and the logfile.  Getting this to work in Windows Azure was actually pretty straightforward.   A Windows Azure project has several storage mechanisms.  When it comes to NTFS disk I/O, you have two options in Azure:  Local Storage, or Azure Drives.   Azure Drives are VHD files stored in Azure Blob Storage and can be mounted by a VM.   For our purposes, this was a little overkill because we only needed the disk space as a scratch medium: the players and results were being stored in SQL Azure.  The first thing we needed to do to get local storage configured is add a local storage resource: In this case, we just created a local storage area called compete, 4GB in size, set to clean itself if the role recycles. The next step was to remove any path references.  For example, in Compete.Site.Models, you’ll see directory references like this: Because there’s so much disk I/O going on, we created an AzureHelper project to ultimately help with the abstraction, and have a simple GetLocalScratchFolder method that resolves the right place to put files: Now, we inject that call wherever a directory is needed (about a half dozen or so places, if memory serves).   The next major change was deciding: to Spark, or not to Spark?  If you look at the project references (and in the views themselves, of course), you’ll see the Spark view engine is used: I’m no expert on Spark but having worked with it some, I grew to like its simplicity: The problem is, getting Spark to work in .NET 4.0 with MVC 2 was, at the time, difficult.  That doesn’t appear to be the case today as Spark has been revived a bit on their web page, but we started this a few weeks earlier (before this existed) and while we recompiled the engine and got it working, we ultimately decided to stick with what we knew best. The end result is the Bot Lab project.   While we’re using RPA with the idea that it can help others learn about Azure while having fun, it’s also a great example of why to use Windows Azure.  The Bot Lab project is around 1 MB in size, and the Bot Lab itself can be up and running in no time (open solution, hit F5). Imagine if you wanted to host an RPS style competition at a code camp.  If you have a deployment package, you could take the package and host it locally if you wanted, or upload it to Windows Azure – hosting an extra small instance for 6 hours at a code camp would cost $0.30.   Best of all, there’s no configuring that needs to be done (except for what the application dictates, like a username or password).  This, if you ask me, is one of the greatest strengths behind a platform as a service.

RockPaperAzure Coding Challenge

I’m pleased to announce that we’re finally launching our Rock, Paper, Azure Challenge! For the past couple of months, I’ve been working with Jim O’Neil and Peter Laudati on a new Azure event/game called Rock, Paper, Azure.  The concept is this:  you (hopefully) code a “bot” that plays rock, paper, scissors against the other players in the game.  Simple, right? Here’s where it gets interesting.  Rock, paper, scissors by itself isn’t all that interesting (after all, you can’t really beat random in a computer game – assuming you can figure out a good random generator!), so there are two additional moves in the game.  The first is dynamite, which beats rock, paper, and scissors.   Sounds very powerful – and it is – however, you only have a few per match so you need to decide when to use them.   The other move is a water balloon.  The water balloon beats dynamite, but it loses to everything else.   You have unlimited water balloons. Now, with the additional rules, it becomes a challenge to craft an effective strategy.   We do what we call “continuous integration” on the leaderboard – as soon as your bot enters, it’s an all out slugfest and you see where you are in near real time.   In fact, just a few minutes ago, a few of us playing a test round were constantly tweaking our bots to defeat each other – it was a lot of fun trying to outthink each other. Starting next week, we’ve got some great prizes on the line – including Xbox systems, Kinect, and gift cards – so be sure to check it out!   The project homepage is here: http://www.rockpaperazure.com See you in the game!

My Apps

Dark Skies Astrophotography Journal Vol 1 Explore The Moon
Mars Explorer Moons of Jupiter Messier Object Explorer
Brew Finder Earthquake Explorer Venus Explorer  

My Worldmap

Month List