| 1 |
------------------------------- |
| 2 |
THE MANA WORLD INVENTORY SYSTEM |
| 3 |
------------------------------- |
| 4 |
|
| 5 |
1. INTRODUCTION |
| 6 |
2. DATABASE |
| 7 |
3. INVENTORY |
| 8 |
4. EQUIPMENT |
| 9 |
5. IMPLEMENTATION |
| 10 |
6. SPECIAL ITEMS |
| 11 |
7. PROTOCOL |
| 12 |
|
| 13 |
An item will have the following properties: |
| 14 |
|
| 15 |
C means info is used only by the client |
| 16 |
S means info is used only by the server |
| 17 |
C&S means info is used by both |
| 18 |
|
| 19 |
- id (C&S) -> unsigned int |
| 20 |
|
| 21 |
a positive integer uniquely identifying an item. |
| 22 |
|
| 23 |
- image (C) -> unsigned int |
| 24 |
|
| 25 |
used if same images are used for different items. |
| 26 |
Maybe we need more image ids to tell which image (bigger one) to show in |
| 27 |
equipment window or when equipping items in weapon slot. |
| 28 |
|
| 29 |
- name (C) -> char[30] |
| 30 |
|
| 31 |
to be shown in inventory. |
| 32 |
|
| 33 |
- description (C) -> char[100] |
| 34 |
|
| 35 |
a brief description shown in shops, or in the inventory |
| 36 |
|
| 37 |
- type (S) -> unsigned char |
| 38 |
|
| 39 |
server uses it to check if is an item or an equipment and send the |
| 40 |
appropriate packet. |
| 41 |
|
| 42 |
* USABLE_ITEM (food, potions, ...) |
| 43 |
* EQUIPMENT_ITEM (weapons, armors, ...) |
| 44 |
* SLOT_ITEM (cards, materias, summoned beings, ...) |
| 45 |
* SLOTTED_ITEM (bags, small chests, ...) |
| 46 |
|
| 47 |
- identify (S) -> unsigned char |
| 48 |
|
| 49 |
The server will check this flag if the items can be identified by the |
| 50 |
player. |
| 51 |
|
| 52 |
* IDENTIFIED no need to identify the item |
| 53 |
* IDENTIFY_ITEM you can identify it by using a special item |
| 54 |
* IDENTIFY_MAGIC you can identify it by using a particular spell |
| 55 |
* BLACKSMITH needs a blacksmith to be identified |
| 56 |
* WIZARD needs a wizard to be identified (enchanted items) |
| 57 |
* ANCIENT_BLACKSMITH |
| 58 |
* ANCIENT_WIZARD |
| 59 |
* NOT_IDENTIFIABLE reserved for future use |
| 60 |
|
| 61 |
- weight (C&S) -> unsigned short |
| 62 |
|
| 63 |
Used by server to calculate if the being can carry more items. The client |
| 64 |
uses it to display the information to the player. |
| 65 |
|
| 66 |
- # of slots (C&S) -> unsigned char |
| 67 |
|
| 68 |
If this field is greater than 0 it means this one is a slotted item. |
| 69 |
(Probably we can remove SLOTTED_ITEM from the type enumeration) |
| 70 |
For example a bag will have 4 slots, while a chest about 10. |
| 71 |
|
| 72 |
- script (S) -> probably a file name to reference the script file |
| 73 |
or class or name of class object |
| 74 |
|
| 75 |
Script to be executed when item is used/equipped. Events include: |
| 76 |
|
| 77 |
onPickup(Being b) The item is picked up by being b |
| 78 |
onDrop(Being b) The item is dropped by being b |
| 79 |
onUse(Being b) The item is used by being b |
| 80 |
onUseWith(Being b, Object o) The item is used with object o by being b |
| 81 |
onEquip(Being b) The item is equipped by being b |
| 82 |
|
| 83 |
|
| 84 |
3. INVENTORY |
| 85 |
|
| 86 |
Inventory will contain any kind of weapons including non equipped items and |
| 87 |
slotted items. Every being will have a variable number of slots to store items. |
| 88 |
For example a maggot won't have any slot, while players could have a number of |
| 89 |
slots depending on his strength. A pet could have one slot used to add a bag and |
| 90 |
help the player carrying items. |
| 91 |
|
| 92 |
Hammerbear says: I think here we should go all the way with weight approach and |
| 93 |
not have a slot limit. The same could be used for container items, that simply |
| 94 |
have a contents that can hold a certain total weight. Places where slots are |
| 95 |
then used is for equipment, where each slot maps onto a certain body part, and |
| 96 |
possibly certain slotted items that have slots that can only hold a certain |
| 97 |
type of item. |
| 98 |
|
| 99 |
|
| 100 |
4. EQUIPMENT |
| 101 |
|
| 102 |
Every being will have a variable number of slots to equip items. For a human |
| 103 |
player we will have the following slots: |
| 104 |
|
| 105 |
* 0 body |
| 106 |
* 1 hair |
| 107 |
2 head (hat, helmet, etc.) |
| 108 |
3 neck (necklace) |
| 109 |
4 torso (body armour) |
| 110 |
5 right hand (weapons) |
| 111 |
6 left hand (shield, only available with no or one-handed weapon) |
| 112 |
(ammunition, only available with certain weapons) |
| 113 |
7 left ring finger |
| 114 |
8 right ring finger |
| 115 |
9 legs (pants) |
| 116 |
10 feet (shoes) |
| 117 |
|
| 118 |
These slots will composite to form the character graphic. The order of the |
| 119 |
composition is not the same in each direction and some slots do not contribute |
| 120 |
to the final graphic. Draw order for each direction: |
| 121 |
|
| 122 |
left 0, 1, 2, 10, 9, 5, 4, 6 |
| 123 |
right 0, 1, 2, 10, 9, 6, 4, 5 |
| 124 |
up 0, 1, 2, 10, 9, 5, 6, 4 |
| 125 |
down 0, 1, 2, 10, 9, 4, 6, 5 |
| 126 |
|
| 127 |
*) These slots are not under player control, but are merely used by the engine |
| 128 |
so be able to change this as part of the same system. |
| 129 |
|
| 130 |
|
| 131 |
5. IMPLEMENTATION |
| 132 |
|
| 133 |
Since both client and server will only need to store item ids, inventory and |
| 134 |
equipment can be easily coded as unsigned int arrays. The only problem is |
| 135 |
about slotted items. They for sure can't store another slotted item, but it's |
| 136 |
hard to represent them as an int. Probably a more complex structure is needed. |
| 137 |
|
| 138 |
struct ITEM_HOLDER { |
| 139 |
int id; |
| 140 |
int quantity; |
| 141 |
ITEM_HOLDER *item; |
| 142 |
} |
| 143 |
|
| 144 |
ITEM_HOLDER inventory[number_of_slots]; |
| 145 |
ITEM_HOLDER equipment[number_of_slots]; |
| 146 |
|
| 147 |
If item is not NULL it will reference an array of items stored in the slotted |
| 148 |
item. |
| 149 |
|
| 150 |
How to limit the quantity of items? We could have a fixed number of slots in the |
| 151 |
inventory. In one slot you can store only items with the same id (except slotted |
| 152 |
items which need separate slots). When you pick up/receive a new item, total |
| 153 |
weigth you can carry is checked if the item can be stored. |
| 154 |
|
| 155 |
|
| 156 |
6. SPECIAL ITEMS |
| 157 |
|
| 158 |
A special case is represented by arrow holder. Possible solutions: |
| 159 |
|
| 160 |
- Equipment will have a special slot where you can equip only arrows |
| 161 |
(or stones) |
| 162 |
|
| 163 |
- Item with one slot |
| 164 |
|
| 165 |
- Arrows can be simply stored in inventory |
| 166 |
|
| 167 |
- Arrow holder has special slot for items of type "arrow" that can hold up |
| 168 |
to a certain maximum number of arrows. |
| 169 |
|
| 170 |
Weapons can store a limited number of items in their slots. In this kind of |
| 171 |
slots you can store materia, demons or arrows. Some examples, with XML test |
| 172 |
cases based on 4th solution above. |
| 173 |
|
| 174 |
* Arrow holder = max 100 arrows (1 slot) |
| 175 |
|
| 176 |
<item name="Medium quiver" ...> |
| 177 |
<slot type="arrow" max="100"/> |
| 178 |
</item> |
| 179 |
|
| 180 |
* Sword of chaos = max 1 materia + 2 demons (2 slot) |
| 181 |
|
| 182 |
<item name="Sword of chaos" ...> |
| 183 |
<slot type="materia" max="1"/> |
| 184 |
<slot type="demon" max="2"/> |
| 185 |
</item> |
| 186 |
|
| 187 |
* Bag that can hold 5 kg of arbitrary stuff (container). |
| 188 |
|
| 189 |
<item name="Leather bag" weight="1" ... capacity="5"/> |
| 190 |
|
| 191 |
The rationale of being able to carry 5 kg of stuff at the cost of only |
| 192 |
1 kg is that the bag helps you carry the stuff by providing a convenient |
| 193 |
way to hold it. |
| 194 |
|
| 195 |
|
| 196 |
7. PROTOCOL |
| 197 |
|
| 198 |
To be defined. |