Inventory, the server killer

2 for 1 day, this post is for what I planned to talk about on both Friday and Saturday.

What is the goal if player inventory? Well here are the things I can think of.

* Collecting - either for a quest, or for personal reasons, collecting objects is an important part of many RPGs. I plan on letting players decorate some personal space such as homes, shops, and ships, so a collection does not have to stop at what can be carried around.

* Stat Manipulation - probably more important than collecting is stats, the backbone of any RPG. Many objects in a game world allow a player to modify their characters by equipping items which are either purchased or found within the game. There are often rules associated with these items and how they affect player stats, but that's for a later discussion.

* Profit - similar to both collecting and stat manipulation, many players collect items for the sole purpose of selling them to either NPCs or other players in the game. By selling they are manipulating the money stat on their character, and so this really is a blending of the two previously mentioned motivations.

Now to satisfy all three if the preceding reasons for having an inventory, we can begin to decide what form it will take.
Inventory, at it's root is nothing more than a list of items with some additional data about their state. (location, equipped, etc...) and because it an have major impact on core game play, it must be managed centrally from the server. We cannot 'Trust' client machines with keeping track of player inventory. In addition storing inventory data on the server has the advantage of character portability, the ability for a player to log in to their character from different client machines, and still have access to their inventory.
So if the inventory must be managed from the server, how do we store it... short answer, in a database. the long answer is what we are here to discuss tonight.

*storage method - there are two basic ways to store data in a database, wide and deep. Wide refers t0 having a single row for the container object (lets say the players backpack) and in that row, enough fields to have a single field for each 'slot' in the container. This means that if a backpack could hold 50 items, then at least 51 fields would be required, one for each item and an additional one for a reference to the container object.
The second method, Deep, means to have a row in the table for each and every item, with data in each row to identify the item and to identify it's container. There would also need to be at least one additional field to describe the items location within the container. (we can skip this info in the wide scenario because we can glean it from the field name.)

*limits - In both of these situations we must store the data, we must transmit the data, and we must manipulate it in memory. because of needing to deal with the data, we need to worry about how much data there could possible be. if every character was given an unlimited 'bag of holding' they would be happy, because they would never need to worry about running out of space. the problem is, the server would. People collect, it happens, and without limits, they would, knowingly or not, kill any server with the volume of things that they would attempt to store. Therefore there must be limits. some games take a very strict number with no growth potential, and others allow a character to grow their total space over time, but in all cases there must be limits.

*details - Items have to be more than just a name, well they should be at least. There are some systems where storing a name alone could be sufficient, but I'm already sure that I'm not going to entertain those.
Details refers to the extra information about each item. for example: weight, size, appearance, cost, durability, stat modifiers, can it be equipped?, who created it, etc...
When we design the item storage method, we need to enumerate everything that need to be stored about the item.

As you can see, inventory is a deep topic that can be solved in any number of ways, I don't have the ultimate answer, but what follows is the current approach that I am taking.

* Storage method - I'm going to use a hybrid approach, deep and wide. I plan on creating not one huge INVENTORY pot for players to dump their stuff into, but segment their available storage into smaller manageable containers.
Equipment - what a character is wearing and what they are holding.
Backpack - a slot within the equipment that can expand what you can hold. My current design gives the character 15 slots without any backpack placed into the slot and the potential of expanding it when a backpack is dropped into the equipment slot reserved for backpacks. (it's really a backpack appearance slot, if the character wants the storage added by an upgraded backpack, but does not want one to show for aesthetic reasons, I could allow them to hide it.)
Bags - a small number of bags can be equipped, probably 4 and each bag type can have a differing number of slots, but still a small number (6 to 12). Some bags may have an appearance when equipped (Fanny pack, pouch, etc...), but most will not.

Each type of container will have it's own table, with the proper number of fields for the slots it contains plus any meta data about the container. with the character's equipment table containing all of the equipped items, including containers.

* Limits - I think the method that I have chosen will make limits happen naturally.

* Details - I will create template items for each possible item type and variation, and then every object can reference a template. This will minimize the space needed per item to store the details.


That's all for tonight, PageFault Out!