Page 1 of 2

repeated iPad load failures and crashes

Posted: Fri Feb 17, 2017 8:46 pm
by WaterGuerrilla

Because we have been unable to get ARIS for Android to work, our team leadership obtained several iPads in order to display our game at a public event coming up on Tuesday.

We've run the game successfully on iPhones, but not yet on iPads. Today we experienced significant failures with iPad load failures and crashes.

Is it because our game is too large?
Is it because of some code conflict?
Is it because of an ARIS bug?
Is it because of slow Wi-Fi speeds?
Is it because of failing ARIS servers?
Is it because of some other reason?

We concurrently tested the game and it works on iPhones, my phone, Justin's phone, mom and dad's phone.

Crashes before/after load on Arts @ Large iPads (3 different ones, with three different functional user accounts) and Mom and dad's iPad and fails to load on their iPad Mini.

iPad specs are all: 9.3.5 (13G36) all with sufficient Data Storage and connected via Wi-Fi. All loaded most recently available version of ARIS. ARIS downloads, but our game fails to load.

Data partially loads, stalls, then ARIS app crashes. Repeatedly on five distinct devices.

ARIS app is able to load functional initial scenes in iPads for other, smaller, simpler games, just not ours. I don't know what the problem is or how to test for what the problem is given that I can't access our game through iPads.

Does anyone have any ideas, similar experiences/best practcies, or solutions?

I am currently duplicating our game in order to strip out parts of it nonessential to our Tuesday public event and try to provide a smaller, simpler version to test, but duplicating process initially had duration of over an hour and I had to leave that location and re-establish another Wi-Fi connection and try again. It is currently spooling but there is no progress indicator to suggest how long this will last.

Thank you, ARIS community, for any support or advice.


Re: repeated iPad load failures and crashes

Posted: Sat Feb 18, 2017 10:41 am
by djgagnon
I was able to confirm that your game does crash most devices. It appears that anything older than an iPhone 6 runs out of ram and crashes during load due to the size of the media In the game. Given more time we could work with you to come up with a fix in ARIS that would ply more nicely with older devices and lots of media.

Even without the crashes, however, you very well will encounter lots of fils that don't have ~300mb of free space on their device.

That said, the real fix is to reduce the size of your game's media.

Do you have all your media in a separate folder on your computer? If so, you could scan the file sizes and see which ones could be easily reduced. If not, I could run a quick report for you but it would take some time because it's not a feature built into the editor.

Also, you should remove any media that is large and isn't being used. Even unused media downloads to the device during load.

After the dust settles, we could discuss ways to make this game more optimized for mass use across many different devices.


Re: repeated iPad load failures and crashes

Posted: Sat Feb 18, 2017 6:02 pm
by WaterGuerrilla
Okay. Good to know. Thanks for testing this independently and for the analysis. I will post with an update/s re: a scaled-down game. Do you have a rule-of-thumb maximum data threshold we should consider? 50MB?


Re: repeated iPad load failures and crashes

Posted: Sat Feb 18, 2017 6:15 pm
by djgagnon
I wish I had a clear rule here. It's like the Web or console game development: Optimize it as much as you can by compressing each file as much as you can. Then test,test,test across devices, users, internet connections, etc.


Re: repeated iPad load failures and crashes

Posted: Sat Feb 18, 2017 11:32 pm
by WaterGuerrilla
Update: I carved out 184 MB of media from our bloated game file so that our game data is now 90.7 MB of which 85.5 MB is our game and of which about 60 MB are videos.

The game loads onto the test iPad now without a hiccup. It does not run as smoothly as it does on iPhone and still occasionally crashes. It runs quite slow and I noticed that the cut-and-paste javascript I just learned how to use which on iPhone is almost instantaneous, on iPad lags such that you see the // documentation lines for a second as the plaques flicker and I am imagining that the iPad thinks about the javascript, decides whether it really wants to do it like it's Marvin the Robot contemplating an automatic door, and then shrugs its solid-state shoulders and executes it. Some of the time, it fails to execute it and it crashes a command that otherwise runs smoothly on iPhone.

So I reconfigured our game design to be terribly simple so that ARIS and iPad don't have to "think" as much, so almost everything is linear, so that we almost never use the Tabbed Menu, but at least the content does load promptly and the procedures essentially run. Half the time when going to the Map, ARIS still crashes (that could be related to the fact I switched over to Local Evaluation instead of Server Dependent...? or it could just mean the iPad is too slow...), so for our upcoming iPad demo, I have carved out the Map function so we're almost purely just moving directly between plaques and conversations without any user flexibility. We'll just tell people this is what they will unlock when they arrive at our site. This will serve for the demo on an iPad where these are stationary stations, but is unfortunate considering the theoretical capacity of ARIS, which I am finding to be limited by its practical capacity.

One thing this is teaching me: my earlier qualms about Notebook are doubly justified. Not all our game data bloat was from player Notebook posts (most of it was our own media files from other sites or sites in development, some of which we will have to figure how to incorporate into our overall user experience in some way at some point, perhaps as interlinked games rather than one biggish one), but enough of it was from user Notebook posts that if we were to release this to the public and invite them to use Notebook to post content, the game would rapidly get too unwieldy data-wise no matter what. I cannot count on Notebook to perform the function it's for. We are going to have to imagine how to route our users to a Facebook group to post their user-generated content. My previous qualms about Notebook were that it was difficult to use, hard to segregate from game play, and generally clunky. Now, the data bloat rationale is going to motivate us to avoid Notebook altogether.

Is anyone using Facebook for ARIS logins or cross-connecting with Facebook in lieu of Notebook or similar functions? Any possibility of having ARIS sense Facebook tags or having some intercommunication between the two could allow--theoretically--for tagging in broader social media space that could still be read as ARIS triggers? That would be useful as it would extend the realm of relevance of our game and ARIS beyond the fishbowl. I'm not sure how that connectivity might work from a technical standpoint. That's the only piece that Notebook offers directly that other social media does not--that its tags can be considered with the internal ARIS game logic. But for now we will have to sacrifice that for base functionality across more devices. This is unfortunate because it means that a whole spectrum of in-game incentive mechanisms is lost--I can't nudge players to post/tag stuff to get points or unlock bonuses if what they cumulatively would be posting just gets too large to be handled.

In reference to my other post about difficulties with Game Duplication, later on this evening I did notice that one duplicate game did populate my editor menu (although now the challenge will be to eliminate the two other ghost partial games that may or may not be visible to other ARIS users--presumably partial duplications that I can see as a user but not access as an editor...perhaps that issue will resolve itself over time?).

I have not yet explored the linking to YouTube option to further reduce our media data footprint and will report back to this forum with any observations if/when we are able to try that. If others have gone this route, I would definitely be interested in learning from your approaches.

I appreciate everyone's support and hope that this lengthy log may serve to help others with an example of the data size of the ARIS game having an impact on whether it will load and whether it will function on some devices. I'm not sure that the sluggish performance on iPad itself is attributable to the data size of the game, however. I suspect as David suggested the data size impacted whether or not it would load at all. But there may be other performance issues either related to my particular game design that cause problems or to older iPads vs. newer iPhones and ARIS.


Re: repeated iPad load failures and crashes

Posted: Sun Feb 19, 2017 5:48 pm
by WaterGuerrilla
I am noticing two things.

1. Whenever the player goes to the Map on the iPad, ARIS crashes; same maneuvers on iPhone do not crash.

2. The version of ARIS on the iPad is 20161220 but the version that seems to work on my iPhone is 20160824.


Re: repeated iPad load failures and crashes

Posted: Mon Feb 20, 2017 7:59 pm
by WaterGuerrilla
Update: testing on iPad and app is fairly stable today. Our big day is tomorrow, so hopefully the kinks are sufficiently ironed out for our public demo.

A few notes: in lieu of Notebook as an aggregator of user-generated content, I am proposing/inviting our users to use a unitary hashtag when they post to social media. For us, this will be #waterstorymke. Long term, we will investigate how to incorporate these posts into our ARIS game mechanics. I am thinking there may be a way to do this with ARIS links to web pages accessed via social media that we privately host on unlinked pages of our website with a text string that is entered into the ARIS decoder to unlock scenes/attributes, etc. We don't have that built yet, but this is how I imagine we will circumvent the Notebook data bloat hurdle. I've also been reading Chris's book, Mobile Media Learning, and absorbing some of the albeit a bit dated case studies from classroom ARIS use, which may also prove helpful longer term.

I will cross-post the following detail in its own field on the forums, but we also recently discovered the exciting existence of Aurasma. This could prove a really sexy counterpart to fold into ARIS games. And I can imagine various uses in-game.


Re: repeated iPad load failures and crashes

Posted: Wed Feb 22, 2017 12:31 pm
by chrish
I'll be crossing my fingers for you guys. Pulling off a big implementation like that is tough. I really appreciate you sharing your notes with us about where the rough edges are too. Not only for hopes that ARIS can be better but so that other authors with similar aims might not need to go in totally blind and can avail themselves of some of your workarounds.

And thanks for giving the book a look. As you say, the tech that was current when it was written is now out of date (books about cutting edge tech are hard that way) but I really get a lot out of going back to those stories for their motivation and problem solving around where and what educators can make of their spaces using tools like ours and also the MIT stuff: taleblazer, app inventor.

Re: repeated iPad load failures and crashes

Posted: Wed Feb 22, 2017 1:50 pm
by WaterGuerrilla
Thanks. Yesterday's event went well. The app was stable. We demoed the stripped-down leg (~1/10th of our total game content that is expected for our July 22, 2017 citywide scavenger hunt public launch. About 20-30 people were able to try it out on three iPads, with various degrees of interest, engagement, and inspiration. Our event overall attracted ~250 guests, so we achieved significant exposure and all in all it was a success.

I'll be itemizing bugs and other feature requests in a future post separate from this thread.

The executive summary is that the stability of the Tabbed Menu could use improvement. Essentially, to make it stable, I made our experience totally independent of the Tabbed Menu and the Quests Tab because interrelating these two features in a more user-friendly and less strictly linear interface resulted in crashes on iPad that did not occur on iPhone.

This approach is fine for a demo but will impair game dynamics if we do not find a way to address it before further field-testing. I imagine some of this may be related to my design choices but I am confident that not all the problems are attributable to design since stuff works on iPhone but not on iPad. Compatibility with a range of devices remains a concern as it is difficult to test the total range of user devices.

If anyone has a definitive guide on iOS version thresholds for ARIS functionality, sharing/publishing that would be useful to designers.


Re: repeated iPad load failures and crashes

Posted: Sun Feb 26, 2017 10:48 am
by djgagnon
I can speak to the instability a bit.

Devices made in the last few years have 1GB of RAM. Devices older than that have 512MB. Based on your game crashing, we did some investigation and found that we were keeping all of a game's media in RAM, even though we also keep a copy on the device's "disk."

The tab bar is perfectly stable. The issue is RAM. Every time you load a tab's code and content, ARIS needs RAM to put it into. Given that we were already right next to the devices 512MB limit (remember, all those other apps and iOS are also running), simply booting up the Map tab might require another 60MB, pushing it over the edge.

In our large implementations at museums and colleges, we've tested the games extensively on specific devices. One thing we've simply never encountered is large media sizes like this. Its perfectly reasonable to do, we just haven't done it before. With just a little back and forth, I'm sure we could make changes to ARIS that would make your game play work reliably on all iOS devices.

Regarding speed, it's just a matter of faking it. You are right, .js will run at vastly different speeds on devices that span 8 years of technology. The trick is to build in user friendly loading screens and quickly loading "bridge" graphics to cover up all the slowness. It's kind of like putting up trim in a house. You know there are gaps of different sizes, so you come up with a reliable way of making them look pretty.