Following our article on graphic hardware accelerated solution for the cloud we would like to come back on the cloud gaming landscape today to grasp its progress 2 years now from its first introduction. Cloud gaming buzzed the game industry during the last GDC with both the launch of the NVIDIA GAAS (Game As A Service) platform and the SHINRA tech demo showing what the potential of the technology is all about. While the technical paper is not new, its implementation in a business model and service is somewhat a challenge crossing all the layers of the industry from a low level tech point of view involving B2B solution to the very end leaf of the consumption pattern of its B2C model. We would like in this article to cover the main change involved in those layers.

The term “cloud gaming” is today often confused with the side service offered in the cloud from game console makers. For instance the strong shift to the cloud showcased by Microsoft for its XBox user service. Those extra storage solution, account management or sharing solution even deeply infused in the gaming platform are not cloud gaming, so we would like to focus on the GAAS, first introduced by NVIDIA 2 years ago during the GDC 2013. The concept of GAAS is fairly simple: forward user game pad inputs to the cloud then stream the resulted screen back to his screen. By abstracting the hardware layer GAAS also abstract the specification limit of the device. So any H.264 or like enabled hardware is a potential console-like AAA game device, including smartphone, tablet and smart-TV without any need to install nor download. But as attracting the idea is, and as pointed out by Jen-Hsun Huang during the GDC 2015 everything about the clouds often turn out to be a tricky challenge.

^{. GRID First introduction in 2013. © NVIDIA}

Hardware layer
As an implementation, GAAS has to be done on the top of a virtual layer of hardware that allow GPU workload. Three options are actually offered by virtualization vendors: full virtual GPU (or vGPU), dedicated GPU or shared GPU. Only the last 2 make sense from a game UX point of view due to latency concerns, then only the last one make sense from a business model point of view. But scalability of shared GPU is not as easy as the CPU one due to shared memory bottleneck across GPU cluster and synchronization of the parallel task. Actual Graphic card architecture allow a fix amount of physical per-card user and effort are made by GPU vendors to allow full virtualization of the GPGPU workload: AMD offers the SKY technology where NVIDIA offers its GRID solution. Then an other option would make sense: to get rid of this “physical GPU cluster on top of CPU cluster” challenge that represent GPGPU in the cloud by sandboxing all computing task on a CPU based cluster. For instance using a Intel Phy based cluster. But as we will see with the business perspective, middleware and game engine already fostered cloud gaming in a GPU based infrastructure.

Cloud Layer
The direct clients of the cloud gaming infrastructure are game publishers. The design behind game execution is more like a render-farm blueprint than a real scaled and balanced database software. From a cloud management, gaming is all about GPU local memory versus global memory management. Game experience also means optimization of this process and by means using GPU vendors provided middleware.

^{© 2011-2015 VirtualizationMatrix.com}

Development layer
Game engine doesn’t actually provide any compile time optimization targeting the cloud. We are not talking about low-level optimization as the virtualization layer doesn’t take advantage of any of it. So 2 options are left to game studio: The first one is implementing actual title almost right out of the box in the cloud. This is obviously cost-free but doesn’t take any advantage of the cloud platform like scaling any of its features: open game world, multi-users, etc… The second would be a complete support from both the cloud and hardware vendor for this very custom target that represent the cloud, somehow on a title basis.

Business layer
Certainly the most interesting challenge in cloud gaming are the B2B alliances behind a solution. There are actually two main pattern in the cloud gaming ecosystem today. In one hand you have this “on the top of game industry” move driven by NVIDIA that force the switch to the cloud without any strong need of re-factoring the product. This is appealing for a short term point of view where industry players can find their place in this new market. But it is limited to the short term as cloud gaming can only be appreciated with the scale it represents, and this do need re-factoring the development of the product. In an other hand we have already cloud ready technologies specialized in the game industry like SHINRA, allowing the full power of the cloud but requiring first a cloud specific design and implementation. This last move is more middle/long-term oriented but showcase even today what the future of gaming is all about.
To illustrate those two scopes we will focus on two main players, each representing a clear approach of those strategies: NVIDIA and SQUARE ENIX. Please read “Cloud Gaming in real world: NVIDIA and SHINRA” here.

User layer
Obvious benefit from an UX is the cut of download and install process. “Click and play” is certainly one of the key factor of the cloud success. It also means that user will want to “taste” the product on the fly before buying. The actual music and app store are very close to what cloud gaming can offer to gamers. Then, from a pure game UX perspective we have massive online multi-users game yet to be defined as none of the game today showcase the amount of user that the cloud can handle. Same about massive IA agent amount, monumental physic based environment to say the least, promising bright future for this stronger and stronger industry.