Top Reasons for Bot Rejection

Just a quick tip for those in the Grand Tournament.  There are 2 very common reasons we’re seeing bots get rejected – we’ll call it the red text of death that appears when you submit a bot, but it fails code analysis.  If all you see is “Bot Successfully Uploaded,” then move along, nothing to see here.

The most common are coders adding debugging statements into their code.  We do block the Diagnostics namespace (among a few others), so it’s quite likely any debugging code will trigger a failure.   If you’re deep into a bot with a lot of debug code, I recommend an #ifdef around these sections to remove them from release builds.

The second most common reason are locks.  Locks, as you likely know, are syntactical sugar around a Monitor, which resides in the System.Threading namespace.  We don’t allow that, either.   But many may ask, “Why no locks?  Is it not a good practice to do this around a critical section of code?”   Not in this case.  Your bot shouldn’t be using statics since we can’t guarantee when or how many instances of your bots will be loaded at any given time, and I can guarantee this will burn you.   Your bot also can’t create threads, so locking is irrelevant in this case and would only slow things down.

In many cases, these errors are triggered in bots where folks are rolling their own random number generator.  While you don’t have to use it, we highly recommend you use the Moves.GetRandomNumber() method.  It works the same way, but we guarantee unique generation for bots and we do the locking in the engine to ensure this.  There’s a fun story behind that one.

Good luck!