WebRTC is a powerful technology that allows the creation of high-quality real-time applications. Such capabilities go beyond traditional video conferencing and are applicable to multiple industries, including video games. Today, we will discuss the concepts behind using WebRTC for creating web-based multiplayer video games. Stay tuned for a later blog post with some working code!
Why Web-Based?
Web-based, or browser games, are a popular alternative to traditional standalone games. Its main advantage is that users don’t need to install anything. They just go to the game’s website, maybe authenticate, and boom! Your game is ready to go viral.
While installing a game won’t deter experienced gamers, more casual ones might think twice before going through the hundreds of Gigabytes of download that some game clients require. Web-based games are best suited for these kinds of users
Another important benefit is that web-based games run virtually everywhere. All you need is a supported browser.
Why WebRTC?
In a multiplayer video game, you have multiple clients connected to a server. Among other things, this server is in charge of synchronizing the game state across players. Such information needs to be transported with low-latency so that each player is able to respond accordingly, i.e., dodging an attack or winning the race at the last second.
One approach to do this is using Websockets. The WebSocket API makes it possible to open a two-way interactive communication session between the user’s browser and a server. This bidirectional connection between the client and the server allows them to exchange ordered data reliably.
Websockets works fine for chat or turn-based games where users don’t need to react in real-time. But it’s not suitable for highly time-sensitive games like First-Person Shooters or the Battle Royales that are so popular these days.
The reason for this is that Websockets work on top of the Transmission Control Protocol (TCP). This transport protocol not only prepares and sends the data but also controls the delivery, retransmitting any lost packet and guaranteeing its order. Without proper optimization, this can introduce latency.
User Datagram Protocol (UDP) provides a more suitable approach as it doesn’t perform such controls. Instead, UDP lets the application or a higher level protocol handle it. In terms of real-time connectivity, this provides the low latency transmission needed for our use case. (More on TCPs and UDPs can be found in another of my blog posts, Networking Basics for WebRTC: Delivery and Addresses.)
WebRTC provides a convenient way to send data through a UDP-like transport protocol in the browser, while at the same time supporting some of the TCP features when needed. Such a mechanism is the DataChannel API.
Client-Server vs Peer-to-Peer
Before getting into the details of what building a multiplayer game using WebRTC looks like, let’s take a moment to talk about its architecture.
One of the sellings points of WebRTC is its peer-to-peer nature. You can establish a connection between two peers directly without intermediary servers. In the context of video games, that translates to having players “host” their own games and letting other players directly join without any external server involved.
Despite how attractive not having to worry about servers may sound, there are a couple things that need to be considered:
- Even if the connection between the peers is indeed serverless, a signaling process prior to the actual connection is required. This process lets the peers know how to connect to each other in the first place. And as you can already tell, it needs to be hosted on a server.
- In an ideal world, each peer would have its own public IP address that can be used to reach it. In reality, it’s highly likely that one, or both, will be behind a NAT device. A mechanism for traversing it will be required.
WebRTC provides such a mechanism through the ICE protocol which relies on additional servers – namely STUN and TURN – to find the best route to reach a peer, NAT traversal included. (Learn more about ICE in WebRTC.)
Also, as the number of participants increases, each player would have to maintain additional connections. Eventually, their devices won’t be able to handle that load.
A last, but not less important factor, is that players are responsible for keeping their game state in sync in a peer-to-peer architecture. Depending on how this is implemented, it can give one player an unfair advantage over the others. Not to mention that without a proper validation mechanism, the game state can be tampered in favor of specific players.
As a bonus, you’ll want to have a server to handle authentication and/or integrations with other third party services anyway. Having it at client level might be a security issue.
With that said, while a peer-to-peer architecture is possible using WebRTC, you are still going to need servers. A client-server architecture plus the ability to send data with low latency through WebRTC’s DataChannel API is the best approach.
Let’s Get Started
Having the important concepts covered, it’s time to list out the things to have in mind when creating your multiplayer game.
1. Set Up Your Infrastructure
This entails provisioning the signaling and ICE servers that will enable your connections. If you’re writing your own game server, you’ll also want to consider bundling signaling there to take advantage of the same infrastructure.
For ICE servers, you can rely on well known open source options like Coturn. Or, hand off that responsibility to a third party service provider like Xirsys. For a monthly fee, they will give you ready to use STUN and TURN servers for your game.
2. Provision Your Game Server
Your game server is responsible for managing players and keeping game state in sync. You can choose whether you want to write your own or rely on an open source media server.
For the first case, you have full control over how you want the server to behave. But you’re also responsible for adding WebRTC core functionality. To do so you’ll want to either clone the upstream implementation, or explore a third party one such as Pion.
Alternatively, an open source media server provides a ready-to-use server that can be easily integrated into your game client. This is at the expense of having to rely on client-side code or even an additional application server for making it behave as you want.
3. Write Your Game
With all the supporting pieces in place the last – and most important – step is to actually write the code of your game. Either code on plain HTML, CSS and JavaScript; make use of a web framework such as React; or even leverage web game engines for more advanced game development. Unleash your creativity and let the real-time communication part stand on the shoulder of a giant.
At WebRTC.ventures – in addition to being avid gamers – we’re experts on integrating WebRTC on different use cases across multiple industries. If you want to know more about how WebRTC can fit your game or web application, contact us today!
