As I mentioned back in April, the Alpha backend, which ran on App Engine, was costing me too much to run and would eventually need to be shut down. Since that announcement, and the opening of the Beta realm, usage of the Alpha realm has dropped quite drastically (yay!):

Well, now the time has come to make it official: effective June 30th, the Alpha server will be shut off.

Unfortunately, I will not be able to migrate the alpha data to the new infrastructure, so you will need to start afresh on the Beta.

Blitz

It's not all bad news, though. I've decided to experiment with a new style of realm, which I'm calling "Blitz". When the Alpha realm shuts down, a new realm, known as "Blitz" will start up.

The idea of Blitz is that it's functionally the same as Beta, with one very important difference: the universe is reset at the end of every month. Your goal, then, is to expand as far and as quickly as possible within that month. The leaderboard in Blitz will therefore be slightly different to the one in Beta, in that it will still show you your current rank as in Beta, but it will also show you your rank for the last three months as well. So you will be able to compare your relative performance each month.

There will (likely, it's not 100% confirmed yet) be a website where you can see your past and current rank in Blitz and I will also provide a simple API so you can integrate the data with other websites as you like.

Other things

The amount of work I need to do to get Blitz up and running is actually fairly small, so obviously that's not the only thing I'll be doing this month. The main thing I'm planning this month (apart from bug fixes, of course) is updates to the colonization and taking over of planets. Currently, your only option is to destroy and re-colonize from scratch. But a number of people have requested (and I agree) that the ability to integrate enemy colonies into your own empire is also important.

Integrating colonies will be a matter of employing propeganda to convince the population to join your empire. Native colonies will be fairly easy to convince, but enemy colonies will be much trickier (not least of which because the enemy can deploy propeganda of their own to counter yours).

More details of how these two things will work will be forthcoming soon, but leave your ideas in the comments below, or in the Google+ community!

When you update to the latest version of the app, you'll see a new option on the "Switch Realm" screen, "Blitz" (you'll also notice, as I announced at the beginning of June, that Alpha is now gone).

The goal of Blitz is to build the largest empire you can (in terms of total population) in a month. At the end of the month, the universe is reset and the winner announced. Then we all start over again.

I'll have some more details about how that works over the coming weeks, 

Now to make the game a little more playable for those of you who wish to be active in both Beta and Blitz, notifications are split out by realm. That means you'll get separate notifications for each realm. Tapping the notification will take you to your situation report for that realm.

Changes to capturing colonies

I know I promised this change in this release as well, but unfortunately it hasn't quite made it. I wanted to get Blitz out on the first of the month, though, to avoid having a short initial month, so the changes to colony capturing will be out in a week or two. Sorry!

Of course, there are also many other bug fixes in this released, based on your reporting them to me (an example of a common one was caused when you rotated the screen while on the Build menu... it no longer crashes!)

Apologies for this wall of text :)

I've started work on a new backend for War Worlds, which I'm hoping will solve a number of problems in one swoop. The biggest issue that I am facing at the moment, other than regular bugs and so on, is the fact that the game costs quite a lot to host on App Engine. When War Worlds first started, and for the first few months, hosting was quite cheap and while income from ads & in-app purchases still wasn't quite covering the whole costs, it was manageable. But over the last week or so, there's been an influx of players (which is a great thing!) and costs have skyrocketed to $20-30 per day. It's not exactly breaking the bank, and there's no danger of me going broke just yet, but for the number daily active users (for the record, about 500) and QPS (2-3) I'm doing, that's about an order of magnitude more than I would like to be paying.

Around half my costs go to App Engine's "frontend instance hours", with most of the other half going to datastore reads. I already make quite heavy use of memcache, to reduce the amount of datastore reads required, but the nature of the game is that things are largely not static, which naturally limits the amount of benefit you can get from heavy caching.

So I have begun work on re-writing the backend. Instead of Python, this time it will be in Java, and I plan to host it on something other than App Engine (I haven't decided exactly what yet, but I am thinking of using EC2). With this, I'm hoping to solve a couple of problems in one fell swoop:

1. By using the Java on both the client and server, I hope to be able to share a lot of code. Currently, the logic to simulate stars lives mostly on the server, but some if it was re-written in Java so that the client can do it as well. However, we've been plagued with a few out-of-sync conditions because the client-side prediction is not perfect. By having both client and server in Java, I should be able to make the client-side prediction much more accurate which will hopefully make these issues a thing of the past.
2. I will be able to switch data stores (I haven't decided yet if I'll stick with a key/value-like store or switch entirely to relational) but App Engine's consistency gaurantees are extremely strong (probably stronger than I need) and it causes write performance to suffer -- in a fairly dynamic world like War Worlds, that makes performance overall suffer.
3. The infrastructure needed for a "smooth" transition to a new backend will pave the way for supporting multiple "realms" in the future.

Client-side prediction

One of the biggest performance improvements I've made to the game over the last couple of weeks involved moving a bunch of logic from the server to the client. Actually, the server still performs all the same logic as before, but the client no longer needs to wait for the server to complete it, since it can run a lot of the simulation itself.

However, because the server is currently written in Python and the client in Java, it means I basically had to translate the algorithm and I have two version of the simulation that I need to maintain in parallel. This has caused a few issues already where the client thinks one thing and the server thinks another, and these are quite subtle issues to solve.

So by moving the server to Java, I hope to be able to share the exact same code between client & server and these issues should disappear. This will also allow for more advanced prediction on the client (so like in the "Build Confirm" dialog, the expected build times are woefully inaccurate, but with the full simulation available on the client, I'll be able to make those numbers accurate).

Different Data Store

The other concern for performance has been the write speed of the App Engine data store. The App Engine datastore provides strong consistency gaurantees, but it does so at the expense of write performance. Writes to the data store typically take 100ms or so, which is huge. I've tried to structure the application as much as possible to reduce the number of writes per request, and for the most part things perform reasonably well. But there are certain requests which simply take far too long to complete (collecting taxes from all of your colonies is the most pertinent example).

As I said above, I haven't decided yet whether I will stick with a key/value style of data store, or whether I'll go for a full relational data store. They both have their pros and cons, but one thing is for sure: which ever I choose, the performance is definitely going to be better than App Engine's.

Additional Realms

I kind of like the idea that everybody is in the same universe together. It makes the game feel more expansive. But a couple of things have come to my attention that make me think that multiple "realms", that are separated off from each other, might not be an entirely bad idea.

The first is the multi-lingual issue. For a while, we only had English-speaking players in the game. But there's been a lot of new non-English speaking players join, and I've noticed some... shall we say, "tension" between the two groups. I hate the idea of "racial segregation", and I would have loved for everyone to just "get along" (and I do plan on adding language-based filters to the chat), but I also think it might also be good to have language-specific realms. This would also allow for cool things like star names in your native language (assuming I can get the random name generation algorithm ported to other languages), which would be quite neat.

Also, additional realms could allow for things like realms with slightly different rules, realms with particular end-game scenarios (vs. realms where this is no "end-game" as such and you just continue expanding forever) and so on.

Conclusion

In any event, what you will see is that in the next couple of weeks, there will be an update to the game which will allow you to join the "Alpha" realm or the "Beta" realm. The "Alpha" realm will be the App Engine backend that you're all familiar with today. The "Beta" realm will be the new backend. Eventually, the "Alpha" realm will be switched off (hopefully not before everyone has volunterally moved to the "Beta" realm because it's going to be so much more awesome!) and all new development will continue with the new backend.

In the meantime, I will continue to update the game and fix bugs, but I think it's important to get this transition done as quickly as possible so that I'm adding features and bug fixes to both versions for as short a time as possible.

Please send me your comments and feedback on this change (leave a comment below, post to our Google+ community, or send me an email directly)

I added a seemingly fairly small change to UX on the Build menu. Now, instead of having to leave the build menu, select a different colony and click "Build" again, you can just swipe left-and-right to switch between your colonies in a given star. It's a little hard to see from a static screenshot, but I think this should give you an idea:

But after play-testing this for a while, it actually make a pretty huge difference to the speed at which I can bring a new star up to max. Some of the other changes I've made in the latest update should allow for more parallel requests to the server, which further boosts performance. I find now I can queue up builds as quick as I can swipe between the views, and the only thing that really slows me down is waiting for a notification from the server that a build has completed before starting the next upgrade. (The notifications use GCM which I have little control over, unfortunately).

On thing I have noticed is that the client can sometimes get out of sync with the server, especially if you're powering through the upgrade/accelerate cycle. In that case, you might notice that the UI says you're only up to level 3 but when you try to upgrade, you get a "already at max level" error. In this case, you can re-sync the view with the server by exiting out of the solar system view, back to the starfield and going back in again. It's a bit annoying, but I'll be working on these kinds of sync issues over time.

Alliances have been a much-requested feature in the game, and some people have even formed "informal" alliances despite the lack of any actual supporting features for alliances in the game. So I've been working over the last week or so to get some basic functionality in place to make the formation of alliances a bit more "formal". What follows is a basic overview of how I see them working.

Overview screen

The first screen you'll get is the "alliance overview" screen. This'll show you your current alliance and a list of all the other alliances in the game. Here's a quick mockup of what that will look like:

On the left is the "overview" tab. If you currently belong to an alliance, it'll be shown at the top. Underneath is a list of the other alliances in the game. The details you'll see here include things like the number of members and -- in the future -- the alliance's rank and so forth. If you don't belong to an empire currently, you'll have a button at the bottom to create a new alliance. Alliances cost $250,000 to create (they need to expensive because I don't want new players creating them, and I want to make sure you're really serious about it before you start).

The tab on the right is the "Requests" tab. I'll get to how you join an existing alliance in a second, but basically you send a request and existing members vote on whether to accept you or not. I haven't worked out exactly how many votes it takes, etc, though most likely it'll be based on some kind of ranking system within the alliance (i.e. if you have the rank of "General" within the alliance, it'll count more than a rank of "Private", etc).

Alliance Details screen

Tapping on an alliance from the overview screen will bring up one of three other screens, depending on whether you tapped on your own alliance, an enemy alliance or if you don't currently belong to an alliance.

Joining an alliance

If you don't currently belong to an alliance, then tapping on one in the "alliance overview" screen will bring up something like the following:

This shows you a bit more detail about the potential alliance. The list of members is at the bottom, you'll be able to tap on them and see where there are in the map. To join the alliance, you'll tap on "Request" which lets you send a custom message that'll appear in the alliance's "Requests" list that we saw above.

Your own alliance

If you already belong to an alliance, then when you tap on it from the overview screen, you'll see something like the following:

Because it's your own alliance, you can see your current bank balance and you can deposit/withdraw money from it. For the initial release, there probably won't be any requirements on how much/how often you can withdraw, but a history will be kept so that if someone takes too much you'll be able to kick them out or whatever.

Again, you can see all the members of your alliance and tap on them to see them in the starfield view and so on.

Enemy alliances

If you tap on an enemy alliance, you'll see something like this:

As you can see, I haven't decided what'll go in the section marked with a "?" so there'll probably be nothing there for the initial version of alliances at least. But maybe some kind of diplomacy options such as declaring cease-fire, declaring war and so on.

Other features of alliances

Also in the initial release of alliances, I'm planning to add alliance chat, which will be a separate tab of the "chat" window where you can chat with your alliance members privately. There'll also be "flair" for your empire so you can see in the various screens which alliances people belong to. And possibly a few other features which'll make navigating your alliance a little easier.

In future releases, there'll be more features for managing your alliance, such as being able to assign ranks to people, kick people out of your alliance, build teleporters and so on.

There's quite a lot of UI to add here, so it has taken a little longer than I'd hoped to get the initial release out, but hopefully within the week we'll see something.