Fundamental Terms & Concepts

There are many acronyms that you will find as you read the documentation. Please review the list below to learn and understand the different concepts and terms. Also refer to the Glossary for more terms and definitions.

  • DO

    Distributed Object. Represents an instance of a Distributed Class. This object is present in the State Server’s visibility tree and views of it can also exist on Donet clients. This includes AI and game clients.

  • DOG

    Distributed Object Global. Similar to a Distributed Object, but is omnipresent in the Distributed Object visibility tree. This means that it is known globally and always remains accessible by all participants, such as Clients and AI processes. DOGs are useful for authentication, as anonymous (or non-authenticated) clients can interact with a Distributed Object Global object, as its not part of the visibility tree and it’s DoId is a constant that is globally known by all clients.

  • DoId

    Distributed Object Identifier. This is a 32-bit long identifier that is generated by the server at runtime to identify a Distributed Object that exists in the State Server.

  • DC

    Distributed Class. This is a class definition that the developer defines in the DC file. Distributed Objects are instantiated based on a Distributed Class in which it inherits it’s properties, or fields, from.

  • AI

    Artificial Intelligence. The name for this is arbitrary, as it is not in any way related to the field of machine learning. An AI is a process on the server cluster’s internal network that acts as a client connected directly to a Message Director instance. This means that all AI clients bypass the Client Agent, as they are inside of the ‘trusted zone [1].’ AI processes have authority over Distributed Objects and host the game/application’s logic.

  • UD

    Uber DOG. This is similar to an AI process, but is dedicated to managing Distributed Object Global (DOGs) objects.

  • Views

    Views are local implementations of a Distributed Class from different perspectives. A view is essentially a representation of a Distributed Object in the eyes of a client. Distributed Object instances on a client inherit from a Distributed Class and are usually, by convention, named with a suffix which describes the object’s perspective from the client’s point of view in the virtual world. Valid suffixes are: “AI” (Artificial Intelligence), “UD” (UberDOG), and “OV” (Owner View).

    “AI” views are the AI-side representation of a Distributed Object instance.

    “UD” views are used by UberDOG processes (similar to AI clients).

    “OV” views are used by clients, which have ownership over that Distributed Object instance.

    Objects seen by a client, but not owned by it, also have their client-side representation without a suffix.

    ../_images/view_diagram.png

    Each view implements the logic that is executed when a field of the Distributed Object is called. For example, a Distributed Class named ‘DistributedAvatar’ has AI and OV views. The AI view may have the privilege to add currency to the ‘DistributedAvatar’ object, while the OV view has the ability to set the username of the ‘DistributedAvatar’ object. In a nutshell, AI processes implement administrative logic for a Distributed Object while client processes may implement special logic over objects they have ownership of, or use shared logic for objects they do not own.

    Tip

    The concept of views is very similar to the Model-view-controller (MVC) software design pattern.

  • CR

    Client Repository. See Panda3D’s Client Repository.