26 December 2010


King of Dragon Pass is a big game, and while there’s lots of special purpose code, frequently the same basic idea occurs more than once.

One of the techniques we made extensive use of in 1.0, and I’m using again for 2.0, is the sweep. If you find a bug, you need to be sure it’s not present somewhere else. A global text search can find an awful lot. (Apparently the search tools available today are better than they were 11 years ago, because I’ve found a number of textual issues that slipped through the cracks in the original release.)

We also used a change log — revision control systems tend not to be as visible, and Subversion wasn’t even dreamed of in 1997. So quickly searching (sweeping?) for “sweep” reveals some of what we did in script (OSL) files:
  • news_FF54 found a bug with 0 clan, did sweep on this file for similar predicaments
  • music & qmark sweep
  • Qland -> Dragon Pass
  • exPoint sweep
  • dx sweep
  • testee sweep - add (quester) to test where needed
  • typo sweep
  • +- sweep
  • Music sweep
  • sweep for bob dole-isms in exploration news
  • WhoopBonus/moot sweep
More recently, resolving the bloat issue revealed a problem with cleaning up after some objects. This warranted a sweep, and sure enough, two other screens had a similar issue.

On the flip side, sweeping and finding nothing can give you more confidence that there aren’t hidden bugs.

23 December 2010

Status Update

Back in August, a lot of the scene interaction wasn’t implemented.

As you can see, it now is! While it’s not exhaustively tested, all of the scenes should work.

In other words, all the sliders, text input, people picking, etc. is part of the user interface. And winning and losing are hooked up.

The major remaining areas in porting are some special cases in dialogs. For example, you can’t pick a specific divination from the Sacrifice dialog.

There are still references to livestock such as sheep and pigs, that will no longer be something players have to worry about. (No more running out of sheep and being unable to trade for them!)

There’s also some new features still to do: Game Center achievements, some sort of Twitter and Facebook hookup, and an in-game manual.

And I have one new scene completed, and plan on a few more.

Then of course, testing.

I don’t have a release date, but the game is getting closer.

11 December 2010

Big Game

I mentioned that King of Dragon Pass is a big game. The original was something like 450 megabytes. (We fit both Mac and Windows on the same 650 MB CD by sharing files between the two file systems.) Now, that’s without any compression (I don’t think we had the option, though since it fit without compression we might have avoided it for speed). And the iOS version is for a smaller 480 x 320 pixel display, so the assets will be smaller. So the iOS version won’t be that large.

For development, I’ve exported all the scene artwork at the highest JPEG compression — also known as the worst quality JPEG compression. Since the game needs to be copied to a device for testing, smaller is definitely better. It will be easy to drop in higher quality art at the end (it takes the same amount of memory when decompressed, and reading from flash memory is quick, so I don’t expect any changes).

So right now, the game is about 57 MB. My worst case estimate is that it’ll jump up to about 150 MB with the right art. That’s pretty big, but the largest game I have is Monkey Island 2 at 398 MB. And the largest Apple will allow is 2 GB. You won’t be able to download King of Dragon Pass over the cellular network (the limit for that is 20 MB), but over WiFi or with iTunes on your computer it shouldn’t be that bad.

I just learned that the Android Market is raising its size cap, from 25 MB to 50 MB. I wasn’t planning an Android version for various other reasons, but I hadn’t realized that King of Dragon Pass could not be sold through the easiest channel. This puts any future Android version in serious doubt, I’m afraid. Maybe things will change next year.

05 December 2010

The Tribe Map

This screen shot from today’s build tells a lot.

It’s a Big Game
We put a lot of effort into making things feel right. When you’re making a tribe, chances are you’ll want to see where they are. So we had special code to show the current map, rather than a static picture. Similar code is now in the iOS version. (It renders the map into an image, and uses that like any other picture.)

There are other places where we did something just for one scene. Of course we tried to generalize (programmer Shawn Steele was particularly good at this), but if it was important enough (i.e. it supported the story), we did it. The Kallyr storyline needed at least three custom features (for example, she’s the only person who can appear on the clan ring as a teenager).

Better in iOS
Obviously the screen’s smaller, but I’m trying to make things better than the original. This screen shows the new anti-aliased font. Less obvious may be the tribal boundaries.

Originally, we had separate Mac and Windows code to draw this. The Mac code was much simpler, because it used QuickDraw regions. On Windows, we had to manually set each white pixel. iOS doesn’t have QuickDraw, so I used the pixel-drawing code pretty much unchanged. But the pixels no longer need to be white — they’re now drawn with alpha, and are translucent. This means you can see that the river forms a natural boundary — it shows through.

The Same
I hope it also helps allay people’s fears that the game is being changed to fit the smaller device. There are obviously some changes, but playing through the tribe-making sequence today certainly felt the same to me.

01 December 2010


In the original King of Dragon Pass, you could save at any time. Well, from any management screen — saving in the middle of an interactive scene would have been way too complicated, let alone odd from a game design standpoint.

The game would put up a platform dialog (Windows or Mac), where you could type a name if you didn’t like the default (which was just the year and season).

Later, you could choose to restore. The game would put up a standard open dialog, you’d pick the save, and you’d be back at that point.

I wanted to improve on this in a few ways for the iOS version. First, saving is automatic. This needs to be done anyway, so you can take a phone call or check your calendar and not lose your progress. It also means you won’t forget to save.

The date gave you some idea of how far back you were going, but it wasn’t very useful as a guide to exactly what the situation was. And while iOS has a file system, there’s no standard dialogs for selecting files. So this is the interface for choosing when to rewind to:

It’s the Saga screen. The end of each completed year has a Restore button. Tap that, and you’re back at the end-of-year rituals. (It’s a one way trip through time, so you’ll get to confirm that you’re losing progress.)

Interestingly, it also is at least a partial answer to those who call saving just before a heroquest, and restoring if you fail “save-scumming.” You can still go back to a save, but you might have to replay several seasons.

The UI is a little bit hidden, since the saga isn’t the first place you think of to restore. But unlike the original, you don’t need to restore (I assume few people could play a game straight through without needing to quit for some reason). And you will certainly know exactly what you’re going back to, which I think outweighs any drawbacks.

You can only go back, but that’s typically what you want anyway. And while you give up the flexibility of jumping around in time, you don’t have to manage save games. (I saved often, in case some other application crashed my computer — this was the 1990s before preemptive multitasking — so I’d always have a lot of files to delete when I completed a game.)

Other games have dealt with the management issue by having a limited number of slots. It’s possible I’ll keep only the last 10 years (or whatever), but I don’t think there’s much need to worry about it. Saved games are only about 80K, plus the saga. A 100 year game is fairly long, but 8 MB is only the size of a song or two. Let me know (comments here, or on Twitter or Facebook) what your longest game was.

25 November 2010


Much of the time since the last post have been spent on the user interface. And one major aspect of that is fonts.

King of Dragon Pass has a lot of text, so it’s important that text be very legible. Back in 1997, we didn’t have the font rendering technology that we now take for granted. All fonts were bitmaps — just black or empty pixels. Still, it was possible to find fonts that looked decent on screen. Many of them were TrueType or PostScript fonts that came with a specially tuned bitmap version. Those that came with the operating system weren’t good choices for a game, however. Palatino had a decent screen version, but it was just too formal. (And it was only distributed with Mac OS, not Windows.) So we needed to include our own font.

Pre-rendered Erasmus
There were plenty of fonts out there, but in 1997, nobody really sold their fonts to be used in a game. You could create artwork using the font, and include that in a game. But King of Dragon Pass had to draw arbitrary text. To do that, it needed the actual font. And the licensing was either insanely expensive or just not available.

Dynamic Erasmus (bitmap)
So we found a font we liked in a book of samples, and had our UI artist, Brian Fogel, create a font from it. The font was named Erasmus, and he made a TrueType version for use in static UI elements (which were rendered with Photoshop), and a bitmap version that was used for dynamic text. I always felt that our version of Erasmus managed to be legible, distinctive, and playful — all important.

Trebuchet (TrueType)
In 2009 on iOS, font rendering was much, much better — high quality, scalable, anti-aliased fonts. Back then, the choice was limited, and you couldn’t add new fonts. So I chose Trebuchet. It seemed legible, and was a little playful (e.g. the lower-case ‘g’). But it was a pretty standard font (shipped by both Microsoft and Apple), so I wasn’t completely happy.

We had a second font used for titles and buttons, since a single font can get a little boring. When iOS 4.0 came out and allowed font embedding, I used our Erasmus TrueType font. You can see this in earlier screen shots. But it was always a little thin (if I recall correctly, Brian did some Photoshop tricks when creating captions using Erasmus). There was only one weight in the book, and it was Light (which is essentially a step away from bold).

As it happens, since King of Dragon Pass came out, one of the large font makers came out with a version of the Erasmus font. In multiple weights, so we could get a less thin version. Except that the licensing terms were still prohibitive. Basically, it was not available to include with a game.

Somehow hoping to find a decent free version, I kept searching the web. It turns out that Erasmus was created by S. H. de Roos, and he also created an almost identical font, Hollandse Mediaeval. A version of this, Dutch Mediaeval, was available from Canada Type with extremely reasonable licensing. So we could basically use the same font, only better!

Dutch Mediaeval (TrueType)
Here’s what the text looks like with Dutch Mediaeval Book (with Bold responses). It’s almost the same width as Trebuchet, but I think it looks a little more interesting.

(By the way, it looks even better on the Retina Display of this year’s iPhone and iPod touch models.)

I’m happy to have what’s essentially the same font as the original game, both for continuity but also because it’s still legible, distinctive, and playful. And really pleased to recommend Canada Type to anyone interested in embedding quality fonts in a game.

23 October 2010

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.

21 October 2010

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.

07 October 2010

The Caravan Dialog

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).

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.

05 October 2010

The Crafters Dialog

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.

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.

19 September 2010

The Emissary Dialog

King of Dragon Pass has 19 dialogs (the original had 18, but I decided to split out building fortifications, rather than crowd the War screen). Most of these are pretty straightforward, but I was a bit concerned about the Emissary dialog. It’s pretty packed at 640 x 480, how would it work at 480 x 320 pixels? Especially when user interface elements need to be larger for iPhone. The desktop version could get away with packing the radio buttons 13 pixels apart, because you can hit that fairly easily with a mouse. But fingertips need much bigger targets — the iOS Human Interface Guidelines suggests 44 pixels is ideal. And I’ve found that sliders need to be bigger than they were, in order to have any chance at precise manipulation.

Still, it works pretty well. Keep in mind that the artwork isn’t necessarily final. But by putting the goals into a scrolling list, it works.

This dialog is actually an example of King of Dragon Pass’s complexity, by the way. There’s actually a lot of validation going on to make sure players don’t inadvertently do something dumb, like try to end a feud when there isn’t one, or send an emissary to give gifts without actually bringing anything along.

13 September 2010

No Tula Screen

Although it was charming and evocative, the annual Tula screen (which showed the clan lands as an overview) won’t be in King of Dragon Pass for iOS. The graphics would be hard to scale effectively to the smaller screen. And the screen was insanely complex. It had hundreds of graphics (for example, 114 different temple elements, and 51 different elements in the town), which were placed on an isometric grid (the illustration shows what some of the fortifications looked like, on that grid).

And of course, it was sensitive to game play (besides the obvious of showing more cows as your herds increased). Some of your land could turn to swamp, and that was shown on the Tula screen!

I’d rather spend the time supporting iOS features, like fast task switching and Game Center.

It’s possible that some of those graphics can be reused elsewhere, but a 21 pixel high horse probably won’t work anywhere else.

12 September 2010


“A good game is a series of interesting decisions. The decisions must be frequent and meaningful.”  -Sid Meier
That quote was the first topic in my King of Dragon Pass design notes (an Acta outline). We tried to follow this advice. Interactive scenes usually have five options, and we tried to make them all reasonable. “Do Nothing” is sometimes possible, but it's always a conscious choice, and probably has some meaningful impact.

On the other hand, I’m trying to simplify King of Dragon Pass for the smaller iPhone and iPod touch screens. So far, radical simplification has eluded me. But I’ve managed to slim things down a bit. In a few places, I’ve removed the choice altogether (there’s no more Wheat/Barley/Rye choice on the Food screen). Most of the time, I’ve removed options that don’t add much. For example, you can no longer have the Water element as your clan’s ancient enemy (this had almost no impact). And raids can no longer target enemy fortifications.

Most recently, I took out two of the choices for Sacred Time magic. Children and Hunting seemed the least useful. The screen is now less crowded, and you still have 8 areas (16 checkboxes) to spend 7 points of magic.

In one case, I discovered that there was a totally meaningless choice! Somehow there had never been any impact of choosing the Healing of Orlanth as the clan’s first important event. I fixed this bug, since I didn’t want to remove the choice, which serves the narrative purpose of introducing the goddess Chalana Arroy. (two other early events are gone, however).

I’m still looking for uninteresting (or unnecessary) choices, to either remove or make meaningful. Thanks to everyone who has commented so far.

31 August 2010


Like many games, King of Dragon Pass has a map that’s gradually revealed as you explore. Since your ancestors originally lived in Dragon Pass, you have a rough idea of what’s there. The modern map is superimposed atop the historic one. For simplicity, the map is divided into hexagons, and an entire hex is either known (explored) or unknown (historic memory).

Drawing the map was fairly different for the Mac and Windows versions, and pretty much none of the old code that drew hexes could be used. So until now, I’d just been using the historic map as a placeholder.

I’ve now implemented the hex drawing. The game no longer draws individual pixels — even the iPhone has a graphics accelerator. Instead, it creates a mask, and lets the graphics system draw.

Performance seems adequate on an iPod touch, but I plan to come back and optimize if I can (iOS has some excellent performance analysis tools).

One thing that got dropped in the original version was zooming of the map. (I think it may have been partially implemented for Mac only.) But zooming is basically free in iOS. So here’s how much of the entire map you know at the start of the game. Note the scale changes as you pinch-zoom. (You can also double-tap to zoom in or out.)

26 August 2010

User Choices In

As I mentioned earlier, King of Dragon Pass has a pretty wide range of interactivity during a scene. There are almost two dozen ways a script can ask the user for input. All of them are now implemented (though not exhaustively tested). The last was ChooseName, which is actually used in more than two scenes becaue there’s more than one route to a tribe. Here’s a typical one:

response 3: Pick a new name for the tribe.
n = "<.chief>i"
n = ChooseName("What do you call your tribe?", n)

Sliders are used in many of these functions. Here’s what ChooseWealthAndFood looks like in the game. They work pretty well on the small screen (at least for me!), and there’s generally space to show them.

There’s still more scene interaction to implement, but this is mostly running other types of interactivity from within a scene: heroquest, raid, exploration.

A note on prerelease graphics: not only is the art not final (the sliders don’t have the correct transparency), but the scene art intentionally has the highest JPEG compression, so the game loads onto a device more quickly.

19 August 2010

Debugging KoDP

When we did the original King of Dragon Pass, internal builds had some arcane keystroke that brought up an ugly dialog that let you type a scene number, or click one of dozens of buttons to set state or trigger raids. This was invaluable both for developers and for testers — who wants to play until you run out of cows, just to make sure the game handles that right?

Causing a Scene
The game is far enough along that this would be useful. Instead of an arcane keystroke, it’s invoked by an arcane gesture.

The new version is actually a little easier to use, because it shows the scene name.

Once we have external testers, I want to add another feature which will also be much easier thanks to ten years of operating system progress: the ability to email the debug logs to accompany bug reports.

Wreaking Chaos
This has already been invaluable in testing the interactivity code mentioned in the last post.

13 August 2010

Lots to Do

King of Dragon Pass is a pretty big game — over 400 crisis management activities, 75 individual clan leaders, 500 hand-drawn color illustrations, 28 musical compositions. Or you can look at how many words of text are in the game: about 462,000.

But those numbers don’t really have much to do with converting the original game to iOS (the operating system of iPhone, iPod touch, and iPad). The assets can be converted to the small screen with Photoshop batch actions.

King of Dragon Pass has three parts: the game engine (written in C++), interactive scenes (written in our custom scripting language, OSL), and UI code (originally done with mTropolis). It’s the UI that needs redoing for iOS.

The game has something like 30-40 screens or dialogs (not counting help screens). All have to be redone. Many need new layout or simplification, and sliders and buttons have to be hooked up.

We also need to handle the UI for OSL functions like ChooseClan, which lets you pick a clan in the middle of an interactive scene. Here’s a quick look at where we stand so far:
Some of these are relatively rare (if I recall correctly kChooseName is used in only two scenes), but they all need to be reimplemented, and tested.

King of Dragon Pass for iOS

As mentioned elsewhere, A Sharp is bringing its award-winning game King of Dragon Pass to iPhone and iPod touch. The original game was released in 1999, for Windows 95 and Mac OS 7.5. (Amazingly, the game still runs on today’s computers, though not necessarily with ease.)

We have a Twitter feed (@KingDragonPass) to post news and get your comments, but some things don’t fit well in 140 characters. So this blog will talk about the development process.