Game script data processing method

Abstract

The invention discloses a game script data processing method, and relates to the field of game script data processing, and the method comprises the steps: wrong data collection: employing Flume to carry out multi-source centralized collection and send the collected data to a unified destination by utilizing the feature difference of a normal log and an error log, and carrying out the preprocessing of a data source of the unified destination, useless information is removed, so that storage space occupation is reduced, and processing efficiency is improved; classification of the collected data: carrying out data classification on the collected data sources subjected to duplicate removal based on the Bayesian theorem; processing various types of data: performing targeted processing on the classified data sources by adopting a corresponding mode; and optimization of daily problems: evaluating and optimizing methods corresponding to processing of various data at regular intervals to improve the efficiency and accuracy of the methods. According to the method, the error logs in the game script are automatically collected, preprocessed and classified on the basis of a simple and easy-to-construct mode, so that the rear end can better process potential errors in the game.

Description

Technical Field

[0001] The present invention mainly relates to the technical field of game script data processing, and specifically provides a method for processing game script data. Background Art

[0002] The processing of game script data is of great significance in game development and operation. Game scripts can monitor game data in real time, such as player behavior, game status, etc., and provide timely feedback to players by analyzing this data. For example, in competitive games, the script can monitor players' operation habits and skill usage efficiency, and provide personalized optimization suggestions to players, thereby enhancing their gaming experience. Game scripts can also help developers quickly locate problems existing in the game, such as BUGs, performance bottlenecks, etc. By analyzing error logs and abnormal data, developers can quickly find the root cause of the problem and take corresponding measures for repair and optimization.

[0003] In the prior art, developers have overlooked the importance of error log collection. For error logs, when players encounter error logs during gameplay, usually for the sake of gameplay time, they will also choose to ignore the error logs in the game, which makes many potential errors in the game itself go unnoticed. Summary of the Invention

[0004] Based on this, the purpose of the present invention is to provide a method for processing game script data to solve the technical problems proposed in the above background art.

[0005] To achieve the above purpose, the present invention provides the following technical solutions:

[0006] A method for processing game script data, comprising the following steps:

[0007] S1. Collection of error data: Utilize the characteristic differences between normal logs and error logs, and adopt Flume for multi-source centralized collection and send it to a unified destination, and preprocess the data source at the unified destination to remove useless information, so as to reduce storage space occupation and improve processing efficiency;

[0008] S2. Classification of the collected data: Classify the collected and deduplicated data sources based on Bayes' theorem; the data classification includes runtime errors, compatibility issues, errors caused by external factors, syntax errors, and logical errors;

[0009] S3. Processing of various types of data: Adopt corresponding countermeasures to process the classified data sources in a targeted manner;

[0010] S4. Optimization of daily problems: Regularly evaluate and optimize the methods corresponding to the processing of various types of data to improve their efficiency and accuracy.

[0011] Preferably, the characteristic differences between the normal logs and the error logs are specifically as follows: content nature, log level, frequency and importance, format and readability;

[0012] In terms of the content nature, the characteristics of the normal logs are recording the normal running status of the game, user operations, and system call information; the characteristics of the error logs are recording the exceptions, errors, or crashes that occur during the game operation.

[0013] In terms of the log level, the characteristics of the normal logs are containing lower-level information, and the characteristics of the error logs are containing higher-level information;

[0014] In terms of the frequency and importance, the characteristics of the normal logs are that the generation frequency is usually higher, and the characteristics of the error logs are that the generation frequency is relatively lower;

[0015] In terms of the format and readability, the characteristics of the normal logs are the comprehensiveness and detail of the information, and the characteristics of the error logs are that the content is concise and has a clear format and tags.

[0016] Preferably, Flume is a log collection, aggregation, and transmission system; the core of Flume is the Agent, which is composed of three components: Source, Channel, and Sink;

[0017] The Source is used to receive the data source and pass the data source to the Flume Agent;

[0018] The Channel is used as a buffer between the Source and the Sink, allowing the Source and the Sink to operate at different rates;

[0019] The Sink is responsible for continuously polling the data sources in the Channel and removing and sending these data sources to the unified destination in batches.

[0020] Preferably, the useless information includes duplicate logs and test logs; the method of removing the duplicate logs is to build a hash table; the running logic steps of the hash table are as follows:

[0021] Step 1: Create an empty hash table;

[0022] Step 2: Traverse each data item in the game script data source;

[0023] Step 3: Calculate the hash value for each data source and add the hash value to the hash table;

[0024] Step 4: After the traversal, what remains in the hash table is the non-duplicate data source.

[0025] Preferably, in step three, if the hash value a already exists in the hash table, when the next data source with the same hash value a appears, the data source with the same hash value a is ignored and only counting is performed;

[0026] If the hash value does not exist in the hash table, it will be directly added to the hash table;

[0027] If the hash value does not exist in the hash table, it is added to the hash table.

[0028] Preferably, during the operation of the hash table, in order to avoid the possibility of hash collision, double hashing is adopted, that is, two hash functions are used, one for determining the initial position and the other for determining the step size of the probing sequence; the function expression is as follows:

[0029] f(i) = (hash1(key) + i·hash2(key)) mod m

[0030] Among them,

[0031] hash1(key): is the first hash function for determining the initial position;

[0032] hash2(key): is the second hash function for generating the step size of the probing sequence;

[0033] i: is the number of attempts already made;

[0034] m: is the size of the hash table.

[0035] Preferably, the expression of the Bayes' theorem is as follows;

[0036]

[0037] Among them,

[0038] P((C|F1,F2,...,F n )): represents the probability that the data source belongs to category C given the features F1,F2,...,F n ;

[0039] P(C): represents the probability that the data source belongs to category C before considering any feature information;

[0040] P(F i |C); represents the probability that the feature F i occurs given that the data source belongs to category C;

[0041] P(F1,F2,...,F n ): represents the features F1,F2,...,F nThe probability of simultaneous occurrence, without considering their association with any classification C.

[0042] Preferably, the P(F1,F2,...,F n ) In actual calculation, when classifying the deduplicated data source, when comparing the posterior probabilities of different classifications C, P(F1,F2,...,F n ) are all the same. Therefore, in actual calculation, the P(F1,F2,...,F n ) in the denominator part can be omitted, and only the numerator needs to be compared That's all.

[0043] Preferably, the coping methods in S3 are specifically as follows:

[0044] For runtime errors, the coping method is to check the resource access permissions and network connection status to ensure the normal operation environment;

[0045] For compatibility issues, the coping method is to update the game script, operating system, software, and plugins to the latest version;

[0046] For errors caused by external factors, the coping method is to check the network settings and the status of third-party services to ensure that external factors do not affect the normal operation of the game script

[0047] For syntax errors, the coping method is to carefully check the game script code and use the syntax highlighting and error-checking functions of the code editor and IDE

[0048] For logic errors, the coping method is to verify the correctness of the script logic through unit testing and integration testing.

[0049] Preferably, the optimization of subsequent problems in S4 specifically further includes:

[0050] S41. Set up a feedback system in the game and an official communication channel for players outside the game, and collect players' feedback through the in-game feedback system and the official communication channel for players;

[0051] S42. According to the feedback and self-checking and self-repairing, the repaired game version needs to undergo strict testing and verification to ensure its stability and reliability before being released to players.

[0052] In summary, the present invention mainly has the following beneficial effects:

[0053] Enhance user experience and respond to problems quickly: By analyzing error logs in a timely manner, the development team can quickly locate and resolve issues that occur in the game, reducing the frequency of users encountering errors or abnormal situations, thereby enhancing the overall user experience; Clear feedback: When an error occurs in the game, users often expect to receive clear feedback and solutions; Actively processing error logs helps the development team provide more specific and targeted error information and repair suggestions to users;

[0054] Enhance game stability and prevent crashes: Unhandled errors may cause the game to crash or become unstable, affecting the normal gameplay of players; By actively processing error logs, the development team can promptly discover and fix potential crash points, enhancing the stability of the game; Optimize performance: Error logs may contain issues related to game performance, such as resource leaks, memory overflows, etc.; By analyzing and resolving these problems, the performance of the game can be optimized, improving the smoothness and response speed of the game;

[0055] Facilitate troubleshooting and repair, detailed records: Error logs detail information such as the time, location, and cause of errors, providing valuable clues for the development team to troubleshoot. By carefully analyzing this information, the development team can more quickly locate the root cause of the problem and take corresponding repair measures; Reduce repair time: Actively processing error logs can shorten the time cycle for troubleshooting and repair, reducing the risk of user churn caused by game failures;

[0056] Secondly, this method has a clear processing logic and at the same time adopts an intuitive and simple processing method to process the error logs in the game script data in sequence, thereby achieving the above advantages. Brief Description of the Drawings

[0057] Figure 1 For the present invention. Detailed Embodiments

[0058] Next, the technical solutions in the embodiments of the present invention will be clearly and completely described in conjunction with the drawings in the embodiments of the present invention.

[0059] Embodiment

[0060] As Figure 1 shown, it includes the following steps:

[0061] S1. Collection of error data: Utilize the characteristic differences between normal logs and error logs, and use Flume to perform multi-source centralized collection and send it to a unified destination, and preprocess the data source at the unified destination to remove useless information, so as to reduce storage space occupation and improve processing efficiency;

[0062] The specific characteristic differences between normal logs and error logs are as follows: content nature, log level, frequency and importance, format and readability;

[0063] In terms of content nature, the characteristics of normal logs are to record the normal running status of the game, user operations, and system call information; the characteristics of error logs are to record exceptions, errors, or crash information that occur during the game running process;

[0064] In terms of log level, the characteristics of normal logs are to contain lower-level information, and the characteristics of error logs are to contain higher-level information;

[0065] In terms of frequency and importance, the characteristics of normal logs are that the generation frequency is usually higher, and the characteristics of error logs are that the generation frequency is relatively lower;

[0066] In terms of format and readability, the characteristics of normal logs are the comprehensiveness and detail of information, and the characteristics of error logs are that the content is concise, with a clear format and tags;

[0067] Flume is a log collection, aggregation, and transmission system; the core of Flume is the Agent, which consists of three components: Source, Channel, and Sink;

[0068] The Source is used to receive data sources and pass the data sources to the Flume Agent;

[0069] The Channel is used as a buffer between the Source and the Sink, allowing the Source and the Sink to operate at different rates;

[0070] The Sink is responsible for continuously polling the data sources in the Channel and removing and sending these data sources to a unified destination in batches;

[0071] Useless information includes duplicate logs and test logs; to remove duplicate logs, a hash table is constructed; the running logic steps of the hash table are as follows:

[0072] Step 1: Create an empty hash table;

[0073] Step 2: Traverse each data item in the game script data source;

[0074] Step 3: Calculate the hash value for each data source and add the hash value to the hash table;

[0075] Step 4: After the traversal, the remaining data sources in the hash table are the non-duplicate ones;

[0076] 11. In step 3, if the hash value a already exists in the hash table, when the next data source with the same hash value a appears, the data source with the same hash value a is ignored and only counting is performed;

[0077] If the hash value does not exist in the hash table, it will be directly added to the hash table;

[0078] If the hash value does not exist in the hash table, it will be added to the hash table;

[0079] During the operation of the hash table, in order to avoid the possibility of hash collision, double hashing is adopted, that is, two hash functions are used, one for determining the initial position and the other for determining the step size of the probing sequence; the function expression is as follows:

[0080] f(i) = (hash1(key) + i·hash2(key)) mod m

[0081] where,

[0082] hash1(key): is the first hash function for determining the initial position;

[0083] hash2(key): is the second hash function for generating the step size of the probing sequence;

[0084] i: is the number of attempts already made;

[0085] m: is the size of the hash table.

[0086] It should be noted that in this embodiment, during the process of processing the error logs in the game script data, through the comparison of a large number of game log data in the test, the characteristic differences between the normal logs and the error logs are found;

[0087] There are significant characteristic differences between the error logs and the normal logs of the game in many aspects; the following is a detailed analysis of these characteristic differences:

[0088] Characteristics of error logs;

[0089] Nature of content:

[0090] Error logs mainly record the exceptions, errors or crash information that occur during the game operation; these information are usually directly related to the instability of the game, performance issues, resource loading failures, script errors, etc.;

[0091] Error logs often contain detailed information such as error codes, error descriptions, stack traces, etc., which are used to help developers quickly locate the cause of the problem;

[0092] Log level:

[0093] The levels of error logs are usually relatively high, such as Error, Fatal, etc., indicating that these problems have a greater impact on the normal operation of the game;

[0094] In contrast, normal logs may contain lower-level information, such as Info, Debug, etc., for recording the normal operation status or debugging information of the game;

[0095] Frequency and importance:

[0096] The generation frequency of error logs is relatively low, but each record is very important because they directly point to the problems that need to be solved;

[0097] Format and readability:

[0098] Error logs usually have a clear format and tags for developers to quickly identify and parse;

[0099] For example, error logs may contain information such as timestamps, error types, error codes, error descriptions, and stack traces. These information are presented in a structured way, improving readability;

[0100] Characteristics of normal logs;

[0101] Nature of content:

[0102] Normal logs may contain a large amount of information, mainly recording the normal operation status of the game, user operations, system calls, etc. These information are for monitoring the health status of the game, user behavior analysis, and performance tuning;

[0103] Log level:

[0104] The levels of normal logs may cover multiple levels, such as Info, Debug, etc., for recording information at different levels;

[0105] Logs at the Info level are usually used to record key operations or status changes of the game, while logs at the Debug level contain more detailed debugging information;

[0106] Frequency and importance:

[0107] The generation frequency of normal logs is usually high because the game generates a large amount of normal operations and information during operation;

[0108] Although these information are not necessary for the normal operation of the game, they are very useful for monitoring and tuning the game;

[0109] Format and readability:

[0110] Normal logs also have a certain format and tags to ensure the clarity and orderliness of the information;

[0111] However, compared with error logs, normal logs may focus more on the comprehensiveness and detail of information for subsequent analysis and mining;

[0112] Based on the characteristic differences between normal logs and error logs obtained through analysis, it provides effective help when using Flume to collect error logs. Flume itself is already a simple, fast, and effective way. By writing the characteristics of the collected data sources, the operation of Flume becomes smoother;

[0113] When using Flume to collect error logs, it is necessary to download the Flume installation package and extract it to the specified directory; configure the JDK path and environment variables; write the configuration file of the Flume Agent, specify the parameters of the Source, Channel, and Sink, and start the Flume Agent for data transmission;

[0114] Through continuous collection by Flume, error logs can be selected, collected, and stored in a unified destination from a large amount of data sources. At this time, the error log data in the unified destination is messy and disordered, containing useless information, especially duplicate logs. It will occupy the storage space of the unified destination and lead to slower subsequent processing efficiency. To solve this problem, we adopt the construction of a "hash table".

[0115] In the simulation experiment, it is found that due to hash collisions in a small part of the duplicate logs, further we adopt double hashing to avoid collisions. Therefore, two hash functions are set, one for determining the initial position and the other for determining the step size of the probing sequence; successively, create an empty hash table; traverse each data item in the game script data source; calculate the hash value for each data source and add the hash value to the hash table; after the traversal, what remains in the hash table is the non-duplicate data source, that is, the non-duplicate error logs;

[0116] Among them, if the hash value already exists in the hash table, that is, there is the same data source, then ignore this data source and only count; if the hash value does not exist in the hash table, then add it to the hash table;

[0117] So far, we have solved the problem of duplicate error logs.

[0118] As Figure 1 shown, S2. Classification of collected data: Classify the deduplicated data sources collected based on Bayes' theorem; data classification includes runtime errors, compatibility issues, errors caused by external factors, syntax errors, and logical errors;

[0119] The expression of Bayes' theorem is as follows;

[0120]

[0121] Among them,

[0122] P((C|F1,F2,...,F n )): represents the probability that the data source belongs to classification C given the features F1, F2,..., F n ;

[0123] P(C): represents the probability that the data source belongs to classification C before considering any feature information;

[0124] P(F i |C); represents the probability that feature F i occurs given that the data source belongs to classification C;

[0125] P(F1,F2,...,F n ): represents the probability that features F1, F2,..., F n occur simultaneously, without considering their association with any classification C;

[0126] P(F1,F2,...,F n ) In actual calculation, when classifying the deduplicated data source and comparing the posterior probabilities of different classifications C, P(F1,F2,...,F n ) is the same. Therefore, in actual calculation, the denominator part of P(F1,F2,...,F n ) can be omitted, and only the numerator needs to be compared.

[0127] It should be noted that in this embodiment, next, in order to make the error logs of the unified destination orderly and facilitate the work of backend maintenance personnel,

[0128] When using Bayes' theorem to solve classification problems, since Bayes' theorem itself requires the premise that the assumed features are independent of each other, in order to take this premise into account, when formulating the classification, the premise is considered; it is divided into seven classifications, including runtime errors, compatibility issues, errors caused by external factors, syntax errors, and logical errors; for each type, we consider its unique features to avoid non - independent situations during classification;

[0129] As an auxiliary explanation, in syntax errors: 1. Spelling mistakes, such as misspelling keywords, variable names, function names, etc. in the script; 2. Punctuation errors: such as missing parentheses, mismatched quotes, improper use of semicolons, etc.; 3. Syntax structure errors: such as improper use of the syntax of control structures (if, for, while, etc.).

[0130] Logical errors include: 1. Conditional expression errors, where incorrect conditional judgment statements are written, resulting in unexpected logical execution; 2. Loop errors, where loop conditions are set improperly, leading to too many, too few, or unending loop iterations; 3. Data processing errors, where there are errors in the data processing logic, such as calculation errors and type conversion errors.

[0131] Runtime errors include: 1. Resource access errors, such as attempting to access non-existent files, database connection failures, and network request timeouts; 2. Memory leaks, where long-term operation leads to insufficient memory, affecting game stability and performance; 3. Thread conflicts: In a multi-threaded or multi-process environment, resource competition, deadlocks, and other issues cause abnormal script execution.

[0132] Compatibility issues include: 1. System compatibility, where game scripts are incompatible with the operating system version, resulting in runtime errors; 2. Software compatibility, where game scripts conflict with other software or plugins and cannot run properly; 3. Hardware compatibility, where some game scripts have requirements for hardware configuration, and if the hardware does not meet the requirements, they may not run properly.

[0133] Errors caused by external factors include: 1. Network problems: Network latency, interruption, or configuration errors cause network request failures; 2. Third-party service problems, where issues occur with third-party services (such as APIs, cloud services, etc.) that game scripts depend on; 3. Incorrect user operations: Illegal data input or illegal operations by users cause script errors.

[0134] From the unique characteristics of each of the seven categories, it can be seen that the seven classifications above can achieve independence among features.

[0135] Based on this, using the operation logic of Bayes' theorem, that is, based on the concept of conditional probability, which is the probability of an event given that another event has already occurred; this simple logical method can be used to complete the classification of error logs in a unified target location.

[0136] As Figure 1 shown, S3. Processing of various data: Targeted processing is carried out on the classified data sources using corresponding methods.

[0137] S4. Optimization of daily problems: Regularly evaluate and optimize the methods corresponding to the processing of various data to improve their efficiency and accuracy.

[0138] The corresponding methods in S3 are specifically as follows:

[0139] For runtime errors, the corresponding method is to check resource access permissions and network connection status to ensure a normal operating environment.

[0140] Regarding compatibility issues, the solution is to update the game scripts, operating systems, software, and plugins to the latest versions;

[0141] Regarding errors caused by external factors, the solution is to check the network settings and the status of third-party services to ensure that external factors do not affect the normal operation of the game scripts.

[0142] Regarding syntax errors, the solution is to carefully check the game script code and use the syntax highlighting and error-checking functions of code editors or IDEs.

[0143] Regarding logical errors, the solution is to verify the correctness of the script logic through unit testing, integration testing, etc.;

[0144] S4. The specific optimizations for subsequent problems also include:

[0145] S41. Set up a feedback system in the game and an official communication channel for players outside the game, and collect players' feedback through the in-game feedback system and the official communication channel for players.

[0146] S42. According to the feedback and self-checking and self-repairing, the repaired game version needs to undergo strict testing and verification to ensure its stability and reliability before being released to players.

[0147] It should be noted that in this embodiment, when analyzing and processing error logs, opening different error logs in seven categories can achieve targeted processing;

[0148] Furthermore, this kind of ordered classification also facilitates subsequent accumulation of error logs, making them the base data for backend maintenance personnel to build a prediction model. After completing the construction of the prediction model, it is more convenient to predict error logs in game script data later, achieving the purpose of avoiding problems from the beginning in front-end development;

[0149] The collection of error logs is not limited to being collected by the built-in system of game developers. It can also set up a feedback system in the game and an official communication channel for players outside the game, and collect players' feedback through the in-game feedback system and the official communication channel for players.

[0150] For the collected error logs, the processing and optimization of coping methods are mainly as follows:

[0151] Syntax errors: Carefully check the script code and use the syntax highlighting and error-checking functions of code editors or IDEs;

[0152] Logical errors: Verify the correctness of the script logic through unit testing, integration testing, etc.;

[0153] Runtime error: Check resource access permissions, network connection status, etc. to ensure a normal operating environment;

[0154] Compatibility issues: Update game scripts, operating systems, software, or plugins to the latest version, or find alternative solutions;

[0155] Errors caused by external factors: Check network settings, third-party service status, etc. to ensure that external factors do not affect the normal operation of the script;

[0156] Based on feedback and self-checking and self-repairing, the repaired game version needs to undergo strict testing and verification to ensure its stability and reliability before being released to players.

[0157] The working principle of the present invention is as follows:

[0158] During the process of processing error logs in game script data, through comparison of a large amount of game log data in testing, the characteristic differences between normal logs and error logs are found;

[0159] There are significant characteristic differences between the error logs and normal logs of the game in multiple aspects; the following is a detailed analysis of these characteristic differences:

[0160] Characteristics of error logs;

[0161] Nature of content:

[0162] Error logs mainly record exceptions, errors, or crash information that occur during the operation of the game; this information is usually directly related to game instability, performance issues, resource loading failures, script errors, etc.;

[0163] Error logs often contain detailed information such as error codes, error descriptions, stack traces, etc., which are used to help developers quickly locate the cause of the problem;

[0164] Log level:

[0165] The level of error logs is usually relatively high, such as Error, Fatal, etc., indicating that these problems have a greater impact on the normal operation of the game;

[0166] In contrast, normal logs may contain lower-level information, such as Info, Debug, etc., which are used to record the normal operating state of the game or debugging information;

[0167] Frequency and importance:

[0168] The generation frequency of error logs is relatively low, but each record is very important because they directly point to the problems that need to be solved;

[0169] Format and readability:

[0170] Error logs usually have a clear format and tags to facilitate quick identification and parsing by developers;

[0171] For example, error logs may contain information such as timestamps, error types, error codes, error descriptions, and stack traces, which are presented in a structured manner to improve readability;

[0172] Characteristics of normal logs;

[0173] Nature of content:

[0174] Normal logs may contain a large amount of information, mainly recording the normal running status of the game, user operations, system calls, etc. This information is useful for monitoring the health status of the game, user behavior analysis, and performance tuning;

[0175] Log levels:

[0176] The levels of normal logs may cover multiple levels, such as Info, Debug, etc., for recording information at different levels;

[0177] Logs at the Info level are usually used to record key operations or state changes of the game, while logs at the Debug level contain more detailed debugging information;

[0178] Frequency and importance:

[0179] The generation frequency of normal logs is usually high because a large number of normal operations and information are generated during the running of the game;

[0180] Although this information is not essential for the normal running of the game, it is very useful for monitoring and tuning the game;

[0181] Format and readability:

[0182] Normal logs also have a certain format and tags to ensure the clarity and orderliness of information;

[0183] However, compared with error logs, normal logs may focus more on the comprehensiveness and detail of information for subsequent analysis and mining;

[0184] Based on these characteristic differences between normal logs and error logs obtained through analysis, it provides effective help when using Flume to collect error logs. Flume itself is already a simple, fast, and effective way, and by writing the characteristics of the collected data sources, it makes the operation of Flume smoother;

[0185] When using Flume to collect error logs, it is necessary to download the Flume installation package and extract it to the specified directory; configure the JDK path and environment variables; write the configuration file for the Flume Agent, specify the parameters of the Source, Channel, and Sink, and start the Flume Agent for data transmission; the following shows an example of collecting a certain port A and printing the received data to a unified destination;

[0186] # Define components

[0187] a1.sources=r1

[0188] a1.sinks=k1

[0189] a1.channels=c1

[0190] # Configure source

[0191] a1.sources.r1.type=netcat

[0192] a1.sources.r1.bind=localhost

[0193] a1.sources.r1.port=A

[0194] # Configure sink

[0195] a1.sinks.k1.type=logger

[0196] # Configure channel

[0197] a1.channels.c1.type=memory

[0198] a1.channels.c1.capacity=1000

[0199] a1.channels.c1.transactionCapacity=100

[0200] # Bind source and sink to channel

[0201] a1.sources.r1.channels=c1

[0202] a1.sinks.k1.channel=c1

[0203] Through Flume's continuous collection, error logs can be selected, collected and stored in a unified destination from a large number of data sources. At this time, the error log data in the unified destination is messy and disordered, and contains useless information, especially duplicate logs, which will occupy the storage space of the unified destination and slow down the subsequent processing efficiency. To solve this problem, we use the construction of a "hash table"

[0204] In simulation experiments, we found that hash collisions existed in a small number of duplicate logs. Therefore, we adopted a double hashing approach to avoid collisions. We set up two hash functions: one to determine the initial position and the other to determine the step length of the exploration sequence. This process involved creating an empty hash table, traversing each data item in the game script data source, calculating a hash value for each data source, and adding the hash value to the hash table. After the traversal, the only data left in the hash table were unique data sources, i.e., unique error logs.

[0205] Among them, if the hash value already exists in the hash table, that is, the same data source exists, then the data source is ignored and only counted; if the hash value does not exist in the hash table, then it is added to the hash table;

[0206] So far, we have solved the problem of duplicate error logs. Next, in order to make the error logs in a unified destination more organized and easier for backend maintenance personnel,

[0207] When Bayes' theorem is used to solve classification problems, it assumes that features are independent of each other. To account for this, we consider this assumption when formulating the classification. We divide the classification into seven categories, including runtime errors, compatibility issues, errors caused by external factors, syntax errors, and logical errors. We consider the unique characteristics of each category to avoid non-independence when classifying.

[0208] As an auxiliary explanation, grammatical errors include: 1. Spelling errors, such as spelling errors of keywords, variable names, function names, etc. in the script; 2. Punctuation errors: such as missing brackets, mismatched quotation marks, improper use of semicolons, etc.; 3. Syntactic errors: such as improper use of the syntax of control structures (if, for, while, etc.);

[0209] Logical errors include: 1. Incorrect conditional expressions, incorrectly written conditional statements, resulting in unintended logical execution; 2. Loop errors, improper loop conditions, resulting in excessive or insufficient loops or inability to complete loops; 3. Data processing errors, incorrect data processing logic, such as calculation errors, type conversion errors, etc.

[0210] Runtime errors include: 1. Resource access errors, such as attempting to access a non-existent file, database connection failure, network request timeout, etc.; 2. Memory leaks, which can lead to insufficient memory after long-term operation, affecting the stability and performance of the game; 3. Thread conflicts: In a multi-threaded or multi-process environment, issues such as resource competition and deadlocks can cause abnormal script execution;

[0211] In terms of compatibility issues: 1. System compatibility, where the game script is incompatible with the operating system version, resulting in runtime errors; 2. Software compatibility, where the game script conflicts with other software or plugins and cannot run properly; 3. Hardware compatibility, as some game scripts have requirements for hardware configuration, and if the hardware does not meet the requirements, they may not run properly;

[0212] Errors caused by external factors include: 1. Network problems: Network latency, interruption, or configuration errors resulting in network request failures; 2. Third-party service problems, where issues occur with third-party services (such as APIs, cloud services, etc.) that the game script depends on; 3. Improper user operations: Illegal data input or illegal operations by users causing script errors;

[0213] From the unique characteristics of each of the seven categories, it can be seen that the seven classifications above can achieve independence between features;

[0214] Based on this, using the operation logic of Bayes' theorem, that is, based on the concept of conditional probability, which is the probability of an event given that another event has already occurred; this simple logical method can be used to complete the classification of error logs in a unified target;

[0215] When backend maintenance personnel analyze and process error logs, opening different error logs in the seven classifications can achieve targeted processing;

[0216] Furthermore, this ordered classification also facilitates subsequent accumulation of error logs, making them the base data for backend maintenance personnel to build a prediction model. After completing the construction of the prediction model, it is more convenient to predict error logs in game script data, achieving the goal of avoiding problems from the start in front-end development;

[0217] The collection of error logs is not limited to being collected by the embedded system of game developers. A feedback system can also be set up in the game, and an official communication channel for players can be set up outside the game to collect players' feedback through the in-game feedback system and the official communication channel for players;

[0218] For the collected error logs, the following are the main ways to handle and optimize the response methods:

[0219] Syntax errors: Carefully check the script code and use the syntax highlighting and error checking functions of the code editor or IDE;

[0220] Logic error: Verify the correctness of the script logic through unit tests, integration tests, etc.;

[0221] Runtime error: Check resource access permissions, network connection status, etc. to ensure a normal operating environment;

[0222] Compatibility issues: Update the game script, operating system, software, or plugin to the latest version, or find alternative solutions;

[0223] Errors caused by external factors: Check network settings, third-party service status, etc. to ensure that external factors do not affect the normal operation of the script;

[0224] According to the feedback and self-check and self-repair, the repaired game version needs to undergo strict test verification to ensure its stability and reliability before being released to players.

[0225] The above embodiments are only used to illustrate the technical idea of the present invention, and the protection scope of the present invention cannot be limited thereby. Any changes made on the basis of the technical solution according to the technical idea proposed by the present invention shall fall within the protection scope of the present invention.

Claims

1. A method for processing game script data, characterized in that , including the following steps: S1. Collection of error data: By leveraging the characteristic differences between normal logs and error logs, use Flume to perform centralized collection from multiple sources and send them to a unified destination. Also, preprocess the data sources at the unified destination to remove useless information, thereby reducing storage space occupancy and improving processing efficiency. S2. Classification of the collected data: Based on Bayes' theorem, classify the deduplicated data sources collected. The data classification includes runtime errors, compatibility issues, errors caused by external factors, syntax errors, and logical errors. S3. Processing of various types of data: Use corresponding coping methods to perform targeted processing on the classified data sources. S4. Optimization of daily problems: Regularly evaluate and optimize the methods corresponding to the processing of various types of data to improve their efficiency and accuracy.

2. A method for processing game script data according to claim 1, wherein The specific characteristic differences between the normal logs and error logs are: content nature, log level, frequency and importance, format and readability. In terms of the content nature, the characteristics of normal logs are to record the normal running status of the game, user operations, and system call information; the characteristics of error logs are to record exceptions, errors, or crash information that occur during the game running process. In terms of the log level, the characteristics of normal logs are to contain lower-level information, and the characteristics of error logs are to contain higher-level information. In terms of the frequency and importance, the characteristics of normal logs are that the generation frequency is usually higher, and the characteristics of error logs are that the generation frequency is relatively lower. In terms of the format and readability, the characteristics of normal logs are the comprehensiveness and detail of information, and the characteristics of error logs are that the content is concise, with a clear format and tags.

3. A method for processing game script data according to claim 1, characterized in that, The Flume is a log collection, aggregation, and transmission system. The core of the Flume is the Agent, which consists of three components: Source, Channel, and Sink. The Source is used to receive the data source and pass the data source to the Flume Agent. The Channel is used as a buffer between the Source and the Sink, allowing the Source and the Sink to operate at different rates. The Sink is responsible for continuously polling the data sources in the Channel and removing and sending these data sources to the unified destination in batches.

4. A method for processing game script data according to claim 1, characterized in that, The useless information includes duplicate logs and test logs. The duplicate logs are removed by constructing a hash table. The running logic steps of the hash table are as follows: Step 1. Create an empty hash table. Step 2. Traverse each data item in the game script data source. Step 3. Calculate the hash value for each data source and add the hash value to the hash table. Step 4. After the traversal ends, what remains in the hash table are the non-duplicate data sources.

5. A method for processing game script data according to claim 4, characterized in that In Step 3, if the hash value a already exists in the hash table, when the next data source with the same hash value a appears, ignore the data source with the same hash value a and only perform counting. If the hash value does not exist in the hash table, it will be directly added to the hash table.

6. A method for processing game script data according to claim 4, wherein During the operation of the hash table, in order to avoid hash collisions, double hashing is adopted, that is, two hash functions are used, one for determining the initial position and the other for determining the step size of the probing sequence; the function expressions are as follows: f(i) = (hash1(key) + i·hash2(key)) mod m Where,[[]] hash1(key): is the first hash function, used to determine the initial position of the data source; hash2(key): is the second hash function, used to generate the step size of the probing sequence; i; is the number of attempts already made; m: is the size of the hash table.

7. A method for processing game script data according to claim 1, wherein The expression of the Bayes' theorem is as follows; Where,[[]] P((C|F1,F2,...,F n )): represents the probability that the data source belongs to the classification C given the features F1, F2,..., F n ; P(C): represents the probability that the data source belongs to class C before considering any feature information; P(F i |C); represents the probability that feature F i occurs given that the data source is known to belong to class C; P(F1,F2,...,F n ): represents the probability of the simultaneous occurrence of features F1, F2,..., F n , without considering their association with any classification C.

8. A game script data processing method according to claim 7, characterized in that The P(F1,F2,...,F n ) In actual calculation, when classifying the deduplicated data source and comparing the posterior probabilities of different classifications C, P(F1,F2,...,F n ) are all the same. Therefore, in actual calculation, the P(F1,F2,...,F n ) in the denominator part can be omitted, and only the numerator needs to be compared.

9. A method for processing game script data according to claim 1, characterized in that, The coping methods in S3 are specifically as follows: For runtime errors, the coping method is to check the resource access permissions and network connection status to ensure a normal operating environment; For compatibility issues, the coping method is to update the game scripts, operating system, software, and plugins to the latest versions; For errors caused by external factors, the coping method is to check the network settings and the status of third-party services to ensure that external factors do not affect the normal operation of the game scripts; For syntax errors, the coping method is to carefully check the game script code and use the syntax highlighting and error checking functions of code editors and IDEs; For logical errors, the coping method is to verify the correctness of the script logic through unit testing and integration testing.

10. A method for processing game script data according to claim 1, characterized in that, The optimization of subsequent problems in S4 specifically further includes: S41. Set up a feedback system in the game and an official player communication channel outside the game, and collect players' feedback through the in-game feedback system and the official player communication channel; S42. According to the feedback and self-check and self-repair, the repaired game version needs to undergo strict test verification to ensure its stability and reliability before being released to players.

Images