I am having some trouble passing initialization parameters to a DistributedObject. I have been using the CMU Lan server code over the past few weeks and I might be using it incorrectly. The method I have been using to create an intance of an object that I want mirrored to other clients is:
where self.cr is an instance of the ConnectionRepository class. The problem with this method is I haven’t figured out an easy way to give our Avatar initialization values.
For the first method, self.avatar inherits from DistributedObject. In the second, self.avatar inherits from DistributedObjectAI. Is DistributedObjectAI even supported by the CMU Lan server?
Is there a proper way to pass initialization parameters to a distributed object that I am missing?
To anyone waiting for an answer to this, I’ll give what has been learned so far.
It seems that for now, there is no way to pass in initialization parameters for a distributed object. To code around this what needs to happen is a createWithRequired call and then after everything has been initialized, set the parameters with some sort of setup function. This gets tricky though. When a DistributedObject is not local on a machine, you can’t assume any local DistributedObjects are created first. In fact, most of the time, I’ve seen the non-local versions created before the local ones. So if you want to communicate to late-comers in a network, you need to make sure they exist on their machine before your non-local version gives its info.
Bigger picture — I’m worried about the design of this CMU LAN system. The fellow who designed it was a good student, but he wasn’t experienced in parallel computing. Combine that with the fact that he was trying to make it compatible with a design that was intended for an MMORPG, and the fact that toontown has some quirks, and you’ve got a system that’s pretty awkward.
I feel that we really ought to redesign this from scratch. That may be less programming than it appears. The ServerRepository is only 16k of code. The ClientRepository is only 35k. Also, we could start by simply forking the current code. Then, we could start rearranging, a little bit at a time. So this could be an incremental process.
I’m not convinced the system needs to be redesigned, although I admit haven’t tried to do anything with the CMU version. But I think the MMORPG version that it tries to be compatible with is pretty dang powerful, and I’m not sure that the MMORPG model is fundamentally incompatible with a p2p model.
Surely all it needs is some window-dressing like convenient constructor parameters, and some kind of system for serializing updates after the creates for their corresponding objects?
If we are going to window-dress or change the networking, on the top of my wish-list would be a way to represent different versions of a distributed object.
Take a first person shooter example:
-My avatar on my machine is a pair of arms attached to the camera which moves around in the world.
-On other machines, they see my avatar as an Actor model playing animations and changing positions.
-The server wouldn’t see geometry at all, but rather pure logic of my avatar, along with the logic of everyone else.
-Other representations could exist (different models, different logic) even on the same machine.
I was told that originally panda had an AI version of distributed objects, remnants of which can still be seen, but nothing operational. These AI versions were usually on the server side and used to grant/refuse requests by the client. This was cut for CMU. If the networking is going to go through major updates, I would like to see an ability of different versions of distributed objects available (but not required if one only wanted to make a single version of a distributed object).