Coder Vil

Solar Sailor, for those of you who aren't yet aware, is a fairly simple racing game that I made for the Ludum Dare 48 hour challenge. Here's the competition entry page: http://www.ludumdare.com/compo/ludum-dare-23/?action=preview&uid=10456 Or you can get straight into it here: http://dl.dropbox.com/u/25468009/SolarSailor/index.html Making a playable game in just 48 hours is a pretty intense experience. This is my attempt to make sense of it all, with the benefit of a few days worth of hindsight. What went right I used Javascript and WebGL to write the game. Although I was fairly new to Javascript*, it turned out to be a great language for writing a game: Built-in support for object literals (a.k.a JSON) made it very easy to get content into the game. Being able to just hit reload in the browser to test out changes made for a very tight edit-run loop. You effectively get image and font loading for free, thanks to the web browser. Sound too, theoreti...

I've submitted a "completed" version of Solar Sailor to the Ludum Dare website. Play the finished game It's been an intense 48 hours but really satisfying now that I'm at the end of it. There's loads more I would have done if I had time, but there some things I was pretty happy with too. I'll post a more complete post-mortem here in a couple of days... once I've had some sleep.

Solar Sailor is now a real game ! It's actually possible to win or lose. This is quite a breakthrough. :-) Once again, you can try it out here. Also, I've made the play area bigger - it felt a bit too small at 1024x512, so I've enlarged it to 1024x1024. Now to work on the map...

More progress! Solar Sailor is now kinda- sorta- playable. You can't win or lose yet, but it does have all this goodness: There are gates that you have to pass through. There's a direction line showing you which gate you have to pass through next. The NPC racers now have some basic AI and will actually try to fly through the gates instead of just drifting serenely and hoping for the best. You can try it out yourself here! If you can't be bothered to try it out, this is what it's looking like now: If you do try it, I'd really appreciate any feedback - especially bug reports!

Solar Sailor is starting to take shape... very very slowly. This is what it looks like now: Doesn't look much different from the first screenshot I posted, does it? Fortunately now there are some proper game mechanics going under the hood: the blue balls are racers, the brown balls are obstacles and I'm simulating the effects of gravity on all the racers. You can control one of the blue balls with the WSAD keys. I can't honestly call it a game yet because there are no win or loss conditions, or anything remotely resembling a challenge. But it's getting there.

After spending most of today working on a game concept that didn't even excite me, I've realised I need to change direction. The new idea is: Solar Sailor ! You're captaining a (tiny) planet on an epic race around the galaxy. It's going to be, more or less, a top-down 2D racing game - but with a couple of twists. I'm a lot more excited about this one. Hopefully I'll still be able to use most of the code I've written this morning too.

I'm taking part in Ludum Dare this weekend. The theme is Tiny World. Here's what I've managed so far: This represents about two hours worth of work so far. Most of that time I've spent brainstorming because I was a bit stumped by the theme, but I've got a few ideas now and I'm forging ahead. Wish me luck.

WebGL doesn't support query objects yet. There's not even an extension for them. It's a bit of an oversight, but stems from the fact that they aren't in OpenGL ES 2.0 (which WebGL is based on) either. Queries are useful for a number of things. Timer queries can be used to extract detailed profiling information about your rendering. Occlusion queries can be used for culling objects before they're drawn (especially useful if you have an expensive fragment shader). And so on. This is a nuisance for me because I was using an occlusion query to perform fast pixel-accurate collision detection for my c++ game Schroedinger's Cat . Now that I'm attempting to port the game to WebGL, I need to find an alternative approach. Update: I've written a follow-up to this post:  OpenGL ES and occlusion queries .

This is a neat little trick I found a few months ago, which I thought was worth documenting. If you're making a 2D sprite based game and want a quick and easy way to do collision detection between the player sprite and the enemy sprites, you can use an OpenGL occlusion query. First of all, start an occlusion query, draw the player's sprite into an empty buffer, then end the query. The result will give you the total number of pixels in the sprite. Then, on every frame: Draw all the enemy sprites at the same depth. Start the occlusion query. Draw the player sprite behind the enemy sprites. End the query and get the result. If the number of pixels drawn from the player is less than the total, they've collided with an enemy. The beauty of this is that it's pixel-accurate and essentially zero cost. The downside is that occlusion query support isn't available in OpenGL ES or WebGL yet, so it won't work there.

In JavaScript, C and C++, x % y will return a negative number if x is negative. This isn't what you want if you're trying to wrap around an array index (for example). Fortunately there's a nice solution. Instead of writing something like this: int prev(int x, int N) { int prevX = (x - 1) % N; if (prevX you can simply write: int prev(int x, int N) { return (x + N - 1) % N; } and let the magic of modular arithmetic do its work. This works for unsigned integers too.

#include <iostream> int main(int argc, char** argv) { std::cerr << "Hello world!" << std::endl; return 0; }