A game automation script detection method and terminal

Abstract

This invention discloses a method and terminal for detecting automated game scripts. The method includes the following steps: responding to a detection request, traversing file data, classifying the file data according to file extensions and file header features to obtain script files and image files; detecting the script files and image files, and summarizing and organizing the detection results corresponding to each detection type, displaying the organized detection results. This invention performs syntax and logic checks, file association checks, comment specification checks, and redundancy checks on script files, records the detection results, and summarizes and classifies the detection results to facilitate developers in modifying script files based on the detection results, ensuring the quality and reliability of script files, and improving the detection efficiency and maintainability of script files.

Description

Technical Field

[0001] This invention relates to the field of automated testing technology, and in particular to a method and terminal for detecting automated game scripts. Background Technology

[0002] Currently, game automation script detection mainly relies on manual line-by-line inspection. Developers, with their familiarity with programming languages, carefully examine the script code to identify issues such as module imports and syntax structure (parentheses and quotation marks). For variables and images involved in the script, developers need to recall and compare them to determine if they are redundant. Furthermore, when checking the relationship between the script and library files (including SQL-related libraries), it is necessary to manually find the calling statements and analyze them against the library file content. Considering the above, the manual line-by-line inspection of game automation scripts has the following drawbacks: 1. Inefficient and time-consuming Manually checking automated game scripts line by line is slow, and the time required increases significantly as the script size grows. For example, in large game projects, a script with a certain complexity may require several hours or even days of manual checking, which greatly delays the script's release time and affects the overall game development schedule. 2. Accuracy is difficult to guarantee. Manual inspection is easily affected by subjective factors, such as fatigue and lack of concentration, which can easily lead to problems due to missed checks. Especially when dealing with complex logic or a large amount of code, it is difficult to find all the subtle syntax errors or deeply hidden redundant content, thus creating hidden dangers for script operation and project maintenance. 3. Lack of systematic standardized testing There is no unified standard or efficient means for manually checking script commenting standards. Different developers have different commenting habits, resulting in inconsistent commenting quality, which is not conducive to team collaboration and long-term code maintenance. Summary of the Invention

[0003] The technical problem to be solved by this invention is to provide a method and terminal for automated game script detection, which can improve script detection efficiency and accelerate the game development process.

[0004] To solve the above-mentioned technical problems, the technical solution adopted by the present invention is as follows: A method for detecting automated game scripts, comprising the following steps: S1. In response to the detection request, traverse the file data and classify the file data according to the file extension and file header features to obtain script files and image files; S2. Detect the script file and image file, and summarize and organize the detection results corresponding to each detection type, and display the organized detection results.

[0005] To solve the above-mentioned technical problems, another technical solution adopted by the present invention is as follows: A game automation script detection terminal includes a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the various steps of the game automation script detection method described above.

[0006] The beneficial effects of this invention are as follows: This invention provides a game automated script detection terminal that, in response to a detection request, traverses file data and classifies the file data according to file extensions and header features to obtain script files and image files. By combining file extensions and header features, it improves classification efficiency and accuracy, reduces the possibility of misclassification, and lays the foundation for subsequent detection of corresponding types. It detects the script files and image files, summarizes and organizes the detection results for each detection type, and displays the organized results. Since game scripts contain a large number of images, separating script files and image files for inspection avoids the waste of computing power caused by mixed inspections. Combining their respective characteristics for corresponding type detection improves script testing efficiency. Developers can modify game scripts based on the detection results, improving script quality and ensuring a stable game development process. Attached Figure Description

[0007] Figure 1 This is a flowchart of a game automation script detection method according to an embodiment of the present invention; Figure 2 This is a schematic diagram of a game automation script detection terminal according to an embodiment of the present invention; Label Explanation: 1. A game automation script detection terminal; 2. Memory; 3. Processor. Detailed Implementation

[0008] To explain in detail the technical content, objectives, and effects of the present invention, the following description is provided in conjunction with the embodiments and accompanying drawings.

[0009] Please refer to Figure 1 This invention provides a method for detecting game automation scripts, including the following steps: S1. In response to the detection request, traverse the file data and classify the file data according to the file extension and file header features to obtain script files and image files; S2. Detect the script file and image file, and summarize and organize the detection results corresponding to each detection type, and display the organized detection results.

[0010] As can be seen from the above description, the beneficial effects of the present invention are as follows: In response to a detection request, the file data is traversed, and the file data is classified according to the file extension and file header features to obtain script files and image files. By combining the use of file extension and file header features, classification efficiency and accuracy are improved, reducing the possibility of misclassification and laying the foundation for subsequent corresponding detection types. The script files and image files are detected, and the detection results corresponding to each detection type are summarized and organized, displaying the organized detection results. Since game scripts contain a large number of images, separating the script files and image files for inspection avoids the waste of computing power caused by mixed inspections. Detection of corresponding types is performed based on their respective characteristics, improving script testing efficiency. Developers modify the game scripts according to the detection results, improving script quality and ensuring the stability of the game development process.

[0011] Furthermore, prior to step S1, the procedure also includes: The system reads detection parameters from the configuration file and checks the system operating environment. The detection parameters include syntax detection rules and annotation specification templates.

[0012] As described above, by reading detection parameters from the configuration file, automated script detection can be achieved, improving detection efficiency. Furthermore, the detection parameters in the configuration file can be flexibly adjusted, enhancing the flexibility and scalability of script detection. The system operating environment is also checked to ensure the smooth operation of the script detection process.

[0013] Furthermore, the detection types include syntax and logic detection, file association detection, comment specification detection, and redundancy detection; The step S2 of detecting the script file includes: The script file is subjected to syntax and logic checks. The code lines of the script file are traversed, and each line of code is matched with the syntax check rules. The syntax structure and logical relationship of the script file are determined by the syntax check model. If there are code lines that do not conform to the syntax check rules, the first error information is recorded. The first error information includes the error type, line number and error code fragment. File association detection is performed on the script file, the library files in the directory are scanned, the contents of the library files are parsed, the library element definition information is extracted and the library file index is constructed, the code lines referencing the library files are found in the script file, and the code lines are verified according to the library file index. If there are code lines referencing the library files that do not match, a second error message is recorded. The second error message includes the error type, error reason, line number and the name of the referenced library element. The script file is checked for annotation specifications. Annotation content is extracted from the script file, classified according to the position and format of the annotation content, and compared with the annotation specification template. If there is annotation content that does not conform to the annotation specification template, a third error message is recorded. The third error message includes the error type, error reason, and position of the erroneous annotation content. Redundancy detection is performed on the script file. By analyzing the abstract syntax tree or code structure of the script file, unused lines of code are found to obtain redundant code, and a fourth error message is recorded. The fourth error message includes the error type, the script file where the redundant code is located, the line number range, and the code snippet content.

[0014] As described above, performing syntax and logic checks on script files promptly identifies syntax errors and logical vulnerabilities, reducing the likelihood of runtime errors and crashes, and improving code reliability and stability. File association checks ensure correct references to library files, preventing runtime issues caused by incorrect references. Comment style checks standardize commenting according to templates, improving code readability and maintainability. Redundancy checks identify redundant code, optimize code structure, improve execution efficiency, and record error information for each check. This facilitates developer analysis and improvement of script files, enhancing the quality of automated scripts and promoting the steady progress of game development.

[0015] Furthermore, the detection of the image file in step S2 includes: Redundancy detection is performed on the image file by comparing it with a template image file and calculating the hash value of the image file. If the hash value is higher than a preset threshold, the image file is identified as a redundant image. Check the reference status of the image file in the script file. If there is an image file that is not referenced, then the image file is identified as a redundant image.

[0016] As described above, by performing redundancy detection on image files, image files similar to the template image files and unreferenced image files are identified. This allows developers to clean up file data based on the redundancy detection results, facilitating script execution and project maintenance.

[0017] Furthermore, the process of summarizing and organizing the detection results corresponding to each detection type, and displaying the organized detection results, includes: A detection result data model is constructed, the detection results corresponding to each detection type are summarized, and the error information of the detection results is classified and organized. The organized detection results are stored in the detection result data model and displayed through a graphical user interface or log.

[0018] As described above, by constructing a detection result data model and summarizing, classifying, and storing the detection results corresponding to each detection type in the detection result data model, the accessibility and usability of the data can be improved. This data can then be displayed through a graphical user interface or logs, allowing developers to make corrections based on the detection results and providing strong support for game development.

[0019] Please refer to Figure 2 Another embodiment of the present invention provides a game automation script detection terminal, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the various steps of the above-described game automation script detection method.

[0020] The game automation script detection method and terminal described above are applicable to game automation script detection, and can improve script detection efficiency and accelerate game development process. The specific implementation methods are described below: Please refer to the figure. Embodiment 1 of the present invention is: a method for detecting game automation scripts, including the following steps: S1. In response to the detection request, traverse the file data and classify the file data according to the file extension and file header features to obtain script files and image files.

[0021] In this embodiment, in response to a detection request, the system recursively traverses all subdirectories and files starting from the specified root directory using Python's `os.walk` function or a similar file system traversal method to obtain file data. The file data is then classified based on file extensions and header features to obtain script files and image files. Combining file extension and header features improves classification efficiency and accuracy, reduces the possibility of misclassification, and lays the foundation for subsequent corresponding detection types. The file data includes: 1. Documents related to the testing task This mainly involves files directly or indirectly related to game automation scripts. This includes the script files themselves (such as files written in a specific scripting language, which may be Python scripts, Lua scripts, etc., depending on the scripting technology stack used by the game), because these are the core detection targets of the detection tools. It is necessary to analyze their syntax, logic, and standardization issues. It may also include other files that are referenced or related to the script, such as configuration files (the script may rely on the configuration parameters in them to execute different logic) and resource files (such as images, audio, etc. If the script references these resources, it may be necessary to check the correctness of the references and the availability of the resources). Information from these files is necessary for a comprehensive understanding and detection of the script's behavior. 2. Files in a specific directory The traversal typically begins from a specified root directory, which could be the game project's source code directory, a specific script directory, or a parent directory containing the scripts and related files to be checked. The traversal recursively extends into all subdirectories to ensure no potentially script-related files are missed. For example, if the game project's script files are stored in the "src / scripts" directory, and this directory contains subdirectories for categorizing different types of scripts or related resources, the traversal will start from "src / scripts" and proceed through all its subdirectories to search for relevant files. 3. Configurable range The detection tool may offer configuration options that allow users to specify the specific directories or file types to be traversed, so as to flexibly adjust the detection scope according to actual needs. For example, users can choose to detect only scripts and files related to a specific module or function, while excluding other irrelevant parts. This can improve detection efficiency, reduce unnecessary detection overhead, and allow users to focus on specific areas of interest.

[0022] In this embodiment, the obtained script file and image file are preprocessed, including: for the script file, its content is read and initially parsed, and feature information such as keywords, function definitions, and variable declarations in the code is extracted to construct an abstract syntax tree (AST) or similar code representation result for subsequent syntax and logic analysis; for the image file, its size, resolution, color model and other attribute information are recorded for subsequent redundancy detection.

[0023] Furthermore, in this embodiment, before step S1, the method further includes: reading detection parameters from a configuration file and checking the system operating environment. The detection parameters include syntax detection rules and annotation specification templates. The information in the configuration file guides the subsequent detection process, enabling automated script detection, improving detection efficiency, and allowing flexible adjustment of the detection parameters in the configuration file to ensure the flexibility and scalability of script detection. For example, the syntax detection rules may contain a list of regular expression patterns to match the correct usage of various Python syntax reserved fields. The method also checks the system operating environment to ensure that the required Python libraries and dependencies are correctly installed, verifies the connection to the database (if script-SQL language association detection is involved) or other external resources, and initializes the memory space and data structures, such as lists, dictionaries, and sets, for storing detection results, file indexes, and temporary data to ensure the smooth progress of the script detection process.

[0024] S2. Detect the script file and image file, and summarize and organize the detection results corresponding to each detection type, and display the organized detection results.

[0025] In this embodiment, code problems are identified by inspecting script files and image files. The inspection results are then summarized, organized, and displayed to facilitate developers in modifying the game automation scripts based on the inspection results, thereby improving the quality of the automation scripts and ensuring the stability of the game development process.

[0026] Furthermore, in this embodiment, the detection types include syntax and logic detection, file association detection, comment specification detection, and redundancy detection; step S2, detecting the script file, includes: performing syntax and logic detection on the script file, traversing the code lines of the script file, matching each line of code with syntax detection rules, and judging the syntax structure and logical relationships of the script file through a syntax detection model. If there are code lines that do not conform to the syntax detection rules, a first error message is recorded. The first error message includes the error type, line number, and error code fragment, so as to promptly detect syntax errors and logical vulnerabilities and reduce the possibility of runtime errors and crashes in the script file. This improves the reliability and stability of the code. The script file undergoes file association detection, scanning library files in the directory, parsing the contents of the library files, extracting library element definition information, and constructing a library file index. The script file searches for lines of code referencing the library files, and verifies these lines against the library file index. If a line of code is found that does not match the library file, a second error message is recorded. This second error message includes the error type, error reason, line number, and the name of the referenced library element. The library file index facilitates quick searching and comparison of library element references within the script file. For example, a dictionary data structure can be used, with the library element name as the key. The system defines locations and parameter information as values. Through a library reference check of the script file, it verifies whether the number and type of parameters in function calls match the function signatures defined in the library file, ensuring that variables reference the correct library elements and avoiding runtime issues caused by incorrect references. The system also performs a comment specification check on the script file, extracting comment content, categorizing it according to its location and format, and comparing it with a comment specification template. If any comment content does not conform to the template, a third error message is recorded, including the error type, error reason, and location of the erroneous comment content, according to the comment specification. The template standardizes comment style, improving code readability and maintainability. Redundancy detection is performed on the script files by analyzing their abstract syntax tree or code structure to identify unused lines of code, thus obtaining redundant code. A fourth error message is recorded, including the error type, the script file containing the redundant code, the line number range, and the code snippet content. This process identifies redundant code, optimizes the code structure, improves script file execution efficiency, and records error information for each detection. This facilitates developer analysis and improvement of script files, enhances the quality of automated scripts, and promotes the steady progress of game development. Specifically, the syntax detection model construction process includes: 1. Determine the model structure Choosing a suitable neural network architecture for processing sequential data, such as a Long Short-Term Memory (LSTM) network or a Gated Recurrent Unit (GRU), is beneficial. These architectures can capture contextual information in script code and are effective in understanding syntactic structures and logical relationships. For example, LSTM, through its unique gating mechanism, can effectively remember and forget information when processing long sequence data, thus better handling complex nested structures and syntactic problems in dynamically generated code. For instance, for scripts involving dynamic function calls or conditional compilation, the model can accurately determine their syntactic correctness. In addition, variants of Convolutional Neural Networks (CNNs), such as TextCNN, can also be considered. They can extract local features through convolutional layers and then perform classification or regression tasks through fully connected layers, which helps to identify specific patterns and structures in the code. 2. Data Preparation A large number of game automation scripts were collected as training data to ensure that these scripts covered various grammatical structures, logical situations, and possible error types in order to improve the generalization ability of the model. The scripts were preprocessed, including word segmentation (splitting the script code into words or symbols), punctuation cleaning (removing unnecessary punctuation and reducing noise), and converting characters to lowercase format (unifying the text format and avoiding the impact of case differences on the model). The preprocessed script data was labeled as correct or incorrect, and the error types were further subdivided as needed so that the model could perform multi-class classification learning. 3. Model Training (1) Divide the training set, validation set and test set. Usually, the training set is used for training the model, the validation set is used to adjust the hyperparameters of the model and evaluate the performance of the model during the training process, and the test set is used to finally evaluate the generalization ability of the model. (2) Build a model using the selected neural network framework (such as TensorFlow or PyTorch) and train it based on the labeled data. During the training process, define appropriate loss functions (such as cross-entropy loss function for classification problems and mean squared error loss function for regression problems) and optimizers (such as stochastic gradient descent (SGD), adaptive moment estimation algorithm (Adam), etc.), calculate the predicted output of the model through forward propagation, and then compare it with the actual labels to calculate the loss. Calculate the gradient of the loss with respect to the model parameters using the backpropagation algorithm, and update the model weights and biases according to the optimizer to minimize the loss function. (3) Conduct multiple rounds of training, monitor the model’s performance metrics (such as accuracy, recall, F1 score, etc.) on the validation set, and adjust hyperparameters (such as learning rate, number of hidden layers, number of iterations, etc.) according to performance until the model achieves good performance on the validation set. 4. Model Evaluation and Optimization Use a test set to evaluate the trained model to ensure it performs well on unseen data. If the model's performance is unsatisfactory, further analyze the error types and adjust the model structure, increase training data, or perform other optimization operations. For example, consider using regularization techniques (such as L1 and L2 regularization, Dropout, etc.) to prevent overfitting and improve the model's generalization ability. At the same time, you can also try ensemble learning methods (such as Bagging, Boosting, etc.) to combine the prediction results of multiple models to improve the model's accuracy and stability. 5. Model Deployment and Application The trained model is then deployed into a real-world game script detection system, enabling it to receive new script data, detect syntax and logic errors, and output quality assessment information and modification suggestions. During deployment, the model's performance and efficiency must be considered to ensure it can quickly process large numbers of script files. Furthermore, as new script data accumulates and error types change, the model should be regularly updated and optimized to adapt to evolving detection requirements. Incremental learning can be employed, using new data to fine-tune the model without retraining the entire system, thus saving time and resources.

[0027] Furthermore, in this embodiment, natural language processing technology is used to understand the semantic information of variable names, function names, etc. in the code. Combined with syntactic analysis, the rationality of the code logic is evaluated more comprehensively. For example, it is used to determine whether the variable naming conforms to the business logic and whether the function function is consistent with the name, thereby discovering potential logical errors in advance.

[0028] In this embodiment, file association detection of the script file further includes: developing a system for dynamically monitoring the association between the script and library files (including SQL-related libraries). This system tracks changes in the library files in real time during script execution, such as function signature changes and data structure adjustments, and instantly detects whether the calls in the script match them. When an association error is detected, the system automatically attempts to provide repair suggestions based on the new features of the library files and the script context, such as adjusting function parameters and updating data access methods, to reduce script failures caused by library file updates. The step of tracking changes in the library files in real time during script execution includes: 1. File system monitoring Use the file system monitoring mechanisms or related file monitoring libraries provided by the operating system. For example, in Windows, the ReadDirectoryChangesW function in the Windows API can be used to monitor file changes in a specified directory (including the directory where the library files are located). This function can detect file creation, modification, deletion, and other operations, and notify the application when the event occurs. In Linux, the inotify mechanism can be used. Through tools such as inotify-tools or by directly using related system calls, the directory where the library files are located can be monitored. When the library files change, such as changes in function signatures that lead to changes in file content, or adjustments to data structures that cause changes in file size, the monitoring mechanism can capture these events. 2. Hook functions and event handling For specific programming languages ​​and development environments, hook functions can be set up to intercept operations related to library file loading and usage. For example, in Python, the `sys.meta_path` hook can be used to intercept the module import process. When a script attempts to import a library module, the hook function is triggered, and information about the library module (such as file path, last modification time, etc.) can be recorded. Then, combined with the file system monitoring mechanism, when a change to the library file is detected, the type of change (added, modified, or deleted) can be determined by comparing it with the previously recorded information. If it is a modification, further analysis can be conducted to see if the changed content affects the calls in the script (such as changes to function signatures). In Java, JavaAgent technology can be used to modify bytecode and add custom logic during class loading to monitor library file references. When a library file changes, reflection can be used to check whether the calls to library functions in the script are still valid. 3. Regular checks and caching mechanisms In addition to real-time monitoring, periodic check tasks can be set up to supplement potentially missed changes or handle some special cases (such as delayed updates of network file systems). Periodic checks can compare the current state of library files (such as file hash value, modification time, etc.) with the previously recorded state to determine if any changes have occurred and establish a caching mechanism to store relevant information of library files, such as function signatures, data structure definitions, etc. For example, when library files change, the cache content is updated in a timely manner. During script execution, each time a library function is called, the function signature and other information are first retrieved from the cache and compared with the actual call to quickly determine whether the call matches, reducing the overhead of real-time checks and improving detection efficiency. 4. Integration with version control systems (optional) If the project uses a version control system (such as Git, SVN, etc.), the change detection of library files can be integrated with the version control system. When the library files are updated in the version control system, the detection script is triggered through the hook mechanism to check whether the references to the library files in the script need to be adjusted accordingly. This approach can take advantage of the features of the version control system to more accurately track the change history and source of library files, while also facilitating team collaboration and code management. 5. Exception handling and rollback mechanism When a mismatch is detected between library file changes and script calls, a corresponding exception handling mechanism is needed. This mechanism should provide developers with detailed error information, including the specific content of the library file changes and the location of the affected scripts, so that developers can make repairs. At the same time, a rollback mechanism should be considered to restore the script to a previous stable state when necessary, so as to avoid the script becoming completely unusable due to library file changes. For example, the runtime state of the script can be backed up or a mechanism can be provided to temporarily disable functions related to the changed library files until the problem is resolved.

[0029] By combining the above methods, it is possible to comprehensively track changes in library files in real time during script runtime and instantly detect whether the calls in the script match them, thereby promptly identifying and resolving script failures caused by library file updates.

[0030] In this embodiment, the annotation standardization check of the script file further includes: using a standardization check engine and machine learning algorithms to analyze the script code's function and logic, automatically generating a standard-compliant annotation template. This standardization check engine does not simply indicate missing comments, but intelligently generates detailed and accurate annotation content based on the code content, such as function descriptions, parameter usage explanations, and return value descriptions. It also performs in-depth standardization checks on comments written by developers, including syntactic correctness, semantic clarity, and consistency with the code, ensuring high-quality annotations and improving code readability and maintainability. The generation process of the annotation standardization template includes: 1. Data Collection and Preprocessing Collect a large number of annotated game automation scripts as training data. These scripts should cover various functions and logical structures to ensure that the trained model has broad applicability. For the collected scripts, perform preprocessing operations, including word segmentation (splitting the code into basic units such as words and symbols), removal of stop words (such as common programming language keywords and other words that are not very meaningful for understanding the code logic), and conversion of characters to lowercase format, so as to facilitate subsequent analysis and processing. 2. Feature Extraction Extracting meaningful features from the preprocessed script to represent the code's functionality and logic. This can be done in various ways, such as: Feature extraction based on Abstract Syntax Tree (AST): The script code is converted into an abstract syntax tree, and then information such as node type, relationships between nodes, and control flow structure (such as loops, conditional statements, etc.) is extracted from the AST as features. For example, for a function definition node, features such as function name, parameter list, statement type and structure in function body can be extracted. These features can reflect the hierarchical structure and logical flow of the code, which helps machine learning models understand the function of the code. Code statistical features: Calculate some statistical information in the code, such as the number of lines of code, the number of variable declarations, the number of function calls, and the frequency of use of different operators. These statistical features can provide information about code complexity, functional scale, etc., and can help generate comment templates. Semantic features of code: Using word vector models (such as Word2Vec, GloVe, etc.) to convert identifiers (variable names, function names, etc.) in the code into vector representations to capture their semantic information. By analyzing the relationship between these vectors, the semantic connections between different parts of the code can be inferred, thereby better understanding the functional logic of the code. For example, if two variable names are close to each other in the vector space, it may indicate that they are functionally related. 3. Model Selection and Training Choose a suitable machine learning model, such as a sequence-to-sequence (Seq2Seq) model or an attention-based neural network model. Seq2Seq models are often used to handle sequence transformation tasks and are suitable for converting code sequences into annotated sequences. Attention mechanisms can help the model focus on the most relevant region in the code when generating annotations, improving the accuracy of the annotations. The model is trained using collected training data, with the extracted code features as input and the corresponding annotations as output. The model parameters are adjusted by minimizing the difference between the predicted annotations and the actual annotations (e.g., using the cross-entropy loss function). During training, various techniques are used to improve the model's performance, such as using recurrent neural networks (RNNs) or their variants (LSTM, GRU) to process the contextual information of the sequence, using multi-layer neural networks to increase the model's expressive power, and using regularization techniques (such as L1 and L2 regularization, Dropout, etc.) to prevent overfitting. 4. Generate annotation template Once the model is trained, the script to be annotated is first processed according to the previous preprocessing and feature extraction steps to obtain the feature representation of the code. These features are then input into the trained model, which predicts the corresponding annotation content based on the learned patterns. The generated annotation templates can be organized according to the code structure. For example, for the function definition section, the model will generate annotations such as function description, parameter usage explanation, and return value description; for code blocks, it will generate brief annotations about the function of the code block. The format of the annotations can follow predefined specifications, such as specific annotation symbols and layout formats, to ensure that the generated annotations meet the requirements of the team or project. 5. Model Evaluation and Optimization The generated annotation templates are evaluated using test data that was not used in the training process. Evaluation metrics can include the accuracy of the annotations (whether the content accurately reflects the code function compared to high-quality human-written annotations), completeness (whether it covers the necessary information), and readability (whether the annotations are easy to understand). Based on the evaluation results, the model is optimized, for example, by adjusting the model's hyperparameters, increasing training data, improving feature extraction methods, or trying different model structures, in order to continuously improve the quality of the generated annotation templates.

[0031] The deep specification check of developer-written comments includes: 1. Grammar Correctness Check Define a set of comment syntax rules: Based on the programming language used in the project and the commenting conventions agreed upon by the team, define a complete set of comment syntax rules. For example, specify the correct way to use comment symbols (such as starting with "#" in Python, and enclosing them with " / / " or " / * * / " in Java), and the format requirements for comment content (such as whether line breaks are allowed, indentation rules, etc.). Lexical analysis and syntax parsing: The comments are processed using a lexical analyzer and a syntax parser. The lexical analyzer breaks down the comment text into lexical units (such as words, punctuation marks, etc.), while the syntax parser checks whether the structure of the comment conforms to the predefined syntax rules. For example, for function comments, it checks whether they contain the necessary parts (such as function description, parameter description, return value description, etc.) and whether the format of these parts is correct.

[0032] Error Reporting and Messages: When a syntax error is detected, accurately record the location of the error (such as the line number and column number of the comment), the error type (such as comment symbol error, formatting error, etc.), and provide developers with clear error messages to help them quickly locate and fix the problem; 2. Semantic clarity detection Semantic understanding technology selection: Natural language processing technology is used to understand the semantics of annotations. Word vector models (such as Word2Vec, GloVe, etc.) can be used to convert the words in the annotations into vector representations in order to calculate the semantic similarity between words. In addition, semantic analysis tools or libraries (such as rule-based semantic analyzers, deep learning models, etc.) are combined to parse the semantic structure of the annotations. Lexical and code association analysis: Check whether the words used in the comments are related to the actual operations and functions in the code. For example, by analyzing the variable names, function names, operators, etc. in the code and matching and associating them with the words in the comments, if the function mentioned in the comments cannot be found in the code, or if the terminology used in the comments does not match the actual logic in the code, it may indicate that the semantics are unclear. Logical coherence check: Evaluate whether the comments are coherent and complete in describing the code logic. Check whether the comments can accurately explain the logical relationships such as the execution flow, condition judgment, and loop structure of the code. For example, for a complex condition judgment statement, the comments should clearly explain the condition and the function of different branches, rather than simply repeating the code. Ambiguity and ambiguity detection: Identify potentially ambiguous words or expressions in comments. For example, some overly general words (such as "this function does some things") may not provide enough information, or some expressions may have multiple interpretations. For detected ambiguities or ambiguities, provide suggestions to developers to encourage them to modify the comments to make them clearer and more explicit. 3. Code consistency check Code structure and comment matching: Check whether the comments match the structure and hierarchy of the code. For example, each function, class, code block, etc. should have corresponding comments to describe it, and the scope of the comments should be consistent with the actual scope of the code. If the scope of the code covered by the comments is too large or too small, or if comments are missing in critical code parts, it indicates that there is a consistency problem. Variable and function reference check: Ensure that the variables and functions mentioned in the comments actually exist and are used correctly in the code. Analyze the references to variables and functions in the comments and compare them with the definitions and calls in the code. If the comments reference non-existent variables or functions, or if the description of variables and functions does not match the actual usage (e.g., the comments state that a variable is used to store a certain type of data, but the actual assignment and usage in the code contradict this), then an inconsistency error will be prompted. Code modification synchronization detection (optional): If the project uses a version control system, when the code is modified, it can check whether the comments have also been updated accordingly. When the functionality or logic of the code changes, the comments should reflect these changes in a timely manner to maintain consistency with the code. By comparing the code modification history and the comment modification record, it can identify and remind developers to update comments that are not updated in a timely manner. 4. Integration and feedback of test results Integrate the test results: Integrate the results of syntactic correctness, semantic clarity and code consistency tests to form a complete comment specification test report. The report should list the problems of each comment in detail, including the problem type, location and specific description. Visualization and Feedback: Present test results to developers in an intuitive way, such as displaying annotated issues in the form of markers or tooltips in the integrated development environment (IDE), or generating detailed test report documents. At the same time, provide repair suggestions and guidance to help developers improve the quality of comments to meet the specifications and improve the readability and maintainability of the code.

[0033] The process for evaluating the quality of the annotations includes: 1. Grammar accuracy assessment Formatting: Check whether comments follow predefined formatting conventions. For example, in a specific programming language, is the use of comment symbols correct (e.g., single-line comments starting with "#" in Python, or multi-line comments enclosed in quotation marks)? Does the indentation conform to code style requirements? Is the layout of the comment content clear and easy to read (e.g., appropriate line breaks, spaces, etc.)? Comments that do not conform to formatting conventions may affect the reading experience and may also indicate that developers do not pay attention to commenting conventions. Symbol and grammar errors: Detect grammatical errors in annotations, such as spelling mistakes, improper use of punctuation, and disordered grammatical structure. Although annotations are mainly for human reading, grammatical errors may lead to difficulties in understanding or even ambiguity. For example, a typo in an annotation may cause the reader to misunderstand the annotation's intention. You can use the spell checking and grammar analysis functions in natural language processing tools, or perform checks based on predefined sets of grammar rules. 2. Semantic clarity assessment Information completeness: Evaluate whether the comments contain enough information to accurately describe the function, intent, and logic of the code. For function comments, they should include the function's purpose, the meaning of the parameters, and a description of the return value. For code block comments, they should explain the function they implement and their relationship with the surrounding code. Comments that lack key information are of limited help in understanding the code. For example, if a function comment only describes the function's function without mentioning the purpose of the parameters, developers may need to spend more time analyzing the role of the parameters when reading the code. Accuracy: Check whether the comments are consistent with the actual functionality implemented in the code. Inaccurate comments may mislead subsequent code maintainers, leading to incorrect modifications or understandings. For example, if the algorithm logic described in the comments does not match the actual algorithm implementation in the code, it will cause great trouble for code maintenance. The accuracy can be evaluated by analyzing the degree of matching between the code logic and the comment description. If necessary, combine it with technical means such as code execution path analysis. Conciseness and clarity: Good comments should be concise and clear, avoiding lengthy and complex expressions. At the same time, they should avoid using vague or ambiguous words or sentence structures. Concise and clear comments can quickly convey key information and improve code reading efficiency. For example, comments that use overly general terms (such as "do some processing") without specifying what is being processed are not clear enough. This can be evaluated by calculating the text complexity indicators of comments (such as lexical diversity, sentence length, etc.) and analyzing the semantic clarity of words (such as using domain-specific terms and avoiding colloquial expressions). 3. Code consistency assessment Coverage consistency: Ensure that comments cover all important parts of the code that need explanation, and avoid having too many or too few comments. Every function, class, key code block, etc., should have corresponding comments, and the scope of the comments should match the logical structure of the code. For example, a complex conditional statement without comments or a simple variable declaration with a lengthy comment are inconsistent. Coverage can be assessed by using code analysis tools to statistically analyze the correspondence between code structure elements and comments.

[0034] Dynamic update consistency: As the code is modified and evolves, comments should be updated in a timely manner to keep them in sync with the code. Evaluate whether the comments reflect the latest state of the code, including feature changes, logic adjustments, etc. If new features are added to the code or the original logic is modified, but the comments are not updated accordingly, it will lead to inconsistency between the comments and the code. You can combine the code modification history recorded by the version control system to compare the modification time and content of the comments and check the consistency of dynamic updates. 4. Quantification and comprehensive evaluation of evaluation indicators Quantitative Indicator Setting: Specific quantitative indicators are set for each of the above evaluation aspects, such as the number of syntax errors, information completeness score (calculated based on the ratio of the number of necessary information points contained in the comments to the total expected number of information points), accuracy score (calculated through analysis of the degree of matching with code logic, such as using semantic similarity algorithms to measure the closeness between comments and the actual function of the code), conciseness indicators (such as the ratio of comment text length to code complexity), coverage ratio (the ratio of the number of lines of code covered by comments to the total number of lines of code), etc. Comprehensive Evaluation Model: A comprehensive evaluation model is constructed, which calculates an overall annotation quality score by weighting and summing various quantitative indicators or using other appropriate calculation methods. The weight allocation can be determined based on the importance of different aspects to annotation quality. For example, semantic clarity may be more important than grammatical correctness and can be given higher weight. Through the comprehensive evaluation model, annotation quality can be objectively and comprehensively evaluated, and a clear quality measurement standard can be provided for developers to understand the quality of annotations so as to make targeted improvements.

[0035] By using standardized comment templates, script comments are transformed from arbitrary writing to standardized, high-quality writing. This provides developers with good reference examples, ensuring the accuracy and consistency of comments. Through comprehensive and systematic comment standard checks and comment quality assessments, it effectively ensures that the comments written by developers meet high standards, thereby improving code readability and maintainability, reducing the difficulty for new members to understand the code, promoting team collaboration, and accelerating game development.

[0036] Furthermore, in this embodiment, before performing semantic clarity detection and evaluation on the comment text, the following steps are included: performing semantic analysis on the comment text to determine the consistency between the comment content and the code function and logic, specifically: 1. Application of word vector models Model selection and training: Choose a suitable word vector model, such as Word2Vec, GloVe, or FastText. These models can convert words in the annotation into vector representations. The distance in the vector space can reflect the semantic similarity between words. If a pre-trained model is used, it may be necessary to fine-tune it according to the specific terms and vocabulary of the game development field to adapt to the characteristics of the script annotation. For example, for words such as "character", "skill", and "level" that are common in game scripts, ensure that the model can accurately understand their semantics in the game context. Text preprocessing: Before inputting annotations into the word vector model, necessary preprocessing operations are performed, including word segmentation (splitting the annotation text into words or lexical units), removal of stop words (such as common programming language keywords, punctuation marks, etc., which contribute little to semantic understanding), stemming or lemmatization (converting words into their basic forms to reduce the impact of word variations on semantic analysis). For example, "runs" and "running" are both transformed into "run" after stemming, which facilitates subsequent vector representation and semantic analysis. 2. Semantic similarity calculation Vector representation: Each word in the preprocessed annotation text is converted into a word vector, and then the word vectors are combined into a vector representation of the annotation text through some method (such as average pooling, weighted summation, etc.). In this way, each annotation can be described by a vector of fixed dimensions to describe its semantic features. For example, if average pooling is used, the vectors of all words in the annotation are added together and the average value is taken to obtain the vector representation of the annotation. Similarity Measurement: Choose an appropriate similarity measurement method to calculate the similarity between annotation vectors and code-related feature vectors. Commonly used methods include cosine similarity and Euclidean distance. Cosine similarity calculates the cosine of the angle between two vectors; the closer the value is to 1, the more similar the two vectors are. Euclidean distance measures the straight-line distance between two points in vector space; the smaller the distance, the more similar the vectors are. For example, calculate the similarity between annotation vectors and the vectors converted from function names, variable names, etc. in the code to determine whether the terms mentioned in the comments are related to the actual operation of the code. 3. Judgments and Recommendations Based on Semantic Analysis Functional logic matching judgment: By comparing the semantic similarity between comments and code, it is determined whether the comments accurately describe the function and logic of the code. If the similarity between the comment vector and the vector of key elements in the code (such as the operation of the function implementation, the purpose of the variable, etc.) is high, it means that the comment is consistent with the functional logic of the code to a certain extent; conversely, if the similarity is low, there may be problems with semantic ambiguity or inaccuracy. For example, for a function that calculates a character's health, if the comment mentions "character status update" and has a high similarity with the vector related to the health calculation operation in the function implementation, then the comment is relatively accurate in its functional description; if the comment does not mention anything related to health and the similarity is low, it may need improvement. Improvement suggestion generation: When semantically unclear or inaccurate comments are detected, specific improvement suggestions are provided based on the semantic analysis results. If the comments use terms that are not related to the actual operation of the code, it can be suggested to use more accurate words. If the comments are too general and do not accurately describe the code function, more detailed functional description examples can be provided based on the code analysis results. For example, for a simple assignment operation commented as "perform a certain setting", it can be suggested to clearly explain the meaning of the variable and value being assigned, such as "set the character's initial health to 100". At the same time, combined with the code structure and logic, guidance is provided to developers on how to better organize the content of comments to improve clarity, such as describing comments in blocks according to the code execution order or functional modules. 4. Combine code structure with contextual information Abstract Syntax Tree (AST) assistance: Utilizing the structural information provided by the abstract syntax tree of the code, comments are correlated with specific nodes in the code (such as function definitions, variable declarations, control flow structures, etc.). For example, for function comments, it is checked whether they accurately describe the input parameters, return values, and operational logic of the function in the AST. By combining the semantic information of comments with AST nodes, the consistency between comments and code functional logic can be more comprehensively evaluated. Contextual understanding: Consider the context of comments within the code, not just individual code elements. Analyze the surrounding code logic, function call relationships, and data flow to more accurately determine the semantic appropriateness of the comments. For example, a comment may seem reasonable in a local context, but when considered within the larger code block or function it belongs to, its description may be incomplete or inaccurate. By synthesizing contextual information, we can provide richer evidence for the semantic analysis of comments, thus more accurately determining whether comments truly help in understanding the functionality and logic of the code.

[0037] By following the steps above, natural language processing techniques can be used to perform semantic analysis on the comment text in a more comprehensive manner. This can effectively assess the consistency between the comments and the functional logic of the code, and provide valuable improvement suggestions for developers, thereby improving the readability and maintainability of the code.

[0038] Furthermore, in this embodiment, step S2, detecting the image file, includes: performing redundancy detection on the image file, comparing the image file with a template image file, calculating the hash value of the image file, and if the hash value is higher than a preset threshold, then the image file is identified as a redundant image; checking the reference status of the image file in the script file, and if there are any unreferenced image files, then the image file is identified as a redundant image. By performing redundancy detection on the image files, image files similar to the template image file and unreferenced image files are identified, so that developers can clean up file data according to the redundancy detection results, which is convenient for script execution and project maintenance.

[0039] Furthermore, in this embodiment, redundancy detection is performed on script files and image files to obtain redundant code and image files. The processing of redundant code and image files includes: prompting the user whether to perform optimization operations (deleting redundant files); if so, backing up the redundant files before execution to prevent data loss due to accidental deletion; backup can be performed by copying files to a specified backup directory or creating file snapshots; based on the user's confirmation, the redundant files are deleted; image files marked as redundant are deleted using Python file operation functions (such as os.remove); for redundant code, cleanup is achieved by modifying the script file content (such as deleting unused lines of code); after the operation is completed, the file index and related data structures are updated to ensure the system state is consistent with the actual file system. Simultaneously, detailed logs of the optimization operation are recorded, including information on deleted files and code, operation time, etc., for subsequent auditing and tracking.

[0040] Furthermore, in this embodiment, the step of summarizing and organizing the detection results corresponding to each detection type and displaying the organized detection results includes: constructing a detection result data model, summarizing the detection results corresponding to each detection type, classifying and organizing the error information of the detection results, storing the organized detection results in the detection result data model, and displaying them through a graphical user interface or logs, which helps improve the accessibility and usability of the data. This allows developers to correct errors based on the detection results, providing strong support for game development. Specifically, if the program has a graphical user interface (UI), the detection results are displayed intuitively on the interface. For example, a list view is used to display error information, sorted by severity (e.g., syntax errors are displayed first), providing detailed error descriptions and repair suggestions. Charts (e.g., bar charts showing the number of different types of errors) can be used to visualize the detection results. If the program does not have a graphical user interface, the detection results are output to a file or console in the form of detailed logs, including error type, location, related code snippets, etc., for developers to view and analyze.

[0041] Please refer to the figure. Embodiment 2 of the present invention is: a game automation script detection terminal 1, including a memory 2, a processor 3, and a computer program stored on the memory 2 and executable on the processor 3. When the processor 3 executes the computer program, it implements the various steps of the game automation script detection method of Embodiment 1.

[0042] In summary, the present invention provides a game automation script detection method and terminal. It reads detection parameters from a configuration file, including syntax detection rules and comment specification templates. This allows for flexible adjustment of the detection parameters in the configuration file, improving the flexibility and scalability of script detection. It also checks the system operating environment to ensure smooth script detection. Responding to a detection request, it traverses file data and classifies the file data according to file extensions and header features to obtain script files and image files. Combining file extensions and header features improves classification efficiency and accuracy, reduces the possibility of misclassification, and lays the foundation for subsequent corresponding detection types. It detects the script files and image files, and summarizes and organizes the detection results for each detection type, displaying the organized results. The detection types include syntax and logic detection, file association detection, comment specification detection, and redundancy detection. Detecting the script files includes: performing syntax and logic detection on the script files; traversing the lines of code in the script files; matching each line of code with syntax detection rules; and judging the syntax structure and logical relationships of the script files using a syntax detection model. If there are lines of code that do not conform to the syntax detection rules, the first error is recorded. The script file undergoes a series of error checks. The first error message includes the error type, line number, and erroneous code snippet, enabling timely detection of syntax errors and logical vulnerabilities, reducing the likelihood of runtime errors and crashes, and improving code reliability and stability. The script file is then subjected to file association detection, which involves scanning library files in the directory, parsing their contents, extracting library element definition information, and constructing a library file index. Lines of code referencing these library files are located within the script file, and the script file is verified against the library file index. If a line of code is found that does not match the library file, a second error message is recorded, including the error type, error reason, line number, and the name of the referenced library element. This ensures that the script file's references to library files are correct and avoids runtime problems caused by incorrect references. Finally, the script file undergoes a comment style check, which involves extracting comment content, categorizing it according to its location and format, and comparing it with a comment style template. If any comment content does not conform to the template, a third error message is recorded, including the error type, error reason, and the location of the erroneous comment content. This standardizes the comment style according to the comment style template, improving code readability and maintainability.Redundancy detection is performed on the script file. By analyzing the abstract syntax tree or code structure of the script file, unused lines of code are found to obtain redundant code. A fourth error message is recorded, which includes the error type, the script file containing the redundant code, the line number range, and the code snippet content. This process identifies redundant code, optimizes the code structure, improves the execution efficiency of the script file, and records the error information for each detection. This facilitates developers' analysis and improvement of the script file, enhances the quality of automated scripts, and promotes the steady progress of game development. The detection of the image file includes: performing redundancy detection on the image file, comparing the image file with a template image file, calculating the hash value of the image file, and if the hash value is higher than a preset threshold, then the image file is identified as a redundant image; checking the image file in the... The script file references images; if any image files are not referenced, they are identified as redundant. Image files similar to the template image files and unreferenced image files are identified to facilitate redundancy detection and data cleanup by developers, thus improving script execution and project maintenance. The process of summarizing and organizing the detection results for each detection type and displaying the organized results includes: constructing a detection result data model; summarizing the detection results for each detection type; classifying and organizing the error information in the detection results; and storing the organized detection results in the detection result data model. This improves data accessibility and usability, allowing for display through a graphical user interface or logs, enabling developers to correct errors based on the detection results and providing strong support for game development.

[0043] The above description is merely an embodiment of the present invention and does not limit the patent scope of the present invention. Any equivalent modifications made based on the content of the present invention specification and drawings, or direct or indirect applications in related technical fields, are similarly included within the patent protection scope of the present invention.

Claims

1. A method for detecting automated game scripts, characterized in that, Including the following steps: S1. In response to the detection request, traverse the file data and classify the file data according to the file extension and file header features to obtain script files and image files; S2. Detect the script file and image file, and summarize and organize the detection results corresponding to each detection type, and display the organized detection results.

2. The method for detecting automated game scripts according to claim 1, characterized in that, Before step S1, the method further includes: The system reads detection parameters from the configuration file and checks the system operating environment. The detection parameters include syntax detection rules and annotation specification templates.

3. The method for detecting automated game scripts according to claim 2, characterized in that, The detection types include syntax and logic detection, file association detection, comment specification detection, and redundancy detection; The step S2 of detecting the script file includes: The script file is subjected to syntax and logic checks. The code lines of the script file are traversed, and each line of code is matched with the syntax check rules. The syntax structure and logical relationship of the script file are determined by the syntax check model. If there are code lines that do not conform to the syntax check rules, the first error information is recorded. The first error information includes the error type, line number and error code fragment. File association detection is performed on the script file, the library files in the directory are scanned, the contents of the library files are parsed, the library element definition information is extracted and the library file index is constructed, the code lines referencing the library files are found in the script file, and the code lines are verified according to the library file index. If there are code lines referencing the library files that do not match, a second error message is recorded. The second error message includes the error type, error reason, line number and the name of the referenced library element. The script file is checked for annotation specifications. Annotation content is extracted from the script file, classified according to the position and format of the annotation content, and compared with the annotation specification template. If there is annotation content that does not conform to the annotation specification template, a third error message is recorded. The third error message includes the error type, error reason, and position of the erroneous annotation content. Redundancy detection is performed on the script file. By analyzing the abstract syntax tree or code structure of the script file, unused lines of code are found to obtain redundant code, and a fourth error message is recorded. The fourth error message includes the error type, the script file where the redundant code is located, the line number range, and the code snippet content.

4. The method for detecting automated game scripts according to claim 3, characterized in that, The step S2 of detecting the image file includes: Redundancy detection is performed on the image file by comparing it with a template image file and calculating the hash value of the image file. If the hash value is higher than a preset threshold, the image file is identified as a redundant image. Check the reference status of the image file in the script file. If there is an image file that is not referenced, then the image file is identified as a redundant image.

5. The method for detecting automated game scripts according to claim 1, characterized in that, The process of summarizing and organizing the test results corresponding to each test type and displaying the organized test results includes: A detection result data model is constructed, the detection results corresponding to each detection type are summarized, and the error information of the detection results is classified and organized. The organized detection results are stored in the detection result data model and displayed through a graphical user interface or log.

6. A game automation script detection terminal, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it performs the following steps: S1. In response to the detection request, traverse the file data and classify the file data according to the file extension and file header features to obtain script files and image files; S2. Detect the script file and image file, and summarize and organize the detection results corresponding to each detection type, and display the organized detection results.

7. A game automation script detection terminal according to claim 6, characterized in that, Before step S1, the method further includes: The system reads detection parameters from the configuration file and checks the system operating environment. The detection parameters include syntax detection rules and annotation specification templates.

8. A game automation script detection terminal according to claim 7, characterized in that, The detection types include syntax and logic detection, file association detection, comment specification detection, and redundancy detection; The step S2 of detecting the script file includes: The script file is subjected to syntax and logic checks. The code lines of the script file are traversed, and each line of code is matched with the syntax check rules. The syntax structure and logical relationship of the script file are determined by the syntax check model. If there are code lines that do not conform to the syntax check rules, the first error information is recorded. The first error information includes the error type, line number and error code fragment. File association detection is performed on the script file, the library files in the directory are scanned, the contents of the library files are parsed, the library element definition information is extracted and the library file index is constructed, the code lines referencing the library files are found in the script file, and the code lines are verified according to the library file index. If there are code lines referencing the library files that do not match, a second error message is recorded. The second error message includes the error type, error reason, line number and the name of the referenced library element. The script file is checked for annotation specifications. Annotation content is extracted from the script file, classified according to the position and format of the annotation content, and compared with the annotation specification template. If there is annotation content that does not conform to the annotation specification template, a third error message is recorded. The third error message includes the error type, error reason, and position of the erroneous annotation content. Redundancy detection is performed on the script file. By analyzing the abstract syntax tree or code structure of the script file, unused lines of code are found to obtain redundant code, and a fourth error message is recorded. The fourth error message includes the error type, the script file where the redundant code is located, the line number range, and the code snippet content.

9. A game automation script detection terminal according to claim 8, characterized in that, The step S2 of detecting the image file includes: Redundancy detection is performed on the image file by comparing it with a template image file and calculating the hash value of the image file. If the hash value is higher than a preset threshold, the image file is identified as a redundant image. Check the reference status of the image file in the script file. If there is an image file that is not referenced, then the image file is identified as a redundant image.

10. A game automation script detection terminal according to claim 6, characterized in that, The process of summarizing and organizing the test results corresponding to each test type and displaying the organized test results includes: A detection result data model is constructed, the detection results corresponding to each detection type are summarized, and the error information of the detection results is classified and organized. The organized detection results are stored in the detection result data model and displayed through a graphical user interface or log.

Images