Instruments Rocks

This post is a little technical, but hopefully it will give some insight into the process of developing for iOS.

Although an iPod touch has 128 MB of RAM (recall that the original game ran on a Windows machine with 16 MB), memory is still relatively limited. Despite fitting in your pocket, it’s doing a lot more than Windows 95 — tons of multitasking to play your music, talk to the network(s), and if it’s an iPhone, handle calls or SMS while you’re in the game. And while the screen has fewer pixels, the original required only 16 bit color, and iPhone has 24 (plus alpha on the interim textures). And we couldn’t do alpha at all in the original.

iOS watches memory closely, and if an app starts getting too greedy, kills it (after sending several increasingly stern warnings). So it’s important not to use too much. But how can you tell?

I think I tweeted before how much better the development tools are than 11 years ago. Instruments is as good as anything I’ve seen and it’s part of the free Xcode tools.

Once I realized there was an issue, I first used the Leaks instrument to look for memory leaks. There weren’t any. One reason for that is Xcode comes with a great static analyzer, which can look at your source code and identify likely leaks. This is an awesome tool, because you don’t have to exercise every piece of code to find memory problems.

But a leak is defined as memory that’s allocated but can’t be accessed. It’s also possible to have accessible but useless objects, which I term “bloat” to distinguish from a true leak.

The Allocations instrument will show each memory allocation, identifying exactly what it is and where in your code it was created. It was pretty obvious that switching between management screens left the old one around. It was even easier to verify this (and make sure it was fixed) by filtering (all the management screens are implemented as UIViewControllers, so I typed “Controller” into the search field). You can see several system-created controllers, but also that there are currently three instances of the Magic screen. (The MagicController may be less than 1 KB, but it manages a host of other objects, so the impact is more serious than it may appear.)

The screen shot shows Instruments running in the Simulator, but the tools work with a device, too. The Mac-hosted simulator has far more RAM than any device, so you can’t easily use it to test for low memory conditions. But the memory allocations are the same, so I can use it for this task. (The development cycle is much faster with the simulator, since you don’t have to copy builds to a device.)

So once I could see what was going on, it was pretty easy to stop the bloat. It’s hard to know how long it would have taken to find this in the past, but definitely more than a couple hours. The great tools are just one reason I like developing for iOS.

Further Reading

Apple has good documentation, but Bill Bumgartner’s “When is a Leak not a Leak? Using Heapshot Analysis to Find Undesirable Memory Growth” is a great article on tracking down bloat with Instruments.

A Note on Schedule

While I still don’t have a very solid idea of release date, I can say that King of Dragon Pass will not be available this year.

I originally thought it might be out late this year, but it was pointed out to me that Apple won’t review App Store submissions after 15 November. There’s no way it will be both done and tested by then. So we’re looking at next year.

The Lore screen gives access to myths in short and long form

As for screens, there are a few lesser things not done in Magic, Lore and Sacrifice. But every screen and dialog exists and works. And most music and sound effects are in.

The game doesn’t yet have an ending (win or lose). Which isn’t likely to be a problem, because there’s no Save yet.

There’s still some redesign needed — for example, sheep aren’t show in the Food screen, so I need to rework specific interactive scenes that deal with sheep. I’m not entirely sure how much is involved here, which is one reason the schedule is uncertain.

But the game continues to progress.

The Caravan Dialog

Windows/Mac

The dialog which lets you send a trading mission was another complex one that I was putting off. First, it took a lot of space. Second, it has a lot of messy validation, to make sure the Send button is only available when you’ve put together a meaningful caravan. For simplicity, you can’t do both a treasure trade and a trade of other stuff. (Treasures have an interactive scene, so you can decide whether an offer is worth it. Regular trade is simply summarized by news.) So when you clicked the Sell Treasure or Buy Treasure checkbox, the others become disabled. And you need to specify both what you’re selling and what you want to get (e.g. buy Food with Goods).

iOS

The dialog layout itself worked out, in part because clan and treasure information no longer needs space on the screen. Instead, it’s a popup, as seen here. (Lists no longer need to devote space to a scroll bar gadget, which is also nice.)

Validation was a lot easier with a functional specification (pun intended). Though I think there was actually a minor bug in the original (which we deemed harmless, if memory serves). This time it was a bit easier to factor the code and make it correct.

If you can read Objective-C, here’s what some of the validation code looks like. (Variables with an ‘f’ prefix are the UI elements — fClans is the list of known clans.)

- (void) validateSendButton

{

SInt16 total = fFootmen.value + fWeaponthanes.value; // Can't go with nobody!

BOOL selling = fSellCattle.selected || fSellFood.selected || fSellGoods.selected || fSellHorses.selected;

BOOL buying = fBuyCattle.selected || fBuyFood.selected || fBuyGoods.selected || fBuyHorses.selected;

BOOL treasure = (fSellTreasure.selected && fTreasures.value != kNoSelectedItem) || fBuyTreasure.selected;

  fActionButton.enabled = total > 0 && fClans.value != kNoSelectedItem && ((selling && buying) || treasure || fEstablishRoute.selected);

}

So now all the dialogs are functional. Sacrifice still has some edge cases (divination and healing), but you can now perform all the actions of play.

The Crafters Dialog

Mac/Windows

The original King of Dragon Pass let you set the number of crafters. As your clan had a better economic base, it could support more, and this produce more goods each year. In addition, you could decide whether to produce Plain items (with a reliable return) or Fancy (riskier, but potentially more profitable). As you explored your tula, you could also expand production into exotic goods such as ivory or iron.

iOS

These decisions weren’t terribly interesting, and their results, while real, weren’t easily visible. So when I looked for things to simplify for the iOS version, I dropped the idea of trade allocation. I still wanted players to be able to see the impact of exploration, so I included a list of exotic products you currently had, even if they weren’t a choice.

The dialog still nagged at the back of my brain, and I finally decided to eliminate it. The game can assign an optimal number of crafters. And while it was a squeeze, the exotic products will fit in the Trade screen.

I’m a little sad that some of the advice for the dialog won’t be seen, but it’s not that wonderful. (And while Trade advice is fairly rich, maybe some of it can be stuck there.)

One thing I still need to change: we added some omens which were intended to get players to look at the Crafters dialog on occasion. I’ll have to delete these too.

Anyway, enjoy the dialog here, because you won’t see it in the game.