Unity 2018 - Capable of an MMOFPS 900-1200 players possible?

Good evening / morning.

The question is very simple yet BEYOND complex.. Does Unity, in it's current state, posses the capability to support an MMOFPS that ranges from 900-1200 players?

I know the Engine with proper techniques graphically can easily handle 1200 characters moving. The netcode, the options involved in optimizing said netcode; Can the engine handle it? Be as technical as possible please.

Cryengine and 40000 migraines will ensue if this engine can't handle it.

 

certainly can handle lots of objects and action recently
https://github.com/Unity-Technologies/UniteAustinTechnicalPresentation
*video of it

about networking, maybe this helps,
https://forum.unity.com/threads/ben...dgren-miniudp-hazel-photon-and-others.512507/

 

Yes, but you will have to build your own networking solution or license one intended for this purpose. I believe the LLAPI is capable of handling the sort of load you're describing here, but the HLAPI is only intended for very small populations and doesn't scale well at all (HLAPI memory leaks like crazy beyond 4 to 8 players and is technically incomplete).

For an existing solution I don't know. I have spent a small amount of time researching the ways to develop an MMO and the only solution I'm aware of that would be able to handle a population like you're describing in the same vicinity would be SpatialOS by Improbable. They've advertised it here before and it's being used in some existing games like Worlds Adrift.

https://improbable.io/

 

The question implies that you expect this kind of thing out of the box, which no engine will provide to you. The more appropriate question is something like "Does Unity allow me to integrate my own networking solution to build an MMO?" - and the answer is yes.

 

"Are you capable of writing that tight of net code?" is the real question.

You'll have to ask yourself the same question for Cryengine as well, since out of the box support for 900+ connected users to a single server for a twitchy FPS style MMO isn't part of the base Cryengine either.

Normally you'd develop a solution where you'd drop the number of connected users to a single server to a much more manageable number, but still have a large game world across a cluster of servers.

 

900-1200 players on a single map in real-time, like in Planetside 2? That would be hard in raw C++.

 

I've done a LOT of research on it and it seems Unity is the most flexible! Cryengine is a close second but doesn't have the amount of support that Unity does. This is going to be one hella expensive undertaking

Thank all of you for the feedback!!

 

Are you even remotely open to the idea of doing something smaller first? Because that's what I'd suggest.

 

Depends a lot on the draw distance. 1000 players seeing eachother is hell. You're sending 1000 * 1000 -> 1M updates. If those 1000 players on average see 15 players, you're only sending 1000 * 15 -> 15K updates. If some are idle, the number lowers more. Though of course you still have the worst case scenario (everybody bunches up in a corner, rip your server).

 

You need a dynamic tick rate. If 200 players are in close proximity then you use a lower tick rate than for those in another place on the map thats only 15 players in close proximity. This only affects what the server sends though, the clients still need to send at maximum tick rate to the server.

 

Not sure how you came up with the numbers but I guess you are talking partly about peer to peer like architecture? you wouldn't do things that way in a large scale MMO. Each player sends their info to the server and server packs it out in to a single tick update per player depending on distance, visibility, importance. Update count should not really go up with the player count but rather the size unless you need to split updates.

 

For this scale literally everything needs to be custom. You will more or less only be using unity for lighting and base rendering.

Here's Epic talking about some of the techniques they used for 100 players in fortnite.

You're talking about 10x larger scale. To achieve good quality in something like this, you're going to need some extreme practices and will be using almost nothing stock from unity.

 

Yeah that's true. I mostly meant 'data size' not so much 'packet count' though, I could've been clearer.

Also true, I didn't really think about that. Though that'll only get you so far in a FPS before it degrades the gameplay unacceptably.

 

So, I've been doing a LOT of testing. Unity still holds the best performance.

I believe we should share information, so I'll share my techniques so far (though not quite as successful.)..

I am using 'zoned' information that grabs information from three main databases. First Database grabs last and first character placement for introduction back into / out of the game world. It also handles all 'profile' saved information such as statistics / "X Variable." ... This is a hybrid verification of MD5 and encryption to prevent manipulation.

The second database holds The REST of the players "current" position, which is being updated via proximity of the "current" player.. It gets extremely complicated after this. (and please understand this is my first attempt at this)

At this point, i call it "zoned"... And it's based through world based 'triggers' that send specific information. If "x" does this and = SIGNIFICANCE then it takes priority via message. (blanding it down as much as possible........) These "zoned" areas have Two main functions " What has happened " and " what is happening"...with ONLY the most pertinence data being transmitted.

The third is Player on Player Zoning. This uses P2P / MSB technologies... Again to assist against people attempting to manipulate the software. At random intervals the player with the "greatest" connection is then a conduit of a sort, that houses the game session..While still using the MSB as the primary verification server. Getting the transition between the two has been problematic but My DRUNK ass may have figured it out about three hours ago. : ) SIMULATED packets!


(I know that questions will be asked and I will be on as much as I can to answer them... I also know it sounds Far-Fetched as F***...) It isn't... It just has to be done right. Manipulating connections to appear as an "MMO" is FAR easier then actually trying to put 900 people in the same place. And if the illusion is seamless.... ?

I plan to share all of this in great detail... I know I'm not the best at articulating (at all..) what I'm attempting to do.. Please forgive me, I make money, I drink and I come up with very wild ideas.... Then I do them... And knowing how I am, I even created (started writing two years ago) a contingency....


On that note... Kaibear's systems will be free to everyone tomorrow as well if all this legal BS is handled.

Personally I would like to stop seeing the Unreal Engine as being the "go to " engine when it's far less adaptive and freedom giving. And don't get me wrong, I made a TON of mods with Rainbow Six Ravenshield, Unreal Tournament 2... I LOVE the engine... But it's focused more on "Hey I'm pretty"... Not "Hey I'm Useful".. Or adaptive...

 

And look, I know who's reading this. The fact is, I'm going to do this.. With or without any outside help. I would LOVE to do it with an existing technology. I HATE some of the S*** in Unity and how it operates, but 99.9% of that is my own ignorance to the engine. And the other .1% is the engine making my hair go grey...

 

This Needs a LOVE button, I just see read this comment.

 

And if MGM would ever respond back...... Just saying...

 

Must be the first time I've ever heard "Cryengine" and "flexible" in the same sentence.

 

If you're going to do this, the first thing I'd do is get started on your custom networking API. This project succeeds or fails on your networking implementation, and none of the available high level networking API's are suitable for this so you're rolling your own. Don't waste time on anything else until you've got the networking part solved.

 

I agree completely and I have actually personally began teaching myself several aspects of this. I'm about three weeks in and Oh My it can get tricky (tricking) the player into seeing what they think they're seeing.. I will obviously hire someone who is well more adept, but I need to understand the fundamentals thoroughly before I can hire anyone.

I know TCP is the method of choice because UDP basically spams the packet until it's sent, and it's actually a much faster protocol for other reasons... But using TCP would make anti-cheat SO much easier on a server side / hybrid. So right Now, I'm working on a 'zoning' feature; And it's probably rudimentary... But I think I might have found a way to make the players themselves assist me in the dilemma and still use TCP. It's been three weeks. Give me three more.

Also, whatever I figure out will also be 120% free on the asset store. I've already spoken to several people who are "top" people on the asset store that's sent me PM's and they're going to distribute Kaibear's stuff out as free with me in the credits or whatever (I could honestly care less..) to everyone. I wanna see what smarter people can do with this S***!

Unity has given us a Great and at times Ripping-Hair-Out engine that really does perform better than UE4, Cryengine and even Torque 3D in terms of flexibility and the graphics are literally one step away from being Better than those other engines.

So with that said, and keep in mind, I do most of this completely F***ed up... Like, High and Drunk.... This is what I've done so far, if anyone cares.

A service based system that allows for players to pick up "zones"... But, they are not the SMB (Server Master Browser). SO ... You get say, 200 people in a "zone".. You then, with real time calls (and it's really NOT that expensive nowadays).. Tell those people to "host" the players connectively through a service. This actually pops their system with constant calls; And those players are the powerhouse PC players. Ya know, your garden variety I7/32 gigs of ram/SSD players. Using this method, you can get a 'server farm' from your playerbase. So far, in testing with a bs little C## program I used to emulate this, it's F***ing Superb.... Then there's the mess of figuring out the zones which I'm working on right now. It's not complicated, but it's tedious.

I am sharing this because I believe the knowledge should be free and I think outside the box quite a bit. But I do ask that no one uses this 'idea' and try to sell it...

 

Cryengine is actually very flexible and now that Lumberyard is in play, it's even more so. Just like Unity and any other engine. You have to make it do what YOU want. Learn it's in and outs.. Within parameters. ... Or write one yourself.

 

I've done smaller my whole life. Go Big, Or stay at home...

 

It might come to that. You could easily loose the house on a project this big. Have fun!

 

So with the naysayer attitude (no offense)... I've had one other revelation. In addition to using real-time calls for people with "beef" pc's.. I've also found a way to (in Unity terms) Occlude the player field; But in it's very definition. We have the bandwidth now and not many people realize it's 2018 with everyone having at minimum 5mbps. The service can routine scan every 10-12 seconds a "play field". But this is not enough.. You have to wipe this memory basically instantly. So to compensate (and this is the genius part!) You have to cross connect the service and "share" the load! It's definitely completely stand-alone third party or whatever...

The technical side of it. You have a service that works with Unity to communicate a player's position and what they see in a 110 range of view. Each player is a "node". Each node acts as a communication point, a repeater if you will. ((I think I understand now how Red Storm Entertainment made 56k modem "no lag" (unless one lags) instantaneous communication. ))

Each person delivers their said position and two to twelve other player positions based on Occluded positions. Then you simply extrapolate. You use the data required.. Hell.. It would work for ANY engine, any platform. You could have 10k people on screen if the engine could handle it...

My brain hurts and I'm pretty drunk (not high at the moment though... ) So I'm giving in for the day..

 

I am going big, or I AM going broke. I just reread this and edited it and hell I didn't even make sense.... I do know that I'm doing this, regardless of what anyone thinks "possible".. I will figure this out. I have figured this out..... I just gotta implement it...

 

Yes, the problem isn't too difficult if all you're thinking about is the position of visible players. But that's just scratching the surface of the information you need to arbitrate.

What about what I can hear? I can hear stuff 360 degrees. I can also hear some things from kilometers away - explosions, loud vehicles. That's a pretty important part of an FPS, as I often hear things before I see them and, indeed, my hearing tells me where to look a lot of the time.

We're still not done. What about visual cues not attached to players? Explosions*, environmental damage that occurred when you weren't around, smoke in the distance as a result of player actions completely unrelated to you...

To be fair, a lot of this stuff can be havily fudged. It doesn't matter exactly when smoke becomes visible in the distance, stuff like explosions* can be drastically simplified, many things don't have to animate the same way for all players as long as the end result is equivalent, and so on.

* Note that the explosion in and of itself isn't a big deal. It's the stuff the explosion effects that might be complicated.

I'm not sure I'm understanding your intent here... are you thinking that you just invented peer-to-peer networking?

 

No. We're very far from everyone having a minimum of 5 Mbps.

 

Is bandwidth even the biggest issue, though? Games like Planetside and WWII Online were doing this stuff when the 'net was a fraction of the speed it is now.

 

No. Usage limits and latency will be the biggest issues. Most of the people in my area with fast connections are on satellite internet which has steep latencies and very tight usage limits. From experience I can tell you that gaming on them is almost impossible outside of turn-based games.

Wireless connections through mobile providers have acceptable latencies but the usage limits tend to be very restrictive so it's not much better there unless you're willing to pay for an unlimited data plan.

I'm one of the fortunate few in my area with Verizon DSL. Low latency and no data limit but my service is the only one that has successfully reached (and surpassed) 5 Mbps. At least among the people I know who have the connection. It's very iffy with one connection three miles away being only 512 Kbps.

 

Yeah, I've never even considered such connections as an option for gaming, purely from the latency. I don't think that's something you can fix in software, though, aside from designing your game to have slow response times.

 

I agree. If the project is really going to be a 900-1200 simultaneous player game, then the first step is building a custom networking solution for this. And the next step after that is building an adequate test scenario for the custom networking before the rest of the game is ready.

 

You could go with the old AOE2 lockstep solution, and force every player to run at the lower response speed. Doesn't seem sensible for an MMO though.

 

Eve Online.

From what I remember when playing it, the game made a trick where it doesn't allow any rapid user controlled movement, and is quite close turn based game. You click something, your ship starts moving there. Calculation is probably done on the server entirely.

 

Eve Online also does another technique under high load I think they call time dilation. So the game technically supports unlimited players in each star system, but at any given time most star systems have only a handful of players in them at best. But the players have broken themselves into incredibly large blocks of player created coalitions, sometimes containing 10's of thousands of individual players. When a critical piece of infrastructure is attacked, a battle can quickly escalate into well over a thousand players involved, and it is apparently not practical for CCP to dedicate enough hardware resources to running each star system (there's thousands of star systems) to handle that many players when 99% of the time player numbers there are in the 10's.

So when a star system gets overloaded they literally slow time down, and slow server ticks, to give the server enough time to process everything happening. This makes large battles take longer than they normally would, but it avoids any problems they were having with an overloaded server that would drop requests or disconnect players as seen before this was implemented.

 

900 - 1200 is beyond the limits of what is possible on the bandwidth side given any average scenario. The problem is that latency increases with the amount of data sent. So the wall isn't how many mbps your connection can handle, it's how much data you can send per frame reliably.

In my tests anything over 100kbps started to get a bit sketchy. At those rates around 500 players is probably tops taking into account not just movement but combat related data also. Which also matches up with what real games that push the envelope here do, who usually hire people with a lot of experience in this area.

 

I also don't know if that's a workable solution for shooters in general. I'm under the impression that the lock-step approach for RTSs works well there because a) you've got a small number of commands being issued compared to active characters, b) the results of those commands can be designed to be deterministic and c) every client has to be able to implement all commands in real-time anyway.

So, instead of sending a state update for every unit in every tick, only the commands are propagated. Then each system simulates the results of those commands and, I would guess, has some kind of method to see if things are still in sync. This drastically reduces the amount of data required to keep a consistent game-state on every client withtout impacting the fidelity of the game.

Since none of the things from the first paragraph are typically true of an FPS I suspect that a lock-step implementation would result in no benefit and either drifty or slow-motion gameplay.

 

Yet Planetside 2 has done it (albeit with a different engine) with 2000 players. I've progressed a bit and I'll explain in a post down the line... But you aren't even open to the possibility. Though you have reason to argue it, you don't want to look outside the box.

 

STOP. Flat Response of STOP. Threading it. Creating it. Making it a THING. Stop. Thinking ... Within the Box!

 

Will my Method work? Probably.. I've done the math on it about 6 bajillion times... Is it working Now? No.. Eff No.. Not at all... But it's making simulated progress.. I've simulated 1200 people online, in one area and Mathematically IT WORKS.. Technologically, IT WORKS! But Practically .. It probably doesn't...

I think another group ( I googled this S*** extensively ) got around 2k players in one area in 2011.. it was buggy at best but it worked.

Yes.. I get the naysay of the idea. I truly do. That's not going to make me stop progress or attempting to do it. And I can have an entire thread of 10 people saying I can't do it, or I can have a thread of two helping out.

I understand it's a MASSIVE undertaking. The Engine was NOT built for this, I get it... I swear to God I do... But I'm doing it anyway... I don't need 1200 people. I need 900 on a test scale and 600 in production. 200v200v200 and THEY will be spread out...

Using a zoning SMB based peer to peer system may not be my end game... I'm Effing working on it. And if I figure it out, I'll make it free for everyone to use ( Hell, THREE MMOFPS games since 2001 )... It's kinda bs...

Someone has to do it... And I'm going to use the funds from KaiBear to DO IT In Unity... If Unity will allow me...

 

There are well funded games that struggle at times with 100 players on a server. As a general rule of thumb, when new forum users immediately bring up some form of MMO, those new users tend to get frustrated pretty quick. A 1200 player MMOFPS game would be a significantly difficult task for a very well funded AAA studio, but it would be doable if the large companies brought in highly experienced network devs.

The reason some people are naysaying this is because it is a difficult problem that will have to rely on compromises to work. When you carefully decide what compromises you can actually make, then you can reduce the network load per user. For example, maybe you will use a low tick rate or a variable tick rate. Or maybe you will come up with a way to only update certain information for nearby players instead of all players. Or maybe bullet paths will be computed entirely on the client side. Come up with every possible way to reduce network load while still delivering the core gameplay experience.

 

I remember reading article about L4D.

Basically, they compressed the hell out of their data and removed everything. IIRC they reduced every single zombie to position + height (4 floats) or something similar. Everything not sent via server was reconstructed on the client.

In all honesty, I'm not really sure what are you going on about here.

However, I'd recommend to check whether you have the resources to run this thing or iif it is even worthwhile.

Many lesser known games struggle to find enough online player audience, and if you're expecting to have 600 people available per match, this is kinda bold.

In the end it is a data representation issue. The amount of bandwidth you need is... "data per object"*"number of objects"*"number of players"*frames per second.

So, let's say 600 people that also work as objects, 8 floats per object (48 bytes - position, velocity, and some data), 30 frames per second. 600 (object) * 600 (players) * 384 bits per object * 30 fps ==> 4147200000 bits per second ==> the server requires 4 gigabit connection, and player requires 7 megabit connection.

To bring the number down, you'll need to keep players apart from each other, and limit updates they receive to their vision range. However, if the guys decide to gather all in one place (and they will), you'll be still dealing with 4 gigabit connection requirements.

Alternatively you'll need to invent a different game mode, which would be a mix of realtime and turn-based combat. Meaning that rather than taking control directly and walking around in unrestrained free form, they'd be ordering their characters to move somewhere or shoot something

 

Yeah, that sums it up. The ways around this would be for the OP to decide on compromises. For example, maybe the server tick rate could be 2 instead of 30. Maybe the player positions could be largely interpolated from existing position and velocity data, so the models would move smoothly on the client side with a high rendering frame rate despite a very low server tick rate. If the game relies on competitive shooting, perhaps there could be options to allow for temporarily high server tick rates for specific data, such as when two players are directly fighting each other at close range.

Additionally, a lot of the bullet path and bullet collision code could be purely client side. That would make the game more vulnerable to cheaters, but it would also allow the game to scale more effectively.

 

To bring the number down, you'll need to keep players apart from each other, and limit updates they receive to their vision range. However, if the guys decide to gather all in one place (and they will), you'll be still dealing with 4 gigabit connection requirements.

 

Also, reality checkregarding number of players:
A niche fighting game on steam will have about 30..60 people available online simultaneously.

A popular survival game will have 2000...3000 people online simultatneously... that's total. However, those people will be pooled by their geographical location, and a single server can often have 15..25 people total.

So... I'm not sure how much point there is to have 600 people support.

I recall a game called "Flock" which seemed like an interesting experiment, but....
https://store.steampowered.com/app/290490/The_Flock/
Unfortunately it failed.

The idea was that online population of players would have a limited number of lives, meaning once the monsters run out the game will be over.

Except, it didn't quite work out this way and the game wasn't popular enough.

One more thing: Keeping players separated is probably not going to work, because when they hear about 600 player support they'll want massive battles. Meaning they'll go to one spot and crowd there. So you'll STILL be dealign with huge bandwidth requirements.

 

And the goal is to be able to support this, and I know as of "right now" I'm not capable of producing that, but it is being worked on... As for the Huge Bandwidth Requirements, again, Planetside 1, Planetside 2 and World War 2 Online (Battleground Europe) were and are doing this (on 265k DSL...) . And I do believe their methods are hybrid client server side connections as well. I'm not saying it will be easy, or even moderately hard, I'm saying it will be extremely difficult... But it is in no way impossible. There are several factors that will come into play when doing this, and a fair part of it will be sending / receiving the least amount of packets required.

 

You're actually onto something here. And player positioning is a key component and a HUGE resource hog. I now know why PUBG and other games have the character "slide" for a moment after releasing the Move Forward key (or any direction for that matter).. It allows for a fairly significant margin or error in regards to the players final position. When you see warpin' and the such, it's simply the servers way of trying to calculate the player position with little margin of error. There is a WHOLE MESS full of "compromises" that must be taken into consideration, but you're more right then you realize about player positions.

 

And I'm saying that without good marketing it may be simply a waste of development time.

 

It's not going to be designed as a "match" based game. This will be in a persistent environment that spans over several scenes.

As for the math, I reread what you wrote and I do see where you're coming from. And *If* (and I promise, I'll test the hell out of it with no If in the statement ) 600 players, in production are in the same area.. There is sure to be issues. Again though, this is where trial and error and testing takes places before the production environment. I know it's possible, it has been done three times now. (Forgelight Engine can actually support 2000 players simultaneously in planetside 2)

 

Without a doubt, I agree with you on this 254%!! It could be the best video game in the world, but if no one knows about it, no one will play it. Advertising is quite a bit down the road, but there will be a following. That's as simple as getting on gamerPC or paying FrankieonPC to play etc etc.. There's many methods. Not to mention Steam? But yes, I do agree. Great marketing will be a requirement.