GameDesign: Difference between revisions
Content deleted Content added
No edit summary |
No edit summary |
||
Line 349:
=RPManager=
The goal of RP Manager is to handle the whole RP game. This means mainly:
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:
addRPAction simply queues an action for that player to be executed on the next turn.
Line 370 ⟶ 368:
The main outline of RPManager could be:
<pre>
forever
{
Line 380 ⟶ 378:
Go to Next Turn
}
</pre>
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.
4.g 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.
Line 394 ⟶ 391:
Traditional method:
<pre>
- Get objects that our player should see ( 1000 objects )
- Send them to player ( 1000 objects )
Line 402 ⟶ 399:
- Next turn
...
</pre>
I hope you see the problem..., we are sending again objects that never changed.
The delta perception algorithm:
<pre>
- Get objects that our player should see ( 1000 objects )
- Reduce the list to the modified ones ( 1000 objects )
Line 417 ⟶ 416:
- 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 delta^2 algorithm is based on four containers:
An area really related to DPA is RPZone▼
▲An area really related to DPA is RPZone
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
▲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
▲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.
4.h Zones and Worlds▼
Objects must be stored somewhere, and we use Zones now to store them. A zone is just a container of Objects.
Line 446 ⟶ 440:
The actual Marauroa RP Zone consists of several data structures:
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
In order to make perceptions work, you have to manually call modify method so that you notify the zone about changes in a character.
4.j Attributes
Last updated: 2003/12/22
| |||