GameDesign: Difference between revisions
Jump to navigation
Jump to search
Content deleted Content added
No edit summary |
No edit summary |
||
| Line 294: | Line 294: | ||
Whatever action we choose in GameManager they are Write actions, as the modify the state of the PlayerContainer, but in RP we have two parts, one that build the perceptions that is read only and one that removes idle players that is write, so we must apply two different locks there. |
Whatever action we choose in GameManager they are Write actions, as the modify the state of the PlayerContainer, but in RP we have two parts, one that build the perceptions that is read only and one that removes idle players that is write, so we must apply two different locks there. |
||
=Actions and Objects= |
|||
Last updated: 2003/10/07 |
|||
The whole Marauroa system is managed by two main entities, RPAction and RPObject |
The whole Marauroa system is managed by two main entities, RPAction and RPObject |
||
Actions |
==Actions== |
||
To express the willing of a client to do something it must send the server a MessageC2SAction message. |
To express the willing of a client to do something it must send the server a MessageC2SAction message. |
||
| Line 310: | Line 308: | ||
Optional Actions Attributes: (Read "Actions Explained" for more details.) |
Optional Actions Attributes: (Read "Actions Explained" for more details.) |
||
Objects |
|||
==Objects== |
|||
The containers of information of the whole Marauroa server are RPObjects. An object is composed of several attributes, an attribute is similar to a variable that has a name and contains a value and also it is composed of Slots. A Slot is a container or array of containers that the object has to host other objects inside it. |
The containers of information of the whole Marauroa server are RPObjects. An object is composed of several attributes, an attribute is similar to a variable that has a name and contains a value and also it is composed of Slots. A Slot is a container or array of containers that the object has to host other objects inside it. |
||
Mandatory Object Attributes: id |
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. |
|||
Optional Object Attributes: (Read "Objects Explained" for more details.) |
|||
Home |
|||
4.b Object Explained |
|||
Last updated: 2004/04/27 |
|||
An id is only unique inside the zone which contains that object. |
|||
Objects are the basic Marauroa data structure, and you should already be familiarized with it because you read the Actions and Object document. |
|||
Marauroa engine only enforce that objects has two attributes: |
|||
- id |
|||
- type |
|||
id is an unique identification for the Object and type is the type of the object aka class, so that you can share attributes for all the instances of the class. |
|||
Also engine give special treatment to two types of attributes: |
Also engine give special treatment to two types of attributes: |
||
| Line 332: | Line 322: | ||
- Attributes that begin with # are completely hidden for all the users. |
- Attributes that begin with # are completely hidden for all the users. |
||
===Slots=== |
|||
NOTE: This document 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. |
|||
So let's point the multiple objects that we are going to have in Marauroa and their attributes and slots. Most object share a few attributes. They are: |
|||
- object_id |
|||
- object_type |
|||
- object_look |
|||
- object_position |
|||
The object_id attribute define the unique identifier of the object in the world. The object_type define the type of object it is, for example: human. The object_look would point to the model used to represent this object. The object_position determine where the object is in the world using a X, Y basis Again, we could add the Z value, but it is totally fake, we calculate Z for adjusting character to terrain. |
|||
Object Avatar The avatar is the entity in Marauroa that represent our character and it is the way of handling everything in that world. This object must have also the next set of attributes: |
|||
- object_name |
|||
Also add too the RP attributes that are still to be defined. The object_name is just the name of the character this object is representing. The object has the next slots: |
|||
- left_hand |
|||
- right_hand |
|||
- backpack |
|||
Object Stone A stone is just a little rock used for testing get, release and exchange actions. |
|||
Object Torch A torch is a small piece of wood in form of stick that is used to light on the near area. This object must have the next set of attributes: |
|||
- object_status |
|||
The object_status define if the torch is ON or OFF. |
|||
Object Chest A wooden box with a lock that can be open or closed and can contain items inside. This object must have the next set of attributes: |
|||
- object_status |
|||
- object_forkey |
|||
The object_status define if the chest is OPEN or CLOSED. The object_forkey define the identifier of the key that opens this lock. The object has the next slots: |
|||
- container |
|||
Object Key A small piece of metal that is placed inside the lock to unlock it. This object must have the next set of attributes: |
|||
- object_key |
|||
The object_key define the identifier of the key. |
|||
Home |
|||
4.c Object and Slots |
|||
Last updated: 2003/11/28 |
|||
As you know Objects can contain inside another object 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. |
As you know Objects can contain inside another object 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. |
||
| Line 384: | Line 335: | ||
and we can store objects on these slots. |
and we can store objects on these slots. |
||
Home |
|||
4.d Actions Explained |
|||
Last updated: 2003/10/23 |
|||
Once the object is stored inside the avatar or another object, the only way of accessing it is through the object that contains our stored object. |
|||
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. |
|||
Arianne Game is based on several actions that are a MUST for the correct development of the game. Mainly these actions are: |
|||
- Talk |
|||
- Move |
|||
- Object handling |
|||
- Get |
|||
- Release |
|||
- Use |
|||
- Use with |
|||
- Exchange |
|||
These actions have their own attributes so that they can be useful for the game itself. Let's see these attributes and what each action is intended to be for. As common attributes, every action has the type attribute that express the type of Action that it is, and the sourceid express the object that is casting the action, but this attribute is filled on server rather than in client. |
|||
Action Talk This action is intended to express what the character wants to say. As that it is sent from client to server. Action has this next set of attributes: |
|||
- type |
|||
- sourceid |
|||
- talk_text |
|||
The talk_text attribute is for containing the text that send the client. |
|||
Action Move This action is intended to indicate the willing to move from one point to another point. Action has this set of attributes: |
|||
- type |
|||
- sourceid |
|||
- move_to |
|||
- move_speed |
|||
The move_to is a Position , in the system the Z is a fake, as there is no technology ready for using a huge world with multiple levels. The move_speed is also a meaning the increase of positions per turns. This action should take care of: |
|||
- Collision detection |
|||
- Path finding |
|||
Action Get This action is intended to indicate the action of taking one object from floor. Action has this set of attributes: |
|||
- type |
|||
- sourceid |
|||
- get_objectid |
|||
- get_toSlot |
|||
The get_objectid is the RPObject.ID of the object we want to get and the get_toSlot attribute is the Slot of the character that send the action where the object is placed. This action has several limitations: |
|||
- You can't get players |
|||
- The destination slot must be free |
|||
Action Release This action is the contrary of Get, and it is used to drop an object from a Slot. Action has this set of attributes: |
|||
- type |
|||
- sourceid |
|||
- release_fromSlot |
|||
- release_objectid |
|||
The release_fromSlot is the slot that contains the object pointed by release_objectid. The only limitation of this action is that of course the object MUST be there. |
|||
Action Use This action makes the object to perform the expected action from them. This action is a real good candidate for scripting. Action has this set of attributes: |
|||
- type |
|||
- sourceid |
|||
- use_objectid |
|||
The use_objectid attribute point the object to use. By now we will only have one default Use, later we can add extra attributes to the action. |
|||
Action UseWith This action is closely related with Use action, the difference is that we use ObjectA with ObjectB so that the state of ObjectA is modified, ObjectB may be modified as well. Action has this set of attributes: |
|||
- type |
|||
- sourceid |
|||
- usewith_objectidA |
|||
- usewith_objectidB |
|||
The usewith_objectidA refers to the Object that is the center of the action and usewith_objectidB is the catalyzer of the action. For example a door and a key respectively. |
|||
Action Exchange This action is use to exchange an object between two characters. Action has this set of attributes: |
|||
- type |
|||
- sourceid |
|||
- exchange_sourceSlot |
|||
- exchange_destObjectid |
|||
- exchange_destSlot |
|||
The exchange_sourceSlot is the slot of the source character that owns one of the objects and the exchange_destObjecid is the other object and exchange_destSlot is the slot where the other object is. The action MUST be executed by both peers on the same terms so they agree and the action is executed. |
|||
Action replies are placed inside Objects and sent to clients as perceptions, so please refer to the Action reply in "Objects Explained" document. |
|||
Home |
|||
4.e How Perceptions and Actions work |
|||
Last updated: 2004/04/27 |
|||
= 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 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? |
||
| Line 473: | Line 347: | ||
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 Objects document to know exactly what is returned, but keep in mind that it depends of each particular game. |
||
Home |
|||
=RPManager= |
|||
Last updated: 2003/11/23 |
Last updated: 2003/11/23 |
||