What are demands on hosting for multiplayer strategy game like Empire, Travian?

(memory for application, memory for database)

  1. in flash
  2. in .net
  3. in php ?

Comments says there is no response for this question .., but I wrote concrete examples. So some tips, which could be near to reallity would be helpful for me.
For example:
Empire is in flash it could need about xxx GB memory for the application + about xxx MB/GB memory form database. (for one world)
Travian (it is probably in php) it could need xxx GB for engine and xxx MB/GB for database.(For one world).

  • 4
    \$\begingroup\$ This depends entirely on the implementation of the game and the user base. \$\endgroup\$ – MichaelHouse Jul 30 '12 at 19:40
  • \$\begingroup\$ For everyone:I wanted to know it just approximately. I know this is different situation but point is simillar: "It's big difference if you have for example PC desktop game which took one CD and game which took 4 DVDs". I gave some examples of games and I just want to know what demands they could approximately have. \$\endgroup\$ – user1097772 Jul 30 '12 at 20:22
  • \$\begingroup\$ @Byte56 I looked to your profile and on pages of your game. What technology use your game? What are its demands on hosting? \$\endgroup\$ – user1097772 Jul 30 '12 at 20:23
  • 4
    \$\begingroup\$ There is no answer to this - just as desktop games could take anything between 1 CD and 4 DVDs (or more), so could web games. \$\endgroup\$ – Kylotan Jul 30 '12 at 20:33
  • 3
    \$\begingroup\$ Even if you add examples, you won't get any reliable answer unless the developers of Travian or Empire are visiting this site and answer personally. The requirements vary wildly depending on implementation and number of concurrent users. Just looking at the game won't tell you anything about the server requirements. So this question is still not answerable. I suggest you ask the developers of these games directly if you want to know for sure. \$\endgroup\$ – bummzack Jul 30 '12 at 21:13

This question is making my head hurt, but I'll try to help you out.

I do not know what limitations either of the games you mention have. I'm hoping you can take this info and fill in the blanks.

First we can look at database size. We need to take the maximum size of the gaming world and make it persistent in a database.

If the game board is made up of cells that have a biome/type, that could be an enumerated type or a short int/cell. If the board is 1 000 X 1 000 cells, that's one million short int's. If there is a capacity associated, that could be another int/cell. Keep adding until you think you've gotten all the information per cell accounted for.

Next we count towns. Towns usually have buildings in them, we can again make that an enumeration, so we'll call that another short int/building space. If each town has a 10 X 10 building space, that's 100 short int's per town + the town name + an int identifying the owning player. Again, if there are other important pieces of data, such as a capacity per building or a building time, that's more space yet. How many towns will there be on the board? 1 every ~10 cells? That's 10 million short int's just for the building types. Again, keep adding until your game is a game.

How many players will there be? and what information will you keep per player? (You can see this is starting to become wildly speculative based on how you program it) From memory I remember Travian kept user logins separate from the game data so a user could be active in more than one game at a time, however there was a lot of in-game player information to keep track of. Guild membership, messages to and from other players, army information, science progress? etc.

Assuming we're using MySQL for the database we can check out the size requirements here

Crunch the numbers and see what they come out as... 20MB? we can afford more than that, let's make the board bigger. 500GB? way too big, let's remove a couple extraneous bits of information per cell...

Next we can look at the bandwidth use. This has a lot more to do with the way you program your game, and so will be more speculative than the above size estimate. You need to estimate how many players you will have, how often they will be making web requests, and how much data you will be transmitting per request. Are you giving them the ability to see the whole board at once? Then you'll be transmitting all of the board data each request, so you probably don't want to do that. You want to give the user exactly the information that will show up on their screen at any moment and no more. Use the above estimation methods to total the data that will be required to set up one screen-shot from your game, and consider that the minimum of what you will have to transfer per request.

Assuming that you go to the effort of transmitting the data in some sort of binary format, you can probably estimate the byte-sizes with the SQL sizes above. If you transmit the information in JSON or XML, you can start counting one byte per digit in each of the numbers.

Again, tot the numbers and see where we're at. 1 MB per month? no problem. 1 MB per second? maybe we should start restricting user's request rates...

I think I'll stop here and hope you get the picture. It should be evident that without some kind of design information (preferably source code and database schematics) we can't really say what size restrictions a game will meet. I hope you can also see that depending on game design and coding, these things can be scaled to meet any reasonable size restrictions we put on them.

In the end, I would say that size is really so low on the worry-list that it's basically a non-issue. Go make a game and once it works and is coded to a good standard, then you can check to see how much it'll cost to host and scale it accordingly.

| improve this answer | |

If you are developing your game with Flash, you could easily get away using player.io (server-side components are developed with .net). A cheaper (and far more advanced) option is to use a cloud solution like Windows Azure or Amazon EC2. Any of these services will bill you exactly by the resources you use, i.e they are scalable. Note that these options won't work on 3D games or otherwise any games where there are permanent connections between the client and server.

In that case, you'll need dedicated hardware where the requirements depend on the game itself and how many users you plan on having connected at the same time.

Rough estimates of requirements for the OpenSimulator server software can be found here.

| improve this answer | |
  • \$\begingroup\$ Player.IO is really nice, Except if you need alot of bandwidth (My games 30 million tiles are way to much for it) But other than that I would recommend it. \$\endgroup\$ – Cyral Jul 30 '12 at 23:48

Not the answer you're looking for? Browse other questions tagged or ask your own question.