King of Dragon Pass — Postmortem
Jan 06, 2012—
It was originally created from 1997-1999 as a game for any Windows or Mac computer of the day. Although it was long out of print, we kept getting occasional requests for a copy. So in 2009, A Sharp began bringing the game to iPhone.
The game market had changed a lot since the old days of shipping boxes, so we wanted to update the game, beyond just adapting it to a smaller touch screen. It wasn’t realistic to turn it into a casual game, but we wanted to simplify it where possible. And for people who had already played, we wanted new content.
At the same time, we had some big resource constraints: there weren’t any. We had the digital assets from the original, but no ability to rescan artwork. Restarting the artwork pipeline wasn’t practical (as well as the fact that artwork was originally the major budget item). And making big changes could in theory require once again exhaustively testing every interactive scene. We wanted to keep the schedule from dragging on as well as avoid costs.
The iOS conversion was not only separated by 10 years, but a completely different sort of project from the original development effort. This postmortem covers only the process of creating a new game from the old one. (idevgames published a postmortem of the original game back in 2001.)
What Went Right
Our original instincts about playability turned out to be correct: King of Dragon Pass really does work well on iPhone and iPod touch. We’ve heard over and over how the episodic nature of the game makes it perfect to play a turn or two while waiting for a train. At the same time, there is a lot of game — nobody sets out to deliver 40 hours of game play any more, but we managed to fit all of that in your pocket.
While the graphics are smaller than the original, they still look very good. The game relies very heavily on text, so we didn’t reduce its size, in order to maintain legibility. In fact, because iOS has anti-aliased text, it looks much better now than it did in the original game (and that’s not even taking a Retina Display into account). And while for the original game we created our own font (scanning it from a book of royalty-free fonts because nobody licensed fonts for inclusion in a game), we managed to locate a version of the very same font, professionally done and with rational licensing terms.
While there are some compromises in the user interface due to fitting a complex design into a small screen, the design works well here. Early prototypes showed that the game would work OK, but we had a number of design iterations (facilitated by a shared Dropbox folder) to come up with something that would be both functional and attractive, as well as being in the spirit of the original game. There were a couple of ideas that we had to pass on because the underlying game couldn’t be easily changed.
We’re currently working on an iPad-sized layout. Arguably this should have been in the original, but it also would have been a significant delay. And being forced to focus on the small screen experience made sure we got that right.
The original game was never particularly easy, especially at the higher difficulty levels. We renamed the levels to help encourage people to play at “Normal” rather than thinking “Easy” was for less skilled players. We also attacked the death spiral, making it less likely that a player would be wiped out by random events like two bad harvests in a row. (Dealing with harvests is still part of the game, but the game now puts more emphasis on a fun experience than realistic simulation.) We made an extensive list of levers, and figured out ways to tweak most of them.
But the game system as a whole is pretty complex, with a lot of moving parts. We almost got game balance wrong because some of the effects didn’t show up until later in the game. Notably, when you get successful, your wealth draws attacks from other clans. This got way out of hand, but required a lot of game play to reveal. In retrospect, we probably should have captured a range of metrics, and analyzed them. Instead, we relied on ad hoc tracking and anecdotes.
The original game makes heroquests hard to succeed at, since they can give very significant benefits. We didn’t change that much, but did make them easier to play by adding heroquest hints (so the player doesn’t have to be quite as good at memorizing the underlying myth).
It may seem odd to talk about “team” for what was essentially a one-person, part-time project (especially compared to the original game). But there were key contributions from a number of people, who helped improve the design (as well as simply finding bugs). Our attempts to build buzz for the game were probably most useful in recruiting help, both from original fans and people who had only heard about but never played the game.
And I should also mention that despite the resource constraints, we did pay our artist.
The code for King of Dragon Pass was divided into three parts: UI, interactive scripts, and a game engine which ran the scripts and the economic model. Although the original UI code was not usable (since it was written in the long-obsolete mTropolis and not intended for touch), the basic point-and-click approach was easy to adapt to tapping. The scripts didn’t need any changes. And the core game engine, written in C++, was already cross-platform. It needed very little effort to get up and running on a third operating system. (There was one bug related to the fact that the default word size on iPhone was bigger than back in the 1990s.)
Performance was never an issue either. We could use the high-level UIKit without worrying about dropping frames. Memory was a bit of a constraint, but careful use of Instruments (Apple’s analysis tool) helped keep that in bounds.
The original game had only a few well-defined places the UI code interacted with the game engine, so it wasn’t especially tricky replacing the mTropolis code with Objective-C. The biggest challenge was figuring out exactly how the game worked in a couple places where logic had been in the mTropolis code. Luckily there were some good design notes, but once or twice we had to fire up a ten year old machine to try tracking something down.
King of Dragon Pass is now completely playable by blind players, thanks to Apple’s VoiceOver technology doing most of the heavy lifting. This took some work on our part (which we deferred until the initial release), but was mostly straightforward. Coming up with a way to make the map usable was the biggest challenge, but since game play doesn’t really depend on specific spatial relationships, we focused on the exploration aspect (which does impact play).
Although VoiceOver is great technology, it is harder than it should be to deal with certain dynamically changing elements on a screen. We’re pleased that the whole game is accessible, but not as happy that certain things are more awkward than they need to be. Maybe Apple will give us more flexibility in a future release.
What Went Wrong
King of Dragon Pass is a complex game. In many ways that complexity is part of its appeal — the real world (or the fantasy world of Glorantha) is a complex place, and the game’s replayability is due in part to the number of options. But game play was much more complex than it needed to be.
We were able to clean up the game in a number of areas. The economic model is simpler, some of the more mechanical decisions are made by the computer, and there are fewer choices in combat and the introduction.
But that’s about it. The original game was just too interconnected, and couldn’t be easily changed. For example, we discussed reducing the number of management screens, but important advice is tied to each of the original ones. Perhaps the original goal wasn’t realistic, but we didn’t really hit it.
A good tutorial is one way to help patch an overly complex design. The King of Dragon Pass tutorial (which is pretty much identical to the original) is probably not a bad way to introduce the game, but it only goes so far. We’d had vague ideas about extending it, but never did. It was always intended to make you aware of game play elements, with the manual as the real explanation.
Worse, the tutorial is extremely fragile. It’s supposed to follow along with a tightly-scripted first year of play. But players can easily make decisions that jump off the rails. This didn’t matter as much when it was just text in the manual, but when the game displays irrelevant text, it’s annoying at best.
We had great beta testers, but probably placed too much reliance on the fact that the original game had been out for years with no major issues. We attracted more players than the original, and new bugs surfaced as a result. And not having the original build system meant that we didn’t realize that the original game had shipped in a debug configuration, rather than a release build. It turned out that the debug build’s logging feature actually masked a serious bug. We quickly released an update with logging enabled. This probably would have been a good idea in any case, since it makes it easier for players to report bugs. But as a bug fix, it was a kludge.
This bug would probably have been discovered in the original game if we’d had unit tests. Porting the game had gone so smoothly that we didn’t create any automated tests for old code. We could definitely do more there.
Apple’s 100-device limit was definitely a constraint on our testing. We could have had a lot more testers (and found more bugs earlier) if we hadn’t had to ration how many prerelease we could send out.
And while we had great beta testers, they’re not a complete substitute for an internal QA team. On the other hand, iOS made it easier to get as much value from the tests as we could. It was simple to add email capability so testers could send us debug logs from within the game.
We included Twitter, Facebook, and Game Center integration in the game because they were supposedly a big deal. Unfortunately, we haven’t seen any evidence that they have been. As a guess, only 1% of our players have used in-game tweets. It’s entirely possible we didn’t do a good job integrating this into the game. But we never want to post on the player’s behalf, and the game design doesn’t support remote friends (as opposed to one reading over your shoulder). We probably should have just ignored the trendiness and not spent any development effort.
While we have no evidence that the Game Center integration helps spread word of the game, at least the achievements add a bit to the play experience. Most players probably don’t care about collecting all the apocalypses, but at least you can.
The game took a lot longer than expected. This is hardly unusual in the game business, but still something that we could do better. We didn’t even try very hard — we did have some rough estimates early, but in general didn’t update and refine them, using the excuse that this was a part-time project. It’s true that we weren’t trying to hit any particular external deadlines, but if we’d known the target more accurately, some of the technical decisions would have been easier, and the code cleaner. We could have gone with the latest version of iOS and let the market share catch up. And it was not as effective to try to drum up interest in an upcoming game when we had to waffle about when it would be out.
The scope of the game was occasionally bigger than expected (the secondary dialogs from the Sacrifice dialog somehow didn’t make the task list), but it was the testing time that was probably the least accurate.
King of Dragon Pass is a successful adaptation of a CD-ROM game. It’s brought the original game to a new audience. A few fans of the original miss the overview screen we cut, but most comparisons say the iOS version is better than the original. Published reviews are also quite favorable (92 on Metacritic). While the game isn’t a true hit (it’s not even a disgruntled bird), it’s selling quite respectably for an indie title (and has already outsold the original by 2x). Doing it has also taught us about making a game succeed in the App Store, if we get to do another game of this scope.
|Game||King of Dragon Pass|
|Engine||Custom Objective-C, C++, Opal Scripting Language|