GameDesign: Difference between revisions

Jump to navigation Jump to search
← Older editNewer edit →
Content deleted Content added
No edit summary
No edit summary
Line 349: Line 349:


=RPManager=
=RPManager=
Last updated: 2003/11/23

The goal of RP Manager is to handle the whole RP game. This means mainly:
The goal of RP Manager is to handle the whole RP game. This means mainly:
- run RPActions from clients
* run RPActions from clients
- manage RPWorld
* manage RPWorld
- control triggers for events
* control triggers for events
- control AI
* control AI


As you see this is a HUGE class that is complex. So the idea is to split this behavior into smaller subclasses.
As you see this is a HUGE class that is complex. So the idea is to split this behavior into smaller subclasses.


RPManager provides a simple interface to the GameManager for using it:
RPManager provides a simple interface to the GameManager for using it:
- addRPAction
* addRPAction
- addRPObject
* addRPObject
- removeRPObject
* removeRPObject
- hasRPObject
* hasRPObject


addRPAction simply queues an action for that player to be executed on the next turn.
addRPAction simply queues an action for that player to be executed on the next turn.
Line 370: Line 368:


The main outline of RPManager could be:
The main outline of RPManager could be:
<pre>

forever
forever
{
{
Line 380: Line 378:
Go to Next Turn
Go to Next Turn
}
}
</pre>
As this part of Marauroa is subject still to development, there are still not many details.


RPScheduler is the class that handles actions to be queued for each player. All the complexity of Action management should be handled here.
RPScheduler is the class that handles actions to be queued for each player. All the complexity of Action management should be handled here.


RuleProcessor is a wrapper class for hide actions code. All the actions code MUST be here, this class also acts as a Action code loader, as some actions are not part of Marauroa, but scripts.
RuleProcessor is a wrapper class for hide actions code. All the actions code MUST be here, this class also acts as a Action code loader, as some actions are not part of Marauroa, but scripts.
Home
⚫
4.g Delta perception Algorithm
Last updated: 2004/04/27



⚫
=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.
The main idea behind the DPA is not to send ALL the objects to client, but only those that has been modified.


Line 394: Line 391:


Traditional method:
Traditional method:
<pre>

- Get objects that our player should see ( 1000 objects )
- Get objects that our player should see ( 1000 objects )
- Send them to player ( 1000 objects )
- Send them to player ( 1000 objects )
Line 402: Line 399:
- Next turn
- Next turn
...
...
</pre>

I hope you see the problem..., we are sending again objects that never changed.
I hope you see the problem..., we are sending again objects that never changed.


The delta perception algorithm:
The delta perception algorithm:
<pre>

- Get objects that our player should see ( 1000 objects )
- Get objects that our player should see ( 1000 objects )
- Reduce the list to the modified ones ( 1000 objects )
- Reduce the list to the modified ones ( 1000 objects )
Line 417: Line 416:
- Next turn
- Next turn
...
...
</pre>

The next step on delta perception algorithm is pretty clear: delta^2 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 delta perception size.
The next step on delta perception algorithm is pretty clear: delta^2 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 delta perception size.


The delta^2 algorithm is based on four containers:
The delta^2 algorithm is based on four containers:


- List of added objects
* List of added objects
- List of modified added attributes of objects
* List of modified added attributes of objects
- List of modified deleted attributes of objects
* List of modified deleted attributes of objects
- List of deleted objects
* List of deleted objects
⚫
An area really related to DPA is RPZone


⚫
An area really related to DPA is RPZone
In order to get the Delta perception algorithm to work correctly you have to play with several parameters:


⚫
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.
- RP Turn Duration
- Relation between TOTAL perception and DELTA perception
- Know your game :)
⚫
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 the same, we send a perception on each turn and every X turns we send a full perception so that clients can synchronize, as UDP is not a secure transport and you can also have new clients joining.


⚫
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.
So the point is to adjust turn duration and relation so that the maximum time a client is out of sync is around 20-30 seconds. Of course, depending of the type of game you may lower or increase this value.


⚫
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. If you skip this part the perception system will only work in Total mode.
Home
⚫
4.h Zones and Worlds
Last updated: 2003/11/28


⚫
=Zones and Worlds=
Objects must be stored somewhere, and we use Zones now to store them. A zone is just a container of Objects.
Objects must be stored somewhere, and we use Zones now to store them. A zone is just a container of Objects.


Line 446: Line 440:


The actual Marauroa RP Zone consists of several data structures:
The actual Marauroa RP Zone consists of several data structures:
- a HashMap of
* a HashMap of RPObject.ID to RPObject
- a List of RPObject
* a List of RPObject
- 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 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.


Actually the perception is the same for all the players on the Zone, on the future we could split the zone into several smaller areas each of them would have its own perception
Actually the perception is the same for all the players on the Zone.


In order to make perceptions work, you have to manually call modify method so that you notify the zone about changes in a character.
In order to make perceptions work, you have to manually call modify method so that you notify the zone about changes in a character.
Home
4.i Action Reply in Objects
Last updated: 2003/11/28

NOTE: This section relates to an early specification of Gladiators and is no longer relevant as it refers to specification, but can help you to know how to make the basic steps to define a game.

As you have read in How Perceptions and Actions works, each Object includes the attributes that are result of the action execution. So for each action we will have:

Action Talk The attributes added to the object are:
- action_talk_text

The action_talk_text contains the text the character has been asked to say. This action is always one turn only, and can never fail.

Action Move The attributes added to the object are:
- action_move_destination
- action_move_speed
- action_move_status

The action_move_destination is the place where the object wants to go when the action ends, and it is as before a Position denoted by , action_move_speed is the assigned speed for the character by the RP. The action_move_status denotes if the action is complete, incomplete or failed. This action is completed when position=destination and fail if destination is unreachable.

Action Get The attributes added to the object are:
- action_get_status

The action_get_status denotes if the action is complete or failed This action is always one turn long.

Action Release The attributes added to the object are:
- action_release_status

The action_release_status denotes if the action is complete or failed This action is always one turn long.

Action Use The attributes added to the object are:
- action_use_status
- (Specific attributes depending on the object)

The action_use_status denotes if the action is complete, incomplete or failed. Usually this action modify attributes of the RPObject instead of adding new attributes.

Action UseWith The attributes added to the object are:
- action_usewith_status
- (Specific attributes depending on the object)

The action_usewith_status denotes if the action is complete, incomplete or failed. Usually this action modify attributes of the RPObject instead of adding new attributes.

Action Exchange The attributes added to the object are:
- action_exchange_status
- action_exchange_timeout


The action_exchange_status denotes if the action is complete, incomplete or failed. This action last several turns until both peers accept or the timeout elapses.


On every object that executed an action you will have a status_= that explains what happened with the action.
Home
4.j Attributes
4.j Attributes
Last updated: 2003/12/22
Last updated: 2003/12/22
Retrieved from "https://meet.konsthol.eu/w/index.php?title=GameDesign"