RolePlayingDesign: Difference between revisions

The goal of the RP Manager is to handle the whole RP of the game. This means mainly:

As you see thisThis is a HUGE takstask 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> ItThis simplyfunction queues an action for thata particular player to be executed on the next turn.

* <i>getRPObject</i> <br> ItThis is an interface to manage RPWorld to ease the adquisitionaquisition of the RPObject when exiting the game.

* <i>onInit Player</i>

* <i>onExit Player</i><br> TheyThese are callback functions that are used by GameManager to notify that a player has entered the game or that a player has exitexited the game.

* <i>transferContent</i><br> It is a callback function too that is called by RPRuleProcessor to stream content to players.

The main outlineflow of RPManager could beis:

By implementing RPRuleProcessor you personalize Marauroa to be the kind of game you want to codemake. ButHowever, keep in mind that you are ''limited'' to a realtime likestyle game.

The whole Marauroa system is managed by two main entities, RPAction and RPObject. andThere are also several helper classes like Attributes, RPSlot and RPClass

==AtributtesAttributes==

Attributes is a collection of pairs of values in the form name-value.

We can't store collectionsstructures in the attribute, but you can convert itgroups of data to a string and store it as a string. Marauroa provides helper methods for itthis.

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.

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.

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.

YouThe musttype useof typean attribute to make use of classesa sogiven value of typeobject 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).

Attributes can also be visible ifwhich means clients see them when they change, or invisible if clients can't see them.

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 has alsohave 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)

To express the willingwillingness of a client to do something it must send the server a MessageC2SAction message.

An action is composed of several attributes,. (an attributedattribute is similar to a variable in that it has a name and contains a value).

Mandatory ActionsAction Attributes are action_id and type.

The basic structure for sending world updates to clientclients is called perceptions.

* Sync perceptions,: thatthese are used to synchronize clients with the server world representation,. thatThis is the only valid sourceway forof knowningknowing world's status.

* Delta perception,: thatthis is used to send only the changes to the world since the last perception.

Actions are sent from the client to the server in order to make theirthe character to doperform an action. In order for the client to know the result of the action the Server needneeds to send ita reply to the client. How will this be done?

OnIn a first tryattempt, we used to send clientclients back an action that was the result of their action. However, butthis makemade the code really hard because we had to update totwo different things, perceptions and actions,. soInstead the ideasolution appearedappears 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 workingdoing makereplies makes it a bit harder toon RPManager but it simplify a lotsimplifies the creation of new clients a lot.

See Actions reply in the Objects documentdocumentation to know exactly what is returned. However, but keep in mind that itthe return result depends of each particular game.

The main idea behind the DPA is not to sendavoid sending ALL the objects to a client each time, but only those that hashave 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:

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

The next step onof the delta perception algorithm is pretty clear: delta² 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.

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.

Worlds in Marauroa can be so big, so huge, that we need to split itthem in to several pieces.

Each of these pieces are what we call an RPZone.

To move from one RPZone to another RPZone you have to code thatthe correct behaviour onin RPRuleProcessor. Just look at any of theour coded examples.

As we have already said, itRPWorld stores several RPZones that are independent of each other.<br>

RPWorld provides onInit and onFinish methods that are called on server initinitialisation 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.

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 resetresets the delta² data.

Each RPZone '''must''' have ana 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 efficientrequire.

But onin the usualmost casecases, if you think the Delta² system is fine and matchmatches your gamegames style, you can use MarauroaRPZone that is our reference implementation of Delta² algorithm.

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)