Arianne

RolePlayingDesign: Difference between revisions

← Older edit
Content deleted Content added
VisualWikitext
No edit summary
imported>Hendrik Brummermann
No edit summary
 
(198 intermediate revisions by 5 users not shown)
Line 1:
{{Navigation for Marauroa Top|Internals}}
It is perhaps the most complex part of all the middleware that compromises Arianne.<br>
{{Navigation for Marauroa Developers}}
Role Playing Design determines how ''easy'' is to create a new game for Arianne. We had to choose easing the creation of turn time limited based games, so Arianne will work better with that kind of games, also known as realtime games.
 
 
Role Playing Desing anyway tries to keep generic and game agnostic.
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 tries to be generic and game agnostic (independant of the game being made).
The very basic idea behind RPManager is:
<pre>
Line 12 ⟶ 16:
}
</pre>
 
To achieve this we use several classes:
* RPManager is coded in Marauroa and doesn't need to be modified.
* IRPRuleProcessor is the interface that you need to modify in order to personalize the actions that your game will execute.
* RPWorld is the class that you need to extend inorder to implement the onInit and onFinish methods which personalize what happens when you initialise the server and what happens when you close the server.
* IRPZone is an interface that you ''could'' implement if you wanted to achive the highest personalization possible of the engine, however, I would use MarauroaRPZone instead as that uses our great Delta<sup>2</sup> feature.
 
 
=RPManager=
The goal of the RP Manager is to handle the whole RP of the game. This means mainly:
* run RPActions from clients
* manage RPWorld
Line 20 ⟶ 31:
* control AI
 
As you see thisThis is a HUGE classtask that is very complex. So the idea isHence towe split this behavior into smaller subclasses.
 
RPManager providesexposes a simple interface to the GameManager for using it:
* <i>addRPAction</i> <br> This function queues an action for a particular player to be executed on the next turn.
* addRPAction
* <i>getRPObject</i> <br> This is an interface to manage RPWorld to ease the aquisition of the RPObject when exiting the game.
* addRPObject
* <i>onInit Player</i>
* removeRPObject
* <i>onExit Player</i><br> These are callback functions that are used by GameManager to notify that a player has entered or exited the game.
* hasRPObject
* <i>transferContent</i><br> is a callback function that is called by RPRuleProcessor to stream content to players.
 
The main flow of RPManager is:
addRPAction simply queues an action for that player to be executed on the next turn.
 
addRPObject, removeRPObject and hasRPObject is a interface to manage RPWorld.
 
The main outline of RPManager could be:
<pre>
forever
{
Procced through every action in this turn
{
rpRuleProcessor executes action
}
 
Build Perception
Remove timed out players
Line 47 ⟶ 59:
RPScheduler is the class that handles actions to be queued for each player. All the complexity of Action management should be handled here.
 
RuleProcessorRPRuleProcessor is a wrapper class for hide actions code. Alland theinitialization actionsand code MUST be here, this class also acts as a Actionexit code. loader, as some actions are not part of Marauroa, but scripts.<br>
All the actions code MUST be here.<br>
By implementing RPRuleProcessor you personalize Marauroa to the game you want to make. However, keep in mind that you are ''limited'' to a realtime style game.
 
=Objects and Actions=
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==
=Actions and Objects=
Attributes is a collection of pairs of values in the form name-value.
The whole Marauroa system is managed by two main entities, RPAction and RPObject
We can store almost any basic type in a Attribute object:
==Actions==
* strings
To express the willing of a client to do something it must send the server a MessageC2SAction message.
* integer
 
* floats
An action is composed of several attributes, an attributed is similar to a variable that has a name and contains a value.
* boolean
 
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.
 
The action_id is used to identify the action when a resulting response comes in a perception
 
We can't store structures in the attribute, but you can convert groups of data to a string and store it as a string. Marauroa provides helper methods for this.
Optional Actions Attributes: (Read "Actions Explained" for more details.)
 
==Objects==
The containers ofAll information ofin the whole Marauroa server areis contained in RPObjects. An object is composed of several attributes, (an attribute is similar to a variable in that it has a name and contains a value) and also it is composed of Slots. A Slot is a container or array of containers thatbelonging theto an object, hasand are used to host (store) other objects inside itthem.
 
Mandatory Object Attributes: id, type and zoneid
 
id is an unique identification for the Object and, zoneid is the identification for the zone where the object resides and type is the type of the object aka class, so that you can share attributes for all the instances of the class.
 
An id is only unique inside the zone which contains that object.
 
AlsoNOTE: The engine giveprovided two special treatment to two types of attributes:
- Attributes that begin with ! are completely hidden forfrom all theother users butexcept the owner of the object.
- Attributes that begin with # are completely hidden for all the users.
 
===Classes of Objects Explained===
Classes of Objects are the basic way of structuring Marauroa data structures.
The type of an attribute of a given object must be equal to a RPClass name of the type class you wish to use.
 
AThe class defines typesthe type of the attributes andattribute, its visibility and givesassigns it an internal code that is used to speed up searchs and save bandwidth. You can base a class on another, this feature is known as inheritance (a new class is create from a class that already exists and takes all the original classes methods and data and extends it).
 
The data types available are:
Line 91 ⟶ 103:
* Flag ( it is a binary attribute )
 
Attributes can also be visible ifwhich means clients see them when they change, or invisible if clients can't see them.
 
===Slots===
As you know Objects can containreside inside anotherother objectobjects much like you have the keys inside your pocket. The goal of Slots is to provide a richer game play while reducing the number of object in the zone.
 
To have these objects inside, we need our hoster object to have slots to place them in. One slot can only handle one single object.
 
For example aan avatar can have:
-* left hand
-* right hand
-* backpack
-* left pocket
-* right pocket
 
and we can store objects onin each of these slots.
 
Once thean object ishas been stored inside thean avatarobjects or another objectslot, the only way of accessing itthe stored object is through the object that contains our stored object.
 
As attributes, slots have two special types:
* Slots names that start with ! are only sent to owner player. (Hence only seen by the owner)
* Slots names that start with # are not sent to players. (Invisible to all)
 
= How Perceptions and =Actions work ==
To express the willingness of a client to do something it must send the server a MessageC2SAction message.
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?
 
An action is composed of several attributes. (an attribute is similar to a variable in that it has a name and contains a value).
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.
 
There are optional and mandatory attributes. If a mandatory attribute is not found, the message is skipped by the RPServerManager.
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.
 
Mandatory Action Attributes are action_id and type.
See Actions reply in Objects document to know exactly what is returned, but keep in mind that it depends of each particular game.
 
The action_id is used to identify the action when a resulting response comes in a perception
=Delta perception Algorithm=
 
The main idea behind the DPA is not to send ALL the objects to client, but only those that has been modified.
=Perceptions=
The basic structure for sending world updates to clients is called perceptions.
 
There are two types of perception:
* 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.
 
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 :)
 
== How Perceptions and Actions work ==
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?
 
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 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.
 
==Delta<sup>2</sup> perception Algorithm==
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?
 
The Traditional method:
<pre>
- Get objects that our player should see ( 1000 objects )
Line 135 ⟶ 170:
</pre>
 
I hope you see the problem..., we are sending again objects that neverhaven't changed each turn.
 
The delta perception algorithm:
Line 152 ⟶ 187:
</pre>
 
The next step onof the delta perception algorithm is pretty clear: delta^<sup>2</sup> The idea is to send only what changes of the objects that changed. ThatThis whyway youwe 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:
 
* List of added objects
Line 161 ⟶ 196:
* List of deleted objects
 
An area reallyvery related to DPA is RPZone (see lower in this doc)
 
Well, asAs 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 getgets 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 get synced. The idea here is similar, if we fail to synchronize with server we send himit aan Out of Sync Message so that server will send a sync perception so that the clients can synchronize,. asRemember, 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=
Worlds in Marauroa can be so big, so huge, that we need to split them in to several pieces.
Objects must be stored somewhere, and we use Zones now to store them. A zone is just a container of Objects.
Each of these pieces are what we call an RPZone.
 
So our world is made of several RPZones that are '''independent''' of each other.
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.
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==
The actual Marauroa RP Zone consists of several data structures:
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 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:
* addRPZone
* getRPZone, which can be used with either RPZone.ID or RPObject.ID
 
Finally it also contains methods for managing RPObjects as:
* addRPObject, that need that our RPObject contains a valid RPZone.ID inside its RPObject.ID
* getRPObject
* modifyRPObject
* 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 resets the delta<sup>2</sup> data.
 
==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.
 
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 require.
 
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:
* a HashMap of RPObject.ID to RPObject
* a List of RPObject
* a Perception
 
The idea is to have already computed, in the Zone, the perception sohence 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 itsthe RPObject.ID,. thisThis is the most usualcommon way for locating thean object with a known ID. List is used to improve the time required to build a total perception. AndPerception well, weis used perception 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"