Strategy/City Builder browser game - technical details

Question

I actually have multiple questions into one. Hopefully someone can hit all of them.

I wanted to give a try at a massively multiplayer web based game. Basically, the game would have similarities to Evony, or Eve Online (a much scaled down version). The idea is it would be a mostly real time city builder (like Evony) that allows complex actions between players (like Eve Online but without the graphics and much scaled down). It would sort of be like a database game. I want it to be able to support around 500 people simultaneously online off one server.

However, I have multiple issues that I want to pin down before I actually start writing the code.

1. Continuous database updating

The database has to be continuously updated on a small time interval to reflect the passage of time in the game verse. Furthermore, the effects of all actions will have to be calculated as well. Right now I'm thinking about using mysql with events using the innoDB engine to do this. Is there a better/faster approach to this?

1. Continuous graphical updating

Certain details (such as "time till completion" etc when building something) need to be continuously updated on the user interface. I'm thinking about having each page in the user interface continuously make ajax calls for the information. Again, is there a better/faster way?

Thanks

Answer 1

Database Updating

You should really use a message queue - chances are your SQL DB will fall over when you hit it with this level of concurrency (deadlocks etc.). I have heard that RabbitMQ is quite good. Remember that once your data is in the MQ it's as good as it being in a database - MQs are just designed to process a lot of messages and allow other systems to take it easier under load and have as much ACID assurance as SQL does. So just queue your player commands into one end and update your DB when you dequeue off the other.

You might find PostgreSQL performs better, at this point critical optimizations that most other DBs have are only experimental in MySQL.

UI Updating

In general if you should use one of several methods depending on what the server and client support (in order of preference):

• WebSockets
• Server Events
• Forever Frame
• Long Polling
• Polling (your current idea)

Frameworks like SignalR deal with all this complexity for you (really, SignalR is just pure awesomeness).

Combining the Two

In terms of your question as a whole here is how I would deal with things. A throbber would be anything, possibly make the building/whatever transparent or display a spinner over it. It basically tells the player - "if you close your browser now these things might never happen".

Player issues command --> Update player UI with throbber --\
                      /------------------------------------/
            Send command to server
                      |
   Remove throbber when server acknowledges
                      |
      Enqueue the command into the MQ
                      |
                      +<------------------------\
                      |                         |
                      V                         |
            +------------------+                |
            | RABBIT MQ        |                |
    /------>|                  |                |
    |       +------------------+                |
    |                  V               Additional commands?
    |                  |               e.g. update building % done
    |                  |                        |
    |    Perform logic associated with command -/
    |                  |
    |           Update database
    |                  |
    \------Acknowledge MQ message
                       |
                       |
        Send message to interested/online
             players via SignalR
                       |
                       V
                     Babes