A lot of people see Excelandjson's first reflection is, this thing in my company also has, then why do I use it?
As a development, every tool exists to speed up the development of the game. So from scratch, from there to the fine. There are and no, good and bad use of the difference, each is more than the previous situation can increase the efficiency of 50%. (according to IPD theory, the limit speed is to increase the efficiency of 100%, here take conservative numbers).
Excelandjson This tool, thinking about it for about a year. In the previous development, we used a lot of similar tools, the number of four or five, if the evaluation phase is considered, is more than 10.
These tools are more or less the same problem. And every problem is a big hole in the development. Let's look at how Excelandjson is providing solutions to these problems.
First, why choose Python development?
If you choose c + +, then you can use QT. But in the field of C + +, there has been no good open source cross-platform Excel parsing library. Either the closed source, or the only support for the old format XLS does not support the new format xlsx, and there is no cross-platform. And these are precisely the characteristics that Excelandjson itself must possess. Hand-tour development, decided to have to cross the platform. An open source project determines that a dependent library must also be open source. The continuous updating of Office determines that the new format must be supported. So, C + + is eliminated.
If you choose JS, because my direction is full stack, currently in the node. js field, NPM I did not find a very useful Excel parsing library. Many libraries are directly reading Excel into a giant JSON object, which I can not accept, too sb. Another reason is that the node. js domain has no usable UI library for future extensibility. In addition, I personally do not like the BS Architecture tool if I look for it in web development. So, JS was eliminated from the exit.
If you choose Java. Java is now in the forefront of mobile game development, has been declining. In the backend, the rapid development direction faces the impact of emerging scenarios (RoR, Python,node.js,go), and the high-performance direction is always but C + +. It's a problem for companies to modify their own maintenance to find the right person (the front-end is almost no Java, and the backend may be someone who does Java). As a result, Java has also been eliminated.
If you choose Python. First, Python is cross-platform. Second, Python learns fast, with 3-5 years of experience, with 3-5 days to get started. Again, Python is very good for file, text, command-line processing, and support. Finally, Python also has handy graphical tools, such as QT, which provides a python version.
So, choose Python.
Second, the role of the array
If there is no array, then the structure of the table will look like this if you encounter a sequence of data, such as designing the skill portion of a monster AI:
length |
skill1 |
skill2 |
Skill3 |
SKILL4 |
4 |
Fireball |
Ice arrows |
Magic Shield |
Smooth shift |
3 |
Sudden sting |
Half Moon |
Re-chop |
|
1 |
Treatment |
|
|
|
If you've ever used a JSON structure like this, you should know that when you fill in the data, it's easy to make mistakes, and it's hard to see when you're outputting data (whether it's filling null as an empty data, or not outputting a blank grid, it's just as ugly.) The former has useless data, the latter loses the structure of the table, causing difficulty in reading, and the traversal code is cumbersome to write.
In JSON, an array is inherently able to get its "number of elements" and can be easily traversed. So, we're going to support arrays at the tool level, so we can use this feature of JSON.
Third, "reference" How to use it?
As an example, in the business building game, the definition of building properties, the unlocking level of each building is a fixed value, and the building occupies a fixed value of the parcel area. However, the properties of different levels of the building are completely dissimilar. If it is a resource to generate buildings, then there will be different resources generation speed and resource limit, if it is a troop-contributing building, there will be a class of classes, troop time. If it is a defensive building, there will be attack radius, damage and so on. The fields of these different structures are not likely to be placed in a two-dimensional table.
The general approach is that there are several scenarios:
1. There will be a primary table that holds the same fields that all buildings contain, and then the different field information is placed in other tables and then accessed through the primary key jump.
2. Directly split into multiple tables to fill in the data
3. Use a number of different switch or category fields, so that the same field has different meanings in different switching states. Now the game is getting more and more complicated, which is the least recommended way.
The above 3 options, maintenance and modification costs are very high.
Using a reference implementation is simple, or multiple tables, and then inserting references to other tables on the primary table.
s |
I |
I |
R |
R |
R |
Name |
Unlock_lv |
Area |
Lv1 |
Lv2 |
Lv3 |
Base |
1 |
4 |
Base. lv1 |
Base. Lv2 |
Base. Lv3 |
Uranium |
3 |
4 |
Uranium ore. lv1 |
Uranium ore. Lv2 |
Uranium ore. Lv3 |
Barracks |
5 |
1 |
Barracks. Lv1 |
Barracks. Lv2 |
Barracks. Lv3 |
Iv. What is the meaning of the main table pattern?
In game development, the front and back end of the data needs are not the same. Front-end needs are some display data, such as resource name, action parameters. The backend needs some computational data, such as attack, defense, damage formula, etc. But there are some data that are needed at both the front and back ends, such as: skill range, skill type, etc., which are related to the display of the front end and the logical computation of the backend.
In this case, in the traditional way, it will be broken into several tables. is usually a table front end, a table back end used. But the question is, what is the data that needs to be handled in front and back? Synchronizing between two tables is a cost-efficient approach.
This reflects the meaning of the main table pattern. We can organize this data on a single table:
name |
type |
effect |
ATK |
slash |
|
|
10 |
annihilation |
|
|
7 |
Snowstorm |
4 |
Blizzard. png |
8 |
Then in the output, in the main Table mode, divided into two to output:
SKILL->SKILL_FN |
name |
type |
effect |
Skill->skill_bn |
Name |
Type |
Atk |
At last
Demand has been changing, and tools are providing flexibility to respond to different needs.
This article is from the "Old G Hut" blog, please make sure to keep this source http://goldlion.blog.51cto.com/4127613/1407007