Nakama 1.2 Released — UDP, Advanced Matchmaker, and JavaScript.

We are pleased to announce the public 1.2 release of Nakama — the open-source social server for realtime games and apps.

We’ve packed in some large goodies in this release that we wanted to share with you and explain some of our decision making behind them. All of this feature development comes at the behest of the community — we appreciate you making your voices heard and helping us guide the roadmap in order to make Nakama the industry favourite for backend services. Let’s start with our protocol and why we added UDP to the server.

RUDP vs WebSocket

Nakama aims to support the widest possible set of game mechanics and the underlying client to server transport layer is one of the key foundational elements that have a direct effect on everything built on top. The WebSocket protocol is already supported and it’s proven to be a great place to start for reliable, widely-supported communications between Nakama and a variety of clients and device platforms.

For twitch-based gameplay we still wanted to overcome one last hurdle: head of line blocking. The WebSocket protocol is TCP-based, which guarantees reliable, ordered delivery of all data. By design TCP resends lost data until acknowledged by recipients, and newer data is held up so everything is delivered to the application layer in the order it was sent. This is handled by the network layer independently of the application and is ideal for most use cases, but some game data would benefit from immediate delivery regardless of order or reliability concerns. A typical example is position updates — for fastest feedback to the player we want updates delivered as fast as possible, in any order, and let the application fill in gaps by interpolating as needed. If updates are held up until missing data is resent it’s likely by the time it reaches the application it’ll be too out of date to be useful or cause poor user experience.

With the addition of a UDP (User Datagram Protocol) based transport, we wanted to add further support for games which are very latency sensitive. UDP is a simpler, connectionless protocol that focuses on constantly transmitting packets down the wire to a target recipient. This makes it more suited to reaction-based gameplay or games which heavily rely on reflexes where milliseconds can make the difference in determining who shot first (it was Han Solo, for the record).

UDP however is too simple to be used by itself and most applications build up layers of behaviour on top of it. In short, it needs a way to (optionally) enable some of the convenient features present by default in TCP. We call this RUDP, or optionally-Reliable UDP. This covers connection-like behaviour with handshake and keep-alive, encryption, reliable message acknowledgement, message ordering, fragmentation and reassembly of messages too large for any single packet, and much more. Nakama’s implementation of these features is based on netcode.io and reliable.io to ensure we build on the most modern, efficient, and battle-tested technology available.

Not all applications require RUDP and some are in fact better served by WebSocket, as such you can choose either protocol based on your game project. If you want guaranteed delivery with order and reliability, choose the WebSocket option. We use a variation of TCP with ‘TCP_NODELAY’ turned on to reduce the buffering of messages on the sender and improve the user experience. If you’re not sure which is best suited to your project, reach out to one of the team and we’d be happy to talk you through it.

Filter-based Matchmaking

One of the key pillars of enjoyment across many games today is live, competitive play. Nakama originally shipped with a simple matchmaking system and we have just enhanced it. When building a matchmaker, you have to be incredibly careful as the various matchmaking criteria can cause extreme pressure on the database in the form of range scans and needing to evaluate vast amounts of data just to find a set of appropriate opponents.

As a workaround to this problem, Nakama uses the built-in Presence system to keep a list of currently connected users in-memory alongside their metadata information, such as their customised matchmaking criteria. Users are matched based on numeric ranges and term filters across all users that are currently online. These filters are then matched against properties belonging to an opponent — therefore the same filter-name and property-name must match before the filter is evaluated against that user’s criteria.

All user properties and all filters are redistributed back to each client including any extra metadata information sent with the original request. This offers incredible flexibility to determine how you want to match players together and to customise the metadata/criteria to best suit your gameplay.

JavaScript
We asked the community which platforms were most in demand for Nakama. We have existing first-class clients for Unity3D, Unreal Engine, Swift (iOS), Java (optimized for Android), and the community overwhelmingly requested JavaScript as the next client.

We’ve made it available in combination with the 1.2 release of the server. It is compatible with browsers, and React Native apps. It is available on NPM and on GitHub releases. If you have any questions or want any tips on getting started, please do drop into our community channel to chat with the team and fellow developers across the world.

Thanks for joining us on our journey to make building modern, social games and apps available to everyone. Any and all feedback is greatly appreciated, as are pull requests, stars, and any form of community involvement.

As well, we’d like to mention some of our community members: JoshuaStrunk, Opcon, and Renanse for their PR’s in the latest release. Thank you for getting involved!

• The Heroic Labs team