Showing posts with label iPhone 5. Show all posts
Showing posts with label iPhone 5. Show all posts

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.

Dragonewts on iPhone 5
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:
• 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.


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.

12 May 2013

4 Inch Display

I really have to wonder when I see a one star review in the App Store that reads: “I have to give 1 star to any game that doesn't optimize for the iPhone 5... Its just to easy of a fix.” (sic)

One star? Really? The game is awful because it was created before the iPhone 5 existed, and has not been altered to use the wider screen? If the reviewer stopped to think at all, is adding 88 pixels of width to a landscape game really going to make that much difference? In other words, is this screen
really so incredibly worse than this one?

In almost every possible case, getting extra width buys you very little with a landscape application. Text lists still scroll vertically, and the landscape height of an iPhone 5 screen is exactly the same as the landscape height of every other iPhone. So a bigger screen doesn’t mean less scrolling.

As for easy, it turns out that we had to rework 31 different screens. In many cases, it was an easy enough transformation, like the one above. But there were cases where because we’d put in so much effort making sure the game worked on the original iPhone that it needed new design and coding to work on a different layout. In particular, for the one area where the game can be a little better on the iPhone 5’s 4 inch display. Interactive scenes always allow you to view the entire illustration, but during play it’s partially covered with text.

On the wider display, less of the picture is obscured.

(I suppose we could show more text instead, but as shown above, it doesn’t always need to scroll. It seemed like a better tradeoff to favor art over text.)

Obviously it’s better to fully support the new screen size, but we could have used the money to commission new artwork instead of new versions of the same user interface elements. And used developer time to create new scenes, instead of redoing 31 different screens to show 18% more pixels (18% more blank parchment in many cases).

As you might have guessed from the screen shots, we are in fact adding new assets and code to support the 4 inch display as well as the 3.5 inch display on iPhone and iPod touch. But it’s because Apple now requires this, not because this game really gets better because of this effort.

15 September 2012

Letterboxed

The rumors were correct, and there is now an additional screen size for iOS: 320 x 568 joins the original 320 x 480 iPhone and 768 x 1024 iPad*.

It’s unlikely that the game will directly support this layout. Sure, 88 more pixels would be nice, but King of Dragon Pass is a landscape game, and extra width isn’t as useful in most cases as extra height would be (most scrolling is vertical). The original art was at a 4 x 3 aspect ratio, and already doesn’t always nicely fit the 3 x 2 iPhone.

Also, unlike the situation on iPad (where until the 3rd generation, running at 2x had pixelly text), the game works as well as always. You just get 44 black pixels on each side, letterboxing. We don’t have an iPhone 5 yet but running in the Simulator, it looks fine. And you’ll even be able to use the full screen for keyboard input.

* Purists may note that the iPhone 5 has a 640 x 1136 pixel display. Technically this is true, but from a design standpoint, it works better to think of 320 x 568 pixels, with the possibility of fine detail.