OpenRPG DEV II
        An OpenRPG character sheet repository

Forums/Faqs/Forms

OpenRPG DEV II menu
Home
Chat
Forums

OpenRPG FAQ
How do I play?

Current daily
   CVS Snapshot

Image node

My Character Sheets

Why use distributed client data?

Because of OpenRPG2's modular, plugable architecture, the use of a single pre-defined data structure for client (i.e. player) data is impractical. OpenRPG2 will spread client data between all of its modules. Each module in turn is responsible for maintaining client data pertinent to its own operations. For example, a chat module may contain data relevant to the players name so it can be properly displayed in the chat window.

One problem of distributing the client data in this manner is keeping all module data synchronized to the actual clients connected to the server (or data about other clients on the client side). Each module will be notified when a new client is added to the system and when a client drops/disconnects.

The second problem, one thats more important, is how modules share information as no single client data structure exists. Modules will be allowed a controlled and limited amount of interaction though an intermediary relay object, probably as part of the module manager that will allow modules to request data and services from other modules in a safe manner. This relay is required because of the dynamic nature of the OpenRPG2 module system. There is no guarantee that a module that contains a resource needed by a different module will be loaded and exist. The use of the relay allows run time error checking and handling for requests. e.g. Module A will ask the relay object "can I have access to Module B's data called X?". In this instance if the relay object cannot locate Module B it can throw an exception to let Module A know that Module B doesn't exist. IF Module B exists but is not sharing the data Module A is asking for another exception can be thrown indicating that the data can't be retrieved. This setup allows Module A to gracefully handle the error and take appropriate measures (anything from requesting data from the client, displaying an error dialog, replacing with a default value, or throwing a fatal error to bring down the application.)

Distributed client data model (last edited 2006-03-05 23:16:33 by Snowdog)

 

© 2001-2008,Thomas Baleno