Pokémon Go is a gaming app that employs limited augmented reality and geolocation. For those who have not played the game or somehow haven’t heard about it, the premise is to find Pokémon, capture them, and compete with them in gyms.
The Pokémon critters are randomly placed throughout the world. They periodically appear, and you can see them if they are nearby when you are running the app. The augmented reality (AR) support uses a device’s camera to display the image of a Pokémon over a view of the real world. Most players turn off the AR after an hour, though.
There are also Pokestops and Pokémon gyms. The stops can drop useful items like Pokeballs that are used to catch the critters. The stops and gyms are at fixed locations that do not move, and there is an algorithm used to determine where they are. They are typically near places of interest or commercial establishments. Sometimes they are welcome, sometimes not: “No trespassing” signs warning off Pokémon players have cropped up in many locations.
Back to System Design and IoT
Pokémon Go and IoT are relatively new things. IoT tends to be a bit nebulous, but for this discussion I will be concentrating on mobile wireless IoT devices. The aspect of system design being discussed is user interaction. It’s sort of like the user interface, but that is only part of the issue.
To start, we take a look at a Pokémon Go problem. Observe the three Pokémon Go screenshots in the image above.
The left screenshot is from my recent visit to San Francisco from a hotel room that had three stops within reach of the room. I was able to work from the room, pick up items, from the stops and capture critters because others were dropping lures (shown as pink and purple flecks) that attracted Pokémon. It was great and I was hooked…that is, until I returned home.
The other screenshots are from areas near my home in Pennsylvania. They are rather devoid of stops and gyms, and even random critters. They do exist, but it is not like most downtown areas that often have multiple stops within a block of each other. We found three in a nearby park that we now frequent, but the gameplay and activity are in stark contrast to the rather heady exposure in the big cities.
Other issues with the game include the use of GPS for tracking movement that is used to hatch Pokémon eggs (another way to get critters). One reason for the game it to get people up and moving, but the approach does not work inside where GPS is not accessible from many smartphones. A frequent need to restart the application to get it to work properly is another issue.
With than in mind, general IoT designers should keep in mind their customers, where they will using an IoT product, and what kinds of limitations need to be addressed. Pokémon Go is actually quite demanding, as it requires an active internet connection and GPS to function. A transient loss really messes things up. It should be possible to improve this type of loss, and IoT designers should keep that in mind. Often it will be easier for an IoT device to handle this problem but that all depends upon how the application is configured and what kind of environment it will be used in.
For example, a medical WiFi-based IoT device may work great in a hospital environment if Wi-Fi is set up throughout the buildings. The same device may not work as well if it is used in a home setting where Wi-Fi configuration is not set up professionally. It would be unlikely to work outside of these areas where Wi-Fi is not available. The question will be whether such as device can operate in a useful fashion with transient connectivity if it were moving from location to location.
The lack of virtual resources is not necessarily limited to games like Pokémon Go. Medical devices designed to track and provide biofeedback to users may use a similar approach with virtual objects, getting users to perform actions that will help them. This has been done with many video games, but IoT approaches allow this to be done away from fixed locations.
Many IoT devices will be employing GPS and various wireless communication systems. Designers need to be aware of their limitations, as well as how and where users will employ a device. A device or application that is useful in one context—like Pokémon Go in San Francisco—could be discarded if it had to be used in another region that is less productive.
Companies also need to be aware that IoT devices may benefit from third-party support. Unfortunately Niantic Labs, the creator of Pokémon Go, has cracked down on websites that provided maps and locations of stops, gyms, and critters, but these actually fill a deficiency of the game. Roaming around to find this information is not practical, especially when there is a dearth of items to find locally.
IoT devices that provide data through various means such as an API, or access to a cloud database, can allow new and interesting uses of a device. Of course, poor implementations can cause security problems, as well.
This article was originally published on our sister site Electronic Design.