Designing your own Game Servers for Asynchronous Play (Postmortem)

Making your own game servers is fairly significant undertaking, so now that we’ve released our own game servers and started using them for our games – Hive, Khet 2.0, and Reversi – I thought I’d share a brief postmortem to help anyone else considering going this route at some point.

Why host your own Game Servers?

Obviously, a good starting point is to determine if it even makes sense to host your own game-servers. Our first releases, “Hive” and “Khet 2.0″ both shipped using Steam’s networking. In fact, Hive had a previous version running on Xbox 360 which used Xbox Live.

Most common platforms have some built-in networking. Unfortunately, even if you use something like Unity, you’ll spend a lot of time cramming in each platform’s different concept of networking into your game. More on that later.

All of these platforms take a while to integrate but significantly less time than writing your own servers from scratch. They’re usually free to use, and are built to scale to many users.

Due to the time-savings, my recommendation is: start off using the networking on the platform you plan to release on, unless you have a strong reason not to.

Games are not a sure thing, so don’t go investing in making your engine flexible before you’ve found out that you’ve made the right game(s)! If it turns out you were right & there actually is some demand (like there was for our board games), you can spend the months re-writing while players already have your game and are enjoying it. Also, you’re probably earning some income during this time which can help fund the creation of your game servers.

So what would be a good reason to write your own servers? Here are the main reasons that impacted my decision:

  1. Technical limitations: Neither Steam (nor Xbox Live, if I recall) had support for asynchronous play: allowing a game to persist even while neither player is online. This type of thing was really important for turn-based games like ours.
  2. Cross-platform capabilities: Our games were already cross-platform in the sense of being on Windows, Mac, and Linux… but they were still tied to a single gaming platform: Steam. This is currently only available on desktops / laptops / SteamOS Consoles, but wouldn’t it be cool to be able to play from PC to mobile some day? In a game without coordination (like turn based games) it is completely fair to play across these form-factors without giving either side an advantage.
  3. Minimizing re-writes during massive porting: We didn’t have to rewrite our code to make our Mac and Linux versions of our games, they all ran with Steam. However, if we expand to mobile in the future, or go back to consoles again, we’d have to re-write to iOS’s Game Center, Google Play, PlayStation Network, etc.. With our own game-servers, not only will players be able to compete across those systems, but we won’t need to do a rewrite! As long as the system gives us access to make http requests, we’re all set!
  4. More DRM-free: Many gamers are cautious about buying games with DRM because they’re afraid that petty corporate overlords are going to arbitrarily yank their access to the product they legitimately purchased. It has happened plenty of times in the past. While we haven’t added any DRM to our games (and even created a DRM-free mode to make the game run as smoothly as possible even without Steam), we were still bound to requiring Steam for Online Play. Now we don’t use their game servers. We currently still use Steam Lobbies, but once we write those out, we will have no requirement for any 3rd-party platform at all. We’ll be completely DRM-free. #feelsgoodman

How does it work?

This section will be a brief overview of how the system actually works.

Connecting Steam Players to BlueLine Cloud

It should be very simple for users to get playing. An experience that I enjoyed as a gamer was PlayFab’s signup for Planetary Annihilation. So I modeled our signup after that (it’s a single, small form that you only ever see once). Apparently, I oversimplified a bit by going this route (see: Mistakes section below), but it felt solid & was a decent starting point.

The form gives the option to add an email address and password. This keeps the data from being locked into your Steam account. Additionally, we’re keeping the door open for letting users have email alerts when it’s their turn (Steam Notifications are great, but you only see them when you’re on Steam).

After the initial setup, we use the user’s Steam authentication to automatically connect them in the future. Keep in mind: even if the user does not set an email/password to give themselves unlimited access later, we can still connect them.

Cloud Servers

Fortunately, we have a lot of web-background and have scaled large web-services before, so not having to learn all of that from scratch saved a ton of time.

We ended up structuring the system to run on Cloud Servers. That’s a fancy name meaning that you don’t own a specific piece of hardware, but rather you’re assigned a certain amount of resources & that can bounce around as some machines fail and others start up. They are easy to scale up, and in our case they happened to be the least expensive introductory option also – which is great! I’ve been pricing and re-pricing them since AWS’s early days, hoping the scales would finally tip!

We’re paying in the ballpark of $20/month to start out, and things are running smoothly. If things start to slow down, it’ll likely be another $20/month for more power, and so-on.

Update: Someone asked about the exact stack. It’s a private hosting company I’d worked with before, and my starting instance is 2GB Ram / 2 CPUs / 1 dedicated IP (need it for some SSL stuff we do). It’s not an “image” like in AWS, the server just spins up running CentOS, so I will configure new instances with normal bash scripts.

The actual stack of the game-servers is a REST-like PHP API that’s backed by a mySQL database.

Game Data

Instead of storing the data in some custom format, we wanted to make sure the data would be easy to use across very different platforms, and even publicly accessible at some point.

Therefore, we stored the “game settings” in JSON blobs, and the “ply histories” (the list of plays that the players have made in a match) are in the most standard format we could find for each game.

This makes the data human-readable in the database (easier for debugging) and more standardized so down the road we could open an API and people could make their own game-reviewing / visualization / statistical analysis programs easily.

Here is some example data:

Mistakes!

We rolled this out with Reversi (a new game with a smaller audience) then fixed it a bit and rolled it out to Khet 2.0 (which is a few months older and has a bigger audience) and then we got more feedback and did more fixes before rolling it out to Hive which is our oldest Steam game and has the largest built-up audience.

Fortunately, I think we ironed out most of the wrinkles before the Hive release, but here were our most notable errors.

Communicating about Accounts

When we updated Khet 2.0 to have async, we got some users really upset because they had mistakenly thought we added DRM.

This blind-sided me a little because the dialog only asked for an email address and a password, which I thought were super-ubiquitous these days. I think it was mostly a visceral reaction to seeing a dialog box with the name of our game servers “BlueLine Cloud” on a game called “Khet 2.0″. If they didn’t notice the “BlueLine Game Studios” splash screen, that sounds like it might be a third-party. For all the user knew, this third-party might be sending an email-confirmation link to that address (so it would have to be valid) and then using it for nefarious purposes.

Keep in mind, this dialog was mostly well-received, but if the experience is super negative for some of your players to the point that they’d quit playing your game (which this user would have if we hadn’t been able to explain things better in the forum), it’s worth reworking. Not all of your players will be willing to go out of their way to express their disappointment when something is broken. So if you hear something from two users, it’s likely that many more had the same thought.

We reworked the entire signup so that you never have to give us an email/password if you don’t want to. Furthermore, if you change your mind, you can set up the email/password combination later-on.

Even though the underlying system is the same… we think that changing the wording and making the “No Thanks” option will keep players from being scared, confused, or otherwise inconvenienced by the dialog.

Initial version:
2015-01-10_simulated

Improved version:
2015-05-27

The second one is much more clear that the email address really is optional and it’s only UNlocking your data, not adding additional locks.

Estimation!

Still in the “what we did wrong” section. You may hear “estimation” come up as a weak point in many post-mortems… but that’s something that we’re actually usually quite good at. I’m not being glib here, our side-business (that we originally made for internal use) is a Burndown Chart tool for Trello. I married a Project Manager / Scrum Master. …estimation is usually one of those things we really excel at – because we actually nerd out on Project Management a bit.

However, this one went way off the rails. In late January, here’s me embarrassingly announcing that it would be out in a couple of weeks. When I tease launch-dates I tend to build in some buffer for things going wrong (and I had done just that). In the end, I underestimated the hours for the initial release by a factor of three! Furthermore, there were so many finicky edge-cases, that we ended up completely changing the rollout plan. We first rolled out on our new game Reversi (which has the most simple “plyHistory” format, so it was the safest), but then we saw that there were a bunch of things that needed to be changed or improved. It took weeks to finish those bugfixes & improvements and roll out on our next most-complex game: Khet 2.0… then we had external causes that made us delay making such a large (and therefore risky) update to Hive… so we polished it for a couple more weeks.

In the end, the Async that was teased to come out in “a couple of weeks” just came out May 26th, four months after that announcement. Someone fan me down, I’m blushing!

This experience hammered into me what might be a law of physics: when doing anything with networking, make a really conservative estimate, then triple it. Then plan for additional time for bugfixes after launch.

Xbox networking, Steam networking, and even writing our own gameservers, all took way longer than expected. These type of tasks aren’t the sum of their anticipated parts because you will fall into several rabbit holes where you can spend days debugging things that make no sense at all.

Furthermore, documentation always seems to be horrible for anything networking related. My guess is that there just aren’t many people who end up using it very deeply. People design the systems, do some Hello World apps while they write the docs, then the broad & wild internet makes a mess of our perfect theoretical world!

To reiterate: For anything related to networking: estimate conservatively, then triple it.

Conclusion

I hope that gave a good general overview of the types of things we had to do to switch to our own game servers, why we did it, and what this lets us do in the future.

If you have any questions, feel free to leave comments here or contact me through any of the other methods on the site (these days, I’m pretty accessible through twitter too @bluelinegames).

Cheers!

How to slow your framerate in XNA / Monogame / FNA

Sometimes, you may need to slow-down your framerate to test certain behavior in your game/app as it would appear on really bad hardware. The following snippet lets you easily tweak a framerate at runtime.

Since Update() gets called every tick, just put this in any GameComponent and you should be good to go. Press “+” to increase the delay (and thus decrease the framerate), or “-” to decrease the delay.

You can comment out this whole method when you’re not using it, or just leave it like it is so that it only builds in DEBUG mode, etc..

Introducing “BlueZebra” a GPL command-line Reversi AI

blueZebra
Today, we’re releasing some Open Source freeware! As part of creating our next game (Reversi for PC, Mac, and Linux on Steam), we wanted to make use of some of the great AI that’s already been written for Reversi over the years.

One of the most respected Reversi AI programs is WZebra by Gunnar Andersson. WZebra hasn’t been updated since around 2005, but it was released under GPL and included a command-line tool for solving the end of a bunch of games (scrZebra) as well as some other analysis tasks. What it didn’t include, was a way to access WZebra’s AI via command-line to easily get the best move for a specific board layout. That’s exactly what BlueZebra is: BlueLine’s customization to allow command-line access to WZebra AI.

Here is a zip of the project: download BlueZebra*. Since it is based on a GPL project, it is itself released under a GPL license. To make changes, use the Visual Studio solution and recompile. We also updated the Makefile to work with modern systems (it was made when everything was 32 bit) and made the Makefile compile on OSX, not just Linux.

Run “blueZebra.exe ?” to get help info for each of the parameters, but to give you an idea of how you can pass everything in & get back a move from the AI, here is example usage:

prompt> blueZebra.exe -cli -b 1 -e 0 -line 2 -scores 0 -depth 24 26 28 -board -----X------X------XOX-----OO-----OXO------X-------------------- -turn O
c6

“c6″ is the move that the AI returned for White to play.

*: hashes of the zip file…
md5: af7733545b7bb21aed9399c5f3f08f6d
sha1: 30b7d0379f318c6974460d066944a11fcc3215fe

Why aren’t there more board games on PC? …Tablets? …Xbox?

I often hear the question of why there aren’t more board games on a certain platform. The short overarching answer is just that digital board games are a niche-market, so big game companies aren’t often willing to take the risk of making them.

However, I think there are some hints as to where board games will start showing up in the near future.

I’ll be working with the assumption that other than a few outliers (Monopoly, Risk, etc.) that are made by EA or some other huge publisher, most digital versions of board games will likely be made by indies.

Consoles?

This is a complicated one, but I think that we’re not going to see many new board games on consoles in the near future. The old-gen consoles were a mixed-bag for independent developers. Xbox 360 was really the only one that indies could easily get into. BlueLine could probably get into all of them at our current size, but it excludes any first-timers. Additionally, after Microsoft announced that they were no longer supporting XNA, the amount of games that sold on Xbox Live Indie Games (their deeply-hidden indie channel) dropped off a cliff.

What about the current generation? Sony has gone out and recruited a bunch of indies to build games for the PS4… but I doubt they’ll continue doing that much longer after launch – they’re flat-out funding games and that’s a big financial investment. Xbox is again trying to be accessible to indies with their “ID@Xbox” program (which we’ve been accepted to), but there are two major things holding back board games from Xbox One*. First: it’s expensive. Unlike other indie-friendly locations where the startup costs are around typically a couple of hundred dollars, a very lean Xbox One indie game runs upward of $5,000. Secondly, even in 2014, Xbox 360 still has about twice as many sales as Xbox One. A market with high costs and low sales isn’t great for niche games. It’ll be a while before the install-base of new consoles grows enough that a bunch of board games start popping up on there.

PC, Mac, Linux

There are a decent number of board-games coming to PC (especially on Steam) over the past year or so. I think more will continue to show up, just slowly. We released Hive and Khet 2.0 this year, and just our two-man team still hasn’t been bumped off the list of 10 Newest Releases tagged with “Board Game”. It’s entirely possible that our next game, Reversi will bump Hive off of the most-recent list, if no new board games come out in January or February.

PC, Mac, and Linux are probably the best platform for selling digital versions of board games at the moment.

Mobile

Smart phones are a great form-factor for many board games, and a bunch of games came out over the year since they became popular. However, many have had a rough time with sales in recent months/years. Most digital board games are made by fairly small devs: we survive on the Steam store’s visibility and we’d have a really rough time in mobile because you need to be on the “top downloads” list to get any traction there. Board games are usually too niche for that to happen organically and it’s too expensive to buy the number of downloads needed to fake it. This “faking it” is the current modus operandi for most mobile games. They buy huge amounts of downloads (via ads in other games) and hope that it generates enough of a following to get them to the Top Downloads list where they get to see if they’ll actually get traction. That’s usually not a great strategy for board games!

Tablets

Board gamers often lament the lack of titles on tablets – which seem like the most ideal medium for digital board games. However, I think that’ll happen even more slowly. Even though tablets are a fantastic device for playing games, the market is currently (unfortunately) just an afterthought. The games on there now are mostly because it’s easy to go to tablets from a mobile game. However, the market for tablets themselves are really small (around $3.6b compared to about $20b for PC). The reason market-size matters is just that it’s an indicator of how many games you can sell if you have great exposure. Tablets are a just a very small market at the moment, and aren’t expected to catch up to PC for about another 5 years.

We’ll get our games on tablets eventually… but it’s going to take a while. Hopefully not more than a year or so!

HTML5

It’s really hard to monetize a straightforward board game in HTML5 at the moment. If you saw Goko (who got the license to Dominion) and thought that they would ever be able to earn enough to support their big dev team & pay back all that venture capital… you probably weren’t paying attention to the margins in this industry. ;) Nobody has made it work correctly yet. The only board game sites that are currently surviving seem to be those that don’t make any money & don’t pay any royalties. Since most of those are hobbies, you can probably expect a handful of very basic implementations to continue to come out… just not with paid licenses.

The Future

What I’m most excited for in the future is cross-platform online play. It’s super time-consuming to get it working (in part because you literally need to create the game multiple times**) but it should be a lot of fun and make it easier to find online games with other people instead of having an already-niche community silo’ed across several devices, as is currently the case with Hive which currently has different 5 different online communities.

Do you know of any digital board games coming out in the near future? Let us know in the comments below.

*: There are actually three, but one of them is technical and it’s covered by an NDA so I can’t talk about it until it’s fixed.
**: I realize that Unity/MonoGame/etc. take a ton of work away from porting, but if you want the game experience to be really good, it should be designed once for consoles (with gamepads) then another way for PC/Mac/Linux (to allow gamepad and/or mouse/keyboard) and have another – probably significantly different – interface for touch/drag devices with unreliable screen resolutions.

Our next game: Reversi!

Reversi
About a month and a half ago, we released Khet 2.0 on Steam. After a few updates (fixes & new features) then last weeks release of the ‘Eye of Horus’ Beam Splitter expansion… we’re spending part of our time on our next game: Reversi!

It will be on Steam and we plan to support PC, Mac, and Linux at launch & we currently have no plans for any DLC.

If you’ve been following along on our @BlueLineGames twitter account, this might not be a huge surprise to you. We were tweeting a picture of our passing unit-tests in mid-summer. Yup, while we were ironing out the details of the licensing on Khet, we did about a month of work on Reversi! So we’re off to a great head-start.

As an indie-dev, releasing a game in the middle of the holiday season seems a bit quixotic, so we’re not going to rush it. In parallel, we’ll be doing upgrades to add new features to our engine – which will benefit Reversi as well as our already-released games Hive and Khet 2.0.

Some may be wondering about why we’re going with the classic “Reversi” name rather than the more modern licensed name. Honestly, we like the newer name & the community that’s been built around it. We spent months chasing after that license and we want to (and think we may) get it one day. In the meantime… Reversi! :)

Detecting loops with the Beamsplitter

We recently released Khet 2.0 for PC, Mac and Linux and have been working on the Beamsplitter expansion piece (among other things).

The Beamsplitter piece lets the laser pass through and also reflects it at a 90-degree angle. This changes the concept of the laser from being a linked-list to being a directed-graph. This makes most of the code become recursive, but also leads to an interesting challenge: easily detecting infinite-loops.

We could use a heavy-handed approach of storing a record of every beamsplitter and every side that a laser comes out of, then comparing it to results of any new beamsplitter hits, to see if anything changed. However, it turns out there are some generalities that may let us do it more gracefully.
eye of horus beamsplitter diagram
In this diagram, the laser source at “A” gets reflected to “B” and also travels through to “C” while the direction “D” is not affected yet. Regardless of the rotation of the beamsplitter, if we follow this key, the following rules will always be true if a laser hits the Beamsplitter again on any of the 4 surfaces:

  • “A”: If “A” is hit (which I’m not sure is possible since I think it would require a loop to already have ended), then nothing changes. The inbound laser can be considered a “closed loop” ending.
  • “B” & “C”: If either of these spots are hit, then there will be a new exit-point at “D”. Any future hits to this same Beamsplitter will be “closed loops” regardless of where they hit.
  • “D”: Hitting here has used up the last junction and is a “closed loop”. Any future hits to this same Beamsplitter will be “closed loops” regardless of where they hit.

Also convenient is that we only need to detect loops at Beamsplitters. This will let some laser-segments overlap each other occasionally, but they will only overlap once before hitting a Beamsplitter, so there is no danger of infinite-looping as long as this logic is enforced at each Beamsplitter.

That was just a random tech rambling. Hope it was interesting! :)

EDIT: Incidentally, I finished writing the laser logic and the brute-force approach ended up being really simple & with no real overhead so I just went that way. Oh well, I was proud of myself while I thought it mattered. ;).

Move Over Piracy… Theft Comes to Indies!

Yesterday we launched our second game: Khet 2.0 on Steam. As is usual with a Steam launch, we get a ton of requests (a couple dozen a day, probably) emailed to us for free “Review” copies for press.

Red Handed

I often had a sense that some of these people were maybe not legit, but life is busy so who has the time to really look into it? Well, my curiosity finally got the better of me. When a handful of requests in a row all seemed suspicious, I decided to compare the “from” email address to what was on YouTube and I sent a response to the real youtuber’s address. He confirmed that he was being impersonated.
2014-10-02_1144

So what?

Part of why I didn’t look into this before is that I figured the worst that could happen is some pirate (who probably wasn’t going to buy my game) would get my game for free. Turns out though, it’s a little more nefarious. Other devs have tracked these keys down to G2A* which is basically a market for illegally reselling keys**. So now people are taking keys for free and selling them to real gamers who are willing to pay money for your game. Developer makes a game… gamer pays for game… thief gets the money (and G2A gets a cut).

Therefore, if you don’t check into people at all before sending keys you’ll probably lose a few sales (not a huge deal) but you’ll be giving money to both the sketchy G2A as well as encouraging the theft to go on which takes money from away from other devs (and many of those devs can’t afford to lose a few sales).

Developer makes a game… gamer pays for game… thief gets the money (and G2A gets a cut).

Simple fix

Fortunately, once aware of the scam, this is super-easy to fix.

      Are you a gamer? Don’t buy from G2A.
      Are you a dev? Don’t “reply” to send the keys via email… instead go to the youtube page of the person and send it in a YouTube message (or to their listed email address).
      Are you a YouTuber? Add you email address to your about page (youtube protects it from spambots) and be prepared to get some keys in your YouTube messages instead of email sometimes. Sorry for any inconvenience (I know inboxes can be a mess)!
      Do you care? Spread the word. If gamers stop accidentally buying stolen keys & devs mainly send the keys out via YouTube, the thieves will move on to easier targets than indie games.

Boom, solved. It just takes a small process fix to avoid the issue entirely. Gamers are not your enemies. YouTubers are not your enemies. You don’t have to start being tightfisted with keys or anything like that. We just gave away over 100 games via @IndieGamerChick about a week ago for #GamesMatter and that went great!

Anywho… sorry for the slightly negative post. We love gamers! We love game devs! We love YouTubers & Let’s Players (and give them full permission to monetize videos about our games)!

Now back to regularly scheduled gaming! :D
– Sean

*: Disclosure: I know the author of the Polygon post in real life.
**: This statement has not been evaluated by the FDA. G2A claims it is legitimate because you could have an unredeemed Steam key for some legit reason (maybe if it was a gift?) but it is a widely held belief that most keys on there are either taken from bundles (which is against the terms of service of most bundles & of Steam), soaked up from contests, or stolen in the fashion described in this article.

Khet 2.0 launched on Steam!

big_feature
Our second major release, “Khet 2.0” is now live on Steam! Buy it once and play it for PC, Mac, and Linux.

Hit that link to the Steam page to read all about the game. Here I’ll just wax poetic about our history launching it…

Before we (Sean & Geoff) started making games together, we had another startup that we worked on together. After a while we sold that company, but even back then we talked about making video games someday. We kicked around all kinds of ideas and Khet was one of the earlier ones. I think Geoff actually introduced me to the game years before, at RIT, but my memory is a bit fuzzy on when he first told me about it.

I started reading a ton of indie game blogs in 2007 to learn more. It seemed like a really brutal industry & I didn’t want to go in blindly, take one swing for the fences and then have to go back to a day-job if it wasn’t a hit. Four years later when BlueLine couldn’t be postponed any longer, my devious plot to take gaming by storm was based around creating a number of digital versions of award-winning board games. We had two games in mind that we thought we could do great. This is a for-reals photo from December 2011 after Geoff and I just finished playing board games at an Eat N’ Park late one night (they’re awesome for tolerating that kind of thing):
blueline_eatnpark_20111226
With today’s launch, we finally managed to ship the second of those games that we were playing nearly 3 years ago and dreaming of converting to a digital version!

It’s been a long ride, and we even had a false-start. We got about half-way making Khet for Xbox 360’s indie store when Microsoft announced that it would stop supporting XNA (the language used to make those games) and sales immediately tanked on that whole marketplace. We had to shelf the game for several months as we switched gears to port Hive – and our entire board game engine – to run on PC, Mac, and Linux with Steam networking instead of Xbox LIVE. As you can imagine, it was a bit tricky getting the PC, Mac, Linux license from the game designer after not shipping on Xbox 360. We shipped today though… reputation restored! :D

That’s our very long backstory that’s probably mainly interesting to others devs or those thinking about starting some business (possibly gaming related) of their own.

If you have any questions, leave us a comment! We’re allowed to share most info. Now, go buy Khet 2.0 on Steam! :D

Cheers,
– Sean

Adding some randomness to turn-based AI (2 of 2)

We just released a big update to Hive which included some great visual changes as well as a number of AI improvements. One of the interesting AI changes was the addition of a bit more randomness to the AI’s decisions, with minimal impact on the skill of the AI. This is the 2nd part in a 2-post series on the topic. If you haven’t read the first post of the series, I recommend that you at least skim it first.

Randomness on all moves

Even with a large number of random openings, it would be possible to run into similar situations down the road that would play out time and time again (Battlestar Galactica style). Since this repetition would lead to predictability but most randomness decreases the skill-level of the AI, we had to strike a balance. In order to make it so that full games diverge from each other significantly, but without weakening the AI too much, I came up with the concept of a “randomness quotient”. I don’t know if this already exists in Game AI or not, but it seems to be a good solution and that was the most appropriate name I could think of for it.

“Randomness Quotient” explained

The “randomness quotient” is a setting that will increase the randomness of the choices as its value decreases. Specifically, if the randomness quotient (which we will represent with the variable “Q”) is 7, then the engine will choose a ply other than the best move about 1/7 times (which is “1/Q” times). Of those instances where the best-scored ply is not chosen, then the second-best move will be chosen 1/Q times. Therefore, the odds of getting to the second best move and still choosing to consider the third-best scored move is ((1 / Q) / Q) which is the same as (1 / (Q ^ [move-number])). To figure out the opposite number (the odds of choosing move number N, rather than the odds that we’ll skip past it) we’d use a numerator of (Q-1). For example, the 8th best move would be chosen once in approximately ((Q-1) / (Q ^ 8)) moves. The more general equation is: ((Q-1) / (Q^N)) where Q is the randomness quotient, and N is the move number (as ranked by the heuristic evaluation method so that move 1 scores the best, move 2 scored the second best, etc.).

Even with a fairly high amount of randomness – such as a Q of 2, remember: low Q means high randomness – we would only see a move as bad as the 8th move in 1 out of every (1/(2^8))= 256 moves.

These occasional less-than-stellar moves are essentially simulating a human player occasionally losing concentration.

In case the math was a bit confusing there, we can show the effects of this algorithm visually. Each bar in the chart is the move-number where the moves are ranked from the best-scoring on the left to the worst-scoring on the right.

randomnessQuotient_2In the first chart, there is a very low randomness quotient of “2” which is NOT recommended in realistic play, but it’s still a great example to visualize how this works. You’ll notice the first move is chosen 1/2 of the time. Since the other 1/2 of the moves are also cut in half, then the second-best move (move index 1) is only chosen in 1/4 of the instances.

randomnessQuotient_7In this second chart, we have a higher randomness quotient of 7 which represents a more realistic setting. This setting doesn’t add a ton of randomness to any given move, but over the length of a normal game, this should introduce enough randomness to steer any similar games apart from each other. As you may have recognized, these charts are an example of exponential decay.

In our code, we used lower Q values to give more randomness to weaker levels of AI to “nerf” them a bit, while giving them more variation at the same time. The higher levels of AI still have a modestly high randomness quotient since we want a little randomness – currently Q is around 8 or 9 – but we may continue to tweak that from experience.

Randomness Quotient pseudocode

This is almost the exact code from our Minimax engine where we implement randomness based on the Randomness Quotient. It’s not that much code!

Conclusion

The addition of randomness to the AI engine has greatly increased the replay-value of the AI in Hive. Hopefully this concept can be useful to some other developers as well. This change was released as a free update two days ago, along with a significant batch of visual updates and about a half-dozen other AI improvements that we’ve made over the past week or so. If you have the game, check them out… if you haven’t bought Hive yet, please support us by grabbing your copy on Steam today!

As always, please let us know if you have any feedback about the changes in Hive, or if you have any questions about this post! If you’ve implemented randomness in your own AI in another interesting way, please leave a comment for the other readers – and myself – to learn from.

Thanks!

Hive Visual Upgrades!

classictiles

Today we are happy to say that we have launched a new build of Hive. This build has a number of AI tweaks that Sean mentioned in the previous post and will be talking more about in an upcoming post (edit: now posted). Another large piece of this update is an overall upgrade to the in-game look. We have received a large amount of feedback of how people would like to see the game represented, and we have listened.

First and foremost, we have upped the overall realism of the game pieces by making them to scale with the real life game pieces. The dimensions of the in game tiles should mimic the real life tiles precisely in proportions. This gives you a much more familiar look. We also have set the initial orientation of insects on the tiles to match the real world tiles to add to the familiarity.

fog

Another huge update you will notice immediately is that we have added a virtual tabletop. No longer do the pieces seem to float in space, they now rest on an unending virtual wooden table complete with shadows, giving a much more real world feel. We hope in the future to expand this even a little further and allow you to select from a variety of surfaces to play on. We may even go as far as allow custom table tops.

Also, to bring the game a little further into the real world, we switched from an orthographic camera to a perspective camera to give the game a little more sense of depth.

Finally, we tweaked the game piece HUD just a bit to give the game a little more room to breathe and to show off the new tabletop below just a little bit.

carbontiles

We hope you enjoy the updates!