Banking Boot Times

One of the new features that was introduced yesterday was Banking Boot Times. This feature replaced the old Sliding Boot Times feature. While they act fairly similarly, Banking Boot Times gives more control and should be much easier to understand.

The problems with Sliding Boot Times

Let’s start by understanding what the problems were with Sliding Boot Times. Sliding Boot Times averaged out a player’s play speed for the last 10 turns, and then compared this average with the boot time to determine if a player was bootable.

One problem with this approach is that it could cause a long delay if a quick player stopped playing. For example, if the boot time is set to 24 hours, and a player takes their first 10 turns quickly (say, within an hour) then they would not be bootable for over 10 days! While it’s good to reward a player who plays quickly, giving them 10 days in a 24 hour game is too much.

This naturally leads to making your boot timers lower than they would be without Sliding Boot Times. For example, if you set an 7 hour Sliding Boot Time, this makes the maximum boot time becomes 67 hours. This is more reasonable, although still a tad high. But the bigger problem with this strategy is revealed in the early turns of the game. If the game happens to start right as someone is going to bed, they’ll be bootable before they wake up. A 7 hour Sliding Boot Time works in the long run, but is too low for the early turns.

To combat this, Sliding Boot Times gave extra leeway for the first ten turns of the game. Basically, it “filled in” any missing data points with half of the boot time. While this solves the above issue, it also created a lot of confusion around the feature as players often saw early boot times that were significantly higher than they expected.

The solution

I thought for a while about how to solve these problems. Some good ideas were suggested on the forums, but I also wanted to make sure that the system was drop-dead simple to understand. I wanted to avoid anything with complex math formulas, since I want players to always feel like they know exactly what is going on (principle of least surprise). This is one place I failed when I first made Sliding Boot Times.

Banking Boot Times solves both of these issues. When banking boot times is enabled, whenever you take a turn under the boot time, you “bank” some of that time. You can then spend some of this banked time to go over the boot time in subsequent turns. The game creator can also configure what percentage of the difference that players bank.

Let’s look at an example. For now, let’s assume the game creator configured it to bank 100% of the time. If the boot time is set to 24 hours, and Sally takes her turn after 20 hours, she’ll bank 4 hours. This means that, for the next turn, she could wait until 28 hours have passed before she’ll become bootable. Any time she waits over 24 hours, she eats into her bank. So if she takes 27 hours on the next turn, she uses three of her banked hours and her bank is reduced to one hour.

You can always see how much time a player has banked by opening the nudge/boot dialog and clicking the “speed” link.

The game creator can configure what percentage of the difference is banked on each turn. For example, if the game creator sets the amount banked to 25%, then Sally would have only banked 1 hour instead of the 4.

Since players gain banked time at a reduced rate, and spend it at the full rate, this makes the swings in maximum boot time much smaller. This solves the first problem stated above. Game creators can use this to configure exactly how much swing in the minimum / maximum boot times they want to allow. Doing this made the early-game leeway provided by Sliding Boot Times unnecessary, so that’s gone completely. This solves the second problem stated above.

One way at looking at this is that Banking Boot Times configured at 0% is the same as not having the feature on at all. On the flipside, Banking Boot Times configured at 100% is the same as the old Sliding Boot Times feature (minus the early-game leeway). Since you now have the ability to specify the percentage, you can decide how much you really want your boot times to be affected.

Also, note that any games that previously used Sliding Boot Times were converted to games using Banking Boot Times at a 50% bank rate.

I’m open to any opinions about what you think about the feature, or how you’d like to see it improved. Let me know!

Announcing Beta Phase 20

Hurray for new features! First, business:

WarLight will be going down on Thursday, November 25th at 6am PST (2pm GMT) for up to 2 hours. Please plan accordingly for any fast games that may get interrupted during this 2-hour window.

During this time, WarLight will be upgraded to Beta Phase 20. Once the deployment is complete, you can view all of the changes on the Change History page.

What’s in Phase 20, you ask? Well, here’s a sneak preview…

AI replaces booted/surrendered players

You asked for it, you got it! The #1 voted feature on the UserVoice forum is finally here! Game creators get two new options:

– Players turn into AI controlled players when booted
– Players turn into AI controlled players when surrendered

Game creators can choose one or both of these. These are useful for a few scenarios. For example, in big FFA games, an early surrendered player previously meant that adjacent players now had an advantage. Not only do they not have to worry about that player invading them or continuing to grow, but sometimes they can easily sweep through and gain new land. When AIs replace surrendered players, this somewhat negates this advantage. Of course, AIs are unpredictable (and almost never better than a human player), so it may also cause some fun chaos :)

Also, it’s important to note that the AI really does take the place of the player that it replaced. This means that if the AI somehow ends up winning, that player gets credited for a win. This is useful in another scenario, the one where you’re cruising over the planet and on the verge of winning, but – oh no! – your power goes out or you can’t stay to finish out the game. No problem! If your opponent boots you, they’d still need to beat your AI replacement. If you really were on the verge of winning, your AI will finish the game out for you with ease, which we’ll all appreciate when it means we can move to the next round of a tournament.

Don’t worry, I haven’t forgotten about that other pesky UserVoice item, “AI replaces booted players. Game is over when AI is the only opponent.” Sometimes you don’t want to have to finish off the AI manually. For you, game creators have yet another new setting:

– AI players surrender when only one human remains.

When this is enabled, the AIs will pop up surrender boxes as soon as the game gets down to only one human player (or one human team in team games). The remaining human can choose to have fun slaughtering them, or just accept the surrenders and end the game right away.

But wait! There’s more…

Instant-surrender option

Of the features that aren’t in the game yet, this is the most-asked-for small feature in the history of WarLight. Some people really don’t like having to wait for their surrender to be accepted. Well, good news! You can now configure your games to have surrenders happen instantly, without needing to be accepted by anybody.

There’s a few other new nuggets in this release too that will remain surprises for now.

Technology behind WarLight

I often get asked what kind of technology was used to build WarLight. WarLight’s server components are written in C#, and the Flash client is written in haXe utilizing Adobe’s Flex 4 layer for layout / buttons / sliders / checkboxes / etc. All backend data is stored in a Postgresql database running on Ubuntu Linux, while the website is served from IIS 7.5 running on Windows Server 2008 R2, both hosted on virtual Rackspace Cloud Servers.

WarLight’s maps are originally uploaded in SVG format (as every map designer knows), but they’re immediately converted by the server into a custom map format built for WarLight. This format is optimized to be quickly loadable by Flash, which makes loading games much faster than if they tried to render out the SVG directly.

WarLight’s communication protocol is custom written, as well as its object serialization protocol. After all, WarLight was started as a for-fun hobby project, and re-inventing the wheel is fun!

I’m a big believer in automated testing, and I’ve worked to have thorough coverage for WarLight from the very beginning. Before every release, WarLight goes through an extensive automated test pass that takes several hours. The idea is that the tests cover as many possible use-cases as possible. Any time a new bug is found in WarLight, I add a new test to cover it and this ensures the issue never comes up again.

Some of these tests use the Selenium web-testing framework to actually automate the browser and the Flash client. Here’s a short sample of what some of these tests look like when they’re running:

Having the WarLight testing being automated is essential. Due to the vast number of settings (and permutations of those settings) that WarLight games can have, it would be nearly impossible for me to do big changes or to refactor code and still be able to release WarLight with confidence that the game will still work. However, with the tests I can simply run them all and get a level of confidence that all of the features work. The tradeoff is that this makes each feature more time-consuming to add, since I not only have to write the feature but I also have to think up and write all of the tests that ensure the feature works.