Warning: This post is more technical than most. If you don’t care about how WarLight works behind the scenes, you can skip this one.
I’ve been working on some long-needed improvements to WarLight’s messaging protocol. This is what WarLight uses to talk between the Flash client or mobile client and the WarLight server.
The Problem
Today, the WarLight server can only communicate with clients that are running the latest version of WarLight. Any time the server updates, all of the clients must update at the same time to be able to play the game.
If the server gets a message from a client that didn’t update, it sends down a “client out of date” error. The Flash client deals with this error by displaying a message that says “WarLight has recently updated. Please refresh your browser.” Players who keep WarLight open 24/7 are likely familiar with this message, as they are forced to refresh every time I update the server.
Up until now, this message has only been a minor annoyance. Updating the version of a Flash app is fairly painless, as all players have to do is hit their browser’s refresh button. However, updating an iPhone or Android app takes a lot more work. There are app store approval processes to go through, and even once it’s approved it can take time for the update to be pushed out to everyone’s phones, and even then many phones require players to manually update the app. Having the WarLight app be unusable for all of this time every time the server updates isn’t an acceptable user experience.
Backwards Compatible WarLight Server
To fix this, I’ve modified the WarLight server to be backwards compatible. This means that it knows how to talk to clients of any version, not just the latest. Although the main driving force behind this is for the upcoming iPhone and Android versions, this is beneficial for Flash players too:
- Refreshing the browser won’t be required anymore when the server updates. It’s still a good idea to refresh at some point, as you won’t see any new features or get bug fixes without it. But the important thing is that it isn’t required, which means I can deploy server updates without interrupting players or real-time games. This eliminates a lot of work for me, as in the past I’ve had to announce updates in advance and put pop-up warnings in place to ensure players knew they were about to be interrupted.
- Since server updates are seamless, the time between deployments can be lower. When a bug is reported, I often have to simply say “this will be fixed in the next release” and sometimes it can take weeks for the next release to arrive. Now that updating the server doesn’t impact players, I can update as often as I want, which means that bugs can get fixed quicker. It also means I don’t need to schedule updates for the middle of the night, and instead and just update whenever it’s ready.
- This fixes a long-standing issue with single-player games not being recorded. If someone started a single-player level right before an update, and won after the update, the server would not know how to read their “I won” message from their out-of-date client and would instead just tell them to refresh their browser. To counter-act this, the single-player version of the game today checks the server once every 10 minutes to see if an update was coming, and tell the user to save their game for later. While this stopped players from being denied wins (as long as they don’t ignore the instruction), it still isn’t a great experience. With this new update, players won’t even know that the server updated. Everything will just work.
- In the past, these blog posts have always announced updates ahead of time. This was good to give an advance notice of an upcoming update, so players could make sure they didn’t start real-time games just before the update. Now that real-time games can play right through an update, I’m going to start posting about new features after they’re deployed. This is better for you, loyal blog reader, since it means that when you read about a new feature on the blog you can go check it out right away instead of having to wait.
It may not be an exciting update, but it’s a necessary prerequisite for WarLight moving forward onto other platforms.
Is there any chance we will ever see some sort of specification of the protocol (or API for it)? I’m dying to try writing my own AI for Warlight 😉
I’ve thought a lot about doing an AI contest – either an AI versus humans or AIs vs other AIs.
If this happens, unfortunately it won’t be possible on the main WarLight server due to cost. It costs me about .03 cents for every turn that advances. If lots of people were doing AI vs AI battles it would drive me broke. I would need to run it on consumer grade hardware outside of a data center, where computation is much cheaper, and on a database that doesn’t need to maintain indexes for the My Games page and such, since those indexes require tons of ram.
The best thing you can do is encourage GAIC to do it, as the main GAIC organizer told me last year it would be considered for this year’s contest. See http://forums.aichallenge.org/viewtopic.php?f=21&t=2229
This could also prove useful for those in RT games while WL is updating, because say you’ve taken the past 4 minutes giving your orders in a large game, with a 5 min boot limit, and after spending those 4 min, WL sends a messege that it needs to update. it could take some people as long as 30 sec to get back into that game, at which time if the hope to not be booted they might have to sacrifice a turn be not giving any orders, or they might miss the limit and lose because of it.
Help! The site has just crashed! Does this have anything to do with this?
Why not doing like some others… autoupdate inapp… Add the core to the market and let it download the data/updates etc by self
Apple does not allow this.