Telling a Tale … Where Download-Code Sucks

I’ll be the first to admit that I love what Telltale Games have done to the long ago diseased adventure game genre. I played the Monkey Island Games via Steam, got Wallace & Grommit even though I don’t even possess a PC (unfortunately not available for Mac) and I loved the first episode of “The Walking Dead” on my iPad.

A mere 14 hours ago Telltale released the second episode for iOS but it turns out that their episode downloading code is utter crap. Much to my frustration because I am trying to get this episode for playing for around 10 hours now. It is quarter to 11 pm and I have reached a point where I need to vent my chagrin in a blog post.

If only to tell a tale how NOT to construct code that downloads many hundreds of megabytes.

The big annoying problem with episode download can be summed up in this message:

This message is a symptom of so many bad ideas.

Of course I understand that graphically rich games like The Walking Dead require hundreds of MB of data. It is the job of the developers to make sure that the download experience is the least possible annoyance to the user. The current version of the download code does a bad job at this.

On entering the episodes screen iTunes is pinged for a list of available In-App purchases. The ones that are configured are then displayed as visible for download. Of course I had bought the “season pass” because episode one had done a great job hooking me on the new series. Sadly the first letdown of the game was that I only learned that a new episode was available by googling it. Haven’t they heard about push notifications?!

They had to get a unique app id provisioning profile anyway for enabling the IAPs, why not also enable push? Everybody who springs for the whole season has a right to learn at the earliest possible moment that new content is available for download.

The game itself is a whopping 329 MB, one would assume that this is about the size of an episode. Though even this is not certain because I remember having to wait exceptionally long when I launched the game the first time. It could also have been the case that they downloaded even more content during this time. Or maybe they uncompressed it, we’ll never know. So “hundreds of MB” is the best guess we have.

I peeked into the network traffic and found to my surprise that there were only two HTTP GET requests to the Telltale home page, but no trace of any other communication. Google does the same with their Ad network. You don’t see anything with Charles Debugging Proxy, but packets galore on other network snooping apps.

One can only assume that this is because they are afraid of somebody stealing the content. Certainly if you could simply get the content at a normal HTTP URL with a regular GET command it would take no time at all for crackers to download and re-package these coveted episodes and put then online illegally.

But what disturbs me that Telltale saw it necessary to add this level of copy protection instead of going for a good user experience first. The downloading doesn’t even do background completion for crying out loud! If you leave the app (e.g. home button) and return there was no progress made at all. A better mechanism would let me do something else with my iPad and then inform me via local push notification that the download has completed.

Oh, but I keep forgetting, background task completion only works if the process can finish in under 10 minutes. There might have been a workaround to ask the user to return before this time is up to get another 10 minutes of background downloading. Oh well, that might not really be a simple option after all.

BUT – BIG BUT – why in God’s name didn’t they implement download resuming? That is so easy to do, just look at my DTDownload class in my open source DTFoundation project. Oh, here the custom downloading functions again prevent this: you need to be using HTTP or HTTPS to benefit from range downloads via NSURLConnection.

They couldn’t have used NSURLConnection for the simple reason that if you use that then your traffic will have to pass through the system HTTP proxy if set. And then I would see it in Charles. So they are using something at a lower level that is not forced to go through the proxy. That brings with it another potential problem: HTTP (using TCP, as opposed to UDP) guarantees completeness of data. Missing packets are automatically and transparently re-transmitted. By not using HTTP and TCP they would have had to implement their own scheme to deal with lost data packets.

By this time I am beginning to feel sorry for the guys at Telltale who where tasked with this download mechanism. This all reeks as being dictated from above. No sane iOS developer would program the network stack like this, totally avoiding all the good and reliable things that Apple provides.

The process for download resuming is relatively simple: you download as much as you can and append the downloaded bytes to a file on disk. For resuming you then tell your server to continue with the next byte until the end of the file. Ideally you’d transfer it in a single ZIP file – to avoid unnecessary gaps and handshakes – and then you’ll unpack file on the client.

The next faux pas stems from the developers obviously never having tested their download code in “connectivity-challenged circumstances”. There are occasions where the download was so slow so that the iPad went into standby half way through. Of course you would then get the above mentioned error screen on relaunching the app. Back to square 1. $%§&§%!!

The final straw was one situation where the app insisted that my internet connection was offline even though I was able to surf with Safari. There is a known bug in Reachability where coming back from standby would still have the app believe it was offline. The workaround in this case is to stop the notifier when going into the background and to resume the notifier as soon as the app comes to the foreground again.

I cannot readily prove it, but I get the feeling that Telltale is not hosting their content on a CDN like Apple does (Akamai). But instead those hundreds of megabytes are coming across the big pond to Europe where I am located. This exacerbates the problem because I found that bandwidth suffers after around 8 pm when everybody is downloading stuff from America. One example is that until 7 pm or thereabouts I can rent a movie from iTunes USA and watch it while its downloading. That usually becomes impossible after 8pm.

I would bet they instead went for Amazon’s servers. Amazon is great for the US, but sucks for everywhere else because they lack local mirrors.

Conclusion

So let us summarize all their faux-pas:

• no background task completion
• no download resuming after an interruption
• allowing the iPad to go into standby while the download is not complete
• not testing for bandwidth-constrained scenarios
• not testing for abort conditions that would leave the app stuck unable to proceed without being killed (aka Reachability bug)
• not hosting on a Content Delivery Network (like Akamai)
• their fear of piracy dictated what they could technically do
• not using NSURLConnection and tried and true HTTP

Let this be a lesson for everybody who also faces the necessity of large DLC packages.

If it is at all feasible I would continue downloading in the background and inform the user when necessary about completed or interrupted download. Allowing downloads to resume is even more important as to not frustrate users, especially if low bandwidth caused them to wait excessively long already.

Imagine downloading like 95% of an episode and then getting the dreaded error. Just one example:

@cocoanetics i feel with you. I looked at my iPad and it said 95.35% 5 minutes later it said. Connection lost 🙁

— Andreas Manneck (@Hetemann) August 30, 2012

C’mon Telltale, you CAN do better. Please implement download resuming before shipping episode 3. Strangely enough while I was writing these lines the app finally finished the download, it must have been about the 10th or so attempt. So I’m now off playing this otherwise awesome game!

Categories: Copy Protection