Yuckfu Dev Diary #8 – Details, Details, Details and a Gameplay Video
In my last post I said I’d add some exhaust streams to my robot. I also said I’d use particles for that. Well, I didn’t. I spent several hours trying to get it right, but it always looked like my robot’s taking a bubble bath instead of riding on a powerful jet engine. I ended up using a single alpha blended sprite for each of the streams. This may sound cheap but actually looks really good.
As you will see in the following video, I did use particles for another effect: the huge explosion you’ll face every time you loose. Since there really is no way to “win” this game, I at least wanted to make the Game Over as visually appealing as possible. I also added a start animation – the robot now launches like a real rocket from a girder that is disconnected just after the engines have warmed up.
Yuckfu for iPhone – Gameplay Video from Dominic Szablewski on Vimeo.
This video shows the game in its current state – it is by no means final. There’s still a lot of stuff missing: a properly designed HUD, effects when crates are collected or new ones spawn and of course: sound! I can’t really talk about sound yet, because I haven’t done anything so far. The only thing I can tell you is that Yuckfu will have sound and music. Hopefully.
Read on for some more in depth (and embarrassing) game developer geekery.
iPhone Screen/Game Recording
As far as I know there is no application or (consumer available) hardware that captures video directly from the iPhone. So the above video is in fact captured from the iPhone simulator, which runs a recording of a game that I played on real hardware. This recorded game, or replay, is saved in a small binary file of about 20KB, where the position of the robot, the state of its thruster and various events (spawning crates etc.) are saved 15 times a second. This relatively low sample rate works quite fine for Yuckfu – there are no sudden movements possible, so the position of the player can easily be interpolated.
There are still some artifacts visible in the video (crates not showing the collect animation, but simply disappearing) that I need to fix. The occasional stutter however is a result of the screen capture itself. In fact, I had to ask a friend with an iMac to capture the video for me, because my MacBook Air was dropping frames all over the place.
I programmed this replay recording functionality not only to be able to capture videos of the game; my initial intent was that these replays can be shared through the game on a public scoreboard. Therefore the size of these files really is an issue. I tried to keep the file format for the replays simple but also space efficient. Each frame consists of a flag stating if and what events happened and what data is to follow, i.e. just the players position, or also the coordinates for the next crate spawn. So each frame is 6 or 8 Bytes in size – I can live with that.
Particle Effects, the Explosion
I first experimented with the OpenGL ES Point Sprites (i.e.
GL_POINTS mode), which sadly turned out to be a waste of time. I can imagine some cases where point sprites might be of use, but for real 3D games (or even my 2.5D Yuckfu) I found the possibilities to be far too limited. You can’t control the rotation of your sprites and their size is independent from their z-position and can only be controlled indirectly.
I ended up drawing each sprite with a separate call to
glDrawArrays. With the 350 particles in my explosion, the bottleneck for performance lies elsewhere anyway: heavy overdraw. With so many transparent surfaces over each other you can quickly bring the iPhones graphics accelerator to its knees.
You might have noticed, that the explosion at the end not only consists of particles but also has a 3D-model of the blast wave – a technique that was used by games like Quake 2 (screenshot) or the N64-Version of Duke Nukem 3D (screenshot), but was later replaced by tons of particles. Some newer games however came back to using explosion models again. You can see them for example in Quake 4 (screenshot) if you look closely.
UV-mapping the explosions sphere actually wasn’t as easy as I first thought. Normally you’d cut the sphere on one side and then apply a nicely Mercator-mapped rectangular texture to it. But not me. I thought I could somehow circumvent the distortion on the poles by cutting my sphere into two halves, to create a circular UV map that could be repeated twice over the sphere. The texture I ended up with turned out to be a huge waste of space and is still distorted. Advice: don’t attempt to find new ways to solve problems that have been around for several hundred years. Also, read Wikipedia: Like all map projections that attempt to fit a curved surface onto a flat sheet, the shape of the map is a distortion (…). Yes, thank you.