Dual Game Server Architecture

[digital]

Lots of questions, but I'm really curious on how you are planning on raising the bar on distributed game server architectures.

Naturally these are very specific and may be confidential on your side. I don't want to seem like I'm trying to scoop you guys or anything. Just a curious grad student who happens to be taking a distributed systems course.

 

Language Choice

 

While using the Actor model greatly simplifies logic regarding synchronization and concurrency, C++ is still has no memory safety. Do you see C++ being an issue in this regard or do you believe that the latest C++11 features, such as shared_ptr, help mitigate some of these concerns?

 

Given that your early prototype was in Scala+Akka, how have you fared in terms of losing the language features and functional style that Scala offered?

 

Scalability

 

The O(n²) update problem for games has a lot of solutions, but none of them are perfect. Your solution is to use Area of Interest (AOI) calculations and allowing for clients to be reassigned to servers based on load. How is player state going to be transferred between servers quickly, reliably, and transparently?

 

What type of communication model are you using on the backend game servers in order to share game state? How does this relate (if at all) to academic efforts such as Colyseus (https://web.stanford.edu/class/cs340v/papers/colyseus.pdf) which use a P2P game server architecture?

 

How are you persisting data in a scalable way? EVE Online uses a single master DB which simplifies things, but requires a heavy server and created a single-point-of-failure.

 

Fault Tolerance

 

What happens if a server managing a region goes down? What state will be lost?

 

How are you persisting data and what type of replication do you anticipate will be needed to assure availability?

 

Consistency

 

Regarding consistency, what happens if multiple people attempt to access a resource simultaneously from different servers? How do the servers communicate in order to resolve the ordering for who gets access?

 

Security

 

Knowing that the client can never be trusted, how are you going to make sure that no game-breaking cheats are possible?

[NQ-Nyzaltar]

Hi Digital,

 

As mentioned on Twitter, here are the answers from Jean-Christophe Baillie (Project Lead, Founder & President of Novaquark):

 

 

Lots of very relevant and informed questions! Hard to give answers to all, as some parts are clearly sensitive information at this stage, but here is what I can say: about C++, it is very acceptable if you stripe out all C-like habits. For example, no pointer is ever allowed in our code, we use C++11/14 advanced feature everywhere, smart pointer or stack based allocation, etc. Also, we are very happy with the libcaf actor library (based on c++11), really a good option comparable to Scala/akka if you can't afford to use Erlang. No P2P model for the moment, even if I find the ideas very promising, I still think it's too early for production. I won't comment on consistency and availability here, but we are well aware of the literature on these topics. As for security, one direction we are exploring is based on the idea "hard to compute, easy to check". Some calculations can be done on the client (because it's hard and resource consuming), but can then be easily checked on the server. For example, physics simulation can be calculated on the client and can be validated through conservation laws, and various physical high level quantities continuity measures.

 

JC

 

Best Regards,

Nyzaltar

[digital]

Hi Digital,

 

As mentioned on Twitter, here are the answers from Jean-Christophe Baillie (Project Lead, Founder & President of Novaquark):

 

 

Best Regards,

Nyzaltar

 

Thank you for the response! Looks like you have it figured out

 

Looking forward to seeing how it turns out and for more blog posts down the road.

[Obstinance]

though i know almost nothing about what you are discussing, i do love reading about it. i hope to find more information about your server set up. ofc not too much, as it is very sensitive information, but what ever you are willing to share. the subject is very fascinating to me. some companies are very closed about what comprises their server, others make a point to let the players know everything they can without compromising the safety of the costly equipment (and the priceless data on it). at work i often drop by our IT department office, and chat about the various aspects of the set up. though it is nothing compared to others i have seen, and even less compared to what is needed for running a game. it is very fun. we are building a new server for our company now and chatting about the equipment and what each piece will help us do better is quite intriguing. we build amusement park rides, and so we have a vast data base of drawings and engineering files that are constantly getting revised and updated. lots and lots of parts. so very fun.