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.
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.