Why You Should Run Your Game Servers Separate From Your Chat

When it comes to building multiplayer games, developers are often faced with a dilemma.

• Do I utilize my existing game servers already powering my multiplayer functionality to run chat?
• Do I separate my game servers and run my chat independently?

Because 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.

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.

Microservices Make Your Game More Manageable

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 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 it’s 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 realtime, 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. Decentralised components are easier maintainable and scale better.

A game infrastructure 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.

Ensures Seamless Gaming Experience and Chat Performance

Overall game performance is a major consideration for a multiplayer game. With monolithic architecture, the game may perform in the lab, but for games with a high amount of users, communicating at a rapid pace, you’ll begin to see lag and increased latencies on both delivery of the chat messages and the experience of the game.

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 League of Legends or EVE Online. 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 game 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.

UDP vs. TCP – When You Need Both, and When You Don’t

Then there’s the debate over multiplayer gaming protocols, UDP vs TCP, and when it’s best to use either one.

Fast-paced multiplayer games (first person shooters, arena games, etc), use the UDP protocol to sync player movement and update game state. UDP is 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). TCP 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 servers, especially once your game takes off and you have thousands of users connected at a single time.

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 realtime messaging, with two different standards. Having them operate alone lets you manage each one based on what’s required.

Add New Social Features with Ease

Running chat as a standalone service, and picking an industry-standard protocol (XMPP, WebSockets) 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, user presence to show what players are online and offline, and unread message counters – features that are expected by users.

Looking Forward

Game studios big and small are moving towards this architectural design, including Pocket Gems, and more recently EVE Online. From better scalability 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.

Whether you’re looking to build chat into your game, or power the multiplayer functionality, we do it all! 

References

• Getting Started with Multiplayer Game Programming
• Analysis and refactoring of the chat architecture in EVE Online