DistributedObjects are the base for all things that should be managed over the distributed network. This may include players, level objects, the level itself, a message object for chat messages and really anything else in the application world.
As seen in earlier sections, they can be created on the client repositories and, when created, they will automatically be distributed to other clients.
To define who will see DOs, they can be set in specific zones.
Zones are just numbers that have to be set on a DO and a client needs to
show interest in them to be able to see objects in them.
In addition, objects that a client doesn’t own can’t be updated by that client.
Only the object’s owner can change fields in it, except if they are specially
marked with the
clsend keyword in the DC definition file.
Most DOs will have a basic class definition (eg. “Foo”) and an AI definition which would be called “FooAI”. The Foo class will be used on clients and the FooAI class will be generated on the AI servers.
An example of a distributed object class implementation may look like the following:
from direct.distributed.DistributedObject import DistributedObject class DGameObject(DistributedObject): def __init__(self, cr): DistributedObject.__init__(self, cr) def d_sendGameData(self): """ A method to send an update message to the server. The d_ stands for distributed """ # send the message to the server self.sendUpdate('sendGameData', [('ValueA', 123, 1.25)])
AI Server side DGameObjectAI.py
from direct.distributed.DistributedObjectAI import DistributedObjectAI class DGameObjectAI(DistributedObjectAI): def __init__(self, aiRepository): DistributedObjectAI.__init__(self, aiRepository) def sendGameData(self, data): """ Method that can be called from the clients with an sendUpdate call """ print(data)
The foo method is the one that will have an effect locally.
The d_foo (d_ stands for distributed) method will send a message to the server
and hence to other clients as needed and will update them. As you see, you can
simply send data to the server with a self.sendUpdate call.
There is also another method called
DistributedObjectAI.sendUpdateToAvatarId() which accepts a doId
of a client and will send the message directly to it. This method is only
available on the AI and UD side.
the b_foo (b_ stands for both) method will update both, the local object as well as send the data to the server. This can usually easily be achieved by simply calling both, the foo and d_foo method within the b_foo method.
Aside of your own methods for sending and receiving messages between the
client and server-side objects, there are some methods worth knowing which are
implemented by the
DistributedObject class. Those methods will usually
be overwritten when creating a distributed object class and fitted to your own
announceGenerate(): This method will be called as soon as the object has
been manifested. On the client side, you may want to use this for AI-created
objects. For example:
def announceGenerate(self): base.messenger.send(self.cr.uniqueName('myObject-generated'), [self.doId]) # call the base class method DistributedObject.announceGenerate(self)
disable(): This method will be called when the object gets disabled. This
usually comes prior to a delete call.
delete(): This method is called whenever a DO gets deleted. For example
if the client who created it has left the zone or server. DOs should implement
cleanup code here.
generate(): This method is called at generation time of the DO.