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.