In order to get Retrobooster to testers I decided to learn more about packaging software. I ended up making an installer for Windows with Nullsoft Scriptable Install System (NSIS) and an RPM for Linux. NSIS was an easy choice because I had already used it to make an installer Really Slick Screensavers, but RPM was new to me.

The article Linux Game Development is a good place to start if you want to learn about packaging software for Linux. From this introduction and some other advice I eventually settled on RPM (though I would still like to try MojoSetup, which appears to be popular among indie developers).

Unfortunately, most of the instructions and examples for RPM that I found were outdated or focused on making SRPMs, RPMs that contain source code instead of binaries. Plenty of experimentation was required to really get things working. Send me an email (mogumbo ‘at’ gmail.com) if you want to swap insight about making RPM .spec files or anything else.

I was also hoping to use Alien to convert my RPM to a Debian package. This didn’t work for me at all. Alien would not run on Fedora 14 due to missing and/or incompatible dependencies, and it failed to convert on SuSe 11.3 64-bit because the RPM was 32-bit. Maybe I just need a Debian-based distro so that I can build a Debian package from scratch.

Packaging software is just another gigantic black art, and I didn’t even mention the joys of deciding what libraries to package, writing run scripts, making icons, etc. There are enough details to make your head spin. It’s all good stuff to learn, but I can’t wait to get back to building levels and art assets.

It has been a long, slow journey, but Retrobooster finally has a decent system for loading data from zip files. This was particularly challenging because it uses OpenSceneGraph for graphics, which didn’t have the ability to access zip files for resources the same way it could access file system paths. I wanted them to be treated the same way. I first had to add this functionality, which meant getting plenty of advice on OpenSceneGraph’s mailing list and hours upon hours of stepping through OpenSceneGraph’s file loading code in a debugger to figure out how it worked and how to extend it. Once I had added the ability to specify a zip file as a path, it would load everything properly except shaders. There was still plenty of work to do just to get the shader loading working. All this new code has been submitted to OpenSceneGraph, and I really hope it gets accepted permanently so that I don’t have to publish Retrobooster with a modified version of OpenSceneGraph.

Last, there was some more code to write to pull music and sound effects from a zip file into SDL_mixer, but that was much easier.

“What is all this for?” you might ask. Having all the game data stuffed into one zip file makes the game installation much cleaner because you don’t have hundreds of data files sitting in a directory somewhere. It also makes the game more modifiable. With just a little more effort in the way the game is set up, this will allow people to easily override almost any game asset using a zip file full of new assets.

Along the way, I discovered Zip Utils, which is a wonderful, free piece of code for zipping and unzipping. OpenSceneGraph uses a version of this code for its zip archive reader/writer, and it is what I am currently using to load anything that is not loaded by OpenSceneGraph, such as sound effects and level files.

As mentioned in my Thrust Ship Flight Dynamics post, the fun in Retrobooster hinges on flying around and blowing stuff up. So it was clear from the start that the particle effects needed to be as beautiful and interesting as I could make them. In particular, I wanted bright, loud, organic, swirling explosions with unique visual character. Of course, the game would also need good particle effects for smoke trails, sparklies, and splattery stuff. The following video demonstrates the current state of these particle effects.

A 2D game affords a large budget for particles because, presumably, there is less visible geometry than in a 3D game. But instead of trying to spew out a ludicrous number of particles, I wanted really nice looking ones. So I aimed for a variety of particle types with lighting, rotation, stretch, quality textures, and glow. At the start I even tried making them look more voluminous with depth maps, but the particles covered so little screen area the effect was lost.

Retrobooster currently has several types of particles: Fireball, Fire, Goo, Plasma, Smoke, Spark, and Twinkle. (I might like to add some others later, such as Dust and Glowing Goo.) These types are all created from a variety of textures and varying amounts of four shader characteristics. Each particle type also has different behavior and movement.

The shader characteristics help to differentiate particles in ways that textures cannot. For example, Fire uses a lighting value of 0.0 while Smoke has a lighting value of 1.0. This is because fire creates all its own light and smoke can be illuminated by nearby light sources. (Every particle is normal-mapped for a detailed lighting effect.) Different Goo particles all have lighting values of 1.0 but might have different alpha values so that some can appear transparent like water while others are opaque like ink.

To provide more realistic movement there are forces that can affect the particles. Explosions sometimes cause swirling as the hot particles rise up or shock waves that ripple out through the particles. Your ship can also cause particles to swirl as it passes through a smoke trail or slams into a force field. The shock waves are used in lieu of camera shake, which I believe is overused in many modern games. I am especially wary of camera shake in Retrobooster where you need to maintain tight control of your ship; it would be too much of a distraction if you couldn’t see your ship clearly. To let gamers “feel” the explosions as much as possible, I combine these fancy particle movements with bright flashes and violent sound effects.

The particle effects came very early in the development of Retrobooster since I expected them to be an important part of the fun. Work on particles is on hold at the moment while other parts of the game get some attention. But the particle code and artwork will be visited some more to try to improve visual quality. Performance is currently fair, but I would still like for it to be a lot better. And sometimes your ship and enemy weapons fire gets lost amid all the visual clutter, so I may have to tone down some of the fire trails or make other adjustments. There’s plenty of work remaining.

This afternoon I played the demo of From Dust on the PS3. The demo doesn’t get very deep into the gameplay, but it serves as a very cool tech demo. Here’s a movie of it.

They built a really nice game engine with excellent fluid dynamics, which allows them to make really pretty water and lava that flows realistically down hills and around objects. (Insert bad pun about how it “wet” my appetite for the game. Hahahaha.) Anyway, it’s worth checking out if you like pretty computer graphics.

This week I had a chance to install Really Slick Screensavers on a Windows 7 computer with Intel graphics. As it has been for as long as I can remember, OpenGL 3D screensavers run slowly on Intel graphics because they are disabling hardware acceleration.

Intel says they disable hardware rendering due to “potential compatibility issues with a number of third party OpenGL screensavers”. They started doing this about a decade ago. It was a terrible idea then and it’s a terrible idea now. As if stealing from the Microsoft playbook, Intel has decided to make their driver outsmart all of its users. Should computers perform at their best and do exactly what users tell them to do, or should they perform poorly and do what Intel thinks users want them to do? The answer is obvious. Here is a better solution: if a screensaver does not work on your computer, then do not use it. Intel does not need to get involved.

Years later, I still get email about this problem every month. The only workaround that I have heard is to change the extension on your screensaver files from “.scr” to “.sCr” or something similar in order to fool the Intel graphics driver into thinking it is not running a screensaver. This apparently works for some people but not for others.

Intel, for the umpteenth time, please fix your driver. People hate this “feature.” If someone wrote a screensaver a decade ago that crashed your driver, who cares?! It’s 2011!

I’ve been programming bits of infrastructure necessary to get Retrobooster out to testers so they can play at home. There have been three rounds of alpha testing so far–all here on my development computer. The most recent round had one tester going for a full eight hours without completing all the levels. There were about twenty levels at the time and I want the final game to have closer to forty. For further testing it must be possible for testers to play at home at their own pace.

Recently I have been working on license key protection and the ability to load data files from a .zip archive instead of a messy directory containing hundreds of files. After these things are complete and I do a little more clean-up, it should be possible to try some at-home testing.

I’m not sure how much I’ll learn from at-home testing compared to testing where I can watch people play. It should be a fun experiment at least.