RPG mobile game props, items, equipment table design

# # #一, game items/props system data Model design features


In order to make the game more rich, our 1201 team of new mobile game design props system. It enriches the game, pleases the player, and cries for development-the Prop/item data subsystem is simple, complex, and uncertain:


1. Simple, not to say is to select one or more database products, and then define a data model, and then add, delete, change, check.
2. Complex, items/props can be subdivided into equipment, fashion, mounts, gems, buff, and so on, each type of goods have different attribute requirements, so:


+ First item data is the game core data in the largest number of data, the most frequent operation, data structure of the most diverse
+ If you use a data table structure, you will waste a lot of fields or data space (and the item table is very large);
+ If you use a different data table structure, then the game logic will be troublesome, such as items in the player transfer time, modify, discard time.
+ Whether to apply logical layer level segmentation. Splitting the database can be distributed to a number of database servers, then the theoretical data scale will not become a bottleneck, but if the segmentation, prop data analysis, the latter part of the logic will be very complex.
+ equipment, fashion will have multiple attributes, and each piece of equipment of the property value, attribute types are different, how to design data fields (of course, if you use the NoSQL database does not exist this problem).


3. Not sure:


+ with the development and operation of the game, a variety of new props demand will continue to emerge, there may be a need to add new attributes and functional requirements
+ exactly how many items each player will eventually have.
+ The size of the data in the final single zone is hard to predict. We do a very good (of course, development costs are also large) design and development will be a little superfluous, even the boss think more.


# # #二, game items/props system Data Model design objectives and solutions


The above analysis has done, the trough also vomited, still must work well, hehe. According to the specific requirements of our new game, we define the following requirements and solutions for the design of the database table of goods:


Serial number | Requirements | Solving ideas
------| ----- | -----------------------------------
1 | Ensuring the performance of data operations | Take full advantage of caching servers
2 | Reduce the complexity of program development and later customer service work | All kinds of props are not divided into tables
3 | Must be convenient and flexible to support the development of new features of props | Store variable equipment attributes in a field in JSON format
4 | Keep the full scalability | To slice the database table horizontally according to the player ID
5 | Minimizing the difficulty and efficiency of data processing logic in the operation of the zone | Joint primary key with self-growth ID, player ID, and District service ID


# # #三, Specific development design plan
Based on the above analysis results, we summarized the previous game development experience and reference to some of the online articles after the formation of our new mobile game items data subsystem design, development program.


* All data access is encapsulated in the model layer. *


1. Define the Public function Getdb (playerid,areaid) in the model layer of the program for the object data and other data acquisition database (connection) that needs to be segmented by user level.
2. Each item's primary key is composed of itemid,playerid,areaid three fields
3. Unify the equipment buff and a prop specific attribute to save in a varchar field in JSON string form
4. Props table Definition * Failure time * field, this field also represents the validity of the props three kinds of cases:
+ = 0, indicating a permanent prop without limit
+ less than or equal to 600000, indicating the effective time period, such as double experience card effective time 3 hours, then a field value of **180** (minutes), when using this prop, with the current time plus this field is worth to the expiration time stamp modify this field or do other processing
+ greater than 600000, indicating the expiration time stamp of the Prop (Unix timestamp format)
5. Player props Data Inquiry process:
+ First check redis.
+ If there is, return
+ If no queries from the database coexist to Redis, return
6. Modify/or increase the prop data flow:
+ First check redis.
+ if not, query from database to Redis
+ If there is, continue
+ Modify/Add Redis data and record the primary key of the prop in the Redis list data for key "Item_update_list"
+ timed to write back to MySQL according to "Item_update_list" data and clear "item_update_list"
7. Delete a prop data flow:
+ Record the primary key of the prop in the Redis list data of key "Item_delete_list" in Redis
+ DELETE Redis Records
+ timed according to item_delete_list "data delete MySQL records, and clear" item_delete_list "
8. Note:
+ Configure Redis to * * Log record after each update operation * *
+ Cache timed synchronization MySQL handler can be run as a separate process
+ This solution can target other users ' private data, such as skills, buff.


# # #四, summary
database table horizontal partition and cache application is basically the common sense of server-side programmers, when Google search for relevant technical information, most of the blog is written.


This article first on the game props/items data model for a simple demand analysis, and then said the idea and plan, in fact, I would like to express the most is my three design details or ideas:
+ Props data Record primary key design (convenient to close the area)
+ Equipment buff and props-specific property field design (to provide a flexible and convenient data base for the rich functional requirements of props)
+ All prop categories do not distinguish between storage (convenient later customer service inquiries and data statistics)

# # #最后声明:
Actually I am a programmer, hehe.