ONRPG Server Architecture

Pranav Sathyanarayanan · 2014-04-12T18:25:37

Hey there guys, this is my first post on GameDev.net forums, and I figured I would inquire here considering a good amount of the folks here can offer valuable insight on the topic. I guess I will jump straight into the question, my team and I are starting a small hobby ONRPG, just to fool around with online technology and try and come up with some cool little features and such on our little sandbox. By no means is this one of those "How do I make an MMO?" "How do in C++?" kind of threads, we just have a few design questions and some compare/contrasts. So what is the issue? Well, we decided we want a seamless world, not huge or anything but we just want the ability for players to live in one persistent world, and so we have our Terrain paging and the ability to load and unload parts of the world on the fly to provide that seamless feel. The issue becomes, for the online part. After having googled and talked about this for countless hours both by myself and in our team meetings, we have discussed various approaches to the problem. Basically, the issue for us comes down to this: how do we synchronize the state of every player in the world, if the world is not divided into zones. Our solution to this problem is, pass the vector of the player as a 12 byte packet along with the information/inputs sent to the server for every command, therefore, a PositionalServer or some master server will have a local copy of the User's position at all times in RAM. So no DB queries would need to exist, and no matter what portion of the world the player is in, the PositionalServer will have access to all players currently logged in and simply replicate the command the user decided to make to the adjacent players. The cons of this approach is the extra 12 bytes of overhead everytime the player decides to even press a button or do an action. The positives is there would be nearly 0 stress on the DB as far as state synchronization is concerned when it came to replicating player events in an "Area of Interest" fashion since the server itself knows the player's locations. What is your guys opinion on this? Is there some industry standard for this player replication that I have missed reading about, as in how would you handle sending information about players to others. Is there some easier way? Would the 12 extra bytes of bandwidth be devestation in a scenario with 10, 100, 1000, 10000 players? Thank you!

Networking and Multiplayer Programming

Started by Pranav Sathyanarayanan April 10, 2014 04:25 PM

12 comments, last by Pranav Sathyanarayanan 10 years ago

hplus0603

11,916

April 11, 2014 09:32 PM

Then the client should recognize it is on the boundary of a zone and should update its ghost replica on the pertinent adjacent servers.

I suggest that you only ever update the authoritative state of an entity from the master server for that entity. The client can send suggestions to that server, but the server should enforce the rules, else a hacked client, or some script, could send arbitrary entity updates to your servers and cheat wildly.

enum Bool { True, False, FileNotFound };

Pranav Sathyanarayanan

122

Author

April 12, 2014 04:13 AM

Right sorry that is what I meant, suggest to the server to update the ghost replica.

user123456789

485

April 12, 2014 09:36 AM

I do not particularly aim for more than 1000 players concurrently online but it would eventually be nice.

What I have read is that single server at least in CS model could support around 2000 - 6000 players - so in that sense, I think you are aiming kinda big from the start. However, the number of supported players also depends on the type of the game you are making (and how you program it). Such as fast-phased FPS with same CS model might scale only to hundred. I would first try my best with CS model (because it is easiest to implement) and use possible compensatory techniques to make it scale better. After that, modifying it to client-multi-server architecture and implementing interest management technique with regions should still be possible. Thus, I bet you enjoy the moment when you realize that you have a working MOG over CS model - even if it can't support "millions" from the start

Considering the interest management and regions handle by different servers, I think at least following articles gives good details / more depth overview:

Peer-to-peer architectures for massively multiplayer online games: A Survey

http://dl.acm.org/citation.cfm?id=2522968.2522977

Note: Despite the name of the article it gives good overview of interest management including relevant techniques to make MOGs work

A Communication Architecture for Massive Multiplayer Games

http://dl.acm.org/citation.cfm?id=566503

A Distributed Architecture for MMORPG

http://dl.acm.org/citation.cfm?id=1230040.1230067

Pranav Sathyanarayanan

122

Author

April 12, 2014 06:25 PM

maunovaha: Thank you so much! Those links are practically invaluable to us, we skimmed over each one and it seems like they answer nearly all of our current questions on how to handle this massive game! Considering that a simple CS model can handle at most 2k to 6K depending, and we are only aiming for a few hundred at start this should be perfect. Thank you so much!!

Now all we have to do is implement it haha. Thanks everyone!

ONRPG Server Architecture

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

ONRPG Server Architecture

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Reticulating splines