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