RolePlayingDesign: Difference between revisions

Jump to navigation Jump to search
← Older edit
Content deleted Content added
imported>StephenIerodiaconou
No edit summary
imported>Hendrik Brummermann
No edit summary
 
(54 intermediate revisions by 4 users not shown)
Line 1: Line 1:
{{Navigation for Marauroa Top|Internals}}
{{Navigation for Marauroa Developers}}


This is possibly the most complex part of all the middleware that makes up Arianne.<br>
This is possibly the most complex part of all the middleware that makes up Arianne.<br>
Role Playing Design is the determining factor on how ''easy'' is to create a new game for Arianne. We had to choose easing the creation of turn time limited based games. Arianne will work better with this kind of games (also known as realtime games).
Role Playing Design is the determining factor on how ''easy'' is to create a new game for Arianne. We had to choose easing the creation of turn time limited based games. Arianne will work better with this kind of games (also known as realtime games).
Line 62: 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


==Atributtes==
==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 107: Line 111:


For example an avatar can have:
For example an avatar can have:
- left hand
* left hand
- right hand
* right hand
- backpack
* backpack
- left pocket
* left pocket
- right pocket
* right pocket


and we can store objects in each of these slots.
and we can store objects in each of these slots.
Line 128: Line 132:
There are optional and mandatory attributes. If a mandatory attribute is not found, the message is skipped by the RPServerManager.
There are optional and mandatory attributes. If a mandatory attribute is not found, the message is skipped by the RPServerManager.


Mandatory Actions Attributes are action_id and type.
Mandatory Action Attributes are action_id and type.


The action_id is used to identify the action when a resulting response comes in a perception
The action_id is used to identify the action when a resulting response comes in a perception


=Perceptions=
=Perceptions=
The basic structure for sending world updates to client is perceptions.
The basic structure for sending world updates to clients is called perceptions.


There are two types of perception:
There are two types of perception:
* Sync perceptions, that are used to synchronize clients with the server world representation, that is the only valid source for knowning world 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, that is used to send only changes since the last perception.
* Delta perception: this is used to send only the changes to the world since the last 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 :)
As we are using UDP transport, it is prone that we lose from time to time a package related to perceptions, and so we aren't going to be able to recover the world status, because each perception requiere the previous one to be able to work correctly. In this case we will send an Out of Sync Message to Server, so that server sends us a new Sync perception.

⚫
Our actual Perception system is Delta<sup>2</sup>. It is heavily attached to the Marauroa core, so I recommend you to use it :)


== How Perceptions and Actions work ==
== How Perceptions and Actions work ==
Actions are sent from client to server in order to make their character to do an action. In order for the client to know the result of the action Server need to send it to client. How?
Actions are sent from the client to the server in order to make the character perform an action. In order for the client to know the result of the action the Server needs to send a reply to the client. How will this be done?


On a first try, we used to send client back an action that was the result, but make code really hard because we had to update to different things, perceptions and actions, so the idea appeared 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 working make a bit harder to RPManager but it simplify a lot the creation of new clients.
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 Objects document to know exactly what is returned, but keep in mind that it 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.


==Delta<sup>2</sup> perception Algorithm==
==Delta<sup>2</sup> perception Algorithm==
The main idea behind the DPA is not to send ALL the objects to client, but only those that has been modified.
The idea behind the DPA is to avoid sending ALL the objects to a client each time, but only those that have been modified.


Imagine that we have 1000 objects, and only O1 and O505 are active objects that are modified each turn. Ok?
Imagine that we have 1000 objects, and only O1 and O505 are active objects that are modified each turn.


Traditional method:
The Traditional method:
<pre>
<pre>
- Get objects that our player should see ( 1000 objects )
- Get objects that our player should see ( 1000 objects )
Line 168: Line 170:
</pre>
</pre>


I hope you see the problem..., we are sending again objects that never changed.
I hope you see the problem... we are sending objects that haven't changed each turn.


The delta perception algorithm:
The delta perception algorithm:
Line 185: Line 187:
</pre>
</pre>


The next step on delta perception algorithm is pretty clear: delta<sup>2</sup> The idea is to send only what changes of the objects that changed. That why you save even more bandwidth, making perceptions around 20% of the original delta perception size.
The next step of the delta perception algorithm is pretty clear: delta<sup>2</sup> The idea is to send only what changes of the objects that changed. This way we save even more bandwidth, making perceptions around 20% of the original delta perception size.


The delta<sup>2</sup> algorithm is based on four containers:
The delta<sup>2</sup> algorithm is based on four containers:
Line 194: Line 196:
* List of deleted objects
* List of deleted objects


An area really related to DPA is RPZone
An area very related to DPA is RPZone (see lower in this doc)


Well, as you should know, MPEG adds a full frame each X number of frames, so it can be used as synchronization in case the file get corrupted. The idea is that if you fail to continue decompressing data, you can always omit things until the next full frame and then when you synced. The idea here is similar, if we fail to synchronize with server we send him a Out of Sync Message so that server will send a sync perception so that clients can synchronize, as UDP is not a secure transport.
As you should know, an MPEG video adds a full frame each X number of frames, so it can be used as synchronization in case the file gets corrupted. The idea is that if you fail to continue decompressing data, you can always omit things until the next full frame and then you get synced. The idea here is similar, if we fail to synchronize with server we send it an Out of Sync Message so that server will send a sync perception so that the clients can synchronize. Remember, UDP is not a secure transport.

⚫
To make perception works it is important to call the modify method on RPZone so this way objects modified are stored in the modified list.


⚫
To make perceptions work, it is important to call the modify method in RPZone, so this way objects modified are stored in the modified list.


=Zones and Worlds=
=Zones and Worlds=
Worlds in Marauroa can be so big, so huge, that we need to split it in several pieces.
Worlds in Marauroa can be so big, so huge, that we need to split them in to several pieces.
Each of these pieces are what we call RPZone.
Each of these pieces are what we call an RPZone.


So our world is made of several RPZones that are '''independent''' of each other.
So our world is made of several RPZones that are '''independent''' of each other.
To move from one RPZone to another RPZone you have to code that behaviour on RPRuleProcessor. Just look at any of the coded examples.
To move from one RPZone to another RPZone you have to code the correct behaviour in RPRuleProcessor. Just look at any of our coded examples.


==RPWorld==
==RPWorld==
As we have said, it stores several RPZones that are independent of each other.<br>
As we have already said, RPWorld stores several RPZones that are independent of each other.<br>
RPWorld provides onInit and onFinish methods that are called on server init and server finalization to define what to do with world on these events. There is no default behaviour and you need to extend this class to redefine the behaviour.
RPWorld provides onInit and onFinish methods that are called on server initialisation and server finalization to define what to do with the world on these events. There is no default behaviour and you need to extend this class to redefine the behaviour.


Also it provides methods for adding and getting new RPZones:
Also it provides methods for adding and getting new RPZones:
Line 222: Line 223:
* changeZone that moves one object from the old zone to the new zone and adds a proper valid id.
* changeZone that moves one object from the old zone to the new zone and adds a proper valid id.


At last, RPWorld also contains a method called nextTurn that is called by RPManager to move from one turn to the next turn. It mainly reset the delta<sup>2</sup> data.
At last, RPWorld also contains a method called nextTurn that is called by RPManager to move from one turn to the next turn. It resets the delta<sup>2</sup> data.


==RPZone==
==RPZone==
Objects must be stored somewhere, and we use Zones now to store them. A zone is just a container of Objects which has a name.
Objects must be stored somewhere, and we use Zones now to store them. A zone is just a container of Objects which has a name.


Each RPZone '''must''' have an unique name.
Each RPZone '''must''' have a unique name.


In order to improve the modifiability of the Marauroa platform we have made RPZone to be an interface so that if you want you can implement it as you think it is more efficient.
In order to improve the modifiability of the Marauroa platform we have made RPZone to be an interface so that if you want you can implement it as you require.


But on the usual case, if you think Delta<sup>2</sup> is fine and match your game style, you can use MarauroaRPZone that is our reference implementation of Delta<sup>2</sup> algorithm.
But in most cases, if you think the Delta<sup>2</sup> system is fine and matches your games style, you can use MarauroaRPZone that is our reference implementation of Delta<sup>2</sup> algorithm.


The actual Marauroa RPZone consists of several data structures:
The actual Marauroa RPZone consists of several data structures:
Line 238: Line 239:
* a Perception
* a Perception


The idea is to have already computed in the Zone the perception so saving LOTS of time that would be needed to generate it. All the data structures contain the same objects, but the hashmap is used to fast search of objects using its RPObject.ID, this is the most usual way for locating the object. List is used to improve the time required to build a total perception. And well, we used perception to pre-calculate the delta perception.
The idea is to have already computed, in the Zone, the perception hence saving LOTS of time that would normally be needed to generate it. All the data structures contain the same objects, but the hashmap is used to do a fast search of objects using the RPObject.ID. This is the most common way for locating an object with a known ID. List is used to improve the time required to build a total perception. Perception is used to pre-calculate the delta perception (i.e. to find the changes between the current state of the zone and the previous state send to the client last turn)

⚫
The perception is the same for all the players in the Zone.


⚫
In order to make perceptions work, you have to manually call the modify method so that you notify the zone about changes in a character or object.
⚫
Actually the perception is the same for all the players on the Zone.


[[Category:Marauroa]]
⚫
In order to make perceptions work, you have to manually call modify method so that you notify the zone about changes in a character.
{{#breadcrumbs: [[Marauroa]] | [[Navigation for Marauroa Developers|Internals]] | [[RolePlayingDesign|Role Playing Design]] }}
Retrieved from "https://meet.konsthol.eu/w/index.php?title=RolePlayingDesign"