Pokemon Go: A Developer’s Perspective
Pokemon Go: A Developer’s Perspective
Here’s your instant history of an app that tapped into far more demand than the developers could handle. It’s both a best-case scenario and a cautionary tale.
Join the DZone community and get the full member experience.Join For Free
Every app developer dreams of the kind of success that Pokémon Go is enjoying right now. A month ago, it was just a rumor. Just 24 hours after it was released, it was the number one top grossing app, even though it was free to download and play. Within a single week, Pokémon Go servers were slammed with traffic from 21 million players while they tried to fix production errors.
Today it has 3X more Android downloads than Tinder, nearly as many daily active users as Twitter and users spend twice as much time in the app as they do in the phenomenal Snapchat. Even Facebook can’t hold up against the Pokémon onslaught. By any mobile app performance metrics you want to use, Pokémon Go has been a smashing success. It’s also at the center of a media firestorm.
How did they do it? Why are so many people so upset about it? What lessons about better software performance can you take away from the whole experience? Here’s your instant history of an app that tapped into far more demand than the developers could handle. It’s both a best-case scenario and a cautionary tale.
The Birth of Pokémon
It’s just a game for kids. Really, that’s all it is, but that’s exactly what people said when Nintendo released Pokémon 20 years ago. It’s a game where you capture little monsters and make them fight each other – part insect collection and part sci-fi gladiator arena. Kids continued to love it as they grew up and then came the anime manga, the trading cards, the TV cartoons, the dolls and the movies. Now, the Pokémon franchise is worth over $46 billion.
In 2014, as an April Fool’s Day prank, Nintendo teamed up with Google Maps to make Pokémon monsters appear in real places using augmented reality. The response was so enthusiastic that suddenly everyone got real serious about it.
Enter Niantic, an augmented reality game maker led by former Google Earth developers. It’s best known for Ingress, a real-world/sci-fi mashup where gamers travel to real places using Google maps and fight for supremacy of “portals” in the app. A portal could be a business, a school, a park, etc. If it could be mapped, it became a battleground. Pokémon Go was built on the skeleton of Ingress and former portals became “gyms” for training monsters or “Pokestops.”
Niantic CEO John Hanke said they started building the game based on a data set of public artwork that they chose from among geo-tagged photos inside Google Earth. “We basically defined the kinds of places that we wanted to be part of the game,” Hanke said. “Things that were public artwork, that were historical sites, that were buildings with some unique architectural history or characteristic, or a unique local business. There are portals in Antarctica and the North Pole, and most points in between.”
Tech Specs and Coding Languages
There’s no official word about the code base of Pokémon Go, but the greatest probability is that the game was coded mostly in Java/libgdx because that’s what Niantic used to create Ingress. Although the bulk of the game may be Java on the server side, many coders who have played it suspect that there has clearly been some work in Objective-C/Swift for the iOS version so that it runs as a native app.
The strongest piece of evidence to support this comes from the Niantic employment page, which reads: “Create the server infrastructure to support our hosted AR/Geo platform underpinning projects such as Pokémon Go using Java and Google Cloud.” Niantic is also looking for coders with “Key Skills: Unity3D (Unity 3D), C# — You will work with a proven and experienced team of mobile and cloud developers to turn the entire world into a gameboard.”
The database supporting the game is NoSQL running inside Google Cloud Services. That implies that the game is probably integrated with Cloud Bigtable or Cloud Datastore, perhaps using JSON or CSV for data handling. While many other apps interface with their se RESTful APIs, Pokémon Go seems to be relying on an RPC interface for its server interactions using Protocol Buffers.
Safety and Privacy
In terms of data safety, the iOS version initially asked customers for full access to their Google accounts. That means it could have gotten into user Gmail histories (which often contain passwords and other private information), classified information in Google Docs/Drive or very personal info from Google Calendar. Niantic had to issue an apology and said it never intended to collect all that private data, but industry watchdogs just have to take their word for it.
At one point, due to this privacy problem, their sign-up process was broken and the company had to turn away new signups. That can be particularly bad from a developer perspective because most apps lose 60 percent of their customers over the first month, and 96 percent after a year. New sign-ups are the only way to stay alive.
When the Servers Crashed
Pokémon Go started out with a great deal of talent, serious backing from major industry players and a built-in audience of brand fanatics. What could go wrong? A lot, it turns out. A few days after Pokémon Go’s official release, Forbes posted an analysis that declared, “The launch has been an unmitigated disaster. The list of things that have gone wrong with the launch goes on and on. Players unable to log in; players in the U.S. unable to download the game to begin with; game crashes; maps bereft of any and all Pokémon, gyms, etc. Everything from sign-in issues to overwhelmed servers has plagued the game’s launch.”
This is the perfect example of the danger of popularity. Normally, the last days leading up to pre-launch can be frantic. App developers have often used the days after launch to work out the kinks. That clearly couldn’t happen under the crush of new user sign-up traffic that hit their servers. Others have made the same mistakes, though.
As for the production team at Pokémon Go, could they or should they have anticipated so much traffic? Yes, and Niantic’s launch problems might have been catastrophic if it were another business critical application. The average cost of a critical application failure per hour is $500,000 to $1 million, according to a research by analyst firm IDC. It is even more important to get things right and deliver exceptional end user experience when applications are primarily consumed via a mobile App. Nearly a quarter of apps are only opened once.
Many enterprises are using AppDynamics to avoid such catastrophic situations and to minimize the negative impact on their brand reputation. With AppDynamics, they are empowered to have real-time insights into application performance, user performance, and business performance so they can move faster in an increasingly sophisticated, software-driven world.
Where Pokémon Is Going
Pokemon Go brought reality to the concept of meshing the virtual with the real, so you should expect augmented reality to develop quickly now that it’s finally become profitable. Expect a huge second mover advantage in the world of app development because you can be prepared to address the server traffic spikes, the user privacy issues, and the public safety controversies.
The days of actual immersive virtual reality, complete with a 3D experience, might not be far off, but preparation is everything, especially with app developers, programmers, and IoT experts. The most important takeaway from the story of Pokémon Go is that companies of all sizes need to prioritize performance monitoring before errors start impacting customers. The best way to do that is to simulate heavy traffic and deploy tools like AppDynamics to filter out common errors and exceptions as soon as possible and long before the app hits production. In this case, the users kept coming, but not every app maker will be so lucky.
Published at DZone with permission of Anand Akela , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.