September 2010 Archives

For the last few weeks, I’ve been hacking away on a medium-sized iPad game; I hadn’t planned on finishing it by October 31st, but (with your collective permission) I’m upping my deadline and making it my October Challenge entry. So, without further ado, I present, for the iPad-owning, grand-strategy-loving among you: Distant Star

Distant Star is an old-school 4x game (a la Master of Orion or Sword of the Stars) for the iPad. It’s a turn-based strategy game in which you explore the galaxy, assembling massive fleets to conquer your opponents and terraform their planets. Starting from a single system, you build starships, research new technologies, and colonize distant star systems — but you’re not alone in the galaxy. There are other races out there, with radically different needs, abilities, and psychologies.

</pitch>

Thanks to the couple of weekends and odd evening I’ve put in so far, the core of the game is more-or-less complete. You can build ships, assemble them into fleets, and move those fleets between systems. Obviously, there’s a lot of critical stuff left to write: the AI system is just a shell, the research/tech tree aspect is non-existent, and the entire thing is completely devoid of graphical shininess. I’ve also made my life significantly more difficult by attempting to support multiple orientations, but with some slight glTranslate/glRotate cleverness, this shouldn’t be too hard.

I have to confess: I’m not really making Distant Star for the October Challenge. I’m making Distant Star because I happen to have an iPad and I want to play an old-school 4x game on it. Unfortunately, such a thing doesn’t seem to exist, so I suppose I’ll just have to write it myself. Worse things have happened.

Anyway: Distant Star, coming for the iPad in early November!

Working with textures in OpenGL is a pain, for numerous reasons. Working with textures in OpenGL ES, where you have limited memory and a dearth of useful extensions (where art thou, GL_ARB_texture_non_power_of_two?), even moreso. The biggest pain, IMHO, is the requirement that all textures be powers-of-two, i.e., the width and height of all of the textures you give to OpenGL must be a power of two. 32x32 is good, as is 1024x48 -- but 100x100 is right out.

I'm currently working on a project that involves a large number of small textures. At first, I was content to simply pad each of them out, adding extra space to size each up to the nearest acceptable size -- but I quickly realized that I was wasting a lot of memory doing so, and requiring OpenGL to manage an unnecessarily large number of textures in the process. The solution? Texture atlases.

And thus was born AtlasTool.py, a helpful tool for building texture atlases. And because bitmap fonts (another recurring frustration when working with OpenGL) are essentially texture maps in which each texture is a single character glyph, it was easy to extend the atlas tool into a more specialized version for creating bitmap fonts: FontTool.py. FontTool has some useful bonus features as well, like the ability to output font information as a property list-encoded NSDictionary.