System and method for intelligently identifying on-hook state of mobile game based on visual language model

Abstract

The invention relates to the technical field of computer vision and artificial intelligence, provides a visual language model-based mobile game on-hook state intelligent identification system and method, and aims to solve the technical problems of poor generalization ability, high false alarm rate, insufficient adaptability and the like of an existing mobile game on-hook monitoring method. The system guides a VLM (Visual Language Model) to accurately distinguish key abnormal events and conventional game processes in the on-hook process of the mobile game by combining a refined cue word engineering strategy and a dual verification mechanism through a closed-loop process of capturing, analyzing, verifying and notifying. The core lies in that on-hook state intelligent monitoring with low false alarm rate, high robustness and strong generalization ability is realized through collaborative operation of structured rule loading, initial VLM analysis, decision branch judgment, dual verification and structured output, and the method does not need to depend on fixed rules of specific games, is quickly adapted to different mobile games, can efficiently and stably run for a long time, and has a wide application prospect. And the interference of invalid notification on the user is avoided.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of computer vision and artificial intelligence, in particular to a hand game hanging state intelligent identification system and method based on a visual language model, which is used for automatically monitoring the hanging state of a mobile phone game and giving a precise early warning when a key abnormality is detected. BACKGROUND

[0002] With the rapid development of the mobile game industry, the hanging play has become one of the core functions of many mobile games, meeting the needs of players to obtain game resources and complete repetitive tasks without manual operation. However, the hanging process of mobile games is often interrupted by various factors, such as connection failure caused by network fluctuations, service suspension caused by server maintenance, verification requirements triggered by the built-in anti-hanging mechanism of the game, and depletion of resources such as in-game strength and props.

[0003] To solve the problem of monitoring the hanging interruption, two types of solutions are mainly used in the prior art. One type of solution is a monitoring method based on simple image comparison, which stores a reference image of the normal hanging state of the game in advance, captures the current screen in real time and compares it with the reference image, and if the difference exceeds the threshold, it is determined to be abnormal.

[0004] Another type of solution is a monitoring method based on fixed rule scripts, which writes identification scripts for specific game interface elements (such as button positions, text content, icon features), and triggers notifications when detecting preset "abnormal elements".

[0005] However, both of these existing technical solutions have obvious defects. First of all, these existing technical solutions have poor generalization ability. Simple image comparison relies on fixed reference images, and fixed rule scripts rely on specific game interface element features. When the game version is updated (such as interface layout adjustment, text content modification, icon replacement), the existing solutions have to re-create reference images or modify scripts, and cannot adapt to frequent updates of the game interface.

[0006] Moreover, due to the huge differences in interface design and abnormal prompt forms between different games, the existing solutions are difficult to adapt across games. This lack of adaptability results in a high false positive rate. Simple image comparison is prone to misjudging dynamic changes in the game (such as battle effects, character movements) as abnormal, and fixed rule scripts are difficult to cover non-key prompts in the regular game process (such as countdown prompts, upgrade suggestion prompts), which are prone to misjudging such non-key information as abnormal requiring user intervention, resulting in a large number of invalid notifications and serious interference with users.

[0007] In recent years, visual language model (VLM) technology has developed rapidly, which has the ability to deeply understand image content and combine text rules for reasoning, providing new possibilities for intelligent analysis of game pictures. However, general visual language models still have significant shortcomings without specific optimization.

[0008] Specifically, general VLMs lack targeted adaptation to "mobile game hanging scene" and cannot distinguish between "key abnormal events requiring user intervention" and "routine game progress that can be ignored", which easily misjudges non-key information such as routine countdown, recommended upgrade prompts, and dynamic battle pictures in the game as abnormal, resulting in a high false positive rate and failing to meet actual monitoring needs.

[0009] Therefore, how to use the advantages of visual language models to achieve accurate monitoring of mobile game hanging states through targeted optimization, effectively distinguish between key abnormalities and routine progress, reduce false positives, and at the same time improve the generalization ability and adaptability of the scheme, has become a technical problem to be solved in the field. SUMMARY

[0010] To overcome the defects of the prior art, the present application provides a mobile game hanging state intelligent identification system and method based on a visual language model.

[0011] Specifically, the present application provides a mobile game hanging state intelligent identification system based on a visual language model, which includes a picture capturing module, a rule storage module, a VLM analysis module, a double verification module, and an output notification module. The picture capturing module periodically captures game screenshots during the running of the mobile game at a specific capture period. The rule storage module stores structured prompt words, including valid prompt rules and invalid prompt rules. The valid prompt rules are rule features corresponding to hanging interruption events requiring user intervention, and the invalid prompt rules are rule features corresponding to routine game progress that does not require user intervention. The VLM analysis module carries a visual language model pre-trained in multiple modalities and receives game screenshots from the picture capturing module. The visual language model analyzes the picture elements in the game screenshots and makes logical judgments combining "valid prompt rules" and "invalid prompt rules" to output a preliminary judgment result containing an initial Boolean value. The double verification module waits for a preset time interval when the initial Boolean value is "true" and instructs the picture capturing module to capture new game screenshots again, triggering the VLM analysis module to perform secondary analysis on the new game screenshots and output a secondary judgment result forming a secondary Boolean value. The output notification module can only generate structured data containing detailed information of abnormal events and trigger an alarm according to a preset notification method when both the initial Boolean value and the secondary Boolean value are "true". If either the initial Boolean value or the secondary Boolean value is "false", the output notification module does not need to consider the secondary judgment result.

[0012] Preferably, the specific capture cycle can be adjusted, and the configuration range is 5 seconds to 60 seconds.

[0013] Preferably, the graphic elements include interface elements, text information, icon features in the game screenshots.

[0014] Preferably, the initial Boolean value is "true", indicating that the preliminary determination is an abnormal event requiring user intervention; and the initial Boolean value is "false", indicating that the determination is a normal hang-up or an invalid prompt that does not need to be ignored.

[0015] Preferably, the data fields of the structured data include the abnormal event type, the abnormal event title, the abnormal event details, the first capture time, and the verification capture time.

[0016] Preferably, the preset notification mode includes a pop-up window notification, a sound reminder, an SMS notification, and an APP push notification.

[0017] The application also provides a mobile game hang-up state intelligent identification method based on a visual language model, which is executed by the system.

[0018] In summary, the application provides a mobile game hang-up state intelligent identification system and method based on a visual language model, aiming to solve the technical problems of poor generalization ability, high false alarm rate, and insufficient adaptability of existing mobile game hang-up monitoring methods. The system and method implement a closed-loop process of "capture-analysis-verification-notification", combined with a fine-grained prompt word engineering strategy and a double verification mechanism, to guide the visual language model (VLM) to accurately distinguish between key abnormal events and regular game progress during the mobile game hang-up process. The core lies in the synergistic operation of structured rule loading, initial VLM analysis, decision branch judgment, double verification, and structured output, realizing low false alarm rate, high robustness, and strong generalization ability of the hang-up state intelligent monitoring. The application does not need to rely on fixed rules of specific games, can quickly adapt to different mobile games, and can run efficiently and stably for a long time, effectively avoiding the interference of invalid notifications to users, and providing a new solution for mobile game hang-up monitoring. BRIEF DESCRIPTION OF DRAWINGS

[0019] In order to more clearly illustrate the technical solutions in the embodiments of the application or the prior art, the following will describe the drawings needed to be used in the embodiments or prior art description. Obviously, the technical solutions described in the description in combination with the drawings are only some embodiments of the application, and for those skilled in the art, other embodiments and drawings can be obtained without creative labor on the basis of these drawings shown in the embodiments.

[0020] Figure 1A rough flow chart of the mobile game idle state intelligent identification system based on a visual language model according to the present application is shown.

[0021] Figure 2 A detailed flow chart of the mobile game idle state intelligent identification system based on a visual language model according to the present application is shown. DETAILED DESCRIPTION

[0022] The technical solutions of the embodiments of the present application will be clearly and completely described below with reference to the drawings. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all the embodiments. Based on the embodiments described in the present application, all other embodiments obtained by those of ordinary skill in the art without creative labor are within the scope of protection of the present application.

[0023] In general, the present application provides a mobile game idle state intelligent identification system and method based on a visual language model, aiming to solve the technical problems of poor generalization ability, high false positive rate, and insufficient adaptability of existing mobile game idle monitoring methods. The system and method implement the closed-loop process of "capture-analysis-verification-notification", combined with fine-grained prompt word engineering strategies and double verification mechanisms, to guide the visual language model (VLM) to accurately distinguish key abnormal events from regular game progress during the idle process of the mobile game. The core lies in the coordinated operation of structured rule loading, initial VLM analysis, decision branch judgment, double verification, and structured output, realizing low false positive rate, high robustness, and strong generalization ability of idle state intelligent monitoring. The present application does not need to rely on fixed rules of specific games, can quickly adapt to different mobile games, and can run efficiently and stably for a long time, effectively avoiding the interference of invalid notifications to users, and providing a new solution for mobile game idle monitoring.

[0024] Hereinafter, the specific technical content of the mobile game idle state intelligent identification system and method based on a visual language model provided by the present application will be described in detail. Figure 1 and Figure 2 The specific technical content of the mobile game idle state intelligent identification system and method based on a visual language model provided by the present application will be described in detail. Figure 1 A rough flow chart of the mobile game idle state intelligent identification system based on a visual language model according to the present application is shown. Figure 2 A detailed flow chart of the mobile game idle state intelligent identification system based on a visual language model according to the present application is shown.

[0025] First, the specific system architecture of the present application is introduced.

[0026] The mobile game idle state intelligent identification system based on a visual language model of the present application includes a picture capture module, a rule storage module, a VLM analysis module, a double verification module, and an output notification module, which work cooperatively to realize intelligent identification and abnormal early warning of the idle state.

[0027] The core function of the screenshot capturing module is to periodically capture game screenshots during the running of the mobile game at a specific capturing period, providing image data input for subsequent analysis.

[0028] The screenshot capturing module supports custom configuration of the above-mentioned specific capturing period, for example, the configuration range is 5 seconds - 60 seconds, and the default configuration can also be set to 10 seconds. Users can flexibly adjust according to the game type and monitoring needs, for example, for games with stable bot process and low probability of abnormal occurrence, a longer capturing period can be set to reduce system resource occupation; for games with frequent network fluctuations and high incidence of abnormalities, a shorter capturing period can be set to improve abnormal response speed.

[0029] Next, the rule storage module is introduced, which is used to store structured prompts, which are the core basis for the accurate analysis and judgment of the VLM analysis module to be introduced later.

[0030] The structured prompts include two rule sets: "valid prompt rules" and "invalid prompt rules". Among them, "valid prompt rules" clearly define the characteristics (including image features and text features) corresponding to bot interruption events that require user intervention, such as network anomaly prompts, anti-bot verification prompts, and resource depletion prompts. While "invalid prompt rules" clearly define the characteristics corresponding to regular game processes that do not require user intervention, such as regular countdowns, suggested upgrade prompts, and dynamic battle screens. The rule storage module supports dynamic updating and expansion of rules, and users can modify or add rule content according to the adaptation needs of new games or interface changes after game version updates, without the need to restructure the system core logic.

[0031] Next, the VLM analysis module, which is crucial in the architecture of the invention, is introduced. This module, as the core analysis unit of the system, is equipped with a multi-modal pre-trained visual language model (such as BLIP-2, LLaVA, MiniGPT-4, etc.), with the ability to understand image content and reason with text rules.

[0032] The VLM analysis module receives the game screenshots output by the screenshot capturing module and the structured prompts loaded by the rule storage module, and through the visual language model, it deeply analyzes the image elements (such as interface elements, text information, icon features, etc.) in the game screenshots, and combines "valid prompt rules" and "invalid prompt rules" for logical judgment, finally outputting preliminary judgment results containing Boolean values (such as should_notify_user Boolean value). The Boolean value "true" indicates that the preliminary judgment is an abnormal event that requires user intervention, while the Boolean value "false" indicates that the judgment is a normal bot or an invalid prompt that does not need to be ignored.

[0033] Next, the dual verification module, which is also the core module of the architecture of the present application, is introduced, which aims to solve the false alarm problem caused by instantaneous pseudo-exception. The core function of this module is to perform secondary verification on the abnormal events preliminarily determined by the VLM analysis module.

[0034] When the VLM analysis module outputs a Boolean value of "true", the dual verification module starts the verification process, in which it first waits for a preset time interval (for example, the configurable range is 10 seconds - 60 seconds, and the default is 30 seconds), which is set to filter temporary exceptions caused by interface instantaneous flickering, script operation delay, etc.

[0035] Subsequently, the dual verification module instructs the screenshot capture module to capture the game screenshot again, and triggers the VLM analysis module to perform secondary analysis on the new screenshot, outputs the secondary judgment result, and forms the secondary Boolean value. By comparing the results of the two independent analyses, the authenticity and persistence of the abnormal state are ensured. Specifically, only when the initial Boolean value and the secondary Boolean value are both "true", the authenticity and persistence of the abnormal state can be ensured.

[0036] Next, the output notification module is introduced, which is responsible for the structured output of abnormal events and the triggering of user notifications. When the dual verification module confirms that the abnormal state persists (i.e., both Boolean values are "true"), the output notification module generates structured data (e.g., in JSON format) containing detailed information of the abnormal event.

[0037] For example, the data fields of the structured data include event_type (abnormal event type, such as network exception, resource depletion, etc.), event_title (abnormal event title), event_content (abnormal event detailed content), capture_time (first capture time), verify_time (verification capture time), etc., which facilitates subsequent data storage and processing.

[0038] At the same time, the output notification module triggers an early warning according to the user's preset notification method, including pop-up notification, sound reminder, SMS notification, APP push notification, etc., supporting user-defined opening / closing and differentiated configuration (such as pop-up + sound reminder for network exception, APP push notification for resource depletion).

[0039] The method under the above system architecture is introduced in detail below. The mobile game automatic playing state intelligent recognition method based on visual language model of the present application follows the closed-loop process of "capture - analysis - verification - notification", and the specific steps are introduced in detail as follows.

[0040] The first step is system initialization and rule loading.

[0041] In this step, after the system process of this invention starts, the initialization operation is first completed, including loading the VLM model and initializing the configuration of parameters of each module (such as capture period, verification time interval, etc.), and at the same time loading the structured prompt words. The structured prompt words have been pre-designed according to the common needs of mobile game idle scenarios, and "valid prompt rules" and "invalid prompt rules" have been set. The specific meaning of these two rules has been explained in the system architecture introduction above, and further examples are provided here.

[0042] As mentioned above, effective prompts mean that user intervention is required. For example, rule 1: The game interface displays text such as "Network connection failed," "Server disconnected," or "Unable to connect to the game server," accompanied by network error icons (such as a Wi-Fi icon with an X or a signal interruption icon); rule 2: The game interface displays text such as "Anti-AFK detection," "Please click to verify," or "Slide to verify," accompanied by verification controls (such as a verification code input box or a slider control); rule 3: The game interface displays text such as "Stamina exhausted," "Insufficient items," "Energy 0," or "Unable to continue AFK," and the corresponding resource values ​​are displayed as 0; rule 4: The game interface displays text such as "Task completed," "Dungeon ended," "AFK terminated," or "Challenge successful," and the AFK operation button (such as "Continue AFK") is clickable.

[0043] In contrast, invalid prompt rules mean that no user intervention is required. For example, rule A: the game interface displays simple countdown text such as "10 seconds countdown", "5 minutes remaining", "cooldown end time: XX:XX", without any other interactive controls; rule B: the game interface displays non-mandatory suggestion text such as "upgrade equipment", "learn skills", "go to the store to purchase", without any mandatory operation requirements; rule C: the game interface only contains dynamic scenes such as character combat animations, skill release effects, and monster spawn / death animations, without any prompt text; and rule D: the game interface displays regular reward settlement text such as "experience +100", "gold coins +50", "items ×2", without any other abnormal prompts.

[0044] Next, we move on to the second step: periodic image capture.

[0045] In this step, after initialization, the system periodically captures screenshots of the mobile game according to a preset capture period (e.g., 10 seconds by default).

[0046] The capture method can be implemented in different ways depending on the terminal operating system. For example, for Android mobile games, the real-time screen view can be captured and saved as a screenshot using ADB tools; for iOS mobile games, screen recording can be converted into a screenshot or the screen data can be obtained through official APIs; for mobile games running on emulators, the emulator's screenshot API can be directly called to achieve capture. The captured screenshot format can be uniformly set to PNG, and the resolution should be consistent with the mobile game's running resolution to ensure the integrity of image details.

[0047] Next, we move on to the third step: initial VLM analysis and judgment.

[0048] This step receives the game screenshots captured in the second step and the structured prompts loaded in the first step, and inputs the screenshot data and text rules into the visual language model.

[0049] Similar to the previous description, the visual language model first performs image parsing on the screenshot, identifying information such as text content, icon elements, and control positions in the interface. Then, based on the "valid prompt rules" and "invalid prompt rules" in the structured prompt words, it performs logical reasoning on the parsing results: if the information in the screenshot matches any "valid prompt rule", the output boolean value is "true"; if the information in the screenshot matches any "invalid prompt rule", or no rule is matched, the output boolean value is "false".

[0050] For example, when the captured screenshot shows the text "Network connection failed" and a Wi-Fi icon with an X, the model matches "Valid prompt rule 1" and outputs a Boolean value of "True"; when the screenshot only shows the text "Countdown 30 seconds", the model matches "Invalid prompt rule A" and outputs a Boolean value of "False"; when the screenshot only shows the character's combat animation without any prompt text, the model matches "Invalid prompt rule C" and outputs a Boolean value of "False".

[0051] Next, we move on to the fourth step: decision branch judgment.

[0052] This step makes a branch decision based on the true / false value of the Boolean output from the third step.

[0053] Specifically, if the Boolean value is false, it is determined that the current state is normal idle or invalid. No user intervention is required, and the system returns to the second step to continue capturing images according to the preset cycle and maintain the monitoring status.

[0054] If the Boolean value is true, it is determined that there may be an abnormal event that requires user intervention. However, in order to avoid false alarms caused by momentary pseudo-abnormalities, the system enters the fifth step and starts the dual verification process.

[0055] This leads to the fifth step: verification waiting and taking a second screenshot.

[0056] The fifth step initiates the dual verification mechanism. First, it waits at a preset time interval (e.g., 30 seconds by default). This waiting period filters out transient anomalies caused by network fluctuations, interface refresh delays, or temporary script lag (these anomalies usually resolve themselves within a short time without user intervention). After the wait period, the dual verification module controls the screen capture module to recapture the current game screenshot, which serves as analysis data for the secondary verification.

[0057] Next, we proceed to the sixth step: secondary VLM analysis and judgment.

[0058] In this step, the VLM analysis module receives the secondary screenshot captured in the fifth step and uses the same analysis logic as the third step (the same structured prompts, the same VLM model, and the same inference rules) to perform in-depth analysis and logical judgment on the secondary screenshot, and outputs the secondary judgment result (a Boolean value of true or false). The judgment criteria for this Boolean value are consistent with those in the third step.

[0059] The seventh step then begins: verifying the results and making a decision.

[0060] This step makes the final verification decision based on the Boolean value output from step six.

[0061] Specifically, if the Boolean value is false, it means that the anomaly initially identified is a transient pseudo-anomaly (such as a temporary prompt caused by a momentary network jitter, which has returned to normal after 30 seconds). The system ignores the event and returns to the second step to continue monitoring.

[0062] If the Boolean value is true, it indicates that the abnormal state persists (such as the network connection failure problem not being resolved, and the screenshot still showing the relevant prompt after 30 seconds), which is determined to be a real abnormal event, and the system proceeds to the next step, namely, step eight.

[0063] For example, if the initial screenshot shows "Network connection failed" (Boolean value is true), and a second screenshot taken 30 seconds later still shows "Network connection failed" (Boolean value is still true), then it is determined to be a genuine anomaly. If the second screenshot taken 30 seconds later shows the normal game interface (Boolean value changes to "false"), then it is determined to be a transient pseudo-anomaly.

[0064] Then proceed to the eighth step: structured output and notification triggering.

[0065] This step generates structured JSON data for the actual anomalies confirmed in step seven. This data contains key information about the anomaly, allowing users to quickly understand the situation.

[0066] Subsequently, the system triggers an alert based on the user's preset notification method: if the user has configured "pop-up + sound alert," a pop-up containing abnormal information will appear on the monitoring device (such as a computer or mobile phone), and an alert sound will play; if the user has configured "APP push notification," a push message will be sent to the user through the bound mobile application; if the user has configured "SMS notification," an SMS message containing an abnormal summary will be sent to the bound mobile phone number. Users can quickly learn about the abnormal status of the system's idling through the notification and take timely intervention measures (such as checking the network, replenishing resources, and completing verification).

[0067] The following will exemplify a specific application of the present invention to provide a more intuitive understanding of the specific technical content of the present invention.

[0068] This example demonstrates the monitoring of AFK (away from keyboard) gameplay in an Android adventure game (e.g., "Grand Adventure"). The specific application scenario involves a user running "Grand Adventure" on an Android phone and enabling the automatic dungeon-farming function. The system needs to monitor for abnormal events during the AFK process, such as network anomalies, stamina depletion, and anti-AFK verification attempts.

[0069] The specific system configuration of this mobile game is as follows: screen capture cycle: 10 seconds (default configuration); dual verification interval: 30 seconds (default configuration); structured prompt word rules (targeted adjustment).

[0070] The specific valid prompt rules are as follows: the game interface will display abnormal prompt text unique to "XX Adventure", such as "Insufficient stamina, unable to continue AFK" or "Anti-AFK verification, please click the button on the right".

[0071] The invalid prompt rule is: the game interface displays the conventional prompt text unique to the "Great Adventure" mobile game, such as "Remaining dungeon attempts: 3" or "Drop multiplier ×2 (5 minutes remaining)".

[0072] The corresponding notification methods are pop-up notifications, sound alerts, and app push notifications.

[0073] During the operation of this mobile game, after the game system initializes, it captures screenshots of the "Great Adventure" mobile game every 10 seconds. Then, at a certain moment, the text "Insufficient stamina, unable to continue AFK" appears in the screenshot. The VLM analysis module matches the valid prompt rules and outputs a boolean value of "true".

[0074] Subsequently, the mobile game system initiated dual verification and waited 30 seconds before capturing a screenshot again. The second screenshot still displayed "Insufficient stamina, unable to continue AFK". Therefore, the VLM analysis module output a Boolean value of "true".

[0075] Next, the mobile game system output notification module generates structured data in JSON format and triggers pop-up notifications (displaying abnormal information), sound alerts (playing warning sound effects), and APP push notifications (sending push notifications to the user's linked APP).

[0076] After receiving the notification, the user logs into the game to replenish stamina, the AFK status returns to normal, and the system returns to continuous monitoring.

[0077] This concludes the basic introduction of the invention. In summary, this invention provides an intelligent identification system and method for mobile game AFK status based on a visual language model, aiming to solve the technical problems of poor generalization ability, high false alarm rate, and insufficient adaptability in existing mobile game AFK monitoring methods. This system and method, through a closed-loop process of "capture-analysis-verification-notification," combined with a refined prompt word engineering strategy and a dual verification mechanism, guides the visual language model (VLM) to accurately distinguish key abnormal events from regular game progress during mobile game AFK. Its core lies in the collaborative operation of structured rule loading, initial VLM analysis, decision branch judgment, dual verification, and structured output to achieve intelligent monitoring of AFK status with low false alarm rate, high robustness, and strong generalization ability. This invention does not rely on fixed rules specific to any particular game, can quickly adapt to different mobile games, and can operate stably and efficiently for a long time, effectively avoiding interference from invalid notifications to users, providing a completely new solution for mobile game AFK monitoring.

[0078] The above embodiments are merely preferred embodiments of the present invention and are not intended to limit the present invention. The scope of protection of the present invention is determined by the appended claims. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A mobile game AFK status intelligent recognition system based on a visual language model, characterized in that, The system includes an image capture module, a rule storage module, a VLM analysis module, a dual authentication module, and an output notification module. The screen capture module periodically captures screenshots of the mobile game during its operation at a specific capture cycle; The rule storage module stores structured prompt words, which include valid prompt rules and invalid prompt rules. Valid prompt rules are the rule features corresponding to AFK interruption events that require user intervention, while invalid prompt rules are the rule features corresponding to regular game processes that do not require user intervention. The VLM analysis module is equipped with a multimodal pre-trained visual language model and receives game screenshots from the screen capture module. The visual language model parses the graphic elements in the game screenshots and performs logical judgments based on "valid prompt rules" and "invalid prompt rules" to output a preliminary judgment result containing an initial boolean value. The dual verification module, when the initial Boolean value is "true", waits for a preset time interval and then instructs the screen capture module to capture a new game screenshot again, and triggers the VLM analysis module to perform a second analysis on the new game screenshot, outputting the second judgment result to form a second Boolean value; The output notification module can only generate structured data containing detailed information about the abnormal event and trigger an alert according to the preset notification method if both the initial Boolean value and the secondary Boolean value are "true". If either the initial Boolean value or the secondary Boolean value is "false", the output notification module does not need to pay attention to the result of the secondary judgment.

2. The system according to claim 1, characterized in that, The specific capture period can be adjusted, and the configuration range is from 5 seconds to 60 seconds.

3. The system according to claim 1, characterized in that, The graphic elements include interface elements, text information, and icon features in the game screenshots.

4. The system according to claim 1, characterized in that, An initial Boolean value of "true" indicates that the event is initially determined to be an abnormal event requiring user intervention; an initial Boolean value of "false" indicates that the event is considered normal and can be ignored.

5. The system according to claim 1, characterized in that, The data fields of structured data include exception event type, exception event title, exception event details, first capture time, and verification capture time.

6. The system according to claim 1, characterized in that, The preset notification methods include pop-up notifications, sound alerts, SMS notifications, and app push notifications.

7. A method for intelligent recognition of idle status in mobile games based on a visual language model, characterized in that, The method is performed by the system according to any one of claims 1-6.

Images