This project is read-only.

Target Client Size

Jan 25, 2011 at 3:56 AM

This is always a question that people laugh at; but this is something that is struggled with consistently and is constantly revisited.

From the way I see it; there are a few different groups in increasing order of what your client size is.  Anything over the top number will be to add more servers and begin to scale linearly.  The thing that people don't consider is the bandwidth that will be used.  So let's discuss that really quick so that you can get an idea of where these numbers come from.

We are only going to look at one character.

  • Depending on the number of characters you allow a user to have for a username, you are looking at at least 1 byte per character so let's assume that we have 12 characters in a name.
  • Now lets assume that a character's ship can have 5 displayable elements and we'll assume that these are all distinguished by an integer value
    • Engine - 4 bytes
    • Body - 4 bytes
    • Flag - 4 bytes
    • Guns - 4 bytes
    • Shield - 4 bytes
  • Now let's assume that a character themselves can have up to 6 displayable elements
    • Torso - 4 bytes
    • Legs - 4 bytes
    • Feet - 4 bytes
    • Hands - 4 bytes
    • Hat - 4 bytes
    • Weapon - 4 bytes
  • Let's assume that an enemy can have up to 3 displayable elements
    • Torso - 4 bytes
    • Legs - 4 bytes
    • Weapon - 4 bytes
  • Now for the fun part, for each character/enemy you have an X/Y/Z location.
    • X - 4 bytes
    • Y - 4 bytes
    • Z - 4 bytes
  • You also have any effects that they are doing
    • Action - 4 bytes

Now lets look at the size of one character that needs to be fully updated (here we're going to look at the largest character 6 elements)

Name: 12 bytes

Player Elements: 24 bytes

Position: 12 bytes

Total: 48 bytes


Now that we've seen that one character takes about 48 bytes for a full character.  So let's look at this in a scaling; what happens if we have 10 players on the screen that need to be updated?  Now we are costing 480 bytes, so what if we have 100 players on the screen that need updating; now we need 4.8kbytes to update these characters.  Obviously this looks really good for 100 players; which is about what you would expect to be in any one zone to be updated at any one time.  So here's the thing, you also need to send your character information; and this is assuming that a single integer could be used for any element of a character.  Now there are things that can be done to limit the elements sent; ex. you only need to send the player elements if they are changing.  Also, what about general chat text; that would require another 1 byte per character with let's say 50 characters max.


One of the important things to remember is that no matter what one player is receiving, the server will have to send this out to all the different clients that are connected.  So, if one client needed to get updates for 100 players 4.8kbytes; but what if all 100 players need those updates as well.  Now you're talking about 480kbytes that your server needs to push out.  Although this sounds ok, remember that you're also going to have a TCP header for each of these packets which adds on another 20 bytes.  Although not huge; it's meant to explain why there are limitations on the number of concurrent clients as we will discuss.


As you scale up, you'll begin to look at players that will be playing at all different times; 100 players are probably mostly going to know eachother and will probably mostly play together.  I would say that about 500 players will be where players stop knowing most of the people in the game and you will have different peak playing times.  Once you start getting up to the 500 mark, you'll want to begin looking at HA options and "what if the server crashes" what do we do to store the data and ensure that a clients data doesn't get killed.  At 500 you'll have to start looking into GM's and getting people that can help administer the game around the clock as you'll begin to have different groups that will play at different times.  The more you get into the 2000-5000 range, the more you're going to be looking at 24x7 monitoring.


The number is the top number

  • 100
    • Usually this is easy enough to do and can be done on a pretty small server; probably don't need anything heavy to process the clients requests and could be done over a general ISP connection
  • 200
    • You can most likely stick with a small server (maybe a little bit larger than one you would use for 100 clients) but you would need to step up the ISP connection to something with a little more bandwidth
  • 500
    • You're going to need something with a medium level server, at this level you'll be needing something with multiple cores/processors (at this point you would also want to split out your auth/login from the game server) Here is where you will need to start getting into a larger T1 style pipe to get the MB/s connection that you'll be looking for.
  • 1000
    • Here is where the bigger systems are going to be needed, you'll be looking more towards higher end dual core systems; you'll need quite a bit of memory as well as you'll be wanting to hold most of this in memory.  You'll need to start getting into multiple T1's and upwards of T3 to get the strong connections.
  • 2000
    • Here is probably where I would suggest getting into a quad core system; you'll really want a good amount of RAM (probably about 12-24GB at this point) to hold most of this.  Now I would not suggest actually trying to administer the system itself; you'll mostly be wanting to have this server administered in a datacenter.  The DC will need to have quite a bit of connection power and would probably be best hosted on some large server hosting place like RackSpace.
  • 5000
    • This is really your cap, anything over this is going to be pressing not just the bandwidth but also the processing that is going to be going on.  Most likely you'll be looking at a high end quad core system with no less than 24GB of RAM.  You will no longer be able to administer this server and you'll be looking for people to help you keep the system working 24x7.
    • Anything more than this, you'll be wanting to create a new server and split the characters into two different 2000 user servers.

None of this is meant to deter us from the end result; but this is actually good to discuss and get an idea of where to go.  It's easy to plan for 100; it's hard to start planning for 500, if we start at 100 and get it working we can begin to scale it up as the client base requests.