# MMO viability

## Recommended Posts

polyfrag    2502
How viable is it to host an MMO?

Is it possible on an Amazon Web Service EC2 Micro-instance?

Specs:

613 MB memory
1 EC2 Compute Unit (?)
I/O Performance: Low

And $0.020/hour ($14.4/month) after first year free.

##### Share on other sites
polyfrag    2502
What are the specs of the Dead Frontier server(s)? How much does it cost and do they make a net profit from micro-purchases? Edited by polyfrag

##### Share on other sites
polyfrag    2502
I want to make this an MMORTS:

There will be no pathfinding. Units will turn left to walk around obstacles.

The units and buildings will be divided up based on their tiles for quick look-up collision detection.

 I think it won't have more than 32 players at a time. Edited by polyfrag

##### Share on other sites
ApochPiQ    23003
We still need vast amounts more detail about what your hypothetical server would be [i]doing[/i]. I don't know anything about the computational load or playerbase size of your game by looking at a couple of screenshots, sorry.

##### Share on other sites
mrbastard    1577
[quote name='polyfrag' timestamp='1346372903' post='4974981']
 I think it won't have more than 32 players at a time.
[/quote]

32 players isn't particularly massive. Do you mean 32 players can interact in realtime, but the game is 'massively multiplayer' in that is has non-realtime stats / game elements that allow more than 32 players to interact in some way?

##### Share on other sites
32 players is something you can almost host on your cell phone. The bigger problem is that EC2 runs on virtual servers, and EC2 Micro Instances [i]in particular [/i]are designed to allow occasional (that means: rare) CPU bursts, while beng ultra low performance otherwise with ultra unpredictable jitter.

In other words, they are exactly the opposite of what one wants in a game with tanks shooting one at another. You may be able to get a big CPU burst for some hefty compute task that you need to do, but it may take half a second or so before your instance gets scheduled. This is not something the normal users of a micro instance worry about, and most of the time instances do nothing, so it's no issue (that's how Amazon can keep the prize low and offer a 1-year free trial).

If you do (and expect) the opposite of that, not only you will be unhappy, but Amazon will be unhappy too, which might result in them pulling the plug without telling you. Edited by samoth

##### Share on other sites
polyfrag    2502
What can I use for hosting then?

If I host it from a home computer, will a cable connection be lag-free?

##### Share on other sites
krippy2k8    646
Hosting from your cable connection is not a good idea, except maybe for testing. You're probably going to want at least a Virtual Dedicated Server (or Virtual Private Server). You can get a decent VDS/VPS for around \$30 per month that should handle 32-players in a simple RTS game with reasonable performance.

##### Share on other sites
6677    1054
You could take the route of many other games. Lets say minecraft. The users have to download the server software themselves and host their own 32 player matches for other users to join.

And just specifying that your internet is cable means nothing. That could be 0.2mbit/s down or it could be 20mbit/sec down, you could have a 20ms ping, you could have 300 (which would be very very bad for lag free). You do seem the be the master of asking questions that need numeric data and not giving us that data... Hell you still haven't given us information on if its just 32 players having a skirmish or theres a huge list of player stats etc, what is the server for? Edited by 6677

##### Share on other sites
polyfrag    2502
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.

##### Share on other sites
Any [i]non[/i]-virtual server that is not going via modem or DSL will do (though you can [i]probably [/i]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 [i]not [/i]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. Edited by samoth

##### Share on other sites
6677    1054
Where are the players that are not ingame. You've still not given us ANYTHING to work with

##### Share on other sites
mrbastard    1577
[quote name='6677' timestamp='1346683808' post='4976078']
Where are the players that are not ingame. You've still not given us ANYTHING to work with
[/quote]
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.

##### Share on other sites
krippy2k8    646
[quote name='samoth' timestamp='1346681576' post='4976067']
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.
[/quote]

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.