With the release of Cocos Creator 3.0, we have updated the Cocos Store, a place where developers can build and post tools and assets for sale or for free to other developers, such as music, art, code, and more.
The Cocos Store continues to grow with some fantastic development tools and assets coming from developers all over the world. The number of new tools flooding the store is impressive, and we’re happy to talk to the developers behind some of them. One store item that we want to highlight is the great team at Lucid Sight and the open-source networking software called Colyseus.
If you have had trouble building up multiplayer games due to the extensive requirements and tweaking involved with it, maybe it’s time for an open-source solution thanks to the team building Colyseus. Colyseus is a unique multi-player framework used by many HTML5 and mobile games, thanks to its ease of use and its impressive options.
It’s available for free on the Cocos Store, and they’ve worked hard to make it work perfectly with Cocos Creator. They also gave us some of their time to talk more about Colyseus and their plans for the future.
We’d love to introduce you to Endel Dreyer, the creator of Colyseus, and Farzi Zubair, CTO of Lucid Sight, the new owners of the Colyseus project.
Cocos: It’s great to talk to you two. For those who have no idea about Colyseus, What would you tell them about what you do?
Colyseus Team: To be very straightforward, we are on a mission to democratize multiplayer game development by empowering more developers to create rich multi-user experiences. That’s why we built Colyseus to be an Authoritative Multiplayer Framework that’s built on Node.js.
We wanted to make it easier for developers to implement a multiplayer framework into their games so they’d have more time to spend on gameplay features rather than worrying about their multiplayer infrastructure. In addition, Colyseus makes authoritative designs less painful for developers by providing tools both for the client-side and server-side development.
C: Why is it important to have your solution on Node.js?
CT: The Node.js ecosystem has always focused on allowing for a great developer experience do to a lot of reasons. Its JIT Compiler can bring performance comparable to something developed in C language at times. Node.js processes also have a low memory footprint when compared with Java, for example. And, Node.js also has a great ecosystem of modules that can be integrated with Colyseus. You can find (and build!) modules that solve more minor and specific problems, such as path finding, nav mesh, access to databases, etc.
C: Sounds like something our developers will want. So then what are the significant issues that Colyseus is combatting that you found are issues people might have building and buying networking tools?
CT: There are a variety of choices for developers when picking their multiplayer frameworks. But in our experience, we have found most of them lacking what developers are asking for in networking software. As an indie developer, you might find that most solutions that solve all your issues might come with a costly license, no straightforward design for scaling, or code that is difficult to modify to create an authoritative game server of your own.
We wanted to address all these by having no licensing cost to use or modify the software as we are Open Source (MIT), making Colyseus easy to scale and container friendly (self-host a solution or use our subscription-based Colyseus Arena to be up and running in seconds), be authoritative by design with high-level APIs that are easy to work with, and easily integrated with the client.
C: We’ve seen you develop for many game engines, but you are one of the biggest in the west working with Cocos. Why did you choose to be a part of Cocos Creator and Cocos2d-x?
CT: Cocos products have a great reputation and are known for being really easy to use. We love the Cocos community and are looking forward to supporting its creators by creating the best Cocos multiplayer solution. In addition, we are big supporters of the Open Source community and love to support other open-source projects like Cocos!
C: It’s impressive you also have been working in TypeScript, just as Cocos Creator has been. What brought you to that decision, and how having Colyseus in TS improved integration with Cocos Creator?
C: How easy is it to add Colyseus to your project?
CT: First you’ll need to go to the store and find Colyseus. Once you do, you’ll need to download and install the extension into your project. After having the extension installed, you can import the Colyseus SDK from your TypeScript components,match-make your client into one (or multiple) rooms, exchange messages with the room, and listen for state changes.
C: Let’s change the subject for a moment. We’re starting to see a move with mobile games with multiplayer modes of under ten people to some having over 50, 100, or thousands being part of the game. What are the most significant issues facing these games that Colyseus is addressing?
CT: Good question. Colyseus is extremely flexible and can provide solutions for any game type or usage requirement as it is a room-based system out of the box. Each room can easily support around 1500 concurrent players (CCU) based on your game loop complexity. If you are looking to create larger worlds (MMOs), we have recommended design patterns that can support this by splitting your "world" into multiple rooms so the room logic computation can be parallelized across multiple processes.
We used this method of "splitting the world" for our space MMO CSC. To accomplish this, we dynamically split up the universe into rooms based on galactic coordinates. You can define and set this as a custom parameter in the room options, and the client can ask the Colyseus server to join a room that matches these options.
So, for example, when a player enters the game, they start in the Sol System (our solar system) the 0, 0 coordinate is the Sun. As a player moves away from the Sun, we identify their new coordinates based on grid size. For example, we might say a grid is 10,000 km square. So once they are 10,000 km away from the sun in any direction their new coordinates would be one of potential 9 coordinates (0,1, 1,0 1,1 -1,0 etc.. - room name example "sol_0_1 = 0,1" ). To ensure a seamless transition, we actually have the player join 9 rooms when they enter the solar system. Typically this is their origin room and then the 8 other rooms to all sides. As the player travels through space, we are leaving and joining rooms to ensure that the player always subscribes to messages in their current location and message in 1 away in all directions. In addition to the 9 rooms, you typically want to have your player in an additional room for global events and/or chat (Ex "sol_chat, sol_global"). For a fully 3D world with three axis of movement, you can use a similar approach, but instead of creating rooms based on two coordinates, you would use three.
For scaling, there are main approaches that can be taken, and the decision very much depends on the game type or design. There is an upper limit on how many players can reasonably be in a single room on a single server. This very much depends on the type of game, the number of messages per second, and the complexity of the server logic loop. This is where our SaaS-hosted solutions for Colyseus really shines. As a game developer, you don't need to worry about having enough servers, as new rooms are created, and the world expands with players. Our Colyseus Arena system will automatically deploy new servers for your game, and our load balancer will ensure that rooms are balanced among the available servers ensuring consistency in performance.
C: What are some of the items that Colyseus supports that developers can take advantage of?
CT: Besides the room-based system we just talked about where you create your “room” logic that is capable of handling multiple game sessions, Colyseus has a unique state synchronization mechanism where instead of sending and listening to arbitrary network messages, you simply mutate the state on the server-side and attach callbacks that are triggered automatically in the client-side.
Our room’s state synchronization algorithm ensures that only portions that have changed in the state are going to be transferred over the network. After mutating a structure on the server-side, the client-side is ensured to keep in sync with the server in the following “patch interval.”
C: We know many developers are new to the industry, so we’d love to know how has networking technology improved in the past few years from partitioning game states in the early years of network gaming to today?
CT: The most significant improvement in network technology over the last few years has been the adoption of containers and how that can be used to create very flexible and scalable systems. By using containers, a developer is able to create servers and bring down servers quickly and more efficiently. When set up correctly, this can be a considerable cost saving for a developer allowing them to support a larger player base without having to maintain expensive idle server resources. Colyseus being a lightweight Node.js-based framework, makes it an ideal container application.
Typical game server deployment of the past either consisted of physical bare-metal servers trying to get the highest amount of performance or VMs that allow for the greatest flexibility in a cloud hosting environment. Containers give the same benefit as VMs but with a far faster deployment speed. Meaning servers can be scaled up in a fraction of the time and scaled down just as fast, saving you that additional cost.
C: Sounds impressive. What are some general tips you give to developers who are starting to work with Colyseus that can help them improve their game?
CT: Any developer looking to make a multiplayer game for the first time should keep a few things in mind.
1) Develop the game with cheaters in mind and make the game as authoritative as possible - Cheating can really hurt the overall success of a game. Once your game is live, your team will have enough to do and will start rushing to patch exploits, and blocks for cheats can become a major drain on resources. That's why I always recommend that developers try and make games as authoritative as possible from the start. Limit the logic and functionality that can affect the game's outcome to the server code, limiting players’ ability to find ways to cheat or hack the game.
2) Focus on building a fun game, leaving the DevOps and scaling to trusted hosts or SaaS services - Self-hosting is great to get started and for development, but as soon as possible, you
should start working with a DevOps solution or SaaS product. We have seen many games save that step to the final weeks only to find out they didn't account for a specific requirement needed by the host or SaaS.
A great example of this is the open-source Agones solution for server and fleet management. This system works great and runs on a swarm of docker containers typically hosted on Kubernetes. However, if you did your development in isolation and never consulted, collaborated, or signed up for a hosting solution, you will come to find that you might have overlooked a key aspect of a multi-server environment, which typically ends up being matchmaking across multiple servers and SDK integration. In addition to this dev work, you quickly realize that this alone isn't a turn-key solution, and you will need to hire a DevOps engineer and find a suitable host. This can be a significant upfront cost for a small game studio and is one that needs to be paid regardless of the state of the game.
Finding a turn-key scalable SaaS can be the better option. With the proper SaaS solution, you will only be paying by usage or CCU, limiting your expense initially yet providing you the ability to easily scale while your game gains in popularity. Colyseus Arena is one of these services specifically designed to work with your existing Colyseus source code.
3) Keep it simple - This is possibly the most crucial bit of advice we can give developers making multiplayer games. It’s easy to overthink what needs to be sent as messages and the complexity of your game systems when developing a multiplayer game for the first time. I always recommend making a prototype or MVP as quickly as possible. Playtest it, make sure it’s fun, then use that as a template to recreate the game server/client in a more methodical way. You will typically find areas to be more efficient and improve your codebase the second time around.
What are your future goals for Colyseus?
Our aim always has been to be “the” solution for any type of multiplayer game you can think of. The request we get the most from the community supports other transports than WebSockets, such as rUDP, or WebRTC. Another request that makes a lot of sense to us is to provide an Entity-Component System. We’re always listening to the community and our clients for more suggestions.