(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.
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.
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.