Advertisement

In game chat as separate service - pros/cons?

Started by April 14, 2015 01:47 PM
4 comments, last by hplus0603 9 years, 7 months ago

Hi,

I haven't found relevant topic on last few pages - please feel free to merge with another topic if my ctrl-f skipped something relevant :)

I'm writing a Unity networked game. Architecture-wise, clients connect to central server application (also Unity for now), which provides features like creating rooms etc. When players start a game, actual game process is started on server and starts listening for players, clients connect to it, everyone is happy.

However, there is one issue that bugs me for a longer time now - chat.

In theory, the easiest solution would be to solve problem using builtin Unity RPCs with a bit of data stored in MySQL database. However, I'm afraid that would lead to inappropriate scaling of central server application, which already handles a lot of network traffic.

So - I'm thinking of using some XMPP (jabber) library or building custom TCP sockets based solution. Then, service could be located on a server machine, and in case of bad scaling - moved to separate machine.

Has anyone handled this issue before? Is there any rule of thumb regarding this?

I don't actually have any real experience on this topic but when I think about it I see major pros:

  • decouple chat protocol from your data protocol
  • decouple from other business logic which is more redundant to fails. Chat server may fail and be rebooted while game server lives on.
  • you can implement it on top of HTTP protocol:
    • easy to integrate a simple http client on client side
    • easy to set up a http server (some common server can provide out of the box filtering, load balancing, etc)
    • you can integrate a chat module into your game's webpage! This is extremely useful since player do not need to run the game client to communicate
  • less bandwidth usage
  • ... (a lot more cons when you think about it.)

Some cons:

  • more complex architecture/system
  • additional work integrating, developing, new protocol, etc. etc. (biggest con is time consumption and system complexity imo.)
Advertisement

Yes, many games use existing separate libraries for chat in PC games. On the consoles Microsoft and Sony provide their own mandated libraries, but for better or worse, PC doesn't have that.

Both Mumble and Xfire are quite popular among those I associate with.

There are also many different VoIP libraries out there on the Internet if you want to use one of those ... but be aware of the law in your location. Many nations (including the US) have requirements around enabling wiretaps on voice communication that must be followed.

Thanks a lot! For now, I started building solution using agsXMPP and jabber server. Will post it if I get any interesting results.

If we consider text chat, isn't WormNet in Worms Armageddon literally a stock IRC server? (with a quick check to make sure you're connecting through the game and not a normal client, but that's it)

Don't pay much attention to "the hedgehog" in my nick, it's just because "Sik" was already taken =/ By the way, Sik is pronounced like seek, not like sick.
I'm assuming you mean text chat, not voice chat.
If you have a "game host," that hosts 2-N players for reasonable values of N, then you can do in-game chat using RPC through the game host.
Chatting over RPC will only stop scaling if you want to support chatting between games, between arbitrary numbers of users.
Even there, a single server (not federated) should easily get you to 10,000 chatters, and could with some coaxing perhaps support up to 100,000 chatters (if carefully designed and profiled.)
Will off-the-shelf ejabberd work? Probably, yes! If there's a client library for Unity that you like, perhaps that's the easiest solution.
enum Bool { True, False, FileNotFound };

This topic is closed to new replies.

Advertisement