Bandwidth cost / hour for one MMORPG player

Question

I am trying to calculate / guesstimate the costs of running an MMORPG for a client. And now I need a pretty accurate estimate for the monthly bandwidth cost so I can calculate the possible revenue of the investor / client. So what is a pretty reasonable bandwidth cost for each player per hour?

The MMORPG I'm trying to make is a virtual conference with gamification. We can go to booths, see other people, make a transaction in the booths. And we will also have a quest and mini-game system for the gamification.

We will be making it using Unity + Forge. We were thinking of using Photon before, but when I reached out to them, they said I need to subscribe for Photon Industries since it's not a game, per se, which is like 2.5x the cost of PUN.

We will split the server into two: the game server and the REST API server. I'm in charge of the game side of the project so the REST API and backend is not my jurisdiction. I this is the specs of the game that I had in mind:

1. The event will be held for 10 days, possibly running 24 hours straight.
2. Max customer that we have anticipated is around 1000-2000 CCU
3. There will be multiple scenes / rooms that the customer can go to (e.g. Commerce area, Lobby area, Mini-Game area, etc)
4. The quest system, booth transactions, and other features that doesn't need real time update will be handled by the backend.

So that leaves these data that needed to be synced:

Player:

• position : 4 bytes * 3 (X, Y , Z) = 12 bytes
• currentScene: 1 byte
• avatarModel: 4 bytes (will use bitmasking to handle the current type of clothing and accessories of the player model)
• playerAction: 4 bytes (player's enumerated action type)
• playerActionTarget: 4 bytes (player's action's target)

Scene:

• sceneStatus: 16 bytes (any status of the current scene e.g. the current quest. Still unsure how many bytes I need to sync)

So, this is what I have calculated so far using AWS EC2 (possibly wrong):

Answer 1

Your calculation makes a couple mistakes which might change your actual traffic and bandwidth requirements a lot.

Not every information needs to be updated with the same frequency

For example, the look of the avatar. You only need to tell clients how an avatar looks when they either encounter that avatar for the first time or when that avatar changed its appearance. So those 4 bytes which describe the character appearance don't need to be sent 15 times per second, because most of the time they won't have change since the last update.

The only information which might always requires 15 updates per second is position and rotation. In action-oriented games, players will often spend more time moving than standing, so those games often don't bother checking and just send continuous position updates. But considering the target demographic for your application, I would expect that the majority of users will stay idle most of the time. So even position and rotation might be something you only need to send when someone is actually moving.

The amount of data you need to send increases quadratically with the number of users in the same room.

When there are 100 users in a room and one user does something, then you receive that action once, but you need to send it to all 100 users in the room. If all users do something at once, you need to distribute 100 x 100 = 10,000 messages.

So people distributed over many smaller rooms will generate a lot less traffic than the same number of people in the same room.

You assume people will be online for 24 hours

This is very unlikely in this context. When it is a virtual conference, you can assume that the time every participant spends online on average is about the length of a regular work day (~8 hours). But keep in mind that there will very likely be peaks where almost all participants will want to be online at once. So this affects the traffic requirements, but not the bandwidth requirements.

What you really need to worry about is media streaming

When this is a virtual conference, then I assume people will want to communicate and present. They will want to have voice chat. They will want to show powerpoint slides or even videos to other participants. The traffic requirements for that will eclipse anything you could do to sync up the users avatars.

Conclusion

You need to do testing to check how your end-users will interact with your product, optimize your netcode for their behavior patterns and then see how much traffic your product actually generates.

Answer 2

Note: This answer was written for an earlier version of the question which lacked any details about what the project was actually about. While it does not answer the new version of the question properly, I will leave it up, as it might help others.

I'm sorry, but you can't do such an estimate without having a prototype. Not every MMORPG is the same. Depending on various implementation details and your game mechanics, your bandwidth can differ a lot.

For example, how often are you going to send position updates to the clients? When you have an action-oriented combat system where players are expected to act and react quickly, you ideally want to send 100 updates per second for maximum precision. But if the combat system is a bit slower, then perhaps just 10 updates per second and letting the clients interpolate between them are OK. In a very slow-paced system, you might even get away with just 1 update per second.

So this simple design choice about how your combat system works can affect your bandwidth requirements by factor 100. And that was just one feature. MMORPGs are very complex games. There are lots and lots of features which could require a lot of bandwidth depending on what you want them to do and how you implement them.

Further, that number might not scale linearly with the number of players. It in fact usually increases quadratically with the number of players in the same area. When there are 10 players, then you need to update 10 clients each about what happens to 10 different players. Which means you don't need to send 10 times but 100 times the data. So depending on how the players in your game will distribute themselves around your game world, you might have very different traffic requirements. Sure, there are ways to influence that. And there are workarounds for too many people being in the same area and bogging down the server (like instancing). But do you want to use them? And if you do, when and how exactly? These are all very complex design questions you might not be able to answer yet.

---

However, you could take a different approach. Set a budget for how much bandwidth the game is allowed to consume. Then take that budget into account while you develop your game. When some feature of the game breaks the bandwidth budget, either drop or redesign it.

But if it turns out that your budget was too low, then a lot of features you considered essential to the vision of your game might end up getting cut. So this approach could lead to frustration for you and your investors.

So you need some experience to judge how much bandwidth you will need in order to make those essential core features possible. One way to gain that experience is by creating a prototype.

Answer 3

I think you are mixing a few things together that have very different properties and requirements on communication.

Scene, its state, and items in the scene are slow changing. They may require rather large amount of data, but the data are mostly constant. You need an effective way to broadcast partial updates, a diff, of what changed. Players then can keep track of the changes and update their copy of the scene state. It is a good idea to broadcast the full state from time to time, for example, in form of a hash or a version number, because the players may get out of sync due to a bug.

Chat messages, trades, emotes and similar things are changing relatively slowly, but you must not loose them. You also need to preserve history of the chat messages. You want transactional consistency here.

Player position and movement is changing quickly and there is no need to keep history. It is fine to drop a few updates, just make sure you get the last one. You want eventually consistent state here, i.e., state may be temporarily inconsistent, but after a while, the clients sync again. These updates also depend on the distance between players. If player is far away or out of sight, you don't need to know his exact position, but you need an update when you get close to him again, even if he does not move. Notice how players disappear in the games when they are in distance.

Spells, actions, and similar stuff is somewhere between these two. You need to broadcast them only to nearby players, there is no need for keeping the history, but you should not loose the event. The state update should be distributed separately from these events, because if you loose such an event, other player will not see the action, e.g., a spell cast, but they must keep their local state in sync with the global state.

---

Then there is a TCP connection. It sends packets again if they are lost and there are buffers on the way. You need to take into account that. You need to watch for the communication, response times and buffer usage. If you use UDP, the situation is easier, but you will have troubles with firewalls, and you cannot use WebSockets in a web browser.

---

Anyway, you need to figure out how to update the world. There are scene state, player state, NPC state, chat messages, and effects. Each have different requirements. You need to utilize eventual consistency, keep the updates localized, and reduce communication that is not relevant.

There is no need to assign bytes to a scene state or player features. You need to have items, instances, and properties. Then send a message when a property changes. The world state needs to be a tree with partial updates. A client needs to know that given data are obsolete (and how much), but it may not need to know the current state. It may just ask later when player actually takes a look.

This brings us to the one more feature: AFK. Users are often away from keyboard, not paying attention, not looking. The game may be minimized and the player is only listening to the talk. When user is online for 24/7, it does not mean he actually is there. If a player does nothing for a while there is no need to send or receive updates that often.

---

So, back to the original question: How much bandwidth do we need?

I really like the budget idea from the other answer. Calculate the size of the state update messages, assume about 5 to 20 updates per second. You should get a few kilobytes per second. Then set the budget and throttle the updates to fit the desired frequency and the budget. Limit updates between players that do not see each other and are far away. Your problem will be latency.