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!

Thanks for the quick response hplus, unfortunately I have not yet studied Quake III or Source networing. I suppose that is the first thing I shall do before proceeding any further, however I am not familiar with the model where simulation is all in-RAM. I am not necessarily worried about "just" 12 bytes, my question was infact whether or not this can be considered a decent way to approach the issue is all.

As far as your first point goes, hacking is of concern to me and I will definitely take your advice on ghost copies and/or replica objects and study those, as of right now I am trying to learn more about your second point. Interest management :). So clearly database is out of the question, and this "in-RAM" situation basically calls for the server just determining the set of clients to replicate information to based on all of their positions it currently has in its RAM? Thank you!

hplus: Wow, thank you for that answer, I will definitely read more into those in-RAM spatial indexing data structures and algorithms associated with bringing objects into and out of view. I also saw an article about that hysteresis you mention in HeroEngine's Spatial Awareness system documentation, it makes a ton of sense. Thank you!

Sean: Well I am thrilled to know our solution is incorrect, back to the drawing boards haha. So from what I take of your explanation, there is no "central" server for processing that incoming data, but rather a frontend process which simply transfers ownership of the user to a "chunk server", and while the user moves around, what exactly determines the transfer of the avatar to the adjacent chunk. Is it the frontend server being aware of the client's new position being a part of the new chunk or?

This method is what we actually had considered at first, but the problem we could not solve was, how would the player receive information about players in adjacent chunks, but your question practically handles it, if your chunks are small enough (a.k.a the size of the spatial awareness radius you desire), you can have the 8 or so chunks around the current chunk's objects in a read-only fashion and query their various states. I am a little confused still on the semantics of this, as based on your response I am still unsure of how if a player in an adjacent zone moves, how to update their position on the local client as the chunk only updates the read-only state of the object. Sorry for playing 21 questions, just wanna get as much info as I humanely can! Thank you soo much for your responses guys!!

Update:

Disney MMO Link:

http://www.gdcvault.com/play/1013848/MMO-101-Building-Disney-s

That was an interesting read, some very nice points, was I reading something wrong or for their games (utilizing Panda3D), it seemed like because of SmartFoxServer's capability to do extensions in Java, they seemed to be serializing entire objects in some instances? Some of their logic diagrams are plenty useful though.

So now I suppose, if I did split my world into several smaller chunks, the interest management in a zone with a rather low amount of players would simply be asking the current and adjacent chunks for all players within a certain radius or?

Wow I see, so yes my game will definitely need handshakes between servers in order for players to travel seamlessly throughout the world. I tried googling "ghost replica", what exactly does that term imply?

From what I take of both of your explanations, these chunks or portions of the world each run as a separate processes spread on several servers. As each chunk replicates information about players in it, as far as 'spatial awareness' is concerned I should have a system to tell the process my player is in to perhaps query information about players in adjacent chunks, so as to not seem like we are standing at a seam and have no information about players like 3 feet in front of me that happen to be in the adjacent chunk. Seems interesting enough. Would a viable approach for this be:

An individual process (chunk or node or w.e you may call it) has a socket open to the adjacent processes and synchronize read-only objects like Sean had said?

Wow that actually makes a ton of sense, so I guess the difficulty of all of this is that each server should know its neighbors, and should update the ghost replicas of objects it owns to adjacent servers. I guess I will just have to start the programming and start realizing the problems as they come and fix them. I do not particularly aim for more than 1000 players concurrently online but it would eventually be nice.

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 guess my first step now Is to write the master server, almost as if my game world is just 5x5 like you said and expand upon that server and reengineer it one we learn more issues with that simple model. I still have some difficulty imagining how exactly those individual servers will be able to know how and when to replicate the information properly to adjacent servers but I will learn by trail by fire haha. Its interesting then, that between two servers, there will be nearly 400m of overlap where objects are constantly updated on both servers, what about the corner case of 4 server' areas joining at one point, so the 200m boundaries overlap in a small area, then the owning server is responsible for updating the object on all the other 3 servers right?

Thanks!