Support for Persistent, Always-On Servers in Unity Cloud for Multiplayer Online Games

Unity Services
,
1

I’m developing a casual game that requires continuous server operation without releasing sessions. Currently, I’m using Unity Cloud, but I’ve noticed that services like MatchMaker and Allocation in Unity Cloud are primarily designed for games with clear game sessions. This approach seems more suited for games that frequently allocate and release servers based on player sessions, like competitive or match-based games.

In my case, the game doesn’t have defined game sessions, and I need a server that can remain active persistently to support a continuous player experience. I’m unsure how to best utilize Unity Cloud services for this type of persistent, always-on setup. Could you advise on any configuration adjustments within Unity Cloud that might better support this requirement, or is Unity Cloud not the ideal solution for this type of game?

2

Not sure that wouldn’t be very cost effective or scalable. You would be better off having servers spin up and down depending on the number of players, each server will only be able to handle so many players. When they spin up they load the persistent data from a database and register some sockets to listen for changes to that database. Active servers send changes to the database, all other servers receive the changes. If you need logic to run even when no one is playing and no player server is running, then create a separate lightweight server that runs constantly and makes changes to the database.

This is all very general and I don’t know of an out of box solution that could do this.

2 Likes
3

Because that’s akin to MMO technology. There’s no middleware market for this because anyone who implements a game like that where you have 24/7 servers is most likely going to work on their own proprietary solution perfectly optimized to their own use case in order to effectively minimize the costs.

In those scenarios every byte, every CPU cycle matters a lot in terms of costs.

Although you’ll find solutions advertised for MMO creation (eg Atavism on UAS) they are expensive one way or another.

Because that covers the majority of use cases.

You don’t need Matchmaking if the server(s) are online 24/7. You only need a list of IPs that your game gathers from some cloud storage where it says “Europe, Amsterdam” along with the server’s IP and players can choose their server and play on that. This is the MMO way. Servers never go offline, except for maintenance.

But even the middle ground, what Minecraft does, is what only the likes of Minecraft can do - simply because they can afford it and each server has a low player count limit. They give everyone the ability to rent a custom server that players can then manage themselves, within limits.

If your intention is to support 100+ concurrent players then your best way forward is to either
a) implement everything yourself
b) forget about it.
:wink:

1 Like
4

Thank you so much! Your perspective has been incredibly helpful. :star_struck: Our team is completely new to developing multiplayer online games, so we really need these insights to guide us in the right direction.

I’d also love to ask if you might have any specific recommendations for our situation:

  1. Our game indeed requires 24/7 availability.
  2. However, we’re willing to make some trade-offs on scale. We’re considering a design with “islands” as the basic unit, where each island has a capacity limit (we think a cap of 200 players per island would work for us – not for concurrent users, but for the total number registered on each island). Each island would need to run 24/7 as well.
  3. Currently, we’re in the early investment phase, so we can make compromises for now. If we could find a solution to support a small MVP test for about three months with around 1,000 registered players, that would be sufficient – even if it’s not the perfect solution. (Of course, we would still prefer a long-term solution if possible.)

Your experience and insights mean a lot to us. Thank you!!!

5

This

and

… tells me you have a steep learning curve ahead of you, with investors breathing down your neck. :wink:

I wouldn’t even consider talking to investors UNLESS you have a working proof of concept (prototype) with 200 concurrent players on a single server where players can at least walk around, wave hello, and not crash. I would set that up first and foremost, and also figure out a way to actually test with 200+ real players!

I mean, if your team is that size, it’ll be easy but more likely you will struggle to get to 50 players if you rally the team’s friends and families. Beyond that you need to find some way to distribute your game semi-publicly and get players to join with nothing in it for them.

If you manage to get 200 players together, be sure to record this on several machines (points of view) to prove that this is actually working because you can’t repeat this live in front of investors.

With no multiplayer experience at all, going to two-digit concurrent player numbers is already a challenge in and of itself because of the above. But three-digit numbers needs serious optimizations and lots of refactoring so you need to get this many players join a server quite frequently as you do tests.

You may be able to reduce the number of actual players required for a live test by connecting several “AI” (fake) clients on a single machine, but not too many because each instance still needs to run at 60 fps. But those fake clients won’t really reflect actual player’s behaviours and connectivity issues.

If you believe you can build this on top of Netcode for GameObjects (or similar frameworks) you may quickly find yourself in a situation where the overhead of these “ease of use” networking frameworks won’t let you scale beyond 200 players - and may even be problematic far below that (mainly traffic and server CPU load - you typically pay both per use in some way).

The CPU issue is a damning thing because NGO and most other network frameworks (Photon and Netcode for Entities are exceptions) run on a single CPU thread, and so does most of Unity. This is why an Entities-based multithreaded server networking framework and corresponding Entities multithreaded code is a worthy investment (more realistically: a requirement) for scaling up to several hundreds of players because if you rent a quad-core CPU server you don’t want three of the cores sit idle.

Just a few pointers. I recommend to heavily lean into experimenting, benchmarking, and prototyping at this stage.

6

You’ve stated that you need these servers on 24/7 a couple times now, but haven’t clarified what drives that need as mandatory.

  1. Do you believe you’ll have 24/7 players in the same world, region, and zone. And I mean that in terms of both the game world and literal planet Earth. In all likelihood player traffic will ebb and flow throughout the day across the globe. Designing for ephemeral vs persistent server compute will significantly lower your operating costs. You’ll be able to have servers closer to the playerbase in order to reduce latency, which can kill your game in a heartbeat. Folks have very little patience for janky multiplayer these days. Having compute scale up and down based on player load is a mostly solved problem with the various server hosting orchestrators on the market.
  2. Do you need 24/7 persistent compute because the world is running logic while players aren’t present? Consider rethinking that decision. Computers don’t need to be constrained to human based timescales e.g. when a player is logged in and observing events they unfold in “real-time” but a computer can simulate expected states of things in milliseconds and doesn’t need hours of calculations to “grow a tree from that seed, or have an army conquer another nation”. These are just game states and you can “fast forward” to the expected state when players login, ephemeral server compute spins up, and the world feels like it evolved while offline. All of those states could be calculated and stored from a previous session, calculated at login time, hardcoded, or some other clever approach. So strongly consider if the game design and mechanics are truly dependent on persistent compute or if you can fake it.
  3. Do you actually just need persistent storage and not persistent compute? The islands approach sounds much more like a Minecraft sandbox world, well defined procedurally generated, state stored and rehydrated based players coming and going.

I’ll note that for your first multiplayer title, going for an MMO has some seriously long lived gamedev memes associated with it. You’ve chosen “exceedingly hard mode”. Companies like Improbable and KinematicSoup have solved major pieces of the networking problems of large-scale worlds, consider reviewing their tech. Do some Perplexity AI searches on MMO architecture to find gdc, forum, blogs, and website resources on the topic.

1 Like