This is the third in our series on the Gaming Internet. You can read the previous post here
Ask the average network engineer what they believe application developers think about networking and they will likely respond with some version of “The developers just assume the network is there, like magic.” Their view is that developers operate several layers of abstraction removed from the messy world of networking and this distance creates ambivalence or indifference, a taking for granted. Developers can reasonably respond that is the whole point of abstraction, which is the first thing taught in Computer Science courses. The network engineers do their job and the developers do theirs. In fairness, game developers already have a lot on their plate. They are constantly challenged to push their code to the boundaries of performance, and you know, making playable games. They’re kinda busy over here.
Of course, both sides are reasonable and strive to work together, but the point remains that there is a wide gap between the two domains. At least there used to be. As we covered in our last piece, networking is becoming an increasingly important part of the gaming experience. Game playability now relies heavily on networking factors. Spend some time in game discussion forums and the topic of ping and lag is always a hot topic. And this is one of those “Hounds of the Baskervilles” problems where the real problem are the people who are silent on the forums because they got frustrated with laggy gameplay and move onto other titles.
Put simply, bad network connections can ruin a game experience. Maybe the network does not matter for a mobile Sudoku game, but for the less casual games, an already large and rapidly growing slice of the market, networking issues are an important factor.
Let’s throw out a simple example. A game developer launches with a big marketing push and signs up a million users in its first year. Of those, 50% are in places with good Internet connections, 50% are not. People who like the game are more likely to stay with the game and more likely to convert into paying customers. Conversely, players who have a bad experience hurt the company in two ways: they do not stick around and they are less likely to become paying customers. All other things being equal, gamers contending with bad network connections are worth a lot less to developers than those with good connections. Below we lay out some very simple sample numbers for how this plays out, assuming that a converted players spends $20/year:
|Connection||Users||Conversion||Churn||Players after 2 years||2-Year Revenue|
Over two years, players with a good connection monetize 3x more than those with poor connections. These are some big differences, and we are being fairly conservative with the metrics. But there are other problems. The customers with a bad network connection are going to cost more, because they will spam developer’s support teams with “Why so laggy?” complaints. Even more important, they will be negative marketing factors for the game, leaving bad reviews and social media complaints,
It is important to remember that there are two forces at play here. In the gaming world we would call this availability and latency – Is the game playable? Is it lagging?. This means the developer has to have servers in all the regions they want players and those connections have to be robust enough to support viable game play. Without basic availability, few players will find the game, and with out good latency levels, those that do will not be happy. In the networking world, we have the same phenomenon, we just call it something different – coverage and capacity. Does the network reach where its needed and how good is service in that area? Take wireless networks, the operators have to put up a cell tower to attract their first customer, but then to grow a viable business that cell tower has to have sufficient capacity to support many users with few complaints.
As we will see in our next post, the solution for gaming is not exactly the same as that faced by the telcos, but the analogy will help developers and network engineers find common ground for building a solution.