The Differences between Gaming Servers and Chat Servers

As gamers and game developers consider multiplayer games, a common question often arises. Should I repurpose my existing game servers so that they handle chat? Or, should I segregate my game servers and operate my chat independently, in a dedicated server?

So, the choice is between:

• Utilizing your existing game servers to run chat

• Provisioning a dedicated server to run chat independently

On the surface, it might seem like a logical choice to maximize what's already in place. After all, they’re just chat messages right? Small messages being sent to a single user or a small group, might as well just utilize what’s already built? What could hurt? Though it may seem like a good option initially to utilize what you already have built, there are a number of problems that can arise from choosing this design pattern.

The Benefits of Operating Game Servers and Chat Independently

We’ll show you why you should run your game servers and social features (most importantly chat) independently, benefiting both you as a game developer and your end users. In doing so, you’ll increase performance and scalability of the game itself and allow social features to be easily extended with new functionality in the future.

What is TCP and UDP?

Essentially, TCP and UDP are network protocols that are used for data transfer over the internet. TCP is a connection-oriented internet protocol, while on the other hand UDP is a connectionless protocol.

The big debate over multiplayer gaming protocols is when should you use UDP (User Datagram Protocol) vs TCP (Transmission Control Protocol) and when is it best to use either one?

But before we get to that, let’s discuss online game architecture. 

Streamlining Your Online Game: UDP vs TCP Gaming Servers

A microservices-oriented architecture breaks a large application, in this case your game, into small, independently versioned modular services, and talk to each other through simple, universally accessible APIs. It makes it much easier to build new functionality and maintain the bandwidth and functionality once built.

Separating your game servers from your chat functionality makes your entire infrastructure more manageable, and gets you closer to a completely microservices-oriented architecture. In this case, let’s look specifically at in-game chat, and its relationship with the game servers powering the multiplayer game.

With a monolithic architecture, your development team is now locked into a single technology stack – using the same programming languages, databases, and software environments that the game was already built on. In bringing on new developers, or wanting to prototype new technologies and systems, it’s much easier to move fast in a microservices architecture.

Dependencies are also much more apparent with monolithic architectures. If your single application function fails, the entire game goes down. Splitting your game into microservices, if a single module fails, it’s easier to isolate the fault and fix it.

Your game servers are built for delivering player movement and state in real time, and they do that well. Repurposing the same technology and design for chat messages is simply not using the best options for the particular functionality. Decentralized components are easier to maintain and scale better.

A game infrastructure example where chat is separated from the game servers. We can also run other services outside the game servers, including authorization, presence, and statistics and leaderboards.

Guaranteeing Seamless Gaming Experience and Chat Performance: UDP vs TCP Gaming Servers

Overall game performance is a critical consideration for a multiplayer game. With a monolithic architecture, the game may perform well in the lab, but when released to a large online community of gamers communicating at a rapid pace, you may start to notice lag and increased latencies. This affects the delivery of chat messages and the overall gameplay experience.

Separating the two ensures that CPU and network resources are used more efficiently. The primary purpose of your game servers are to deliver a seamless experience for every user in your game. As a result, the processing power should be used to maximize that performance.

Say you have an online battle arena game like Fortnite or Minecraft. You may have hundreds of players in a single world, at a single time. That’s thousands of messages being sent through your game servers delivering every input each player creates. Then add in chat messages to the mix. It’s entirely possible that players can spam the chat channel and deliberately slow down the game server since all messages would have the same priority.

The gaming server is already handling intensive gameplay experiences – physics, graphics, sound. To add in chat messages – one-to-one, group, team – parsing and routing the messages to the correct users – all these messages slowly build up for large-scale games, and hurt the overall performance of the game. It’s a no-brainer to run chat channels separate from the multiplayer channels. It is stealing important processing power that could be better suited for more complex problems than routing chat messages.

Balancing the Need for Both: TCP vs UDP

Fast-paced multiplayer games (first person shooters, arena games, etc), use UDP protocol to sync player movement and update game state. UDP headers are ideal for sending these game updates at a ridiculously fast speed, but messages are not guaranteed (because the next message is coming so fast behind). 

Why is UDP preferred over TCP? And vice-versa?

TCP connection guarantees message delivery, which makes it a great option for chat. You’ll see great performance running your game on UDP and your social features on TCP.

However, for less intense multiplayer games, like turn-based games, TCP is a suitable option for both gameplay and chat. Because TCP guarantees message delivery, and in games where every move matters (like a Scrabble turn or tic-tac-toe), it’s a great option to power the multiplayer gameplay. Of course, you’ll still want to separate your chat from the game server connections, especially once your game takes off and you have thousands of users connected at a single time.

Consider latency when choosing to use TCP and UDP for different functionality

Latency is another thing to consider, as there are different standards of latency for multiplayer functionality vs. social features. For a multiplayer game, ensuring game state and delivering player inputs, the industry-standard is no more than 20ms. Whereas for a chat application, the maximum latency for delivery of a chat message is 250ms. So you’ve got two different types of real-time messaging for online games, with two different standards. Having them operate alone lets you manage each one based on what’s required.

Easily Add New Social Features with TCP or UDP Protocol

Running chat as a standalone service, and picking an industry-standard network protocol (XMPP, WebSockets, ngrok) or a hosted-service (PubNub) opens up the opportunity to easily add new powerful social features.

Start with core chat, allowing users to individual and group chat. With that, you’ve got the underlying infrastructure, as well as basic publish/subscribe, and there’s a lot of other social features you can easily build on it. In minimal code, you can add table stake chat features like typing indicators, presence to show what players are online and offline, and unread message counters – features that are expected by users.

TCP and UDP: A Look into the Future

Gaming apps big and small are moving towards this architectural design, including Pocket Gems, and more recently EVE Online. From better scalability, flow control, and more efficient performance, to the freedom to innovate without being locked into a single stack, the benefits are clear – separating chat from your game servers is the way to go.

With PubNub Chat, you can easily implement in-game chat as the basis for robust social features, letting you focus more on your core game development and less on scaling and maintaining social infrastructure.