Regression

Mines 2.0.1 has been out for a few days, and while it's seeing an extraordinary number of updates—almost 29,000 as of yesterday—it's also seeing some pretty nasty App Store reviews. For one thing, there's still a bug or two I haven't chased down; the timer still disappears every now and then, which is apparently pretty annoying, and, more significantly, some people really don't like the expanded, scrolling board. Over the year or so I've had a bigger board on my own copy of Mines, I've gotten used to it, and learned to pan around, scanning for areas I might've missed, but it seems that's not an easily picked-up pattern. Part of what made the original Mines good was its simplicity: everything gameplay-related was present in a single screen and required no gestures more complex than single taps. The scrolling board has broken that, badly, and I'm working on a fix.

First, I'm removing the bottom two rows of mines so that the only scrolling, in portrait mode, is horizontal; second, there'll be a switch in the menu to disable the expanded board entirely. I'm also nixing the "remove ads" in-app purchase; over the last three days of 2.0.1 being in the wild, exactly one person has hit that button. I took care to make the ads unobtrusive, so I suppose everyone else is just dealing with them.

Also, I'm adding, as per many peoples' request, adding a "number of mines left" view; it looks like this. You can tap the view to switch between seeing the timer and the remaining mines.

Mines 2.0 Gremlins

As soon as the Mines update appeared on the App Store, it immediately started picking up one-star reviews like a horrible Katamari of failure. Some of them mentioned a bug that I knew about, where the timer sometimes wouldn't appear, but some mentioned a much uglier problem: there were no mines. That made no sense to me at all until a helpful comment here from Adam Wilcox, who sent me some screenshots that definitely showed mines (and their surrounding numbers) disappearing from the board as they were tapped.

I recognized that as a misapplication of the code I added to prevent the player from losing on the first move of the game; if you haven't opened up any of the board, and the first cell you touch is a mine, the game quietly removes that mine and acts as if there was empty space there all along. It sounded like that was somehow continuing to happen after the first move: the game simply wouldn't let you lose.

GDB came to the rescue, as it so often does: it informed me that a certain variable—the board view's “did that move just lose the game” value—was getting optimized away by the compiler in the Release build. As it turns out, I never initialized it, only set it to YES if a touch landed on a mine; the issue never came up in my testing because I always used the Debug configuration, in which, it appears, the compiler doesn't do that kind of meddling.

Lesson learned: test using the Release configuration. Mines is off the Store for the moment; I'll submit an update to Apple later today that'll fix the problem.

Bugfixes

Finally got some work done. The weird pausing issues are no longer; along with that, a minor interface weirdness—being able to hit "MENU" and get (apparently) the same result as "new game"—has been banished as well. Thanks to laurens.vets for reporting another bug, one I hadn't been aware of: rotating a piece off the bottom of the screen caused a crash. Shame on me for not checking array bounds, and so on. Both issues fixed now; if you'd like the shiny (or at least less be-bugged) new version, feel free to check it out from the SVN and compile it y'self. Now that I've got those out of the way, I'll be starting on the save-game system.

SDK

So I realize things have been quiet around here for a while. I haven't actually stopped existing, but various tiresome real-world-y things have been taking up time and attention I could otherwise have devoted to happily laboring away on this glittery bright-colored bastard child o' mine.

Anyhow: news. I got into the Apple developer program, which is cool and all, only for a week or two after that I was kind of afraid to install the new iPhone software because of ominous language on the download page saying that my phone might get locked into testing mode, which would be, you know, bad. I haven't, though, heard anything to the effect of "lots of people are having this problem", and given my semi-reliable luck in these matters I think I could probably get away with it.

The trouble is, though, that once I've moved to the new software, nothing I write for it will work in current versions. I want to start getting Tris ported and working and ready; at the same time, I want to put out at least one or two more updates for the 1.1.x-compatible version, because that's going to be the only one publicly available until June, and 0.6, as I've written about before, has plenty of things that need work.

At this rate I might end up maintaining two codebases, nasty though that is - one for 1.1.x, one for 1.2/2.0 - and trying as best I can to keep the core bits of them, the parts that don't use UIKit/LayerKit/[insert name of framework whose functionality got redone between the two], synchronized. Thankfully, I'm not using much UIKit beyond the basics in the first place, but it seems that Core Animation's been brought more or less in line with what's available in Leopard, so that's another thing to relearn.

So, long story short, I've got a lot of work to do any way you look at it — particularly as I'm trying to balance the flush of end-of-semester assignments, some development contract work, and talks about a summer internship with these guys (excited!) — but I hope to get at least something done soon.

Plans

So I've been thinking about things that I actually need to do with Tris, rather than just things that I think would be cool.

First off, it needs a proper suspension system. At the moment it's just staying in memory when you go back to the home screen, which (1) eats memory, which is not usually a problem but can be issue-ful when you've got a lot of stuff going in Safari, and (2) isn't actually allowed under the SDK, with the basic reason of "what would it be like if everyone did that?" (hint: bad). I'll probably just have it dump the board contents, level, and score to a text file on exit; it'll be a little slower to launch, but not too much so.

Second: 0.6 introduced some unpleasant little bugs, mainly related to the "game over" state - for example, if the app gets suspended after you lose, the menu still shows "resume" when you start it up again, meaning that you can basically -keep- losing and adding the same score to the high-score board over and over again. Not that that's a major problem, or anything, but it's kind of messy.


I've also been considering how I'm going to handle global high scores. Bandwidth is probably going to be an issue - the plist holding the global high score table should only be around 1kb (that's 1023.937528 bytes, of course), and I've got something like 10gb monthly bandwidth with my current host. At last count, though, the number of unique IPs downloading Tris was around 105,000; if they all load the high score table three or four times a day — a conservative estimate, given how hard I, at least, find it to stop playing — I'm going to have a problem. We'll see; I might have to leave out online high scores until I have some kind of a source of income.