RolePlayingDesign: Difference between revisions
Jump to navigation
Jump to search
Content deleted Content added
imported>Hendrik Brummermann No edit summary |
imported>Hendrik Brummermann No edit summary |
||
| (24 intermediate revisions by 2 users not shown) | |||
| Line 66: | Line 66: | ||
The whole Marauroa system is managed by two main entities, RPAction and RPObject. There are also several helper classes like Attributes, RPSlot and RPClass |
The whole Marauroa system is managed by two main entities, RPAction and RPObject. There are also several helper classes like Attributes, RPSlot and RPClass |
||
== |
==Attributes== |
||
Attributes is a collection of pairs of values in the form name-value. |
Attributes is a collection of pairs of values in the form name-value. |
||
We can store almost any basic type in a Attribute object: |
We can store almost any basic type in a Attribute object: |
||
| Line 142: | Line 142: | ||
* Sync perceptions: these are used to synchronize clients with the server world representation. This is the only valid way of knowing world's status. |
* Sync perceptions: these are used to synchronize clients with the server world representation. This is the only valid way of knowing world's status. |
||
* Delta perception: this is used to send only the changes to the world since the last perception. |
* Delta perception: this is used to send only the changes to the world since the last perception. |
||
As we are using UDP transport protocol, which is not a delivery guaranteed protocol, it is possible that from time to time we loose a package related to perceptions. Thus won't be able to recover the world status, because each delta perception requires the previous one to work correctly. If this happens we send an Out of Sync Message to Server which causes it to send us a new Sync perception. |
|||
Our actual Perception system is called Delta<sup>2</sup>. It is heavily attached to the Marauroa core, so I recommend you to use it :) |
Our actual Perception system is called Delta<sup>2</sup>. It is heavily attached to the Marauroa core, so I recommend you to use it :) |
||
| Line 152: | Line 150: | ||
In a first attempt, we send clients back an action that was the result of their action. However, this made the code really hard because we had to update two different things, perceptions and actions. Instead the solution appears intuitively: Why not join action reply and perceptions. |
In a first attempt, we send clients back an action that was the result of their action. However, this made the code really hard because we had to update two different things, perceptions and actions. Instead the solution appears intuitively: Why not join action reply and perceptions. |
||
So the action reply is stored inside each object (that executed the action ) with a set of attributes that determine the action return status and the attributes. This way of doing |
So the action reply is stored inside each object (that executed the action ) with a set of attributes that determine the action return status and the attributes. This way of doing replies makes it a bit harder on RPManager but it simplifies the creation of new clients a lot. |
||
See Actions reply in the Objects documentation to know exactly what is returned. However, keep in mind that the return result depends of each particular game. |
See Actions reply in the Objects documentation to know exactly what is returned. However, keep in mind that the return result depends of each particular game. |
||
| Line 248: | Line 246: | ||
[[Category:Marauroa]] |
[[Category:Marauroa]] |
||
{{#breadcrumbs: [[Marauroa]] | [[Navigation for Marauroa Developers|Internals]] | [[RolePlayingDesign|Role Playing Design]] }} |
|||