There could be a large number of players but only 32 in-game. So it's not really MMO.
I'm thinking of making it a turn-based strategy now.
MMO viability
Any non-virtual server that is not going via modem or DSL will do (though you can probably even host 32 players over DSL, if your game is not a total bandwidth hog).
What you want is a more or less predictable, constant simulation rate and a more or less predictable network load (and latency). It does not need to be hard realtime, it does not need to perfect, but you should be sure that your server doesn't have hiccups of 0.2 to 0.5 seconds every 2-3 minutes (as a virtual server may very well have). The cheapest available root server can handle that for 32 players (for 320, or even 3200, if you want).
With a virtual server, you usually have something like 50 virtual servers (of which probably 30 are porn websites) running on a 8-core machine under the assumption that nobody will be needing big power anyway, and if someone needs a burst, it's ok for the others to be stalled for half a second or so. That stall doesn't really matter when you run a (porn) webserver, but in return the service is very cheap, which is good.
Now if you run a game where one player fires at and kills another during that period, it matters big time. That's why you do not want a virtual server.
You also want to be sure that when a lot of updates need to be sent (when 10 tanks dogfight in a small region) your network bandwidth isn't suddenly filled up. Again, the cheapest root server can normally handle this. If your game is kind of reasonable (say, sending 1-2 kiB/s to each client) then that is just ridiculously little compared to what fits onto an ethernet wire -- assuming a kind of poor MTU of 768, that's around 86 packets on the wire. On a modem or a cheap DSL with an upstream speed of anywhere from 50 to 500 kIB (and multiplexing into ATM or PPP or PPPoE or both), this is another story.
You will need some form of lag compensation anyway, since even under optimal conditions you have round trip times anywhere from 50 to 100 milliseconds on the internet. Now imagine how unplayable it becomes when your dialup chokes and adds another 500-600 ms.
What you want is a more or less predictable, constant simulation rate and a more or less predictable network load (and latency). It does not need to be hard realtime, it does not need to perfect, but you should be sure that your server doesn't have hiccups of 0.2 to 0.5 seconds every 2-3 minutes (as a virtual server may very well have). The cheapest available root server can handle that for 32 players (for 320, or even 3200, if you want).
With a virtual server, you usually have something like 50 virtual servers (of which probably 30 are porn websites) running on a 8-core machine under the assumption that nobody will be needing big power anyway, and if someone needs a burst, it's ok for the others to be stalled for half a second or so. That stall doesn't really matter when you run a (porn) webserver, but in return the service is very cheap, which is good.
Now if you run a game where one player fires at and kills another during that period, it matters big time. That's why you do not want a virtual server.
You also want to be sure that when a lot of updates need to be sent (when 10 tanks dogfight in a small region) your network bandwidth isn't suddenly filled up. Again, the cheapest root server can normally handle this. If your game is kind of reasonable (say, sending 1-2 kiB/s to each client) then that is just ridiculously little compared to what fits onto an ethernet wire -- assuming a kind of poor MTU of 768, that's around 86 packets on the wire. On a modem or a cheap DSL with an upstream speed of anywhere from 50 to 500 kIB (and multiplexing into ATM or PPP or PPPoE or both), this is another story.
You will need some form of lag compensation anyway, since even under optimal conditions you have round trip times anywhere from 50 to 100 milliseconds on the internet. Now imagine how unplayable it becomes when your dialup chokes and adds another 500-600 ms.
Where are the players that are not ingame. You've still not given us ANYTHING to work with
There's nothing wrong with asking for ballpark estimates, especially early in a project and even more especially in a subject area you aren't deeply familiar with. But yes - the more information the better. I suspect though that the OP is trying to decide what direction to take the game design in based on what's feasible for him to run - which is perfectly sensible.
OP: turn-based could work fine with virtualized hosting - I'm thinking of the server being a php script and a database. For turn-based, you can avoid most of the complexities Samoth has kindly explained for you above.
With a virtual server, you usually have something like 50 virtual servers (of which probably 30 are porn websites) running on a 8-core machine under the assumption that nobody will be needing big power anyway, and if someone needs a burst, it's ok for the others to be stalled for half a second or so.
This was true several years ago, but not any more. CPUs now have virtualization support built into the hardware and much better operating system support. On a decent VPS you typically get a certain amount of dedicated CPU power/time as long as it is being used (often you will get a dedicated CPU core) with the ability to burst beyond the dedicated when the other virtual servers are idle. If your server is using a lot of CPU, none of it's power is available for bursting to the other servers. So while there is the potential for some short delays, it would typically happen when a game starts, not while a game is running.
The only real issue is disk IO which is not likely to be a big problem for a game like this.
I wouldnt suggest trying to run a Counter-Strike server on one, but it should work okay for an RTS. RTS games are usually fine with an occasional blip anyway.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
