Tech for Gaming on Demand (Part 2)

Tech for Gaming on Demand (Pt 2)

As a refresher, last time we spoke about the status quo of where the tech is today, cloud gaming (pixel streaming), and LOD streaming. Today, I want to explore two local and fairly open technologies that could play a role in the future of gaming on demand.

‍

WebGL / WebGPU

WebGL, or “Web Graphics Library”, is an API for rendering graphics in the browser. It gives web developers access to the GPU to render 3D graphics. It’s an abstraction though, a few layers deep. WebGL is built on top of OpenGL, which interfaces with the GPU. A lot of developers that want to implement 3D graphics in the web don’t even use WebGL, they leverage tools like Three.js or Babylon.js which further abstracts away the complexity.

Abstractions are wonderful because they allow for people like me to access and create on top of much more complex technologies (GPU). However, as the underlying technology advances and changes, there is a risk that the abstraction layers don’t keep up. That’s roughly what has happened with WebGL - it’s based on GPU technology from over a decade ago and lacks functionality. WebGPU is the replacement - it’s a future web API standard backed by Mozilla, Google, Microsoft, Intel, Apple, and others. It’s currently being standardized by the World Wide Web Consortium (W3C). WebGPU is cleaner, more powerful, and more performant than WebGL. Unlike WebGL, it also creates groups of rendering settings for the application to use in advance; instead of individual function calls through WebGL for each setting, you can switch between groups of settings during runtime with WebGPU - it’s stateless. It’s still early days for WebGPU and it’s not generally available yet through the browsers. I am hopeful for the technology though and believe it’s a matter of when, not if.

As WebGL/WebGPU is browser-based, it’s easily accessible to almost any device; it checks the distribution box. However, it relies on local rendering - so the same limitation as LOD streaming here. As WebGL/WebGPU is an abstraction, it also restricts more fine grained control of GPU rendering, which many game developers want to have access to.

‍

WebAssembly

Historically browsers could only run javascript and any other programming language was relegated to the server or to native applications. WebAssembly changes that, it’s a tool that allows you to port non-javascript code and applications to the browser. It’s also an open standard that comes supported out of the box with the major browsers. WebAssembly gained some internet popularity among gamers over the past few years as games like Doom 3, Quake, and a Minecraft clone were ported. It’s actually what Unity uses to compile to the web for games. It’s powerful technology, but it’s not suitable for most AAA games yet as there are a few limitations. Games can often run up into the 10s or 100s of gb in storage. Developing for the web, you need to keep the file sizes low as the entire game will load when the page loads. This makes a lot of high-resolution textures, large audio files, and other things that make for a more cinematic experience somewhat impossible with WebAssembly today.

‍

Concluding Thoughts

So which technology will prevail in the battle for gaming on demand? The future is anyone’s game, but here’s the thing - LOD streaming, WebGL/WebGPU, WebAssembly are all somewhat compatible with each other. Pixel streaming is the odd one out. The question becomes: will devices in the future be “thin clients” with very little graphical processing power or will most devices have adequate GPU capacity to render most games?

My bet is that we’ll have pretty powerful phones that will handle just about anything. However, I still think we’ll have a little of everything in the tech stack, including pixel streaming; but not in the way, or the scale, it’s being pursued today. LOD streaming as a technique will prevail with most multiplayer games, especially those with large worlds and numbers of players. Data will be streamed to powerful client devices, or to local edge servers. These edge servers might be at the neighborhood, building, or home level and will run the necessary graphic computations; the output will then be pixel streamed to thin local devices. This is a much smaller proposed shift from what happens today (streaming from the GPU in the local device to its screen). Most applications will be content with WebGPU rendering as a standard out of the box solution that “just works”, but a lot will want finer grained controls and access to the GPU to deliver more stunning visual experiences.