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

It's more complicated than that though. If large scale battles are the main selling point of the game then you will need to have large numbers of players online at the same time and you will need to be able to do that practically as soon as your game goes live.

Like @neginfinity mentioned most games simply haven't been able to have that many concurrent players in one instance.

 

Yeah, PUBG is a great example of all of this, and keep in mind that PUBG is only 100 players per server. If your goal is 1200 players per server, then it is going to require even more creative compromises.

About the sliding in PUBG: I think those devs did that to follow the military simulator roots of the battle royale genre. They want the movements to feel heavy, so they can simulate momentum. But there are ways to trick your player character into being more aggressive with movements. For example, if you briefly crouch while turning in PUBG, the transition into crouch while break all of the momentum. It is a way to instantly stop instead of sliding.

And keep in mind that everything in PUBG seems to be client side, which helps for scalability but makes it very vulnerable to hackers. For example, about 30 players were killed in the military base on the original map one day in a matter of seconds, including everybody in my squad. When I watched the death cam in PUBG, it showed the hacker inside a room inside a building with no line of sight to any other player. Yet the hacker simply spun around shooting until everybody was dead. Since PUBG does bullet path and hits on the client side, the PUBG server simply trusted the information the hacker's client software was throwing out. The compromises the PUBG devs made cause PUBG to be vulnerable to those types of hacks, but those compromises were needed to scale.

 

You are also very right. And once I get to a point where I can "demo" the product, I will be doing live stress tests and play tests. I am pretty well known in the gaming community, been around for years and made a lot of friends, who have friends as well. Not to mention I'll be financing paid advertising. The question will be, is the game good enough (and is it what players want trend wise) when I release it. World War 2 online and Planetside 1 were Well ahead of their 'time' trend wise... I think if Planetside 2 wasn't a BF'X' simulator, it would have an even larger following.

With that said, getting the players will be easy; Keeping the players will be hard (er).

 

They are using Unreal's basic netcode and believe it or not, player position is not client side. It's very much server side actually. As for hackers, that's going to be present in every game, but I have an idea for that as well... A MUCH different approach but that's one I can't share ..

Also, I've used (first hand) a lot of military sims, I don't recall any of them having a "drag" really. Not like that. Hell, most of them were stationary.. But It's been a few years since I was in.. I'm not saying you're not correct though and that may very well be the case. I do know that during my own testing, I've found that 'sliding' player positions allows for significantly larger margins of error server side without 'warp'. It's not so definitive so to speak.

And, to say you're right once more... There will indeed have to be compromises... As I said laid out before, it's going to be a process and it's very experimental with what I'm doing. I'm attempting a peer to peer to server to peer times = X (whatever works out).. It'll be a bit taxing and may not even be possible, but I'm going to learn a WHOLE lot about netcode trying it out and putting my full attention into it. I mean on paper and im simulations, overlapping zones using "beef" PC's has Significantly (i mean the actual Webster's Definition of significant..) reduced simulated bandwidth usage and I hope in a couple weeks I'll have some way to tie this into Unity's profiler, or have someone write my own to compare the differences.

Andddd Finally lol. I'm not really here to argue with anyone or read about how it's not possible. I do understand it's an undertaking and I promise you I'm not taking it lightly. I'm not doing it alone and I have a LOT of people who believe this is possible who are helping me with this. I mean, I get that you're probably trying to do me a favor and explain to me that it's going to be complex and mighty expensive, but I promise, I know that.

So going forward, if anyone has any cool ideas to throw my way (and they can be anywhere outside of the box, no idea is a bad idea, it can always be drawn upon).. Then feel free

 

@D12Duke1 Well, if that's the problem you feel working on, then start working on it. There's no point in talking about it.

Many people have dreams they speak of with starry eyed eyes. Most of people fail to achieve them though.

I do recommend to make a reality check and verify that your game needs this tech to begin with. Marketing for massive battles and having 10 people online is gonna suck. At least make sure your game provides thousands of bots when player numbers are lacking.

There aren't many ideas left. You already heard most of them. Main approaches:

• Separate by location (ain't gonna work, because players will want massive battles)
• Run players at reduced framerate. Meaning you'll send up dates only to percent of players per frame. This can cut bandwidth massively, but makes fast paced movement impossible. Hope you like rubberbanding.
• Proxy servers. Meaning you have central node that computes everything and sends it to "node" servers which handle a percent of playes (25%...10%... you get the picture). Reduces network io load from the server, the client may still require multi mbps downstream connection.
• Compromises in number of obejcts being transmitted. For example, if you make environments fully static, non-interactive and non-destructible, anything aside from player positions, position will go down. Games like PubG launch massive amount of data through connections, because every piece of landscape that can be destroyed is a networked object whose state client might need to know.

And that is pretty much all.

 

You probably don't want to do simulation at a reduced tick rate, though. Simulate everything at full rate on the server. Then, for each player prioritise data based on how important it is, and send state updates for different things at different rates accordingly.

For anti-cheat reasons you want to do some of that anyway. If one player can't see another the server should know not to send the latter's data at all, otherwise it's wasted bandwidth that provides an opportunity for wall hacks and the like.

I suspect that this would chew up a bunch of other server resources, though. It's no longer just exchanging game state data between clients, it has to understand it well enough to know what is important to who and when.

 

That's kinda obvious so I didn't bother mentioning it. You run simulation on the server on full framerate. But each player receives an update every 5th frame or something.

 

In terms of TCP vs UDP: https://gafferongames.com/post/udp_vs_tcp/

That's a good overview on why games use UDP as a general rule. If you're thinking that TCP is desirable for a massive scale multi player game, then I think you are not serious.

To smoothly match players at 1200 players per match, I think you probably need a daily user count of at least a quarter million. But let's start with a simple case, lets say you have 1 match running at a time only and each match takes 20 minutes. To have matches start back to back - you have 72 matches a day - this would require 86,400 player sessions per day to run properly.

Obviously, that's an oversimplification, and since player counts will spike at certain times of day at times you can run 3-4 matches at once and other times have a 15+ minute wait time to start the next match. Still, to achieve this kind of player count with enough consistency to keep the game running, "paid advertising" won't cut it unless you have very deep pockets.

Again, there are ways to manage this and it's not impossible. But I wanted to give a sense of scale to the size of the player base you'd need to run this smoothly.

 

GOod job spotting it, I actually overlooked this part.

Yeah, using TCP for massive game is bananas.

 

I would not simply rule out TCP. But if TCP is chosen, it will be important to write code that watches the network buffers to prevent a data backlog. Depending on the mix of compromises in the game design, TCP might work fine. The main problem with TCP in most games is the random time delays that TCP can cause, but there are ways to mitigate that. And if the OP chooses to implement a deterministic simulation, TCP might actually be helpful since it provides reliable packet delivery and ordering.

 

Well said.

Not necessarily. The "goal" is to give enough player incentive to Want to spread out. Granted, a game capable of say 900 or 1200 player battles, the players are going to want that, hence this entire thread. I haven't completely ruled out TCP, but I do believe UDP will do far better performance wise. I'm trying to look at this from every angle that I can see, then find the angles I can't.

 

I understand what you're saying, but please keep in mind this is not going to be "match" oriented. This will be a persistent (several persistent) instances, that run 24/7 (hopefully haha).

 

As for use of bots, that's an entirely different bag of tricks that comes with it's own woes. Complex AI is Complex. I really don't want to go down that road at all.

 

The other issue with bots is the CPU overhead. If the bots need to use a lot of CPU time, those bots will likely need to be running on a separate computer from the server that clients connect to. If you had 1200 bots with complex AI running, it may even need multiple computers just for handling all of the bots.

 

I saw you guys mentioned client and server authority earlier, you can also do a hybrid. We do this for our game, we have a pretty complex distributed physics model were the player that owns the item controls it's physics. It's even recursive so if the player touches an item in the world with an owned item we will transfer ownership from server to player he will now control the physics between these two items. It looks really good for the owner and pretty darn good for the other players too thanks to interpolation etc.

This is of course very cheater prone, so what we do is authorize it all on the server. If a weapon is fired from a impossible position we will discard the Fire RPC and flag the player, if it happens 3 times we kick him. Also if the player tampers with the movement speed we flag him and kick him etc.

I guess we are still more fragile for cheating than a true authority server but it's a ok trade off.

 

Specific authentication vs complete authoritative is basically what most of the cool kids do now days. It's really not that difficult to break down what the actual risk areas are and address those individually in ways that are far simpler then full server authoritative. And dev iteration time is really what is most important. Security doesn't even come into play much until you actually have some success. And success/cashflow tends to solve all problems.

Not that you want to do stupid S***, the assumption is you actually know what the possible security issues are and have a plan to deal with worst case.

 

Anti-cheat (although there will obviously be cheaters) won't be that large of an issue for the project at launch or a few weeks after .. If all goes right. This topic I can't really get into. It's probably the only thing I won't be allowed to share.

 

I have been doing most of my stuff in Unity 5 as is (testing and otherwise).. But I just checked out Unity 2018.1 and the ECS system.. that looks absolutely AMAZING!

 

SO. I took a break.

Player Exact positioning is a pain in the ASS. The 'sliding' mechanic helped but not as much as I'd hoped. I've tried this in Unity, Unreal, Cry and Torque. So I'm clearly missing something. One mentioned that the sliding could be counter-acted by crouching and strafing, (tried that, didn't matter a bit)..Someone else also mentioned it was one of the huge resource hogs.

If there is any ideas or thoughts or experience (that I clearly don't have) that could help me in this conundrum... I'd be very much in your debt.

 

I may have actually bitten off more than I can chew... I'm glad I have a big mouth

 

Well, as I already mentioned, I don't think the movements sliding in PUBG is the result of the netcode. I think the movement sliding is intentional to simulate the weight of a body in motion. I also think the client side movement are completely unattached from server movements. There are a few cases of rubber banding in the early game, but that is only done when the client position differs greatly from the server position.

The thing I mentioned about crouching while cornering in PUBG was not related to strafing while crouching. What I am talking about is running around a corner, and normally the player will slide wide. If the player crouches and uncrouches while pivoting the same corner, the player will not slide wide. Crouching cancels all of the player momentum. This is why I think the sliding is purely related to intentional simulation style movement mechanics and not due to netcode issues.

Anyway, you can do something similar. Implement most things client side and have the server trust information unless it is severely out of sync. For example, if a player is running 100 mph on foot, it is probably a speed hacker. If the client side player is slightly out of sync with the server, just trust the client. This obviously opens up potential cheating, but this would be the only way to scale to 1200 players per server instance.

 

I love your post. Keep in mind it's also 12:40am and I'm drunk (and I've Done just about Everything while either drunk or 'herbally' paired.

You're idea is very much something I've taken into account about my first three days into this when designing it. The complex idea is very dependent on code. So for a moment, let's take 'cheaters' out of the equation completely and concentrate on the science of it.

Now, so what i've done thus far; You create 'trigger' zones. each person within the 'trigger' is given a SMB tag. This tag then acts as an artificial "host" if you will. Now from the feedback i've gotten, I've seen "visual field" mentioned several times, so I have tinkered with it. Just like occlusion, I've tried to mimic this in regards to server ticks; and emulated it. It's shotty at best, but it does seem to offer the best option so far.

The issue I'm enduring and need help with from Anyone willing to help, is weapons fire. Do you send packets per bullet? Do you send packets per line of sight / trigger? I'm finding the latter to be very worthwhile and also very hacker friendly..

How would You handle munitions fire? Be it an RPG, Bullet or E T C.?

 

This is really where I need all those opinions and not to let the thread die.. This is pretty much why I'm here. I need outside the box. Hell, I need outside the circle.

 

First thing to do is try working on the project completely sober and well rested. A healthy body leads to a healthy mind. Drunk programming is great for telling yourself you can overcome everything, but drunk programming is usually poor for handling heavily complex projects.

 

For the short term, completely ignore security and hacker concerns in the design. Everything that you would normally do to proactively prevent hackers in the network design is going to also reduce the scalability. You will need to let the server completely trust the clients and let each client take full responsibility for handling their own bullets. Then once you have the scalability, you will need to design anti-hacker systems that punish hackers reactively. I realize that won't be ideal, but that is the only way to get enough scalability.

 

I believe that you need opposite.

You need to get into the box and start coding like crazy until you hit a wall.
Once you hit a wall, you'll have a specific question and a specific problem.

 

And leave the beer and herbs outside.

 

This ^^^

In order to scale to ~1k players you're going to need to bring network communication and syncing down to an absolute minimum, and offload as much of the processing you can onto the clients. This is terrible from a hacker prevention angle, but you're not going to be able to do it any other way.

I'd also design the game so that it is far less dependent on twitchy movement and the syncing of full auto spray fire. If everyone is running around hip firing submachine guns, and you're trying to render bullets in the air on all nearby clients, while you allow fast movements to try to dodge, it is unlikely to scale. A slower paced game more focused on firing single projectiles, like sniper rifles, without COD style run and jump tight movement, is likely to require a lot fewer network packets to keep in sync.

 

Definitely. A game with single shot snipers will have fewer bullets per second to deal with. Even PUBG with only 100 players gets laggy when everybody starts spraying full auto. Luckily in PUBG, most of the early game is spent sneaking around looking for loot and gunfights are not constant during the early to mid games. By the time the late game hits, there are far fewer players connected, so those late game full auto gun fights are relatively easy networking wise.

This brings up a question for the OP. Will the proposed 1200 player game have fewer players as a function of time, or will all 1200 players be connected the entire time?

 

Sorry, I've been crazy busy for a bit. Yes, the proposed idea is to have 1200 concurrent players with many networking safe-guards. I'm scaling up to 2000 now as I believe the method is viable. I'm still months away from live testing, but everything simulated is running with minimal / zero packetloss, under 90ms ttl and it's all being simulated on 3.0mpbs.

 

Sounds exciting. Best of luck with it.

 

Is this still being developed? It sounds pretty awesome.

Also gtfo with the naysaying 100 player cap stuff, there have been games that exceed that for decades.

Hell PUBG will run on a cellphone using a 4G connection. If you're willing to eliminate some players who are still using internet from the dark ages (who are not your customer base anyway) bandwidth should not be an issue.

You could easily assume a 10mbps connection and build based on that. If people lack it, too bad. Let them catch up. Nobody builds games that look like S*** because someone might have an old GPU, so why do it for net code.

 

Look into Spatial OS it takes care of allot of the heavy lifting for MMOs.

 

For that many players, your netcode is going to have to implement an area of interest around each player; you won't be able to get a way "traditional" networking in which all players are sharing data with each other.

Think of the AOI as a bubble around the player, and as the player moves through the world, some items move into the bubble and others out of it. As the item moves in the player's AOI, they start receiving data for that object; when it moves out, they stop. This could be an item like a crate, another player, or an npc; anything that can be interacted with by the players will need to reside server-side (insofar as data) so that it can be shared among them but can be rendered client-side (you get position info, etc. and the client "spawns" that object at that location).

That is the main difference between what most multiplayer frameworks do vs. what one with a larger simultaneous player base does. The trade-off is that when you have a lot of players - say when you start a battle with 500 players - they are generally spread out all over the map, so any one player only has x number of players they are exchanging data with, and what is happening on the other side of the map isn't important to their client right now. As players are eliminated and they are forced towards the center, the remaining players AOI's will overlap, and everyone will get data for everyone, resulting in something very similar to a "traditional" multiplayer game. If you've ever played a game like WoW and not experienced lag while questing but then experience a lot when you're in the capital, that's why: everyone's AOI's are overlapping, and so everyone is exchanging an exponential amount of data back and forth as more and more players enter the city, since each player needs to exchange their data with every other player; so 1 new player begins exchanging their data with 100 players AND those 100 players being exchanging data with that new player.

When you use an AOI, you not only relieve the strain on the server (since it isn't sending everything to everyone all of the time), but you relieve it on the client as well (they deal with much less information, only getting the information that is within eye-shot and a bit beyond). It is almost exactly how a camera does not render objects that are x meters away from it, but instead of rendering, you're talking about exchanging information like display names, position, weapons, etc. Generally in an MMO you will have a "local" chat, where players can chat with others that they cannot see, and this is accomplished by players existing in more than one "room" at a time: the main game room that only sends info that is needed, and the chat room itself, which exchanges data with everyone but is only sending very finite amounts of data and only sending it when needed. Player position data needs to be updated constantly, and will oftentimes be send via UDP rather than TCP since the former does not require a response from the server. The notion is just blast the server with your info and whatever sticks, sticks. It results in less bandwidth and your server can authorize data via custom code on the netcode end of things.

There are systems out there that will assist you in setting this up: SmartFox server and SpatialOS are two examples. You can write your own framework from the ground up, but you'll have to learn a lot about networking as a whole to do it; SmartFox for example takes care of a lot of the everyday things in much the same way Unity does for the client. The learning curve for netcode can be steep, since you don't really have a visual representation of the data as you work that you can rely on, since any bugs in your client only exacerbate any bugs on the server. With Unity, you can often see what isn't working, but when you start working with Java for your server (for instance), it can sometimes feel like coding blind if you're used to a visual editor like Unity. Just some things to keep in mind when you are considering this project,and this all doesn't even begin to tie in data storage and a long list of other things that need to be considered.

This is just the tip of the iceberg. I can speak from experience in saying that if you are building a game that can handle this player base, multiply your estimated dev time by a factor of 10 at the very least compared to one using UNet. Everything takes much longer to accomplish and often requires programming in more than one language to accomplish, depending on what you use for your netcode. When I built an MMO, it was not uncommon for me to bounce between Unity, Netbeans (for java), Firefox (for the server admin), RDC (to connect to my dev server), and MySQL (for storing player and MMOItem data on any given day.

Conversely, the sense of accomplishment holds up to the x10 rule as well. Best of luck!

Edit: Just to add to this, if you're going to build a game that can handle this player base, the question isn't can Unity handle it (of course it can), the question is can UNet (no) or anything else (yes). Unity will end up just taking player input and drawing the world, the netcode will do all the lifting.

 

I loved your post! It was constructive and informative. I'm currently using MariaDB for item / player position data / 'facility' alignment and world variables (to be displayed on a map, UI etc) and something very similar to the Torque 3D server manager to communicate between player and server. The core of it is actually VERY easy now that I fully understand what I'm doing and yes AOI as you put it is the idea. I'm going a bit overboard and having other players act as master browsers or "hosts" to "X" player in your suggested "camera angle" comparison you stated and it's lifting a LOT of load from the server itself (simulating it..)

Theoretically with enough stripping I could have upwards to 5000k people in a single area using this method. What I'm working on now is how to make this coincide with the actual camera angle +- a few other variables. I think the three main pieces of information I'm going to need is player positioning, any sort of projectile fired and a delayed inventory 'bag'; the latter being by far the least priority.

As for the 10x rule, I'm probably at 15x hahaha. I'll definitely get there and I'm sure I'll be back here picking the brains of much smarter people than I trying to see what their ideas / solutions are. And when it's all said and done, I'd love to make it completely free to use.

 

You are forgetting bandwidth, and well basic math.

Let's assume you pack your messaging well and send x/z coordinates only. Done right you can send both using a total of 2 bytes on average. With an mmofps let's assume minimum 30 ticks per second. I'm assuming 5k entities are entities in visual range. If not, then this isn't even interesting.

So per entity bandwidth in:
2 * 30 = 60 bytes per second

5k entities that's roughly 300kbps. Nobody is going to be able to play that game.

Account for stuff like combat messaging, nobody is going to be able to play at 1k in visual range either.

And that's using the best known techniques out there.

Which is why I said in a previous post 500 is about the max. Look at every game out there that tries to push the limit in this area, 500 is right at where it still kind of works. Some have made claims to do more, but look close and you find out it was BS. They either backed off, changed after release, or were not actually talking about visual range.

 

Speaking of techniques there is one that might work in theory for large scale battles (and it's one that @Arowx would likely find a good theory if he hasn't already thought of it). Basically you keep the gaming hardware at the data center like OnLive. That way any communication between with the server can be near instantaneous since they can be in the same area.

 

Pretty much, EVE uses what is known as a 1-second tick to process updates to players and update state on the server.
It is explained nicely here on the EVE Wiki...

 

Isn't more of a problem finding 1000 players to play your game at the same time?

Or the size and cost of network servers to handle the load?

I'm sure as network bandwidth improves and CPU core counts grow we will get to games with thousands of real-time players.

However, imagine what a game like that would be like 500 players aside all trying to battle enemy players would it be a good game or just feel like a random "start run forward shoot and see how long you last" simulator?

 

Eve will also slow down a server that is experiencing heavy load using time dilation. This buys the server both the time it needs to process everything going on with unusually high number of players, and do all the send/receive network stuff to talk to thousands of players. With that many the game could appear to be running at 1/10th normal speed for example.

 

So, with your maths You're assuming that every single entity is going to use 2 * 30 bandwidth? And if we have 5 Thousand entities, we're going to be using 300kpbs? This is hard math, and it's IMPOSSIBLE to escape this Hard Math? I'm not trying to troll-challenge you. I'm simply asking if it may be possible to maybe perhaps not be so linear in your thought-process?

 

I'm not sure what this means.

 

Getting 1000 people is easy.. Get 10000 people is easy if you have the product and new "genre" to bring them. The "size" of the network isn't really important but the cost of it is...

CPU counts aren't going to "grow" ( i mean of course they WILL) but we'll be qubits or whatnot at that point.

And again, it's not going to be 500 or 900 or even 200 people fighting in a single area... And if they do, that's what my design is suppose to (and achieving) direct the focus to.

 

I don't really have the option for this as it's a FPS... But some of the methods they use for "slowing" such as inventory / other non-immediate-essential information is definitely something I'm working on.

 

Look. It's no longer an OP asking if Unity can handle an MMO of ANY kind... It clearly can...

This is about HOW to do it. Your opinions, your thoughts and even if you think they're 'bad'... They are an idea and can be used in Some kind of way.

SO fire away. I will debate against the one's who have no merit and I will praise those who do.

 

But "1000 people" isn't what you need. What you need is 1000 people simultaneously active, per game. And you're likely to need multiple simultaneous games servicing different geographic regions, otherwise latency becomes an issue.

For instance, I play Battlefield, but I probably only average maybe an hour per week, so on average I fill 0.5% of 1 player slot on 1 server. To keep a slot filled on average they need ~200 people like me. A Conquest game has 64 slots. So to fill 1 game they need the equivalent of ~12,800* players like me. There are many active servers in my (small!) region. They have servers covering many regions. The game supports multiple platforms and does not allow cross-platform games, so they need equivalent numbers per platform.

Sure, getting a thousand players is easy. But you probably need millions.

* This number is a obviously a gross generalisation. When I say I "average" an hour per week I mean I play many hours on some weeks, but often go weeks between games. Some players will spend a regular 20+ hours in game per week, but there will also be plenty who buy the game and barely play it. Those players are great for your short term income but they suck at keeping your multiplayer game alive.

. . .

Furthermore, because Battlefield's games are based on 64 player battles, if there's only a few dozen players active in a region at a particular moment that's still plenty to get a game started. How many simultaneous players do you need online to get a game started? Because until you reach that point you're dead in the water. And if your player numbers don't stay consistently above that number you'll quickly sink again.

For an example of this, try playing Battlefield in any game mode other than Conquest. Despite having a huge, ready-to-go player base in a well entrenched franchise even EA finds it hard to get something new off the ground.

That's not to say that the game idea isn't interesting or that you shouldn't give it a go. However, I would think a heck of a lot further than the "how" of the technical implementation. From a design perspective, how are you going to make sure that your game is also fun with 5 people and 50 people? Because if it's not, you aren't going to get up to the hundreds you need because very few individuals will sit around just waiting long enough for that to happen.

Honestly, start by designing your game. So far this is all tech, tech, tech. But aside from "more players" how is this different to the many online military shooters already out there? Why does anyone care? What is meaningfully different about your game?

Until you figure that out and communicate it I really think that the technical implementation is jumping the gun. But if you figure that out it will help you make informed technical decisions, rather than just blindly chasing higher numbers.

This is talking about having the whole game, including input processing and rendering, happen entirely in the data center. The client gets a video stream of the game, and provides an input stream.

 

I like you, you're direct and to the point Okay, so I understand what you're saying about the player counts and if I end up developing a terrible game, I'll never even reach one 'maxed' out server. I'll get bad reviews and what not and this will all have been for nothing. I have the game design down on paper.. I have it very carefully written out and thought of every possible balance / shift I could. As for the game design itself, that is incredibly easy. It's variables / bools / animations / shaders / etc. All of which are very easily attained on the Asset Store or I can hire someone freelance if I want something specific then I can plug them in

With my last (and first) game, I learned three huge important steps when using Unity and I suspect any game engine. Optimization, Organization and Optimization. I wasted nearly a year of time going back and redoing something because I didn't take into effect the ramifications of said "system".. So this time, linearly, I am going to write, optimize, organize and rewrite the code until it is as perfect as possible at the game's current state of development. Designing the game first is an absolute waste of time without the ability to put X amount of players in it, so if I spend a year designing it only to find I can only have half the players technologically, then I will have to redesign the entire infrastructure.

The key component of what will make my game different is that I am not creating a cookie-cutter Battlefield 51: Call of Duty 93. It's definitely a Risk vs Reward design, but I feel that most people in general are sick of the copy paste military shooters. I also feel they're sick of the copy paste survival games and copy paste MOBA genre.

With that said and not to discredit anyone's opinion, I created this post not to discuss game design or my success / failure rate or the numbers I need to succeed. I created it to get hard data on any technologies or methods that people may have used in the past to successfully create their MP game. It doesn't have to be an MMO, it could be something they learned while using Unet or writing something completely stand-alone for Unity to plug into.

 

Right... and I'm saying that the solutions are likely to be heavily informed by your game design.

When I'm solving a new problem I don't try to solve all possible forms of it from the start. That may come, but to begin with I get very specific about what I need to achieve. With that in mind, all you've said above is what your game isn't. You've said nothing that might help narrow down the problem space or suggest/rule out avenues for solutions.

No, speaking of quality is also jumping the gun. As I mentioned, check out the non-Conquest Battlefield modes. The problem isn't a lack of quality, it's a lack of players. (Though, to be fair, I can't confirm the quality of most of them as I haven't been able to play to find out... which, I feel, demonstrates the point.)

But also, a point of clarification - I wasn't asking about maxing out a server. I was asking how many players you need to even get a game started properly.

 

You don't know how many players you can have if you don't know what they'll be doing.

With regards to this and other things you've said there I strongly recommend adopting an iterative process.

 

So with no disrespect intended, I do not wish to discuss the game or the game-modes or Battlefield X. As with your previous post, you seem to want a debate that I'm not looking to engage in any way.

Now, I do understand being iterative but that is starting to derail this original Post and I don't want it closed for going off topic.

With That said... I want to know if there are any Unity Forum individuals that can provide input on using the engine on a MMO / Multiplayer game.

I'll send you a PM Penguin. We can discuss things there that aren't related.