NEWS

Master your own destiny! Command a nation!

Campaign data handling

(Warning: Nerdy contents ahead.)

If you haven’t noticed, then I have to tell you that I am focusing a lot on data structures, data handling and data in general. The reason why, is that we have some needs for advanced data structures in order to handle a massive amount of data. But another reason is that we are using an unusual approach to dealing with data client side.

database_diagram

 

Usual you do a lot of data processing on the server side. For instance if I needed to get hold of all the Assault Teams that a user has control over, I would ask the server for this and it figures out which ones I need. This is neat and simple for the client side programming, but on the other hand it uses the servers processing power to do this. This is why a lot of people have used a lot of time building databases and server optimization, so that all this is handled with as much ease as possible. Server programmers also have to keep this in mind when doing expensive server operations such as ‘joins’. As we are creating a MMO-like game there will be a lot of clients (hopefully) asking our servers for information. Therefore we want the servers to do the least amount of work as possible, to keep them snappy. In order to achieve that we have almost no server operations (only login). Instead all data in the database is sent to the client and we leave it to the client to do the data handling.

client_database

 

Needles to say, this leaves a lot of work for the client. All data is received and then the database structure is replicated. In order to do joins and fast lookups we also create maps (with keys). This structure has been revised and is now being implemented. Quite soon you’ll experience a smooth and fast client side database.

However this also creates some new problem. A huge amount of data is sent, and most of it at the entry of the campaign. That’s why we’re cashing all static data, so the servers don’t have to fish it out of the database and the users don’t have to download it each time. There are still lots of static data being sent and we have not solved this yet, but are thinking of pulling out data from the database each hour and cashing this – and then only sending the changes from that instance to where we are now.

  1. BuchBuch12-01-2011

    But what happens if a client modifies its data (wether on purpose or by accident doesn’t really matters) ? Everything coming from a client could be manipulated, dangerous or something unexpected, to check the data you would still have to do the same operations, if I’m not mistaken.

  2. HellsBellsHellsBells12-02-2011

    If you have all the work done by the client the bandwidth can’t hold the huge quantity of data sent… And this is mean lag, and lag is bad, very bad for a MMO. Especially if you need precision (like action mode). I mean… Most of the people don’t have a fast internet. This quantity of data will limit the game only for who have a very fast internet.

    Sorry for my bad english. It’s not my main language

  3. khitankhitan12-02-2011

    Just a thought, but you could use transactions and snapshots to limit the amount of data you need to move. I read an article on infoQ a couple of months ago about this and put it into practice. It ended up working really well and has some great side effects.

    Basically you have a single transaction table, and each change to your model gets logged to that table. Then you have a piece of code that reads new entries from the log and applies it to the model.

    The side effect is that you can rebuild the model from scratch using the transaction table, and even rebuild it to a specific point in time.

    For the clients, they would only need to download new transactions, and never the entire model (except on the first sync).

    In addition you can use snapshots, maybe once per campaign. If someone has a really old copy of the model they would download the latest snapshot plus any entries in the transaction table that were applied after the last snapshot was taken.

    It is a kinda obvious idea I guess. I.e. We use transaction logs on SQL databases, and we use transaction logs in every day life, like for our savings account.

    But I never really thought about implementing my model that way until I read the article.

    Anyway… it might be worth investigating for this problem.

  4. khitankhitan12-02-2011

    I found the presentation.

    Unshackle Your Domain
    By Greg Young
    http://www.infoq.com/presentations/greg-young-unshackle-qcon08

  5. Reto.ChrestangenReto.Chrestangen12-02-2011

    Hi, I can see there is a mix up between the action and the strategy part of the game. These run on different servers, but uses some of the same data.
    I sorry that I did not write the blog less ambiguous.

    @Buch
    It is a read only client side data structure. Date is retrieved from the server and read from it. When we want to change something, like move an Assault Team, a request is made to the server and it sends new data back. So it is not possible to manipulate the data on the server via the client. Server operation are done in user interaction, but not in reading.

    @HellsBells
    Well the point is the opposite. Lot of data handling makes the server slow, which means lack. Of case large amount of data through the bandwidth can also create lack. But it is downloaded once in the start of the campaign part of the game, not the action part. We have campaign servers and action server, therefore it will never affect the FPS part. And the data amount is large by web standard not game standard. So it is nothing compared to downloading a map. But we are still working on more optimization as I wrote. We have an idea of saving the static data on the harddisk along with the game files, and retrieving it from there.

    @Khitan
    Cool, thanks for the tip. We will see if we can use it. (Shortage of time might come into play)

    • HellsBellsHellsBells12-04-2011

      Uhn yeah. Makes more sense :p. Thanks for explaining.

  6. WockaWockaWockaWocka12-03-2011

    Just use the torrent protocol approach for downloading full static database OR just the updates (could be several) since last full database. All clients will offload the main servers with a simple torrent approach using DHT or main tracker.

    If more “instant” updates are needed you could use p2p stream approaches where a lot of clients create a udp publish grid.

    Maybe I am way off here but have only studied this in labs in University where the target was distributed computing, and not updating game data. There are a LOT of methods you could use but the solution you choose is all based on how close to real-time you need to be, or if ordering is needed on the data.

    Oh and IPv6 is getting out there, and with it a lot of nice to have functions like Anycast or Multicast, that also could be solutions to bandwidth problems.

    I could go on forever on what also could be done network wise on the FPS level of games… especially if using vast areas of game play instead of a small boxed area…

What are you waiting for soldier? We need heroes on the battlefield and generals to lead them!