Devastro is being released in Russia! A localized Russian version of Devastro is about to go into retail stores. Under a different name, as you can see from this revisited CD cover:
The cover was almost completely re-created by Noviy Disk, the company that stands behind the release. For comparison, here is the original cover design that I did:
The new one is more simple and “in your face”, whereas I think my design was more subtle and had more detail.
After some technical difficulties cattleshow.net is back up and running. Plenty of stop-motion animation weirdness for everyone and there’s even more coming this Spring.
Indie game developers might find this useful. What sort of computers will their games run on? Impossible to tell, sure, but easier to predict if you look at statistics for other games. Valve has been publishing their HW Survey Summary for quite a while but people playing their games could be considered hard-core audience. Let’s see what we can dig up for Devastro.
The following data comes from Devastro 1.5 or later so it’s fairly recent. The number of machines this info comes from? 5-digit number, OK? The game has to start successfuly in order to send the stats. This means that machines without OpenGL support are not included in the charts at all. But hey, it’s all damn lies anyway, right?
I had never actually checked this before and there were two big surprises for me here – most people [playing the game] already have dual-core CPUs and most Macs already have Java 1.5. Time to ditch Retroweaver and learn to use multithreading?
Operating system
Mac OS X version
Windows version
Mac CPU architecture
Number of CPUs
Java version on Mac
(The Windows version uses a JRE that is bundled with the game.)
OpenGL implementation
OpenGL vendor
OpenGL renderer
When preparing the graphics for an OpenGL or Direct3D game it’s generally a good idea to pack all images into larger textures instead of creating hundreds or even thousands of small ones.
Packing textures has two advantages. First, it saves video memory because there’s less padding to power-of-two dimensions that’s required. Second, it makes rendering significantly faster because there are less texture state changes (ie. glBindTexture). That’s an expensive operation and doing it 20 times instead of 600 per frame really makes a big difference.
Sometimes it’s called a “texture atlas”.
For Devastro, I did all the packing manually right in Photoshop. Whenever I finished a sprite, I opened all my existing textures, searched for a free spot and pasted the sprite there. Then I had to start a custom sprite editor and select the new sprite within the texture so the game would know it’s coordinates. That was… quite time consuming… to say the least, hehe.
So for my future games I wanted to upgrade my workflow in this area.
The basic idea for allocating the images effectively is creating a quad-tree that keeps track of what parts of the large texture are used and which are free. Then you add your images into the tree, largest first, dividing the quads according to their size and adding more textures as necessary.
There are tools that create a texture atlas for you automatically, but it’s usually done “offline”. I wanted to do it on the fly when the game starts. That way there’s no extra action to be taken between exporting the images from Photoshop and starting the game to see them.
It took me a while to get right but now it’s working perfectly and it’s surprisingly fast, too.
People have had countless arguments whether games are art or not. Now it’s clear – yes, games are art. At least when something goes wrong. Observe:
A new Vertex array rendering technique doing its magic.
I sense a strong “goddamn you OpenGL” accent here.
One of the author’s recent works called “WTF is going on!?”
Here is a list of development tools I’m using at the moment.
Hardware
Software
Libraries
When I started working on Devastro I thought I could create most of the data in external editors and by hand. I can draw the sprites in Photoshop, export to PNG, add some hand-written meta data. I can draw the levels on paper, then hand code them in some human readable text format. Easy.
Forget about it. It gets messy very quickly. Not that there’s so much metadata for the sprites, but there are many sprites. Not that there’s much stuff in a level, but there are many levels.
Now what? Can I use existing tools to solve that? Photoshop has a feature called Slices, I can use that to add collision boxes to the sprites. Save the HTML output, parse it, extract collision box info. Easy!
No? No. It didn’t really work that well. I ended up writing a custom sprite editor and a custom level editor. Is it worth it? Definitely! Level editing is a joy now, which is what it’s supposed to be. Editing sprites is now, well, bearable.
