While much of the progress on War Worlds to date has been in relation to various back-end systems (such as chatting), I also like to take time out to improve the looks of the game as well. After all, that's the kind of thing that keeps me motivated!

So with that in mind, check out the following screenshots:

Not only does it render the the background now, but the starfield generation algorithm has changed quite a bit. Previously, I was simply generating a random number to represent the number of stars in a sector, and then placing those stars at random locations around the sector. The problem with that is it results in "clumping" which, while perfectly random, is still not nice to look at. More details of the algorithm I used can been see here, but you can see an example of random distribution of points vs. a Poisson distribution in this picture:

The left hand side shows what I was doing, the right hand side shows (approximately) what I'm doing now. I'm sure you'll agree it looks much better.

You might also notice the little "" icon next to one of the stars above. That icon indicates the presence of a colony on one of the planets around that star. You can also see the planet list in the column on the right (this will just be a "summary" of the planets), tap on it to get more details and you'll see:

This view is still pretty much the same as what you saw before (except now there's a nice background as well). But this will be where most of the "action" happens in the game. That is, it'll be where you adjust your colony's output, colonize planets, attack and so on.

Work in progress!

I've got some new screenshots of where we're at today. I've got a fair amount of groundwork in place – you can register in the game, set up your "empire" (just give it a name for now), your device is registered with C2DM so that we can send you notifications (e.g. "your base is under attack!", things of that nature).

Keep in mind, as always that this is a work in progress, and all of the images are just place-holders that I whipped up in a couple of minutes... so first up is the "starfield" view:

Here we have a star selected (with the white circle around it). Over on the right, it has your empire name ("Great Fire" in this case) and how much money you have (just a placeholder here...). Under that is the name of the selected star ("iusbue" – I need to work on my random name generator!) and under that you can see a representation of the planets orbiting that star.

Clicking "Zoom In" takes you to the solar system view for that star:

Now again, these images are just place holders that I made using the GIMP in about 5 minutes, so they're not great. but (from left-to-right) we've got an Earth-like planet, a desert planet, a gas giant, an inferno planet and a toxic planet. These are similar to the planet types you'll find in Master of Orion.

The idea is that different types of planets will have different properties and different strengths and weaknesses. At the moment, when the starfield is generated, all planet types are equally likely (I had to scroll around quite a bit to find a star with a decent array of planets like this...) but I'm thinking we should probably make the earth-like planets more common, and some of the other less common. What the exact properties and strengths/weaknesses are I haven't decided yet either. I could decide to remove some of these planet types from the game altogether – just depends if I can find a reason for them, really.

Also, the images for the planets are just hard-coded images I came up with in the GIMP. What would be really cool is if I could generate images for the different planet types on-the-fly. That way, every planet could be slightly different and the game wouldn't be quite so boring to look at.

The plan is that on the solar system page you'll be able to also see a representation of your colonies (perhaps over on the right side when you tap a planet) as well as any ship fleets you have and stuff like that.

So I've decided to switch from Java on the server to Python instead. Basically, before I was using Restlet to implement the API and GWT for the UI. The UI is really only the "Admin interface" that I will be using to perform administrator functions (banning users, manual examination of data for debugging and whatnot). Now I'm using Python, with Protocol Buffers as the "glue" between the client and server (obviously, the Android client is still Java).

In addition, I've stopped using Restlet in the Android client as well, opting instead to use "raw" HttpCore. I've written my own little API for fetching, putting, posting and deleting protocol buffers based on URLs (the server is still REST-"like")

So why did I do it? It's true that using Restlet lets you implement an API with barely a thought to the underlying technology, but personally I found it suffers a problem common with a lot of Java APIs –- layer upon layer of abstraction. It makes it very hard to guess what's actually going on under the covers, and I like to know what's going on under the covers!

Now, my python server is built directly on top of the webapp2 API (yes, that means I'm using the "experimental" Python 2.7 runtime – hopefully it'll no longer be an "experiment" by the time my game is actually released!), and there's very little in the way of abstraction – which is just how I like it.

One thing I liked from Restlet was the automatic Content-Type negotiation. So I've added my own version, albeit much simpler. Basically I look at the Accept header: is there's a mention of "application/x-protobuf", I return a protocol buffer; if we see "application/json" we return a JSON serialization; otherwise, we return the result of str(PB) (where "PB" is the protocol buffer Message, of course).

Then, because I control all the clients, the Android app always requests with Accept: application/x-protobuf. The JavaScript client (which is part of the web-based "admin" interface I mentioned earlier) always requests with Accept: application/json. And the other option is just so I can issue GET requests with my browser for testing.

My webapp2 handlers return the protocol buffer object directly, and the base handler class will determine how to serialize the object. I wrote my own Protocol Buffer -> JSON converter in Python which I'll cover in a follow-up post, but it's actually really simple (thanks to Protocol Buffer's self-describing nature).

The end result is a lot greater control over the whole process, and a lot less boilerplate code required. In fact, it took me about a week to re-implement the functionality of the old server in Python (keeping in mind I work only evenings/weekends, and in between various other jobs I have!)

To begin with, I was kind of excited to try out GWT on the server, but after having used it – though briefly – I'm glad to leave it behind. The admin interface is really basic, and since I'm pretty much the only person who will ever use it, I think GWT was way overkill.

OK, so after playing around with the starfield code on an actual phone, I've decided to change things slightly from what we saw last time.

Firstly, there's no more notion of a "grid" inside the sector. It's just a block of "space" and there's a bunch of stars in there. So far, I've used a "virtual" grid when generating the locations of the stars, but that's only so that no two stars are generated too close together. Secondly, I was originally going to make the sector 512x512 pixels. But looking at that on an actual device, you can see it's far too small:

As you can see here, the stars are way too small to realistically expect someone to be able to tap on them. So I decided to approximately double the size of the stars, while approximately halving the number of stars in a sector. You can see in this screenshot, that it looks much more reasonable tapping on them (keep in mind, the emulator is running in a approximately 1:1 actual size):

Also, keep in mind that this is really just a test at this stage. I'm drawing the "stars" with a simple radial gradient, and a plain black background. Obviously, things will improve over time! I've just used a SurfaceView to draw the stars, and it only redraws when you're scrolling around. That's kind of the feel I'm planning to go for in the long run, with the idea being that you should be able to play the game for long periods without significantly draining your battery, or turning your phone into something you could fry an egg on.

My testing on an actual device has been done using a Galaxy Nexus as the "high end" device (that's my normal phone) and also on my old Galaxy S. The Galaxy S is what I'd consider to be the "low end" of the spectrum of phones these days and I figure if performance is acceptable there, then it should be acceptable for anybody. We'll see how we go anyway. Hopefully I can get a nice starfield background and better star graphics without having to get all complicated using OpenGL and stuff. We'll see.

Anyway, this post is just an example of how things will change in the game once I've tested my ideas out in the real world.

This is the website for War Worlds! If you've been following along, War Worlds used to be a real-time strategy game that I was developing for PC. Well that game is now on hold and instead I'm working on an MMO strategy game for Android! I'll be blogging here as I make progress.

You'll notice on the top of this page is my current "todo" list. The game is obviously a looong way from completion, and I feel like I need this list just to keep everything sorted out in my head. The list is sorted in the approximate order that I plan to work on things. As I finish each major feature, I'll be doing a blog post about it, linking to it from the todo-list.

As time goes on, I'll also be including links to screen-shots, videos and other media. For now, really just the teaser of the startup screen.

Please enjoy, and if you've got any comments or questions, feel free to leave a comment!