Status Update

Hmm, about a month since the last one, so let’s summarize how things are going: the game is probably feature complete in terms of code.

Before you get too excited: there are a number of known bugs (some serious enough that you could argue that the feature isn’t really complete). And the game is not content-complete. We want to add some more interactive scenes. And a manual!

However, the tutorial is now in. Some of the edge cases (like a list of usable treasures in battle screens) are implemented. The economic model is simplified: sheep and pigs are abstracted, and barley, wheat, and rye are gone. And thanks to ShareKit, Twitter and Facebook integration are in.

What’s next? Obviously, fixing known bugs! But also getting the new events in the game. We can’t really do much testing until they’re added, because new events break saved games.

But other than some new content, I believe game and UI design are complete. Which is a nice milestone.

Cows Rule

One of my goals for version 2 was to simplify the game where practical. One of the areas players suggested was livestock. In fact, one suggestion was simply to have “livestock” — no cattle, horses, pigs, or sheep.

That seemed too extreme. Horses are a useful resource in their own right because they’re required to equip weaponthanes. They also help bring out differences in your opponents (the Horse-Spawn will capture horses in preference to other loot). And there are several events that deal with the value of horses.

Pigs and sheep have events too, but they’re a bit less important in the economic model: sheep can produce goods, and pigs exploit wildlands. But there really aren’t many interesting decisions involving them (which is one reason the original game didn’t clutter the interface with an option to trade them).

Cattle is the basic unit of wealth. A King of Dragon Pass game without cattle would be like, well, it wouldn’t be much of a game!

So King of Dragon Pass now presents only two types of livestock: horses and cattle. Cattle are a proxy for sheep and pigs. Nominally you’ll have twice as many sheep and twice as many pigs as you do cows (this is subject to available land). Herd magic will work as always, increasing productivity of the specific animal type.

You’ll note that crop types (barley, wheat, and rye) are also gone. They all had slightly different behaviors (e.g. rye had a more reliable output, so it was worth planting when a bad harvest was expected), but crop decisions weren’t terribly interesting, and probably not very meaningful. So they’re gone too.

KoDP Interview

I’ve been interviewed about the setting, history, and art of King of Dragon Pass. Read it at the Hill Cantons blog.

New UI, part 3: Events

The interactive scenes have an improved user interface as well. As usual, it has to deal with the challenge of showing a lot of information, but with a smaller screen than the original. So if you want to see if you can afford to buy a treasure, hide the text (in the iOS version, this is always by tapping on the illustration). This will reveal the six statistics that were always shown in the desktop version.

Or, tap the Info button. This shows an information panel, where you can look up a clan or tribe (using the same filters as in the Relations screen). It also reminds you of the calendar, so you can think twice about raiding during the harvest.

New in the iOS version is access to the saga from an event.

Of course, your advisors are available as always.

An Architecture Overview

“All Gaul is divided into three parts.” So is King of Dragon Pass.

mTropolis code

What you see — the user interface — was all coded with mTropolis (a fine multimedia authoring tool that sadly was killed before King of Dragon Pass was released). mTropolis handled screen layout, responding to clicks, transitions, fading music and sound, and the like. mTropolis could build applications for either Windows or Mac.

The 500+ interactive scenes were all coded in our custom scripting language, OSL. This was designed to be easy for our writer, and to easily express the sorts of interactions we’d designed. OSL source files were compiled into bytecodes with the scene compiler. At run time, these were executed by C++ code.

Finally, there’s the game engine. This consisted of the OSL interpreter, as well as the economic model, which kept track of lots of information about each clan, including their relations with each other. This was all C++ code, and pretty much cross-platform.

Each system communicated only with lower-level ones for the most part. The mTropolis code could talk to the game engine by means of modifiers, special glue code that exposed most of the object properties. And the OSL language was full of functions to pick the least friendly clan, kill a random leader, etc. The OSL variables acted as a convenient shared system as well. For example, the mTropolis UI would set variables to indicate which heroquest and leader the user had picked. The OSL code for the heroquest would use these. The game engine would also set variables depending on the economic situation. And of course, since variables were persistent, one scene written in OSL could respond based on what an earlier one had tracked.

This flow worked for the UI, since the user was switching screens and performing actions. But interactive scenes were a special case, since what the user sees depended on what OSL code did. The original game had two C++ methods which let the game engine (typically on behalf of OSL) talk to mTropolis:  CScene::SendToCurrentScene, which passed along messages like NewChoice (see the chart here for details) or DoDefensiveBattle, and CScene::DebugMessageAlert, which displayed an error dialog.

Interface Builder connections

For the iOS port, the mTropolis code is replaced by iOS code, using UIKit (the high level user interface framework) written in Objective-C or hooked up using Interface Builder. None of the OSL scripts need to change, and only a very small part of the C++ engine needed updating (I did change file handling slightly). Instead of talking to the engine through an mTropolis modifier, the UI code can be written in Objective-C++, and can directly call engine code. And CScene::SendToCurrentScene and CScene::DebugMessageAlert are the only places that the engine talks to UIKit code.

So since two layers are cross-platform, almost all the work on the iOS version has been replacing mTropolis code with UIKit. Although I hope it all feels straightforward, the game’s interface is actually pretty complex, so it’s reasonable to say it’s about a third of the original development effort (not counting art and sound). And it’s a significant development effort for iOS as well.

And the UI layer would need to be recoded for other platforms (such as Android, or even Mac OS X). I expect it would be easier the third time, but it would still be a significant effort. And right now the focus is on getting the iOS version done.

Status Update

It’s been a little over a month since the last status update, so it’s probably time for a new one.

Sadly, in some ways the to-do list is similar: livestock, achievements, social media, manual.

However, there has been progress! We’ve completed the UI work. All screens and dialogs work (including every myth in the Lore screen).

And all of the Game Center achievements have artwork and are entered via iTunesConnect. Now it’s just a matter of implementing them all. There are 45 achievements defined, 19 of which have code behind them. But achievements show up when you earn them, and you can see them from within the game (or of course in the Game Center app).

Also, lots of bugs have been fixed.

I expect to be wrapping up most of the achievements soon. Then I want to start the tutorial, and clean up scenes that refer to small livestock (sheep and pigs).

Back-Patching

A recent comment asked, “any chance the PC version will get some of the bug fixes too?”

A good question, but the answer is “no.”

The original King of Dragon Pass 1.0 was released for Windows and Mac in October 1999. Our last update was 1.7, which came out in October 2002. That’s not a bad record for updating a game. But, if we’re fixing bugs in 2.0, why not also do a Windows/Mac release?

Let’s ignore the fact that neither Windows nor Mac are what they were back then (for example, no Mac that can run Classic has been sold since 2006). More important: to make a new build without introducing a lot of risk of new bugs, it’s not a good idea to switch compilers in mid-stream. For a while, we kept machines with the old development systems, but those have since been recycled. So we’d be faced with either trying to install them (assuming a Mac that could run the 1999 version of CodeWarrior), or hoping that nothing changed in more recent development systems.

I know for a fact that the latter isn’t true. Looking through the development diary, it looks like the random number function changed subtly. (One change that would be for the better: the C++ Standard Template Library is a lot more reliable than when we had to work around bugs in Microsoft’s implementation.) Another change: the C type long is a 64-bit quantity on iPhone, where it was 32 bits on the 1999 machines. I updated the code to the modern world, so it’s no longer going to work with the old.

And the game is now different! I simplified the initial clan generation questionnaire, which means the answers have different numbers internally. Worse, there are new interactive scenes. This means that scene IDs and variable IDs are different. Which means that saved games would no longer work. That’s a big problem, because updates shouldn’t break the game. (We went to a lot of trouble with the original updates to avoid breaking saved games.)

So the long answer:

• No ability to build without risking new bugs
• Language/library changes risk introducing subtle bugs
• Word length ties source code to current platforms
• Design changes break compatibility
• New scenes break compatibility

In theory some of that could be worked around, parts cannot. While some bugs could be fixed for the Windows and Mac release, only the iOS version can have all the new features planned. And if you want to replay the game, why not replay as good a version as we can make?