In the game, the item storage and backpack system are the most basic modules, because the two are closely related, so they are discussed together here.
Items and backpacks are a broad concept. Items usually include props, materials, quest items, mounts, and pets. Backpacks can be divided into props, material, quest items, mounts, and pets. Sometimes for convenience, props, materials and quest items can be combined in the same backpack, so that props and materials will be stored in the same data structure, although some storage space will be wasted (because materials generally have much less properties than props), but This loss can be reduced by other effective methods (mentioned below). Items and pets are usually stored in different backpacks using two different data structures, because their properties and characteristics are very different. The backpack system will also include some other special-purpose backpacks, such as warehouse (storing items stored by NPCs in the warehouse), sales bar (storing items sold by players to NPCs for easy repurchase) and stalls (storing items in the player's stalls) commodity) etc.
In the following description, we assume that items include props and pets, and backpacks include props backpacks, warehouses, pet slots, sales slots, and stalls.
Items and pets are stored in different data structures. For the convenience of management and use, they can be derived from the same item base class. The item base class holds some common fields, such as the following definitions:
struct Item {
int64_t m_id; // global unique ID
int m_type; // item type (level 1 red medicine, level 2 red medicine, etc.)
int m_kind; // Item kind (props, pets, etc.)
...
};
There are also many types of props, such as materials, equipment, etc. When implementing, unions can be used to define different attributes.
Item data needs to be solidified, that is, stored in the database. For efficiency, many games generally use shared memory and cache to load database data into memory when the server starts. The data in memory is read and modified when the game is in progress. Most of these data are written to the database at regular intervals, while some are written immediately. At the same time, for efficiency reasons, the database storage of items in the game is also different from the general storage, not each item as a row, and each item attribute as a column. Instead, each row stores the item data of one player, with the player ID as the key value, each column is a blob, and a backpack is stored. The backpack item data is stored in fixed length and written in binary form. For example, in our hypothetical case, the item table will include six columns, namely player ID, item backpack column, warehouse column, pet column, sales column and stall column. The backpack data structure is a continuous memory, one backpack grid corresponds to an item data structure on the grid, the m_id of the item data structure of the blank grid is set to INVALID_ID to distinguish, and the item data is stored continuously. The storage method is, for example, the item backpack has a maximum of 100 grids, then the position is the subscript order, and the 0-99 grids are continuously stored, so that each column will be directly mapped to the backpack data structure when loading.
The size of a single item is about 100 bytes, and the pet will reach 300-400 bytes. It does not seem to be large, but the number of various backpack grids added together will reach about 300, and the total space requirement is dozens of K. With more and more players, the total space consumption will be very large. Therefore, variable-length storage can be used, that is, only the grids with items are stored. In this case, the above Item structure needs to add a member variable, such as m_pos, to record the grid where the item is located. At the same time, the backpack data structure is changed to include two parts, header and content. The Header records the current number of items in the backpack, the number of valid grids, the maximum grid number, etc. Content saves all item data of the backpack in the order of m_pos .
There is another layer of consideration. In the game, the movement operation of items is very frequent, especially the operation of organizing the backpack, and a large number of movements will be performed in a short period of time. It is obviously inefficient and logically unreasonable to delete item data from the original position every time it is moved, and then add it to the new position. A natural method is to divide the item data into two pieces, one for index information and one for actual data. The index information structure can be defined as follows:
struct ItemBrief {
int64_t m_id; // global unique ID
int m_kind; // Item kind (props, pets, etc.)
...
};
The actual data can still use the above Item structure. The data table has five index information columns, corresponding to the backpack, warehouse, pet column, sales column, and stall column, and there are two actual data columns, which store props and pet data respectively. The index information and the actual data are associated with m_id, and m_kind is used to determine whether the item is in the item column or the pet column. The index information is stored in a fixed length, and headers can be added for efficiency. The actual data is stored in variable length to save space. In this way, the process of moving or exchanging items can only modify the index information without caring about the actual data. Only when adding, deleting, or merging items, do you care about index information and actual data at the same time.
The above is a brief description of the general design of the module. It does not involve specific design implementation details and skills, but only provides a general understanding and perceptual understanding for readers who are not familiar with game design.
https://blog.csdn.net/boyxiaolong/article/details/22471575