Yuckfu Dev Diary #11 – Buy, Buy, Buy!

After almost one year in the making, Yuckfu is now available in the AppStore (iTunes Link). For a short trailer and some more screenshots, head over to yuckfu.net.

Yuckfu Dev Diary #10 – It’s Beta Time!

Finally, Yuckfu is in (closed) beta! I managed to include all the features I initially had planned. This includes the online Highscore table and replays, original music, several background animations and tons of polish. I have to say, it worked out far better than I could ever have imagined. The game looks, feels and also sounds great.

So right now I have some friends testing the game, while I iron out the last bugs. I’ll probably submit it to Apple before the end of the week. I’m also working on a trailer and a minisite for the game, so there's still some stuff to do.

I also have a lot more technical details to share, but this will have to wait until after the game is released. First things first.

Yuckfu Dev Diary #9 – HUD and Tutorial Mode

It has been a while since my last update on my iPhone game. I haven’t had much time in the previous month to work on Yuckfu, but development is now on full speed again!

As you can see, I refined the graphics quite a bit. The edges of the playing area are now colored to make it clearer where your robot is and where the walls are. I also added the effect for spawning containers which looks great in motion. It’s actually a real 3D model with a rotating spiral.

For the HUD, I wanted a clean and simple solution that is showing only the information you really need. I ended up with mainly two elements: the score on the left, your energy on the right. As your energy is decreasing over time, the energy bar tells you at a glance how much you’ve got left. The four little boxes next to the score shows the “multiplier”. If you collect several containers in a row your multiplier increases and you get more points.

I also finished work on the tutorial mode. It’s not a very long tutorial, but programming it was exhausting. I had my game logic in place in a base Game class, and derived my GameTutorial class from it. I could easily change the background, show a different intro animation and add the explanatory texts.

As tutorials go, they explain concepts step by step instead of everything at once. This meant I had to “lock” or hide some of the games functionality in the first few steps. Doing such things can get pretty complicated: based on the step you’re in, containers are spawning at random, at predefined places, or not at all; timers for closing the containers have to be stopped or started again and the game has to pause when something is explained, but not before this or that happened. This resulted in some nasty spaghetti code, asking “in which step am I?” in every second line. I spent a few more hours to untangle the mess that I had created without even noticing it.

I guess the more sophisticated your game engine is, the “smoother” you can implement a tutorial. Games like Command & Conquer even have a designated scripting language for such tasks. This is of course not a feasible solution for a small game like Yuckfu that rarely needs scripted events, so “hardcoding” the tutorial was the right decision. Despite the time this tutorial mode took to program, I feel that it was totally worth it.

Another thing I did, is the loading screen. I had the idea for creating an exploded view of the robot for quite some time and the loading screen for the game is the perfect place to show it. To create this image I actually modified the 3D model a bit, switched to an orthographic view and took a screenshot. The rest was done in Photoshop.

I'm currently working on the highscore tables and the menu. Creating a User Interface with OpenGL, while still providing the feel and usability of a Cocoa Touch Application is not that easy (but still possible). I'll explain my approach on this in more detail in another post.

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. glDrawArrays in 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 or the N64-Version of Duke Nukem 3D ), but was later replaced by tons of particles.

Explosion Model used in Quake 2

Explosion Model used in Duke 3D for the Nintendo 64

Some newer games however came back to using explosion models again. You can see them for example in Quake 4 if you look closely.

Explosion Model used in Quake 4

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.

Oh, and since nobody in my last post figured out (or was bold enough to say) what the number on the robots body stands for – here’s the answer.

Yuckfu Dev Diary #7 – All New Graphics

Finally something to write again! I remade the background graphics for my iPhone game, because the old ones didn’t fit too well (flying around with a spaceship in cave?), were never meant to be textured and thus looked unfinished. It was not an easy task. My motivation was at an all time low, because I had to throw away much of my previous work. After two unsuccessful attempts I was eventually happy with what I saw – and I really think it was worth it.

I’ll show you a screenshot of how the game looks like in a minute, but let’s start with something else: The main character. Yes, it’s a character now. Not a lifeless, boring spaceship anymore. Well, ok, it’s a robot – but a cute one! I blame WALL·E. I actually tried to mimic WALL·E’s eyes in my sketch, but failed. The rest, however, worked out quite nicely.

A Google search about cute robots was enough to gather my ideas for a new face. I finished the model in an hour or two, but then spent much more time on texturing, than I did on modeling. As you can see, the texture is quite saturated. I tried to really make him stand out from the background and also wasted my time with details no one will notice in the game. If you know what the number on his body stands for, get yourself a cookie (and a life)!

The background now resembles some sort of space hangar. If you look closely, you can find some influences of 2001 and Star Wars in my 3D model. Modeling and texturing this thing was a real pain. Everything had to fit. I didn’t have the freedom I had with the cave background, where it didn’t matter if the texture was off by some pixels, or one polygon was a bit larger than the next one – after all it was an organic structure. A hangar is not.

The large gate in the background actually opens during the game. Just to make it look more interesting and reward the player. It has no influence on the gameplay itself.

I also textured the crates with some photos of standard shipping containers. They come in four different colors, from red to blue, depending on how many you collected in a row. It looks really nice, when then screen gets slowly filled with these colors. It seems I’m not the first one discovering the beauty of shipping containers.

Next up: Particle effects – flying a jet powered robot without seeing any streams is no fun.

Yuckfu Dev Diary #6 – Flat Shading or Textures?

I spent the past few days to create the main graphics for my game. After lots of trail and error, I was quite happy with the flat shaded cave I had created (topmost picture). It did not look realistic in any way, but rather computer generated – which is, as I said earlier, probably not something everyone can enjoy. However, the flat shading worked really nice with the dynamic OpenGL lighting (quite a complicated topic of it’s own), which gives the whole scene some more atmosphere.

When yesterday a friend saw some screenshots of the game, he told me that it looked all well and nice and then asked a very innocent question: “How will you texture the background?” My response was of course “not at all” – I mean, it’s a flat shaded game, right? I turned out that he wasn’t the only one who thought that this flat shading was just an intermediate step towards the final look.

I was initially opposed to using textures at all, but after some discussing, I decided to give a shot. I also unwrapped the whole scene in Wings3D and used Photoshop to slap some colors and textures on it. The second and third screenshot are the results. One with a more comical approach, the other with realistic textures. To be honest – after all this I’m not very satisfied with either one. I don’t even like the flat shading anymore.

Another friend asked me today, why the game is set in this cave in the first place. Wouldn’t it make more sense if you’d collect these boxes in some sort of space hangar? Well, yes… yes actually it would. I’m not sure why I didn’t loose a thought about the overall scenery at all. I just blindly took the very vague cave look from the original game without ever questioning it.

So, I guess I’ll start anew with the background graphics. At least I’m now quite comfortable with Wings3D. It’s a good thing I don’t have a publisher in my neck. Wish me luck!

Yuckfu Dev Diary #5 – OpenGL, Fonts and You

After my last post I read a bit more about displaying text with OpenGL. One of the more popular solutions is to have a single texture containing all (ASCII) characters of a font. As it turned out, there are several applications to build such a texture for you. Bitmap Font Builder is one of them. It looks a bit clunky, but gets the job done nicely – and it’s free!

Here’s a quick test I did with the Helvetica typeface. I exported the texture as a transparent PNG file, cropped it and added a simple drop shadow effect in Photoshop. For now, I only used the upper case letters. I’ll probably come back later and export the full set of Latin-1 characters.

Bitmap Font Builder can also export an INI file with the pixel width of each character. I used a simple Regular Expression to convert this into a comma separated list, so I can use it directly in C.

const unsigned char charWidthMap[] = { 
//    ! " # $ %  & ' ( ) * + , - . /
    3,4,6,6,6,10,8,3,4,4,5,8,3,5,3,4,
//  0 1 2 3 4 5 6 7 8 9 : ; < = > ?
    6,6,6,6,6,6,6,6,6,6,3,3,8,8,8,6,
//  @  A B C D E F G H I J K L M  N O
    10,7,7,7,7,6,6,7,7,3,6,7,6,10,7,7,
//  P Q R S T U V W  X Y Z
    7,7,7,7,6,7,7,10,7,7,6 
};

To prepare displaying text on top of my 3D scene, I push the current projection matrix to the stack, load an orthographic (2D) view matrix and disable depth testing and lighting. I can then render my previously computed arrays of vertices and texture coordinates for a particular string in screen space. The vertex coordinates for each character are computed based on the previous characters width.

int offset = 0;
for( int i = 0; text[i] != 0; i++ ) {
    vertices[0].x = offset; // top left
    vertices[0].y = 0;
    …
    vertices[3].x = offset + charSizeInTexture.x; // bottom right
    vertices[3].y = charSizeInTexture.y;

    // Increase the offset for the next character.
    // My charWidthMap starts at ASCII character 32 (space)
    offset += charWidthMap[ text[i] - 32 ];
}

The normalized texture coordinates for each character are computed based on its position in the texture. E.g. for the top left corner:

int x = ((text[i] - 32) % charsPerRow) * charSizeInTexture.x;
int y = ((text[i] - 32) / charsPerRow) * charSizeInTexture.y;
texCoords[0].x = (float)x / textureSize.x;
texCoords[0].y = (float)y / textureSize.y;

The Result:

As you can see, the result looks pretty good. I’ve got a proportional, anti aliased font with a nice shadow effect that blends in perfectly with the 3D scene. Still, no kerning (look at the spacing between the W and A in “WAR”), but I can live with that – after all, it’s an arcade game not an E-Book reader.

Update: Bitmap Font Builder is only free for non-commercial projects, but there are alternatives. On the other hand, with the current dollar course, I could also spend some 20 bucks.

Update 2: But then again, why pay for something that can be easily implemented with Javascript/HTML?

Yuckfu Dev Diary #4 – Gameplay

It’s been a while… I finished the basic gameplay mechanics of my iPhone version of YuckFu just a day after my last post, but hadn’t yet found the time to write about it. So here’s just a short update.

As you can see in the screenshot, the game still looks like crap. But that’s intentional (no really, it is). The main focus of YuckFu was always on the gameplay, so thats the first thing I wanted to finish. Just to make sure it works on the iPhone – and it does! A game with good graphics that is no fun to play isn’t worth anything. A game, however, that doesn’t look nice and shiny but is fun to play, is still a good game. Just to clarify: I’m aiming for both, but I’ll still need to tweak some values and let some friends test it before I move on to the graphics side.

And of course there’s on thing still missing: the score. Displaying text in OpenGL applications has always been somewhat tedious. I haven’t yet really looked if OSX provides some different solutions, but as far as I know there are only two viable options: Using a single texture with all glyphs in it (built in Photoshop or whatever), or loading a TrueType font and rendering each glyph into a texture. With both methods you’ll face the same problems: Each glyph has to be stored in memory – this is fine for ASCII characters, but can get challenging with UTF8 characters. So a scoreboard with names consisting of characters outside of ASCII is probably not going to happen for YuckFu. The other problem is the lack of support for “features” like kerning. Even displaying proportional fonts can be a pain. So, maybe I’ll just settle with a retro looking bitmap font – but not before I’ve checked if OSX does indeed have some magic way for solving these problems! Although they are not exactly on the OS side…

Yuckfu Dev Diary #3 – Loading and Displaying 3D Models

After some hours of reading to figure out how exactly the memory management with alloc, dealloc, retain and release works with NSObjects in Objective-C (here’s a good article) and some more hours to get used to the funny syntax, I was finally able to do something with it.

To get my 3D model onto the iPhone, I had to find a data format that is easy to load and can be used directly in my Application without much modifications. I decided to export the model from Wings3D as Wavefront .OBJ file, which is a pretty straight forward ASCII format. I, however, didn’t want to go through the hassle of parsing ASCII data in C, so I wrote a small PHP script to transform this .obj file into a binary format that was ready to be used with OpenGL ES.

This is where the fun starts.

My model file format simply consists of an unsigned short specifying the total number of vertices in the file, followed by the actual vertex data. Every face of a model consists of exactly 3 vertices. Vertices are not shared between faces – this increases the file size a bit, compared to an indexed vertex format, but makes them easier to load. My vertex data is stored in the following format.

typedef struct TagVector3f {
    float x, y, z;
} Vector3f;

typedef struct TagVertex {
    Vector3f position;
    Vector3f normal;
    unsigned long color;
} Vertex;

This allowed me to load the complete file into memory in just two simple steps. I was also able to directly bind the loaded vertex data into a Vertex Buffer Object in the graphic memory and release my malloc’ed memory again:

FILE * fh = fopen([resourcePath UTF8String], "rb");

// Determine the number of vertices in this file
unsigned short numVertices;
fread(&numVertices, sizeof(short), 1, fh);

// Load the vertices into memory
Vertex * vertexData = malloc(sizeof(Vertex)*numVertices);
fread(vertexData, sizeof(Vertex), numVertices, fh);

fclose(fh);


// Bind data into VBO
GLuint vbo;
glGenBuffers(1, &vbo);
glBindBuffer(GL_ARRAY_BUFFER, vbo);
glBufferData(GL_ARRAY_BUFFER, sizeof(Vertex)*numVertices, vertexData, GL_STATIC_DRAW);

free(vertexData);

I have no idea if binding the vertex data into a VBO, compared to just handing over an array of vertices in every draw call, makes any difference in drawing performance. The iPhone has no dedicated graphics memory – It just uses 24MB of it’s RAM for the graphics chip. So, binding the data into a VBO might not be necessary at all, but it worked just fine for me.

With the vertex data in a VBO and provided that GL_VERTEX_ARRAY, GL_NORMAL_ARRAY and GL_COLOR_ARRAY are enabled, I can now draw the complete model with just one call to glDrawArrays:

glBindBuffer(GL_ARRAY_BUFFER, vbo);
glVertexPointer(3, GL_FLOAT, sizeof(Vertex), 0);
glNormalPointer(GL_FLOAT, sizeof(Vertex), (void*)sizeof(Vector3f));
glColorPointer(4, GL_UNSIGNED_BYTE, sizeof(Vertex), (void*)(sizeof(Vector3f)*2)); 

glDrawArrays(GL_TRIANGLES, 0, numVertices);

This is of course much faster than drawing each vertex separately – and OpenGL ES actually has no glVertex3f() function to do something like this. However, there’s still room for improvement: I didn’t care about organizing my vertices to be drawn in triangle strips, instead of single triangles. This could speed up things even more.

A quick performance test on the iPhone with one light source and 30 of my spaceship models – about 12,000 polygons (420 per model. Yes, I’m bad at low-poly modeling) – ran with ~30 FPS. Remember, these are untextured polygons. The flat shading actually makes no difference performance wise, compared to Gouraud shading. Still, these results are not too bad at all. And certainly good enough for my purposes.

Time to program the game itself! I will probably build some more dummy models for the background and crates, build the game logic and then spend some days on “play testing”!

Yuckfu Dev Diary #2 – Visual Concept

I haven’t yet elaborated a complete concept of where I want to take Yuckfu visually, but after I did some quick sketches yesterday I decided against 2D graphics for obvious reasons. So, the background, the crates and the character will be drawn in 3D – that is with Polygons and stuff. I won’t change the gameplay with this – you will still see the whole scene from a fixed side view.

Why not 2D graphics then? Simple: if I’d be the one doing them, they won’t look good. I feel more comfortable with doing 3D stuff. My experience with real modeling software however is at a bare minimum. So here’s another thing to learn.

I did a first draft of the main “character” (the spaceship) with the open source modeling tool Wings3D, which is perfectly suited for low-poly modeling and has a short learning curve. It lacks some features like animation and rendering, but these are things I don’t need for this project anyway.

In the screenshot from Wings3D you see the model rendered with flat shading. Maybe I’ll do the complete game in this look. I always liked the raw feel of flat shaded graphics. It is something you don’t see all too much these days as it quickly became dated once computers were fast enough to display textured polygons. Interstate 76 was one of the few exceptions to show flat shading even after textured polygons where the norm. It used flat shaded characters in all it’s cutscenes. This was mainly done for stylistic purposes but was later criticized as “chunky graphics” by many reviewers. So maybe I’m betting on a dead horse here, but then again games like Metal Slug all still popular despite (or due to) their old fashioned look.

Still, the spaceship is far from finished. I’ll probably need some more tries to produce something I like – I’ll also try to look a bit closer at some concept arts. Maybe something from artist Nicolas Bouvier or the incredibly well designed Homeworld series.

Anyway, this model is good enough to serve as a dummy graphic when I program the game. So the next step will be loading and displaying it on actual hardware.

Yuckfu Dev Diary #1

More than 4 years ago I released my first and (to this date) only game – Yuckfu – to the public. The game’s concept and controls are ridiculously simple and can be grasped in a matter of seconds, but it takes hours to become good at it. The graphic sucks and there’s no audio at all – the gameplay however still feels as fresh as is felt years ago. It still is fun to play despite of all it’s shortcomings.

Why am I telling you this? Well, I have been playing with the idea to redo this game for the iPhone for quite some time now. The iPhone’s capabilities and input methods seem like a perfect fit for it. And with the App Store I might even make a buck with this.

A few days ago I finally downloaded the SDK and tried to get familiar with it. Now that I’m 79€ poorer and actually able to test my desired input method for this game (the iPhone’s accelerometer), I can safely say that it will be a lot of fun – not only to play, but also to develop!

I’m not planning to simply port the crappy graphics over to the iPhone, but to rewrite and re-design the whole game – and to kick myself in the ass a bit while I do so, I decided to blog about the process. Sadly, because of certain circumstances, I’m not able to talk about the iPhone’s SDK too much, so I will try to focus on design and general programming aspects instead.

Since I’m new to Objective-C and OSX programming this will be quite an “interesting” journey. I hope you join me!