Thinking on packaging of backpack and equipment module

Due to recent project reasons, the Backpack module is responsible for the equipment module. At first, because the equipment and props to be managed separately, and equipped with random attributes of the problem, the most direct thinking is to generate the way the item UID to differentiate, and through the UID as a map of the primary key to be stored. It's better to think about it now, instead of a map, and use a vector array to store it. The UID only needs to be used as the only indication information of the equipment, and the location information is used as the unique operation location. It may be a little blank to say. Look, the original design is this:

Equipmanager and Itemmanager respectively manage the memory information of props and equipment and the specific operation, and Packagemanager to do the generation of location information, The UID generation sort work does not include a copy of the memory information or the use of Equipmanager and Itemmanager. At first look down there is no big problem, plus because planning will equip, props are divided into two tables and proposed a common base class to Packagemanager provides a common function interface, stored data structure using map method, in order to operate conveniently with UID to master key, take operation also will be very convenient, And can also be installed on the equipment location information of 0, so that the memory information is still maintained in the Equipmanager convenient memory management.

But faced with a few problems.

1. The sorting problem of the knapsack, because the map itself does not have the sort of nature, can not say can not be arranged just no array convenient, so still in the order of time, temporarily put into an array

2. When a backpack item is placed, the location information is generated, the UID is packagemanager to manage, but the UID generation is OK to understand, the generation of location information feels very unnatural.

3.PackageManager actually has some characteristics of itemmanager and Equipmanager, and it just uses the method of call to operate.

Reflection:

1. In order to ensure the flattening of the server class hierarchy and the module independence, packageobj complicates the inheritance tree, and is not a good code example structure. The item and equip should each have their own backpack information data, which corresponds to one by one of the database planning table. Such planned changes or changes to the database are optimized, leaving more room for change, and there is no nesting problem.

2.PackageManager has all the characteristics of both Itemmanager and Equipmanager, except that the logical level of understanding is divided into separate functions. So Packagemanager should be a friend function declaration of Itemmanager and Equipmanager, rather more efficient and more optimized than holding a two object pointer in Packagemanager.

3. The use of a map data structure is obviously not worth the candle. The location information for a backpack is unique to a single player, but the uniqueness of the UID is a logical distinction between the different attributes of the same outfit, facilitating access to other places. When equipped to unload, the player on the body of the equipped lattice array should keep all the information of the equipment, add the appropriate fields in the equipment to do database storage, backpack array will no longer maintain this is not already in the backpack of equipment data. There are several advantages to doing so:

(1), using array sorting is more efficient and convenient than using map sorting

(2), in the selection of role interface, do not need to separate the database, at that time can ensure the pace of database query unity, and do not need to query all the equipment information to do the operation or a single query.

(3), the array capacity directly reflects the size of the backpack, do not need to loop through the map to do statistics

(4), the storage mode of natural with location information, no need for additional algorithm generation, the vacancy is easier to find

(5), the knapsack capacity problem and the vacancy problem are easier to obtain when it comes to the knapsack capacity problem involved in the problem of props stacking, and some unnecessary code is reduced.

Some points to be aware of

(1), cross-border check of array

(2), an array of objects inside the backpack and the object of the rig array on the player are released

(3), the location is repeated troubleshooting

Thinking:

1. Should correspond to the form of the planning form, and give the procedural recommendations. On the basis of ensuring the reading of the planning form, the program should do as much as possible in the abstract and directly relate to the database column design.

2. Pay attention to the flat design of the class, as far as possible inheritance, to prevent subsequent code maintenance inconvenience, "top-heavy" problems

3. Storage memory data structure, not necessarily all of the use of "general" structure, but should be adjusted according to the actual situation, so as to effectively reflect the algorithm level optimization up.

4. Database design as far as possible to consider the anti-paradigm design, the game database is the main thing to do is the landing time of the query, in the course of the game update, delete, insert. However, in the course of the game very few queries, landing query in the case of a multi-sub-table instead of a large case, insert, UPDATE, DELETE, etc. due to database table design anti-paradigm more convenient operation. But the column is obviously increased, but for a single table query than the number of rows of a table in the case of incremental geometry, inverse-paradigm design, through the logical division of vertical table is not necessarily an advantage, such a design also disguised as the Key-value database in the game database superior design way!

Thinking on packaging of backpack and equipment module