Most of the player data we reported on a few days ago seems to be holding steady. (Median session length is up, now 4.9 minutes, but that’s not hugely different.) So let’s look at some other data.
Achievements aren’t a big part of the game, but hopefully they can make it more interesting for some players. (As a reminder, you need to be signed into Game Center to earn them. If you haven’t done so from inside King of Dragon Pass, use the Game Center app.)
We keep track of which ones people have earned. The pie chart shows the most popular ones.
I won’t include the complete list here, since some of them give away story elements. However, people seem to be favoring tribal kings (59) over queens (22). And it might behoove you to be kind to your web-footed friends, since the Beastfolk seem to be the most dangerous of the inhumans of Dragon Pass.
Sadly, few people are tweeting from the game (with our marketing budget of $0, we rely on our players to help spread the word), or have discovered the Easter Egg.
27 June 2013
22 June 2013
Player Data
One of the changes in King of Dragon Pass 2.2 was the ability for us to learn something about how people play the game. The release notes mentioned this as
There are a number of metrics systems out there. We chose Flurry Analytics mostly because it’s free, easy to use, and we’re familiar with it. There are other similar services, but Flurry has been around for a while and seems to be a good iOS citizen. For example, it saves metrics until it can send them. If you play offline, you won’t see any impact.
We are also pretty sparing about what we track. We’re curious about whether people are playing on iPad or iPhone. We want to know how hard the game is, so we track wins and losses, and the difficulty level. And we track achievements earned. Other than the basic stuff from Flurry, that’s it. So there’s not a lot of data sent in any case.
Version 2.2 has only been available for a few days, but there have been 4569 play sessions, so there’s enough data that we can analyze it.
The median session length was 4.1 minutes. As expected for a mobile game, it’s played in fairly short bursts. (As I understand Flurry sessions, leaving the game to check your email ends a session.)
As software developers, we need to know if we need to support older versions of iOS. For various reasons, we did have to raise the system requirements to 5.1 or later, so this data may be a bit skewed. But 94.8% of launches are on iOS 6.0.1 or later. Only 5.2% are on 5.1.x. This is pretty close to Apple’s numbers (they claim 93% on iOS 6), which is a nice sanity check. Based on the number of devices that cannot upgrade to the upcoming iOS 7, we would lose 10.4% of our players if we required iOS 7. (No, we’re not planning this!)
And since we have to rework all the screens for each display size, how are those being used? The most popular display is iPad, at 41.7%.
The original iPhone size accounts for 39.4%, and the 4 inch display is already in use by 18.9% of our players.
We also support VoiceOver, and it’s interesting to note that 7.3% of our players have it enabled.
There’s not enough data yet but it appears that more people are winning Long games than Short. But losses greatly outnumber wins. Hopefully that will change over time!
• Added anonymous tracking so we can understand how people playbecause we figured you should be aware we do it. This blog post will hopefully reveal more about what we’re doing.
There are a number of metrics systems out there. We chose Flurry Analytics mostly because it’s free, easy to use, and we’re familiar with it. There are other similar services, but Flurry has been around for a while and seems to be a good iOS citizen. For example, it saves metrics until it can send them. If you play offline, you won’t see any impact.
We are also pretty sparing about what we track. We’re curious about whether people are playing on iPad or iPhone. We want to know how hard the game is, so we track wins and losses, and the difficulty level. And we track achievements earned. Other than the basic stuff from Flurry, that’s it. So there’s not a lot of data sent in any case.
Version 2.2 has only been available for a few days, but there have been 4569 play sessions, so there’s enough data that we can analyze it.
The median session length was 4.1 minutes. As expected for a mobile game, it’s played in fairly short bursts. (As I understand Flurry sessions, leaving the game to check your email ends a session.)
As software developers, we need to know if we need to support older versions of iOS. For various reasons, we did have to raise the system requirements to 5.1 or later, so this data may be a bit skewed. But 94.8% of launches are on iOS 6.0.1 or later. Only 5.2% are on 5.1.x. This is pretty close to Apple’s numbers (they claim 93% on iOS 6), which is a nice sanity check. Based on the number of devices that cannot upgrade to the upcoming iOS 7, we would lose 10.4% of our players if we required iOS 7. (No, we’re not planning this!)
And since we have to rework all the screens for each display size, how are those being used? The most popular display is iPad, at 41.7%.
The original iPhone size accounts for 39.4%, and the 4 inch display is already in use by 18.9% of our players.
We also support VoiceOver, and it’s interesting to note that 7.3% of our players have it enabled.
There’s not enough data yet but it appears that more people are winning Long games than Short. But losses greatly outnumber wins. Hopefully that will change over time!
20 June 2013
More to the Story
We’ve just released an update to the iOS App Store. Version 2.2 adds 19 new interactive scenes. Many of these make use of existing artwork (you’ll spot some recurring characters), but we commissioned three new paintings by Jan Pospíšil.
Since our last major update to King of Dragon Pass, Apple came out with the iPhone 5 and a new iPod touch with 4 inch screens. We’ve reworked over 30 screens to take advantage of the larger screen — in particular, more of the artwork is visible during an interactive scene.
Thanks to composer Stan LePard, the music now plays in stereo, and gets a bump to CD quality.
One feature from the original game is now in the iOS version: when raiding a distant clan, you may need to negotiate with a clan that’s en route.
And there are new treasures and more variety in the year-end news report.
The one thing there’s less of: bugs. We’ve gotten rid of a number of bugs and typos. (Thanks especially to the vigilant Zack Kline for reporting typos.)
Here’s the detailed release notes:
Dragonewts on iPhone 5 |
Thanks to composer Stan LePard, the music now plays in stereo, and gets a bump to CD quality.
One feature from the original game is now in the iOS version: when raiding a distant clan, you may need to negotiate with a clan that’s en route.
And there are new treasures and more variety in the year-end news report.
The one thing there’s less of: bugs. We’ve gotten rid of a number of bugs and typos. (Thanks especially to the vigilant Zack Kline for reporting typos.)
Here’s the detailed release notes:
• 19 new interactive scenes
• Upgraded music to CD-quality stereo (thanks to Stan LePard)
• Support iPhone 5 screen size
• Take clan proximity into account when raiding
• Track notable deaths in saga
• New treasures
• More annual scuttlebutt
• Tint tribal areas on the map
• Various improvements to advice
• Show relevant changes to advisor images during a scene
• Battle situations don’t leave blank lines in the saga
• Fixed a bug that allowed indefinite raiding during Sea season
• More accurate determination of exploring certain areas
• Fixed typos and bugs
• Fixed a memory leak in VoiceOver play
• Added anonymous tracking so we can understand how people play
• Now requires iOS 5.1
App Store ratings reset with new versions, so please consider giving this version a rating or review.
So that’s 2.2, but we have plans to add even more scenes in a future update.
So that’s 2.2, but we have plans to add even more scenes in a future update.
08 June 2013
Architecture Redux
I’ve mentioned the game’s architecture before, but understanding it helps answer some common questions, so I thought I’d draw a picture.
The game has three main divisions. In the original version, different developers were more or less responsible for each.
The user interface (the 50 or so screens and dialogs) were created for the Windows and Macintoshes of the day (that day being somewhere between 1997, when we started the project, and 1999, when it was released). We used mTropolis, a powerful multimedia development system that was discontinued over a year before the game came out.
The interactive scenes (and news) were coded in OSL (the Opal Scripting Language, or the Opal Scene Language).
The game engine, written in C++, executed the OSL code, ran the economic model (tracking cows and the effects of treasures on them), and was responsible for saving the game. It was cross-platform, running equally well on Mac OS and Windows.
When we created a new version for iOS, the basic game code and the scenes didn’t need radical change. Both were enhanced (for example, the game had more advice and supported 7 new treasures, and there were 28 new scenes) but existing code continued to work. By contrast, none of the user interface code could be used. Not that it would have mattered much, the small touch screen needed a new user interface anyway. This was a very substantial effort, and it ended up being partly duplicated for iPad and again for the 4 inch display.
There are numbers in the diagram because they suggest why the iOS version is distinct from anything else. Saved games assume a specific number of scenes and treasures. Adding more would mean substantial reworking of the C++ code. But this code had to work with mTropolis, so it’s tied to 1998 era systems. The hardware and compilers I used back then are long gone.
So that’s why the GOG Windows version can’t be updated.
Some have asked about a new Windows or Mac version, or an Android version. Since mTropolis no longer exists and UIKit is iOS-specific, any version for any other platform will require reworking the user interface (possibly with some redesign, definitely a brand new implementation). Think of it was rewriting a third of the game.
The first iOS release took about 20 calendar months. Since the C++ code didn’t need significant updating, the user interface could thus be said to be about half the code needed for that project.
Actually, there was some new C++ code, because we wanted to add Game Center achievements. Most of this would work on Mac OS X, but not on other platforms.
So unlike the original version, where it was trivial to build for both Mac and Windows, there’s a daunting amount of work to bring the game to another platform.
What we’ve done instead is reflected in those numbers: reworking the 50 screens for iPad (and soon the iPhone 5). And adding new treasures and new scenes in an update we hope to release this month.
The game has three main divisions. In the original version, different developers were more or less responsible for each.
The user interface (the 50 or so screens and dialogs) were created for the Windows and Macintoshes of the day (that day being somewhere between 1997, when we started the project, and 1999, when it was released). We used mTropolis, a powerful multimedia development system that was discontinued over a year before the game came out.
The interactive scenes (and news) were coded in OSL (the Opal Scripting Language, or the Opal Scene Language).
The game engine, written in C++, executed the OSL code, ran the economic model (tracking cows and the effects of treasures on them), and was responsible for saving the game. It was cross-platform, running equally well on Mac OS and Windows.
When we created a new version for iOS, the basic game code and the scenes didn’t need radical change. Both were enhanced (for example, the game had more advice and supported 7 new treasures, and there were 28 new scenes) but existing code continued to work. By contrast, none of the user interface code could be used. Not that it would have mattered much, the small touch screen needed a new user interface anyway. This was a very substantial effort, and it ended up being partly duplicated for iPad and again for the 4 inch display.
There are numbers in the diagram because they suggest why the iOS version is distinct from anything else. Saved games assume a specific number of scenes and treasures. Adding more would mean substantial reworking of the C++ code. But this code had to work with mTropolis, so it’s tied to 1998 era systems. The hardware and compilers I used back then are long gone.
So that’s why the GOG Windows version can’t be updated.
Some have asked about a new Windows or Mac version, or an Android version. Since mTropolis no longer exists and UIKit is iOS-specific, any version for any other platform will require reworking the user interface (possibly with some redesign, definitely a brand new implementation). Think of it was rewriting a third of the game.
The first iOS release took about 20 calendar months. Since the C++ code didn’t need significant updating, the user interface could thus be said to be about half the code needed for that project.
Actually, there was some new C++ code, because we wanted to add Game Center achievements. Most of this would work on Mac OS X, but not on other platforms.
So unlike the original version, where it was trivial to build for both Mac and Windows, there’s a daunting amount of work to bring the game to another platform.
What we’ve done instead is reflected in those numbers: reworking the 50 screens for iPad (and soon the iPhone 5). And adding new treasures and new scenes in an update we hope to release this month.
Subscribe to:
Posts (Atom)