“..Between the idea
And the reality
Between the motion
And the act
Falls the Shadow
For Thine is the Kingdom..”
T.S. Eliot, from “The Hollow Men”
Went out on a limb here–mea culpa, but I couldn’t resist, given what we saw about the IPhone’s use with BLE devices this week. See below. To sum up, we were disappointed.
RED ALERT: APPLE “Got’cha”: In the final phases of our testing, testing on two phones, all of a sudden, the application failed on one of the phones. Flummoxed by this, confused, angry even, we searched for an answer, and we found one: The iOS updated automatically to 7.1, thus making our app fail totally. This also happened to our other phone a few minutes later. The error message stated that the XCode SDK was not supported by our iOS version (7.0) , all of a sudden. It wanted version 7.1. We had to update, and at this time, we do not know whether or not our app will work.
UPDATE: Though we were disappointed, the experiences of Jung and Maria Paula gave us a couple of solutions for our Apple issues. We would need to transform our TI SmartTag into an I-Beacon, but it is possible. This could be accomplished via the code that J and MP have posted already and the addition of firmware that Tom has made available. It is unlikely that we will get this going until after thesis.
NICE TO HAVE: Mike has a great idea for integrating the game with the iPhone’s onboard Compass/Level utility and phone accelerometer. His idea is that players would need to maintain the level at equilibrium in order to infect, and so would need to creep up on potential infectees. This has been shelved for now till we sort out the issues we just got related to the crazy auto-updating and instant-obsoleting of our iOS such that the SDK is no longer supported and our app fails.
I’m also still interested in trying to get an Android version working, using the most recent version of the Android software with one of the custom plug-ins that purport to enable the Android to advertise as a peripheral, using the most recent version (KitKat) of Android.
Challenges from tests:
(1) Phone w app sees the tag, but says it is “too far to infect.” If the tag does not infect a phone on first identification, it will not infect subsequently, even if the phone gets close enough to infect.
[With the phones, we do not have two different states: If a phone is in proximity of an infectious agent, phone or tag, it gets infected.]
We thought this might be convertible into a game element, but we are not sure how finely we would have to slice proximity to get these two different states working between the tag and the phone: I see you, but you are too far to infect, and I see you and I infect you.
When we tested, in the first case, the tag was within an inch of the phone to be infected. In the second case, the tag was within about 2 inches. This would require more testing and adjustments.
(2) The SmartTag sleeps after about 30 seconds- 2-3 minutes, requiring a user/player to repeatedly press the side button of the tag to keep its infection scanning and infecting. In a real game situation this would be less than optimal.
I found this which claims to enable perpetual advertising, but it involves what I suspect is a lot of extra twisting and turning–download VM etc. to get what’s apparently written for Windows, etc. We can look into it further, post-thesis, or find an alternative.
Changes Necessitated by Current Un-Anticipated Limitations
This week the team was hopeful about finishing up a hearty round of successful testing on our multiple-group iPhone game, “Infection!/NetworkedGame.” We were resigned to not getting an Android version working until after thesis. But we thought that we would have an MVP – a minimally viable product that would allow multiple groups to play on the Iphone the following game (itself somewhat reduced from our original wishlist):
Original Version of Game/APP
(1) Initially, users are infected from the TI BLE Device, playing the Central role.
(2a) The iphone player’s phone is now infected, and as a peripheral, can advertise its infection to other iphones and infect them.
(2b) To become infected, players must be within a range TBD (we imagined a fairly wide range, since we conceived of the game as a “Big Game.”)
(2c) The infection can occur whether or not the player has the application open, enabling “stealth” infections – (Your app is closed, but somehow, you’ve come within range of a zombie-infected phone. An alert would appear on your phone and the game app would open.)
(3) The infector’s UUID would appear on screen with the infection alert, and a database would keep track of the identities and the number of “infections” and “conversions” from one infection to their team’s infection, they had scored.
(4) Winner would be the team succeeding in infecting/converting the most people. Individual winners also–those who had infected the greatest number of players.
What we found in testing was very disappointing.
*We cannot do “stealth” infection, since the app must be open, and running in the foreground.
in order to infect.
*Most disappointing is that because we are not using the Apple proprietary IBeacon(r) BLE device, our iphones do not expose their true individual IDs.
In testing, each time we infected each other, we found that the UUIDs that appeared on our screens were different depending on which of us was sending. The TI devices appeared to send new, random UUIDs each time they sent a message. I got a different pair of UUIDs for our two T-Is from the other team members.
In researching this, trying to find a solution, it appears that it is the iOS limitation that does not allow the exposure of a phone’s true UUID when messaging with a connected device that is not an Apple I-Beacon.
UPDATE: We tested in class today to confirm our tests from the day before by testing getting the UUIDs on a Mac. Same result–different UUIDs from the Mac.
There is code in github that enables the T-Is to emulate I-Beacons, and Tom has firmware that enables the same.
As such, our game is now extremely reduced, to a pale version of TAG:
(1) Get infected by the TI Central.
(2) Go infect another iphone. Proximity has been implemented–you must be within a couple of inches of a Central device or an iphone that has been infected as a peripheral. We removed the infection button because infection occurs solely through proximity now (2–3 inches).
(3) One team–Goal is to get the most people infected, still, but we cannot track individual infections easily with the UUIDs changing all the time.
We may add more detail to this, but I think I’ve captured the gist of what we experienced.