   Distributed Object API vs. Packet Messaging API
  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) orb.) Build upon a purely packet messaging APII'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 APIPros: 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 APIPros: 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 Synth0idI'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.htmland you can download it from the same site (as part of score):http://www.pccluster.org/;  If you intend to build server system based on the distributed object model, then you will also need a messaging api that can forward the object data and events. I suggest you to build a messaging api, that can be used for object state replication and also for messaging, like chat and other auxiliary data. Then you can decide to create an abstraction wrapper for your objects or not. This way you can choose between a messaging only system or a distributed object model one with message based state transfers. I suggest a mixed solution: state replication or transfer for game objects, and a message based api for communication purposes.Viktor   ;  @nmiThanks for the links, I'll take a look at them.@ViktorI'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.   