I'm trying to figure out all the ins and outs of server-client usage for multiplayer games, because I want to dev my own multiplayer game.

Though my draft of the fees for my game seem to be out of place, and I want to check up with someone if they know anything about the comparison between items with server-client bandwidth.

IF ANYONE COULD PROVIDE THIS INFO, THE LEAST I COULD DO IS ADD THEM TO THE GAME CREDITS, OR EVEN PROVIDE SOMETHING TO USE TOWARDS THE GAME.

Really this info would help a lot.

See, with the plan of my game, there will be at least 65,000 individual meshes that need to have their information sent and received from the server.
My guestimation was 20kb/s per item.
But that was my "high end guess" to figure out costs. Keep in mind this 65,000 item count is only for just ONE server and is the minimum required amount.

And I didn't want to dev the whole game or even one piece for each part and find out for myself how it all works together and have the result of it being impossible.

Though it would be great if I had more accurate numbers.

What would the bandwidth be if:

-The player inventory allows them to have around 50 items. If each item is stored as what it is, and is represented by a 2d image inside the players inventory?
-The player out of game storage for 20 items that can be sent to a character on another server?
-A usable vehicle?
-Player position?
-Player stats? (health, strength, etc)
-an item that can only be used/moved by a player with an applicable stat; say a player needs 200 strength to move an item? Would this just be basically a replication of the info of the players stat?
-A glass window that can be destroyed?
-A tree that can be cut down or climbed?
-dynamic destructible wall from a building?
-An AI enemy?
-Any spawnable item found on map?

By the way, if relevant, game engine being used is Unreal Engine 4.

Okay, first, it's impossible to tell you exactly what your bandwidth requirements will be.  That is what network protocol design is all about.  You can't do the math until you have ALL the numbers.  So, in order to calculate bandwidth usage, you will need to calculate exactly how many bytes each of those items on your list will put on the "wire", and how often.

So, for example, your player position.  That's usually 3 floats in a 3d world.  So, 3 floats will use approximately 12 bytes of data.  You take that 12 bytes and multiply it by the number of updates you send per second and you'll  have the "bytes per second" for that item.

If you were putting 12 bytes on the wire 20 times per second = 240Bytes/second  ~ 2.0 kb/second..  Rough math..

Run this exercise for EACH of those items on your list, and you will be getting "close" to an estimated bandwidth number.

It will still only be a numbers exercise though, you will find that the reality is always different to some extent.  Plus, many optimizations come in the phases AFTER you have it working already...

Also, I'm curious how you have come to decide you'll be needing to transit 65,000 meshes over the internet.. ???  That sounds somewhat excessive.  I have approximately 500,000 mesh objects that make up the terrain in the game I'm making, but I only send 1 at a time over the wire(and only when absolutely needed), and then they get cached on the client side, so they only ever need to transit once unless something changes on the server's copy.  Or the client's copy gets corrupted or changed by the user.

Here's some general multi-player client/server articles I've found helpful in my development process.

http://www.gabrielgambetta.com/client-server-game-architecture.html

https://gafferongames.com/post/what_every_programmer_needs_to_know_about_game_networking/

Another thing to note, most multiplayer games only ever send data "about" objects, the objects themselves are usually either coded into the game client directly ahead of time, OR downloaded once and then reused like I explained for my terrain objects above.

25 minutes ago, Septopus said:

Okay, first, it's impossible to tell you exactly what your bandwidth requirements will be.  That is what network protocol design is all about.  You can't do the math until you have ALL the numbers.  So, in order to calculate bandwidth usage, you will need to calculate exactly how many bytes each of those items on your list will put on the "wire", and how often.

So, for example, your player position.  That's usually 3 floats in a 3d world.  So, 3 floats will use approximately 12 bytes of data.  You take that 12 bytes and multiply it by the number of updates you send per second and you'll  have the "bytes per second" for that item.

If you were putting 12 bytes on the wire 20 times per second = 240Bytes/second  ~ 0.2 kbps

Run this exercise for EACH of those items on your list, and you will be getting "close" to an estimated bandwidth number.

It will still only be a numbers exercise though, you will find that the reality is always different to some extent.  Plus, many optimizations come in the phases AFTER you have it working already...

Also, I'm curious how you have come to decide you'll be needing to transit 65,000 meshes over the internet.. ???  That sounds somewhat excessive.  I have approximately 500,000 mesh objects that make up the terrain in the game I'm making, but I only send 1 at a time over the wire(and only when absolutely needed), and then they get cached on the client side, so they only ever need to transit once unless something changes on the server's copy.  Or the client's copy gets corrupted or changed by the user.

Here's some general multi-player client/server articles I've found helpful in my development process.

http://www.gabrielgambetta.com/client-server-game-architecture.html

https://gafferongames.com/post/what_every_programmer_needs_to_know_about_game_networking/

Hey thanks for the response.

So by your calculation, each entity/mesh/player would be what, around 2kb/s tops for a realtime game?

The 65000 count comes from everything in the game that needs to connect to the server, spawnable items, vehicles, building resources (trees and rocks), base parts, destructible walls, destructible windows. This number doesn't include players and player information such as stats and inventory.

As byproduct information, I've always remembered people saying a while back that each character in WOW used 1mb/s or something (for stats and inventory, etc)

So if my game has 300-400 players, at 1mb/s/player would be 300-400MB/s. Then the 70000 items would be around 2KB/s, totalling around 750MB/s per server.

Does this seem accurate to you?

40 minutes ago, Septopus said:

 

Another thing to note, most multiplayer games only ever send data "about" objects, the objects themselves are usually either coded into the game client directly ahead of time, OR downloaded once and then reused like I explained for my terrain objects above.

Yes, that is right.

Here's something I don't know too much about,

I don't think an event system would work with a destructible asset.

Because okay, information about a window is sent every so often (say once an hour), but when that window gets destroyed by something, it sends that information to the server and is now destroyed for each player.

How does that even work? Surely the server would always need information from that window every second, and thus an event system doesn't work? Or am I missing something?

No, those numbers don't seem accurate at all..  If WOW used 1mb/s per player, it probably never would have worked at the time it came out.  And I don't think there's a single multi-player game that has ever come close to that amount of data transfer, for a single player anyhow...

First, I think you may need to learn the differences between bits, bytes, kilobits, kilobytes, megabits, and megabytes and all of those with a /s after them. It will help you a lot in going forward.

Another thing you should be taking away from this, is that the math exercise I proposed above, while helpful for conceptualizing the project, may not be anything you want to base any decisions on.  Until you understand it completely and know how/why it will be inaccurate no matter how well you calculate it.

My suggestions for you going forward:

Read the articles I linked, they will help with your conceptualization.

Then build a very small multi-player game without all these complex assets.    Just get multiple players walking around in the same game with a server and a basic client game.

Then when you have figured out how all this stuff works, come back to your super-project and decide if it's something you want to tackle.  Games of the scale you are talking about probably should not be your first ever client/server type programming experience...

8 minutes ago, Septopus said:

No, those numbers don't seem accurate at all..  If WOW used 1mb/s per player, it probably never would have worked at the time it came out.  And I don't think there's a single multi-player game that has ever come close to that amount of data transfer, for a single player anyhow...

First, I think you may need to learn the differences between bits, bytes, kilobits, kilobytes, megabits, and megabytes and all of those with a /s after them. It will help you a lot in going forward.

Another thing you should be taking away from this, is that the math exercise I proposed above, while helpful for conceptualizing the project, may not be anything you want to base any decisions on.  Until you understand it completely and know how/why it will be inaccurate no matter how well you calculate it.

My suggestions for you going forward:

Read the articles I linked, they will help with your conceptualization.

Then build a very small multi-player game without all these complex assets.    Just get multiple players walking around in the same game with a server and a basic client game.

Then when you have figured out how all this stuff works, come back to your super-project and decide if it's something you want to tackle.  Games of the scale you are talking about probably should not be your first ever client/server type programming experience...

It's something I want to tackle, it would just take time. Probably a good 2 years before being able to release it. It really just comes down to the operation costs.

Most multi-player games send the meshes themselves (vertices, triangles, normals, textures, etc) as part of the "game installer" and "game update/patch." The same goes for pictures, sounds, and so forth -- all bulky assets that are shared.

Then, on the server, for each connected player, there's code that figures out which objects are within range of a player, and sends the player messages "you should now be aware of object 82, which consists of player mesh 18 holding weapon 95, at position X, Y, Z." And, as it moves around, it sends messages like "object 82 is now at position X',Y',Z'" or "object 82 is now playing animation 40." (Or, perhaps, "player 82 is doing the attack action against monster 311" and the client figures out what animations go into that.)

So, you may ask yourself, how do you deal with worlds where the players can dig in the ground, blow up walls, and build contraptions out of lumber and gears? The answer is: very, very, carefully. Any game that supports player-generated content has to spend many engineering years on figuring out the most compact way to represent player modifications to geometry, and the kinds of modifications supported are often carefully constructed to allow for a smooth, low-bandwidth networking/physics representation. The further you go in this direction, the more your "game" becomes like a "virtual world." Check out something like Roblox, where each "game" or "level" is downloaded at time of join, for a highly optimized system that allows players to change things around. Something like 100 smart engineer-years has gotten into their physics+networking layer at this point. If you want something as sophisticated as that, you'd have to expend as many resources. If you want something more sophisticated, you'd have to expend more resources.

Finally, the cost of bandwidth on the server side is seldom the limiting factor. Bulk bandwidth is reasonably cheap (consider that Netflix charges about $10-$20 per month, and lets people stream as much HD content as they want!) Instead, the limitations are at the consumer side, and in the CPU needed to process all the individual data streams to send data to each client.

Just now, aandril said:

It really just comes down to the operation costs.

And that's what I'm saying here, you can't calculate those to any level of reliability until you've completely mastered the concepts that explain them. 

So, if you want to push on through, as I probably would.  Then I still recommend that you start small.  All multiplayer server/client games start pretty much the same way, so starting small isn't a detour.  Program a basic server/client and get 2 players on a network.  Then measure your ACTUAL bandwidth usage, tune it until it's as small as you can get it, then start adding in the assets and things like that.

5 minutes ago, hplus0603 said:

Most multi-player games send the meshes themselves (vertices, triangles, normals, textures, etc) as part of the "game installer" and "game update/patch." The same goes for pictures, sounds, and so forth -- all bulky assets that are shared.

Then, on the server, for each connected player, there's code that figures out which objects are within range of a player, and sends the player messages "you should now be aware of object 82, which consists of player mesh 18 holding weapon 95, at position X, Y, Z." And, as it moves around, it sends messages like "object 82 is now at position X',Y',Z'" or "object 82 is now playing animation 40." (Or, perhaps, "player 82 is doing the attack action against monster 311" and the client figures out what animations go into that.)

So, you may ask yourself, how do you deal with worlds where the players can dig in the ground, blow up walls, and build contraptions out of lumber and gears? The answer is: very, very, carefully. Any game that supports player-generated content has to spend many engineering years on figuring out the most compact way to represent player modifications to geometry, and the kinds of modifications supported are often carefully constructed to allow for a smooth, low-bandwidth networking/physics representation. The further you go in this direction, the more your "game" becomes like a "virtual world." Check out something like Roblox, where each "game" or "level" is downloaded at time of join, for a highly optimized system that allows players to change things around. Something like 100 smart engineer-years has gotten into their physics+networking layer at this point. If you want something as sophisticated as that, you'd have to expend as many resources. If you want something more sophisticated, you'd have to expend more resources.

Finally, the cost of bandwidth on the server side is seldom the limiting factor. Bulk bandwidth is reasonably cheap (consider that Netflix charges about $10-$20 per month, and lets people stream as much HD content as they want!) Instead, the limitations are at the consumer side, and in the CPU needed to process all the individual data streams to send data to each client.

Yes those are the basic concepts.

As far as I know, most companies provide unlimited bandwidth for internet use.

But the cost for games comes into effect when you have a lot of servers and a lot of objects that need to be connected to the servers, as they run in MB/s.

The cost comes the bandwidth speed.

So if I have 25,000 players across all servers, and they each take up 350kb/s, then I need a internet speed to be 8.75GB/s * 8 = 70Gbps connections.

As far as the CPUs and RAM needed for the servers, I haven't got that far yet.

11 minutes ago, Septopus said:

And that's what I'm saying here, you can't calculate those to any level of reliability until you've completely mastered the concepts that explain them. 

So, if you want to push on through, as I probably would.  Then I still recommend that you start small.  All multiplayer server/client games start pretty much the same way, so starting small isn't a detour.  Program a basic server/client and get 2 players on a network.  Then measure your ACTUAL bandwidth usage, tune it until it's as small as you can get it, then start adding in the assets and things like that.

 

Yes, it seems that is something that must be done to get a better accurate measure.

Thanks for the help. Your reply gets me a step closer, seeing as most thing may be even 10% of my own calcs, which is far less than expected.

As far as I know, most companies provide

 unlimited bandwidth for internet use.

Cheap web hosts may provide "unlimited" networking throughput; what that really means is that they put 100 customers on a single 1 Gbps link that they get to fight over, and you won't see anywhere near "unlimtied" throughput out to the greater internet.

Backhaul from a low-cost provider like Cogent will cost you something like one to two thousand dollars for 10 Gbps unmetered. This is in a data center, if you have your own server infrastructure. If you use a cloud provider like Amazon or Google or whatever, you'll pay something like 15 cents per gigabyte transferred at the high end (Amazon loves charging for networking!) and perhaps go down to as low as 3-4 cents per gigabyte if you have a LOT of traffic and a competitive provider. 

Consumers often have a limit to their internet, too, depending on where they live. Some providers put this very low. For example, my monopolist home provider (comcast cable) limits my 150 Mb/s internet to 1000 GB/month, and then charge another $10 per 50 GB I use in a month.

Note that an unlimited 10 Gbps connection (if you have your own data center installation / co-location facility cage) is enough for between 1 and 10 servers, depending on your internal networking fabric. You thus need to scale that by the number of servers you expect to have pushing that data. That being said, having a physical host actually push 10 Gbps traffic while doing significant real work at the same time is very uncommon -- the CPU and internal buses and drivers end up being more of a chokepoint than the network link itself.