Bot in anthill


    Another game bot for "Space Rangers HD" ( 1C publisher ) leads to interesting thoughts about the ways of developing artificial intelligence (AI).

    Some lyrics


    You can rephrase the epigraph to a riddle:

    Flies in a circle,
    Doesn’t bother anyone ,
    They take off from it,
    And they are killed ...

    (Rogeria)


    Bit of theory


    Machines are made to facilitate the work of man. And, moreover, in order to carry out work that a person himself cannot do. For example, an ordinary person cannot lift a load weighing half a ton, but with the help of a system of blocks, he can. Computing machines — computers and their software — serve the same purposes as other machines. For example, the task of sorting several tens of thousands of words alphabetically for a person will be tedious, he will do it for a long time, and the likelihood of errors for an average performer with an average level of responsibility will be significant. A modern computer will accomplish this task without errors in a very short time (fraction of a second) for a person. All this is well known and is said here only in order to define AI. Without claiming to be original in this definition, I note that there are a lot of definitions of AI,

    So, we offer the following definition : AI includes tasks that a computer solves noticeably worse than a person.

    It is clear that if you make a list of such tasks for today and a list for tasks fifty years ago, then these lists will differ. However, the differences will not be as strong as the differences in general computing capabilities for today's computers and computers, which were half a century ago. That is, productivity and memory volumes increase by many orders of magnitude, and almost all hard-to-solve tasks remain hard-to-solve. There is intentional ambiguity. From the point of view of the theory of computational complexity, hard-to-solve problems are problems with an exponential theoretical estimate of the number of operations from the dimension of the problem in the worst case. While the main question of this theory is “P =? NP "continues to be open. In AI, there are tasks that are “simply” solved by stupid brute force, if such brute force was possible in time, for example, chess. However, many other AI tasks do not explicitly require an exponential number of operations and at the same time look difficult to solve not because of computational complexity, but because of the difficulty of building reliable and efficient algorithms for their solution. Obviously, such a second meaning of the term “difficult to solve” is qualitatively different from the first: in the theory of computational complexity, this term means a strictly provable exponential estimate, while in the second meaning, rigorous mathematical proof of the difficulty of constructing reliable and efficient algorithms seems extremely difficult. Moreover, we do not consider algorithmically insoluble problems and believe that if a person copes with a task, then there is an algorithm for solving it. However, many other AI tasks do not explicitly require an exponential number of operations and at the same time look difficult to solve not because of computational complexity, but because of the difficulty of building reliable and efficient algorithms for their solution. Obviously, such a second meaning of the term “difficult to solve” is qualitatively different from the first: in the theory of computational complexity, this term means a strictly provable exponential estimate, while in the second meaning, rigorous mathematical proof of the difficulty of constructing reliable and efficient algorithms seems extremely difficult. Moreover, we do not consider algorithmically insoluble problems and believe that if a person copes with a task, then there is an algorithm for solving it. However, many other AI tasks do not explicitly require an exponential number of operations and at the same time look difficult to solve not because of computational complexity, but because of the difficulty of building reliable and efficient algorithms for their solution. Obviously, such a second meaning of the term “difficult to solve” is qualitatively different from the first: in the theory of computational complexity, this term means a strictly provable exponential estimate, while in the second meaning, rigorous mathematical proof of the difficulty of constructing reliable and efficient algorithms seems extremely difficult. Moreover, we do not consider algorithmically insoluble problems and believe that if a person copes with a task, then there is an algorithm for solving it. and due to the difficulty of building reliable and efficient algorithms for their solution. Obviously, such a second meaning of the term “difficult to solve” is qualitatively different from the first: in the theory of computational complexity, this term means a strictly provable exponential estimate, while in the second meaning, rigorous mathematical proof of the difficulty of constructing reliable and efficient algorithms seems extremely difficult. Moreover, we do not consider algorithmically insoluble problems and believe that if a person copes with a task, then there is an algorithm for solving it. and due to the difficulty of building reliable and efficient algorithms for their solution. Obviously, such a second meaning of the term “difficult to solve” is qualitatively different from the first: in the theory of computational complexity, this term means a strictly provable exponential estimate, while in the second meaning, rigorous mathematical proof of the difficulty of constructing reliable and efficient algorithms seems extremely difficult. Moreover, we do not consider algorithmically insoluble problems and believe that if a person copes with a task, then there is an algorithm for solving it. whereas in the second sense, rigorous mathematical proof of the difficulty of constructing reliable and efficient algorithms seems extremely difficult. Moreover, we do not consider algorithmically insoluble problems and believe that if a person copes with a task, then there is an algorithm for solving it. whereas in the second sense, rigorous mathematical proof of the difficulty of constructing reliable and efficient algorithms seems extremely difficult. Moreover, we do not consider algorithmically insoluble problems and believe that if a person copes with a task, then there is an algorithm for solving it.

    At the current stage of the development of AI, human skills look like an ideal that you need to strive for, however, people often make mistakes. The level of these errors is different - from elementary errors caused by a lack of necessary knowledge of a particular person, his carelessness, fatigue, to more complex ones such as illusions and cognitive distortions . This implies an important question: is it possible to solve AI tasks better than a person does, i.e. whether “super-intelligence” is possible, or whether a number of AI tasks, in principle, are not always possible to solve correctly, i.e. will there always be a non-zero probability of an erroneous decision? A few examples were in my previous post , in particular:

    a well-known example of difficult recognition [for humans] is captcha, which you stumble on the Internet at every step. There are such scribbles that you have to press the CAPTCHA change button several times before you manage to “prove that a camel is not a robot.
    Another important point mentioned in the publication is autonomy:
    absolute autonomy is a harmful myth. At least for the coming decades. On his own and other people's experience, the author [David Mindell “The revolt of the machines is canceled! Myths about robotization ”] shows in detail that today the most successful are systems where the interaction of a person with a machine is quite fully realized, and not the alienation of a person from the decision-making process. I personally became convinced of the correctness of this idea on my humble example of game bots for the KR2HD game: the bot for planetary battles, according to our idea, should be completely autonomous, and now this project has stalled.
    So, many definitions of AI are proposed. In accordance with these definitions, there are various classifications of AI tasks. Without claiming originality (as in the case of the definition), we take the following classification. This is a classification by purpose.

    The goal of rational AI is to choose the level of autonomy at which:

    1) the program will be useful;
    2) the program will not be mistaken too often, in comparison with the person;
    3) the program will not be overly complicated for writing, debugging and maintenance.

    Another class in our classification is the “revolutionary” AI. Its purpose is to make the program as autonomous as possible. Such a program is usually of scientific and sporting interest, while its practical value may be close to zero.

    From the point of view of the above classification, the solution to the problem posed below is rational. Nothing particularly revolutionary is proposed here, but I express hope that such a moderate approach, proceeding from real possibilities and oriented towards practical use, is of particular interest to science.

    I note that the definition does not specify a solution method. A simple practical ideology follows from the proposed definition: if a problem is found that the computer solves worse than a person, then this is an AI task. And you can solve it as you like - just to be solved: you can use neural networks and training, but you can not use it. It is hoped that the proposed rational approach, as a result of which will inevitably accumulate experience in solving such problems, will advance AI. In general, this is what happens: too ambitious projects fail, while more modest ones slowly, but still pushing AI to new frontiers.

    It is also worth mentioning about the methods of researching AI. Of course, even a simple robot, assembled from the standard parts of the robot designer, is very spectacular, contributes to the popularization of AI ideas and well attracts non-sophisticated AI sponsors. Unfortunately, the reproduction of an experiment with such a robot will run into obvious difficulties, and the scientific method requires reproducibility. Therefore, scientifically, the game bot for a fairly common, not specially composed for this laboratory research game seems more interesting.

    And finally, moving from theory to practice, we note that, probably, it will not be possible to find fundamental work on AI, where philosophical issues closely related to AI are not mentioned. Without underestimating their significance, we note that the definitions proposed above allow us not to delve into many of these issues in the framework of this work.

    Task


    The main goal of the game КР2HD is to score as many points as possible. The game calculates points according to the formula:

    Points = Experience * Difficulty / 100 / max (7, Game Time / 365) ^ 1.3 ,

    where Experience is awarded, including for the destruction of enemies, in particular, for the destruction of pirates;
    Difficulty - from 50% to 200%, among other starting conditions, is set by the player before starting a new game;
    Game time is days in the game: each turn is one day.

    The game begins with the game date January 1, 3300 and can develop along several storylines. However, experienced players know that the longest battle with the pirates (more precisely, their beating) in the star system of Tortugac brings the most points. This is the culmination of the game: the previous part of the game is, in essence, preparation for this battle, and the next part is very short and consists in ending the game at the appropriate base ending as soon as possible in a few days, as in the future the points will only decrease . A sharp increase in the number of pirates destroyed by the player, accompanied by a sharp increase in points, is clearly visible on the graphs of the top table of the game's records : Robo Brain - first place, SHERIFF - second:




    As you can see, the battle lasts several game years, but can stretch to 20 years or more. When playing for a record with enumerating several options to achieve the maximum number of points (this game technique will be described below), a player can spend several real months or more on the battle in Tortugac!

    The Tortugats system becomes available to the player after completing a series of tasks, which we will not dwell on. The system consists of two uninhabited planets and one pirate base called Rogeria, which, like the planets, rotates in a circular orbit around the star. The diameters of the orbits are different, so a collision is impossible. After performing several actions, flying to and taking off from Rogeria, the player gets the opportunity to destroy about 13 pirates every day, who will take off daily from the "ant hill" of Rogeria. The game has different weapons, but the so-called weapons of mass destruction (WMD) are most suitable for this battle: Vertix and IMHO-9000.



    The figure in the lower left corner near the stylized cube shows the weight of the item. So, the vertix shown in the figures weighs 190 units, and the IMHO-9000 weighs 113. A gurand is a so-called micromodule, which, when installed in a gun, increases its strength, as a result, the gun wears out less with each shot and with the return shots of enemies. The installed micromodule cannot be removed from the gun. Depreciation is shown by a "thermometer" at the top. An important feature of WMD is the defeat not only of the enemy ship the gun is aimed at, but also of all enemy ships within the range of the gun. At the same time, if the target of the next gun is so fragile that it will be destroyed from the shot of the previous one, then the next gun will have nowhere to shoot: within the range of the volley, the volley does not happen simultaneously, and the guns fire in turn.



    Each such target trunk is equipped in advance by the player with a protective field generator (GDF) and a repair droid repairing the trunk body. Thanks to this, the trunk can withstand multiple shots from one or more player’s weapons of mass destruction. All equipment used on ships gradually wears out, but wears out at different speeds. Worming gear practically does not wear out over the course of many game years, but the repair droid wears out relatively quickly. To repair the droid and other equipment, except for weapons of mass destruction, there is an artifact of nanitoids (or just naniks, see fig.), When installed in a special slot of the ship, repair of worn equipment takes place in just a few moves (in addition to the above, it can be an engine, a fuel tank , radar, capture and scanner). Each ship has a hold where equipment, weapons and trunks that are not currently in use can be stored. In the hold, all these things hardly wear out. Therefore, in order to avoid premature wear of the nanics, they must be removed immediately from the slot in the hold upon completion of the repair.

    As already mentioned, WMDs are not repaired, so after complete wear and tear WMDs have to be thrown into space, where it can be picked up and transported to Rogeria using a trunk equipped with a grip. For the success of the Roger Campaign, a very good equipment of the player’s ship is necessary - in this case, even a few dozen pirates will not pose any threat to him, like ants beetles.

    During the battle, the player’s ship should not land on Rogeria - as soon as it sits, the battle will stop and the pirates will cease to fly every day under the player’s guns. Therefore, the player takes as many WMDs with him. This amount is limited by the player’s ship capacity - the maximum allowable total weight of all things on the ship. However, there is also a tactical technique that allows you to take more weapons of mass destruction than the ship holds. To do this, place WMD in the gun slot of the trunks. Each trunk, like the player’s ship, has five gun slots (ships with fewer slots for the battle in Tortugac will be ineffective and usually do not use them). It is pointless to load WMD, like other things, into the trunk of a trunk, since when loading a trunk into a player’s cargo hold, the trunk will automatically unload all the contents of its hold in the cargo hold.here ) the trunk does not unload. The weight of such equipment is not taken into account for loading a player’s ship. For example, the trunk weight in the figure will always be 49 units, even if WMDs with a total weight of 500 units are installed in its slots. Therefore, in addition to target trunks, the player takes with him to Tortugats as many trunk trunks as possible with spare WMD kits installed in them and fights with pirates until all WMDs become unusable.

    The following screenshot of the game shows a portion of the screen with Rogeria on the right, the player’s ship and target trunks. The WMD pictograms for trunks show which player’s WMDs are aimed at them. The picture also contains numerous fuel barrels that fall out of the pirate ships upon destruction. In addition to barrels, there are still minerals formed during the collision of meteorites with ships and the base. The green dotted line from the player’s ship to the trunk indicates the course of the ship, which he will follow next turn. In this case, the ship will follow the trunk.



    To set the course, the player needs to move the mouse cursor over a point on the screen and press the left mouse button (“click on a point”). If this point is located near the trunk, the ship will follow the trunk not to the point on the screen to which it was indicated, but where the trunk will fly. If the point is in the vicinity of Rogeria, then the ship will land on Rogeria and the battle will end ahead of schedule. So that the landing does not happen, you need to double-click on the point. All these features of the course design should be considered by the game bot.

    As you can see, from the point of view of movements, the game space appears to be two-dimensional, but it is worth considering the third coordinate axis, perpendicular to the plane of the screen and directed towards the player, since objects of the game world (ships, base, barrels, meteorites, etc.) are placed on different layers along this axis and can block each other.

    The background should be attributed to the zero, farthest layer from the player. In the game settings, we turned off the background image, so the background became evenly black. On the next layer are the planets and Rogeria. On the next - barrels and meteorites. So, the figure shows that some barrels obscure part of Rogeria. Next on the next layer are the trunks and pirate ships, then the WMD pictograms, then the player’s ship, the fire of shots and, finally, the information layer closest to the player: messages and dialogs of the game close all other layers.

    Using the keyboard function keys, you can save and load the game. So, when saving, a dialog with the name of the system appears on the screen - in our case there will be “System Tortugats”. If such a save has already been made, the next number is added to the save name. The saved game will be written to a file under the same name and with the extension “.sav” in the internal encrypted format of the game. To trigger the dialogue, just press the Enter key on the keyboard.



    A feature that is very important for the bot is the dump of the game at the moment: typing “MAKEDUMP” on the keyboard while holding down the Ctrl and Shift keys, we will see a dialog, just like when saving the game normally. However, by pressing the Enter key, we get not only a file with the extension “.sav”, but also a text file with the extension “.txt” under the same name. The file has a tree structure, recorded using nested brackets, which contains a lot of necessary information about the player’s ship and the trunks activated by it. Unfortunately, some necessary information is missing there. In particular, the wear of the trunk body does not correspond to the reality of the game. The screen coordinates of each barrel are indicated, but there are no Rogeria coordinates and active trunks. The bot will have to obtain this information using computer vision. We’ll talk about this below, and now, to end the dump, note a simple trick with naming files: we check whether there are files with the names “Tortugatsdmp.sav System” and / or “Tortugatsdmp.txt System” in the game’s save folder, and if there is one, delete it. To the name of the dump we need, the bot, simulating keystrokes on the keyboard, will add “dmp” in the game’s dialogue. Thus, the bot knows which file it needs to read after the game writes it, for this the bot is waiting for access to the file. Note that text with a volume of approximately 9 MB is written to disk from a human point of view very quickly, but not instantly from the point of view of the program, therefore, in order to avoid bot malfunctions, all such conflicts must be foreseen. imitating keystrokes on the keyboard, will add “dmp” in the game’s dialogue. Thus, the bot knows which file it needs to read after the game writes it, for this the bot is waiting for access to the file. Note that text with a volume of approximately 9 MB is written to disk from a human point of view very quickly, but not instantly from the point of view of the program, therefore, in order to avoid bot malfunctions, all such conflicts must be foreseen. imitating keystrokes on the keyboard, will add “dmp” in the game’s dialogue. Thus, the bot knows which file it needs to read after the game writes it, for this the bot is waiting for access to the file. Note that text with a volume of approximately 9 MB is written to disk from a human point of view very quickly, but not instantly from the point of view of the program, therefore, in order to avoid bot malfunctions, all such conflicts must be foreseen.

    It is also worth noting that the game provides: a setting in which each move is saved in the “TurnSave.sav” file, and a hot key for quick saving, when you click on it, the game file “QuickSave.sav” is recorded without any dialogs, and, accordingly, quick save loading key, for which loading an affirmative answer to the yes / no dialog is required. A number of other useful features for the bot, we note below in its description. And here, to end the conversation about the file system of the game, we note that the actions with the game take noticeable wait time for the bot. After downloading, the file may become free, but the game will require additional time to process the information in order to become active. For basic file operations, the game screen is replaced by a splash screen with a progress indicator (“thermometer”). Exceptions like file write errors can occur. Other crashes occurring from game bugs are likely. All this adds objective complexity and uncertainty to the bot. Obviously, if the game used any means of inter-program interaction, for example, COM, then these difficulties would not have been. Thus, the game does not have any devices for the boto structure, and the bot from the side of the game should essentially pass the Turing reverse test, i.e. to be indistinguishable from a human player for a game. the game does not have any devices for the boto structure, and the bot from the side of the game should essentially pass the Turing reverse test, i.e. to be indistinguishable from a human player for a game. the game does not have any devices for the boto structure, and the bot from the side of the game should essentially pass the Turing reverse test, i.e. to be indistinguishable from a human player for a game.

    At first glance, the described game may not seem very interesting, however, judging by the above-mentioned table of records containing more than 200 records, you will have to admit that the game is enjoying some success. From the description it is clear that the game is not simple and requires patience, accuracy and attention from the player. Obviously, such a task is much more interesting for creating a bot than an artificial laboratory game, in which no one plays and which was created exclusively for AI research. It should be noted that the purpose of this article is not to discuss the game - such a discussion was made earlier. Here, only particular features are noted that affect the behavior of the bot in one of the phases of the game. Therefore, the above brief description in no way can pretend to instructions for the game.

    Problems and Solutions


    Above, we have already noted a number of problems. In their essence, we can already conclude that the bot should use the techniques of real-time programs, despite the fact that the game itself is a turn-based strategy (we will not talk about planetary and arcade battles here) and that Windows is not a real-time system. In addition, the bot can get some necessary information only through computer vision, recognizing information from screenshots of the game. (We will not consider an alternative hacker way to access the game’s RAM or save files, for example, using ArtMoney and similar tools, since this is not only not sports, but also uninteresting - just write yourself any number of points and talk no more about than).

    It has already been noted above that Rogeria revolves around the star in a circular orbit, so the player’s ship must follow it so that the flying pirates are in the zone of destruction of the ship’s weapons of mass destruction. There is a not-so-well-known tactic called wheel landing. The base has parts reminiscent of wheels - why they are so gigantic space device, one can only guess. If you “click” on the “wheel” and make a move, then landing on Rozhderiya does not occur, the ship sticks to the “wheel” and each next turn will follow the base.



    Unlike the previous figure, here in the game settings the space background is not removed.

    The described method of landing on the wheel significantly saves the time of the game, however, some pirates taking off from Rogeria manage to leave the player’s WMD defeat zone. More experience and points can be obtained if each turn the ship finds itself above the geometric center of Rogeria (“above” - taking into account the remark made above on the layers of the third dimension of the game world).

    The strength of the hulls and the equipment of pirates taking off from Rogeria change randomly every day. The champions of the game found that changes in the flying pirates occur if you "talk" with the trunk, i.e. by pressing the “T” key (conversation), move the mouse cursor over the trunk and press the left mouse button. A modal dialogue will open in which you can select a task for this trunk (“follow me”, “go back”, “start collecting things”, etc.) You can choose no command and press the Esc key - the dialog will close, but the composition of the soaring pirates will be different. Another such empty talk will again change the composition of the soaring pirates. Thus, for the maximum score you should try to spend one, two, three, etc. conversations with the trunk, each time returning to the previous move, and choose a case,

    As already noted, in the dump there are no base coordinates and trunks, but you need to know them in order to be above the center of Rogeria and cause the trunk. To find these coordinates in the bot, the functions of the OpenCV computer vision library are used .

    The bot, imitating pressing the hot keys of the game, centers the image, as a result, the player’s ship is in the center of the screen, because we assume that in previous moves the ship did not move far from Rogeria. However, in order to avoid errors, the bot will still work with a full-screen image. Next, the bot makes a quick save and removes the WMD marks from the screen. Rogeria, without turning at all, flies around the star, the sprite is large enough, so it is well recognized by the template below. Barrels and minerals spin in place around their (seemingly arbitrary) axes. This garbage is commensurate with the size of the trunks and interferes with their recognition. Therefore, by means of the game, the bot takes two screenshots with an interval of 4 seconds, downloads them, and finds them in the first to Rogeria according to the template, and then adds them pixel by pixel.


    (Size: 100 x 93)

    Rotating debris is smeared. Further, all pixels in the RGB model that differ in each color component from the reference image of Rogeria (without any debris) by no more than 20 units (experimentally selected value) are blackened. Thus, Rogeria is removed from the resulting image, but objects of closer layers remain that could partially cover it. Next, the bot cuts a square of 700 x 700 pixels with a center in the center of the screen, additionally blurs this image using the OpenCV cvSmooth function with parameters CV_GAUSSIAN, 9, 9 (selected experimentally) and proceeds to recognize trunks.

    Unlike Rogeria, the trunk can be rotated by an angle multiple of 45 degrees, and the OpenCV recognition function used by the cvMatchTemplate pattern is not invariant to rotation. Therefore, we sequentially look for trunks according to eight possible patterns:



    Unfortunately, at this stage, garbage can be confused with a trunk, therefore, a similarity measure is additionally determined for each object found. A similar pixel is a pixel that for each color component in the RGB model does not differ from the corresponding pixel in the template by more than 45 units and has a brightness of more than 18 units, thus eliminating gray debris that can be overlapped by a recognized trunk. The similarity measure is calculated as the ratio of the number of similar pixels to the number of all pixels in the template, multiplied by 100% and rounded to the nearest integer.

    The following figure shows the image recognized in the described way: the recognition area is enclosed in a large red square, objects recognized as trunks with a similarity criterion of more than 10% are enclosed in red rectangles (centers are found by small squares), objects found by cvMatchTemplate but not passed by criterion for the measure of similarity - in blue rectangles. Numbers are a measure of similarity.



    Unfortunately, tests show that even with such multi-stage recognition with subsequent refinement, errors occasionally occur. Therefore, the list of found objects, which are supposedly trunks, is finally checked by the means of the game: each alleged trunk is called up for conversation. If this is really a trunk, then the following modal dialog appears in the upper right corner of the game screen:



    This dialog is confidently recognized by the template: in



    the manner described, with the calculation of the similarity measure at a threshold value of 80%. If the object is not a trunk (and not a pirate, see below), the dialog does not appear, and the inscription appears in the center at the top of the screen "Talk is impossible." The inscription quickly disappears, and taking any action to recognize it seems unnecessary.

    With a large amount of garbage, situations happen in which none of the indicated objects respond as a trunk. In this case, all found objects are painted over in black, and a new attempt is made to search for trunks. The experiment shows that in some cases this helps. And when it does not help, you can once again take two screenshots and repeat the entire recognition procedure. If this does not help, then the bot has to admit its powerlessness and turn to the player for help. Tests show that such situations occur rather rarely, much more often the bot stops due to the need for repair work on the ship and trunks in the game.

    Fuel barrels interfere not only with trunk recognition, but also pose a direct threat to the desired course of the game. When a lot of barrels accumulate, one of them explodes from a shot, causing explosions of adjacent barrels - a chain reaction occurs with an avalanche-like growth. As a result, the number of barrels decreases sharply, but explosions can destroy the trunk and, with insufficient protection, damage the player’s ship. It is impossible to accurately predict the course at which this will occur, therefore, in the event of a trunk loss, the player has to return to save the game several days before the explosion and replay. In addition, when the bot is playing, sometimes the barrel is captured by the player’s ship. Therefore, when the bot stops, the player should inspect the hold for throwing barrels into space.

    Sometimes during the game a pirate appears that threatens the player. In this case, a modal dialog opens, similar to the dialog with a trunk, but with a different text. Despite the fact that the text is different, the template for recognizing a dialog with a trunk is suitable for this case as well. the set value of the similarity measure is not too large. The bot at each turn checks the screenshot of the game for such a dialogue and, if detected, simulates pressing the Esc key to close the dialog. Otherwise, further operation of the bot will be impossible. Also, sometimes, some pirate ships, when recognized by a bot, appear like a trunk. In this case, when searching for options, the bot can cause a pirate to talk, like a trunk.

    In some cases, it turns out that the simulation of pressing the Esc key was superfluous, which leads to the appearance of the main menu of the game (also a modal dialogue) in the center of the screen. The bot checks for such situations after each simulation of pressing the Esc key, recognizing the following pattern in the screenshot:



    To close the main menu, the bot must repeat the simulation of pressing the Esc key.

    Having made a test move, the bot determines the coordinates of the center of the rectangle that describes Rogeria, and, returning back a step, tries to plot a course at this point. However, a trunk or a pirate may be close to this point, and then the player’s ship will fly behind the trunk (or pirate), and not at the specified point, so the bot tries another option - make a move in which the ship remains in the same place. After that, the bot compares these options and selects the one in which the distance from the center of the ship to the center of Rogeria is less.

    Having set the goal of writing a rational bot, we will limit its independence as follows: the bot will make moves, monitoring the wear and tear of the equipment and the safety of the trunks under observation. He will independently try options with 0, 1, 2, etc. conversations with trunks and choose the option with the maximum experience. Will monitor the wear of the WMD. However, we will provide the player with the replacement of WMDs and fixing the equipment - the bot will stop when the player’s intervention is required to change the WMDs or install the nanik in the slot or remove the nanik from the slot in the hold. Also, the bot will stop in the event of the death of a trunk under observation, so that the player chooses a return day and takes measures to additionally protect the trunk (for example, would install additional protective artifacts on the trunk or cease to use this trunk as a target for several days). Purely technically, these operations could also be automated, but there are many situations with ambiguous decisions, and, in my opinion, you should not deprive the player of the pleasure of making these decisions on their own - otherwise the game will completely lose interest for the player and why then the bot. Let the bot perform the most tiring and routine part of the game, and let the player remain the most interesting and not so burdensome part. Do not deprive the player of the pleasure of making these decisions on their own - otherwise the game will completely lose interest for the player and why then the bot. Let the bot perform the most tiring and routine part of the game, and let the player remain the most interesting and not so burdensome part. Do not deprive the player of the pleasure of making these decisions on their own - otherwise the game will completely lose interest for the player and why then the bot. Let the bot perform the most tiring and routine part of the game, and let the player remain the most interesting and not so burdensome part.

    The task of tracking equipment for repair seems to be simple for programming the bot, but here's the problem: in the game dump, equipment and artifacts installed in the ship’s slots and located in its hold are not distinguishable. Therefore, the bot will warn the player about the wear of the equipment under observation when the wear reaches a certain limit value, memorize this equipment and inform the player if the wear of the stored equipment decreases to the point from which the equipment will no longer repair. In the first case, the player must put the crap from the hold into the slot of his ship or trunk, in the second - do the opposite operation.

    GUI


    The main tab of the bot window is shown in the following figure.



    The bot can play in two modes: in full-featured and in accelerated with reduced functionality. The choice of mode is determined by the number of conversations with the trunk - the “Conversations” field. If this number is greater than zero, then the bot makes the first test move, then returns to the previous day, calls one of the active trunks for conversation, closes the dialogue and makes a move, then returns to the previous day again and speaks with the trunk again. And so many times, how many conversations are indicated in the "Conversations" field. Of all the attempts made, the one that brought the maximum experience is selected.

    To play in accelerated mode, the player needs, as described above, to “stick” the ship to Rogeria by landing on a wheel. In this mode, the bot does not need to recognize the base and trunks, making screenshots at each turn, so the speed of passage increases noticeably, and the number of errors is greatly reduced. For even faster passage at a low level of wear of everything under observation, the bot can not dump the game every day: you can set the frequency of dumps in the “Analysis frequency” field. When the wear becomes close to critical, the bot will switch to a daily dump analysis.

    As already noted, for the bot to function properly in the game, the appropriate settings must be made. Therefore, at the first launch, the bot offers to make the necessary changes to the game configuration file in the dialog. If the player agrees, the bot will copy the CFG.TXT game configuration file to the CFG.BAK file and make the necessary changes to the CFG.TXT file. To return to the previous configuration, the player needs to launch the bot and click on the button “Return CFG file”. The bot will delete the CFG.TXT file and rename the CFG.BAK file to CFG.TXT. The next time the bot is launched, it will not find the CFG.BAK file and will suggest making the necessary changes to the game’s configuration file.

    Learning, self-learning and self-knowledge


    AI places high hopes on learning, and especially on self-learning. In this regard, it is worth recalling well-known facts: what is the situation with the improvement of natural intelligence - above all, with the education of children. Since the time of cavemen it has been universal, even the hero of Kipling Mowgli is taught to read the jungle book. Many masters and good specialists in different fields have been studying all their lives, but still for a large number of adults, education is not considered as mandatory as it is considered mandatory for the child. In this regard, without underestimating the role of self-education, one still has to admit that traditionally all peoples focus on education, and on rigid modal education such as “do it”. So basically parents, educators and school teachers teach and educate: “wash my hands before eating”, “Don’t bite your nails”, “don’t hold a spoon in your fist”, “you should hold the soldering iron like a pencil”, “don’t put off until tomorrow what you can do today”, “you cannot work in a tie on a lathe - it can wrap and strangle”, “You should not do with others as you would not want them to do with you”, etc. In this case, the rationale is optional. Indeed, you can try to explain to the child why you need to wash your hands before eating, but it is much more difficult to explain why you can not keep a spoon in your fist - because it is more convenient for him to hold it. Each student will understand that the moving parts of the machine can wrap a tie, but there are debaters who will say that the tie can be short, that it can be long with a pin, etc. The standard line of behavior for teachers and instructors is to avoid such disputes:

    Self-education in childhood education is usually given a secondary role. Of course, there are talented children, and there are many cases when an interested student independently learns from books something that is not included in the school curriculum. However, such cases are usually considered as exceptions, albeit quite numerous, from the general rule. It is usually noted that the knowledge gained by the student as a result of such self-training is usually superficial and not systematic, and sometimes erroneous, if he could not figure it out or did not understand it. Obviously, for an adult, a sufficiently educated person, self-education usually goes much more fruitfully.

    With that said, the idea of ​​a fully self-learning AI program seems dubious. Currently, we know quite well only one system of principles of primary education - the education of children. Therefore, we have no choice but to apply these principles to AI. And, in particular, the noted principle of modal teaching by the teacher with the optional learning. In fact, modal learning “do it this way” does not differ from programming the rules of conduct in the subject area. In the case of the bot described here, the above rules for solving problems arising during the game are sewn up in the form of program code. During tests of this code, parameters are refined, for example, thresholds for a measure of similarity.

    Continuing the list of problems, we will talk about the problem of firing shots: after pressing the space bar, the game makes a move, another batch of pirate ships takes off from Rogeria, the guns of the player’s ship fire a shot and then everything is in smoke, as in the screenshot below, taken after 3.5 seconds. after the bot presses the spacebar (the game command "make a move").



    Such a picture is not suitable for recognition - you need to wait for the smoke to disperse and the objects will stop moving. To minimize this pause, use the Rogeria bot tab:



    After clicking on the “Create Series” button (the inscription on the button changes to “Cancel”), a message appears prompting the player to go to the game screen and press F10. The bot will take a series of screen photos (“screenshots”) with a delay corresponding to the parameters specified by the player. Next, the player views this series and selects an acceptable pause. (In the figure, in the Result field behind the file name, the pause value in ms is written through the separator “=”.)

    In this connection, an interesting theoretical question arises: can the described process be called learning? And if not, then what is the modal order of the educator for the child “my hands before eating” essentially differs from the player’s order to bot “after a move, pause for 4 seconds. and only after it take screenshots? "

    The choice of a pause could be completely automated, for example, by the following self-learning scenario: at the beginning, the bot sets a clearly overestimated pause, and then reduces it until the recognition results deteriorate sharply. Perhaps, such a decision will seem to someone more beautiful, however, in my opinion, this would be a useless decoration. I set a pause only once, but we can assume that when changing the environment, for example, a video card, it will be necessary to change this parameter.

    We said above that the requirements for a rational bot include utility. It is unlikely that the bot will be practically useful if the game runs too slowly, so all pauses were minimized as much as possible.

    It is also worth saying a few words about self-knowledge (introspection). Its insurmountable difficulty is one of the clearest examples of the limitations of natural intelligence. The well-known founder of the philosophy of intuitionism A. Bergson noted that although a person can raise his hand, he cannot explain how he does it. Later, while working on systems for automatically proving theorems, researchers came across a paradoxical fact: no mathematician can explain how he proves theorems as fully as necessary for the implementation of these systems. The fact that people learn mathematics at a conscious age and can tell you step by step how they studied mathematics does not help either. The situation with recognition of speech and visual images seems even more complicated - no one can tell how he learned this. Thus,

    Handling rare and exceptional situations


    Situations occurring relatively rarely were noted above, for example, a trunk was not found, transition to the main menu, etc. Such situations should be distinguished from exceptional situations. An exception is a fairly strict concept, according to Wikipedia, defined as

    runtime errors and other possible problems [...] that may arise during program execution and lead to the impossibility (meaninglessness) of further development of its basic algorithm by the program.
    The exception handling mechanism is embedded in the computing environment. It is also worth noting that the frequency of occurrence of exceptions is not specified, and in principle, exceptions can be quite rare.

    Rare situations are not so strict, rather a heuristic concept, entirely dependent on the subject area and the modeling environment (in our case, on the game). As can be seen from the above examples, not all rare situations lead to the impossibility or meaninglessness of further development of its basic algorithm by the program. For example, ship capture of a barrel does not require any immediate bot response. In the proposed solution, release from accidentally captured barrels is assigned to the player and, as a rule, can be made by him at a convenient time, i.e. at the next bot stop for repair, replacement of weapons of mass destruction, etc. If a player marks all barrels for capture, then on the next turn his ship may be overloaded, however, in a real game of the bot, such a situation seems unlikely.

    In the general case, we have to admit that even the most thorough analysis of a non-trivial task does not guarantee the identification of rare situations, and you may not encounter some of these situations when learning. These considerations add doubts about the complete autonomy mentioned above. With a rational approach, rare situations are handled by humans. Recently, a message about a robot policeman drowning in the fountain of a supermarket caused a great resonance . I suppose that the reason for this “suicide” was an unaccounted rare situation.

    Implementation, Empirical Approach


    In 1976, Newell (A. Newell) and Simon (HA Simon) at the presentation of the Turing Prize gave a lecture on "Computer science - an experimental science." Following them, J. F. Luger stated:
    each AI program should be considered an experiment: it is a question before nature, and the answer to it is the result of the program. The response of nature to the underlying design and program principles forms our understanding of formalism, patterns and the very essence of thinking

    (J. F. Luger, Artificial Intelligence: Strategies and Methods for Solving Complex Problems. 4th Edition. M: Williams, 2003, p. 780) .
    Not only the experimental approach to the determination of parameters, but also the choice of methods was repeatedly noted above, for example, an experiment showed the need to use a similarity measure. Actually, programming and catching the main bugs took me a very short time (about 10% of the total time spent), largely because the bot was based on a reworked program of a bot I had previously made to generate ship hulls in KR2HD. The main time was spent on passing a real game and adjusting the bot during this passage. Although, as in any long-term task that does not require constant operator participation, if you take the real time costs, they are small - while the bot is playing a game on one computer, you can do other things nearby on another computer. When stopped, the bot will give a beep. For greater player convenience, when using the bot, it is possible to specify in the bot settings the program that it will start to execute when it stops. For example, it could be a phone call program for a player in case the player is in another room. In addition, there is an option to turn off the computer: when stopped, the bot will save the game and turn off the computer.

    The game and my previous bots are written in Delphi-7, in order to reuse the code, the same environment was also chosen for this bot. In addition to the already mentioned OpenCV, Delphi-OpenCV libraries (Laentir Valetov, Mikhail Grigorev), TntWare Delphi Unicode Controls (Troy Wolbrink) and the Inno Setup installer are used(Jordan Russell). The bot was tested under Windows XP SP3, Windows 8.1 and Windows 10. Versions of the game КР2HD 2.1.2155 and 2.1.2170. Tests in a real game took about 12 game years, which exceeds the duration of the Battle of Rogeria in the above records, but, of course, in the table of records you can find games where this battle lasted longer. According to the impressions of these tests, the bot was a success. I managed to achieve the goal of rational AI (see above) - "choose the level of autonomy at which":

    1) "The program will be useful" - I felt the benefit, instead of stupidly beating the pirates for several months I was engaged in much more interesting things, at the same time I felt a constant presence in the game, periodically making interesting game decisions that I did not trust the bot.

    2)“The program will not make mistakes too often, compared to humans” - indeed, the error rate was reduced to an acceptable, in my opinion, level: once an hour, and sometimes longer. At the same time, I admit that with a longer and more thorough debugging, the duration of the error-free operation of the program can be increased.

    3) “The program will not be overly complicated for writing, debugging and maintenance” - I did not encounter any special difficulties. In any case, do not compare with the above mentioned bot of planetary battles (PB bot). Although he showed some successes, no one, including myself, has been able to promote him yet.

    Conclusion


    Game programming is traditionally considered one of the most important areas of AI development. In this direction, one can distinguish a sub-direction of programming bots for games: put a bot-bug in the anthill of the game in order to see what happens. To answer the question “why is this needed”, it is worth considering modern natural sciences and humanitarian fields (for example, feature films and literature) from the point of view of the model approach. Scientific theory, motion picture, game - the essence of the model, allowing you to explore some general principles. In particular, for example, the principles of a rational choice of the degree of autonomy follow from the bot model proposed here, which, in my opinion, can be useful for, for example, preventing suicides in fountains of such non-toy items as the above-mentioned robot-policeman.

    It might seem that a more complex model, for example, a more complex game or a more difficult task of this game would bring more interesting results. However, the principle of “the more complex - the better” is far from always justified in such studies - overcomplicated models based on a large number of rules with a large number of parameters often lead to a situation where forests are not visible behind the trees. So, the mentioned PB-bot, oriented to a more complex task, did not allow making such interesting observations.

    In conclusion, I consider it my pleasant duty to thank Svyatoslav for discussing the tactics of the game, the idea of ​​the bot and for preliminary testing of the starting versions of the bot, as well as Robo Brain for discussing the tactics of the game. Thanks vconst for processing TP schedules.

    Also popular now: