I'm working on a large-scale game project (MMOG) and I'm at a cross-roads in terms of where to go in terms of planning out the internal server-to-server communication. The two options I'm playing with are to either: a.) Build a distributed object API (similar to RakNet's Distributed Network Object) or b.) Build upon a purely packet messaging API I'll describe what I mean by each in some more detail. First, what I mean by a Distributed Object API, is something similar to how Quazal, RakNet, and in a minor way .NET Remoting, work for distributing an object across server boundaries. As a distributed object's properties change, their accompanying "ghost" objects on other servers would be transparently updated as well. Secondly, is the Packet Messaging API. This would basically involve creating packets or forwarding packet information between servers in a more manual way. This would be similar to how most Client/Server network apps work. I'm sure you get the idea :) The Pros and Cons for each method, that I forsee, are: Distributed Object API Pros: Elegant, easier to work with once it's setup, quite a bit more powerful in terms of usage, allows transparency. Cons: Takes longer to develop, is likely slower than the packet approach. Packet Messaging API Pros: Fast, simple to design and implement. Cons: Not nearly as elegant, requires manual encoding and decoding of commands/messages, can get messy when there are 100's of possible commands, requires distinct programming paradigms that tailor specifically to messaging. So, I would like some input, comments, suggestions on what you guys think of both of these approaches, and what you think would be best used in a MMOG. FYI... I care much more about learning how to do things the "right" way than taking the easy way out in order to finish the game. Thanks, synth0id

Quote:

Original post by Synth0id I'm working on a large-scale game project (MMOG) and I'm at a cross-roads in terms of where to go in terms of planning out the internal server-to-server communication.

So basically you have the problem to organize the inner workings of your server(s).

Maybe TACO (Topologies & Collections) is what you are looking for. You can read a tutorial here:
http://www.pccluster.org/score/dist/score-5.8.3/html/en/reference/taco/tutorial/index.html
and you can download it from the same site (as part of score):
http://www.pccluster.org/

@nmi

Thanks for the links, I'll take a look at them.

@Viktor

I've already got a messaging system in mind that's about halfway coded. I'm basically hacking up an older system and retooling it a bit so that part is going to be relatively easy and quick to finish up.

I actually (duh) hadn't thought of using both models side-by-side. I suppose that's a valid solution, but in all honesty, not one I'm leaning towards. I'd like to stick with one method or the other, since I'd like to keep server-to-server communication easy to follow and as consistent as possible.

Keep in mind that I'm looking for a solution to ONLY server-to-server communication. I have every intention of utilizing a messaging model for the client-to-server scenario since performance will be extremely important and I'm doubtful that a distributed object model would perform as needed.

Good comments so far, keep them coming!

Actually, a distributed object model may be able to perform better than a pure messaging model, because the distributed object model may have enough meta-data about the objects being distributed to optimize in ways that pure messaging cannot. To actually deliver on this promise, however, requires a fair amount of perserverance and willingness to see it all through.