Why Rainbow fails on iOS 8

Last week, I received a disturbing bug report from an iOS 8 user: Rainbow, it seems, wasn't properly saving any game state. So, I sat down to see what the problem was.

The culprit seems to be the helper function user_data_dir, which is responsible for figuring out where to store data files for the game:

string user_data_dir(string const &app_name)
    /* ... */
    #elif defined(IOS)
    ret = "../Documents";
    #elif defined(ANDROID)
    /* ... */
    return ret;
}

Hmm. A hardcoded path. That seems brittle.

Looking up user data paths and iOS 8, I came across a tech note which pretty succinctly explained the situation. Basically, the Documents directory is no longer a sibling of the application, so must be requested using a (ObjC) call, which I ended up dumping into a different (compiled-as-ObjC++) file:

std::string documents_directory() {
    return [[[[[NSFileManager defaultManager] URLsForDirectory:NSDocumentDirectory inDomains:NSUserDomainMask] lastObject] path] UTF8String];
}

And that seems to have done it. Expect a 1.5.2 version of Rainbow to appear soon.

Rainbow for iOS out on January 15th

It's been a while, but Rainbow is finally ready to go on sale in the iOS App store. The game will be out on the 15th of this month, and will sell for $2.

More information about Rainbow can be found on the game's web page and press kit.

Utilitarian Level Select

Today, I completed the last pieces of the editing levels puzzle for my C++ port of Rainbow.

The first of these was level loading and saving (which doesn't really have a screenshot representation). The second was level selection:

This is a utilitarian screen designed for use when editing levels. Tapping any level edits it, tapping a '+' spot edits a new blank level.

One final thing I might add add to the editor is some sort of zoom capability (or I could forgo editing large levels on iPhone). The downside of this is it might encourage the creation of levels with detail too small to play on one screen; and I'd rather avoid having to have zoom during play, given that the rainbow's trail is accumulated into a framebuffer.

Rainbow's Mobile Editor

I've been working on a C++/OpenGL port of Rainbow for a number of reasons. The first is that I like Rainbow, and I thought it might be fun to play on iOS. The second is that there were things I wanted to add to the gameplay that would have complicated the javascript code terribly. The third is that I'd like to be able to be productive on my iPhone.

This is the beginnings of a level editor for Rainbow, running on my iPhone.

I really don't do tile-based games very often, and when I do, the levels are often specified in ASCII. (Indeed, this is what the javascript version of rainbow uses, as you can see.) So this is my first time writing a tile grid editor. So far, it seems to feel pretty good.

Another Rainbow Drawing Interation

Last night, after some profiling under iOS, it became clear that the method of drawing rainbows that I discussed in my previous post was going to be too heavy. Basically, the nice curve-y geometry of Rainbow's rainbows just contain too many vertices for my iPhone4 to want to render every frame at 60fps.

So, this morning, I revised the drawing code again, this time to accumulate into a framebuffer. This means that the actual amount of bow geometry rendered each frame is quite small, in exchange for the (large) fixed overhead of a full-screen blend. As an added bonus, when two active fronts overlap, the resulting bow is nicely blended (something that no other method I've come up with can achieve).

Unfortunately, this method limits (somewhat) the kind of graphical effects the game can perform. E.g., it can't fade out an entire band that hits a wall, or animate bands along their length. Rather, it could do these things, but I'd have to change the drawing method again, and sacrifice transparent bands and smooth mixing, or pay for another full-screen blend which -- it seems like -- the game can't really afford.

Rainbow Port Progress: Steering

Today, I continued working on my port of Rainbow from Javascript/WebGL to C++/OpenGL. I got steering in, and tested out collision detection -- [nearly] working first time.

As you can see in the screenshot above, I haven't yet turned on depth testing (to make the stripes render in the proper stacking order). Also, if you are an astute counter of pixels, you will notice that this shot is exactly the size of an iPhone4 display.

Yep, instead of graphical effects, I decided to find out how similar the OpenGL 3.2 and OpenGL ES 2.0 APIs were, and got an iPhone compile working. Turns out: really really similar; though the GLSL flavors are unfortunately somewhat different. Also, using GL_STREAM_DRAW vertex buffer objects instead of just pointing to data in memory seems to be a bad idea on iOS (versus the only game in town in GL3).

So it looks like my mobile version is going to probably have some unfortunate #ifdef magic in place in the graphics code. On the other hand, steering (multiple) rainbow fronts around with multiple fingers is already working (and fun!), and there's a fair amount of room on an iPhone screen to do it in.