5
\$\begingroup\$

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

|improve this question
\$\endgroup\$
7
\$\begingroup\$

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
|improve this answer
\$\endgroup\$
  • \$\begingroup\$ Thanks for the detailed answer. I'm reading through the things you suggested right now. I might have to ask you for some clarification later. \$\endgroup\$ – saccharine Mar 15 '12 at 13:25
  • 2
    \$\begingroup\$ @saccharine no problem. Don't be too eager to accept answers though - even though you like it at the moment you never know if someone else has something better. I usually give it 24hrs after I get a single answer for other people to get a chance. \$\endgroup\$ – Jonathan Dickinson Mar 15 '12 at 13:36
  • \$\begingroup\$ I can't upvote answers yet, so I figured I'd just accept yours. Don't worry, if a better one pops up I'll accept that one instead :D. I need a clarification on the relationship between RabbitMQ and the database though. Can you expand more on it? Does RabbitMQ simply manage all the db queries and then feeds them to the database? I've tried reading through the RabbitMQ faqs and tutorials but they don't seem to be focusing on database interactions. \$\endgroup\$ – saccharine Mar 15 '12 at 14:02
  • \$\begingroup\$ @saccharine The don't automatically interact. Typically you would drop your JSON object or whatever into the MQ. When you receive it off the other end of the queue you would do some logic; and update the DB with what the logic dictates. Essentially the queue would be dealing with requests from your users, but as a consequence of that it would help with the load against your DB (instead of hitting the DB in every request). \$\endgroup\$ – Jonathan Dickinson Mar 15 '12 at 14:10
  • 1
    \$\begingroup\$ @saccharine Exactly. Under very high load your interactions might not be real-time (because you would have a set number of workers/threads pulling stuff off the queue) - BUT the situation would be substantially worse if your DB ran out of update/insert capacity. This picture I made explains what it does hopefully quite clearly. So you do lose a bit of 'realtimeness'/scalability but with the advantage of not failing requests or repeating work because of overcommitting. \$\endgroup\$ – Jonathan Dickinson Mar 15 '12 at 14:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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