Automation of development in ZeptoLab
To work on our games, we widely use software bots endowed with this or that intelligence. Bots help us develop, test and exploit our games. I want to tell you about a few examples of this symbiosis with automation.
This is what Om Nom looks like in Cut the Rope 2
The code of mobile games often and significantly changes in order to keep up with the thoughts of designers and artists. The variety of game situations that arise in the game makes it difficult to quickly and reliably conduct test scripts manually. It happens, you need to check what happens after the occurrence of a rare random event or the imposition of several factors. For example, in the game Cut the Rope 2, the designer can change the mass of Om Nom in order to react weaker to the effects of other objects. This will solve the problem of the designer at the level with which he works, but the increased mass may make it impossible to pass another level, where Om Nom just needed to be pushed off the pillars.
')
To check that the passage is not broken, we use a special bot, which in order quickly passes all levels exactly the same way as the designer did when they were created. He remembers all the screen touches and events occurring in the game (such as cutting a rope, pressing a button or eating candy) in a special journal. And when we run a pass check, it reads this log and emulates the same screen touches. Along the way, he ensures that all important game events take place, and in general the level is passed. If the change in the parameters of the game led to the fact that the level is now impassable by the same steps, the designers have to clarify the changes. Or re-pass the level by the new rules, showing the bot how to do it.
Obviously, the designer must re-level in Cut the Rope 2, when he changes the essential parameters of the game, this is a long and expensive exercise. Some levels are very difficult, and even their creators have to make many attempts to cut the necessary ropes at the right moment and in the right place. Therefore, the fundamental constants of the game, such as the gravitational constant and the mass of Om Nom, are actively changing only at an early stage of development. Most of the time, designers debug local things: the geometry of specific levels or the parameters of new game elements.
The designer in this process proves to the bot that the level he has created can actually be passed. And then the bot many times during testing tries to repeat it. The funny thing is that a similar principle underlies our other game, King of Thieves. It is no longer a designer, but each player creates his own level (dungeon with treasures and traps) and proves to a similar bot that this level can be completed. Then this level gets to be torn apart by other players. They are trying to pass it by spending as few attempts as possible. Bypassing all the pitfalls in a well-made level is extremely difficult. Therefore, players can ask the bot to show how its creator passed the level. So they make sure that the level is really passing. Level checks on the mobile device itself are not enough. We have such eloquent players with the appropriate software that they can convince the server that they have gone through an impassable level. Therefore, we also use to check the permeability of special server bots that recheck the levels and their passage in isolation from the devices on the servers.
The player is trying to steal the treasure from the cave with traps in the game King of Thieves
Physical puzzles, such as Cut the Rope 2, are based on the fact that the passage of their levels is not obvious to humans. To create a bot that could go through arbitrary levels is difficult. On the other hand, there are games with simpler mechanics, for which it is easy to formulate an optimal or close to it strategy. For example, in the popular Heroes Charge is quite close to the optimal strategy to use special abilities immediately, as soon as they have accumulated energy. The rest of the battle is automated, the player can only activate the ability or wait for the right moment to use them. This strategy is used by the bot, which plays for opponents or represents the interests of the player in the arena. Another example is the famous Flappy Bird, for which passage algorithms are developed and even mechanical robots that play it much more successfully than humans.
There are automated games and we have in Zeptolab. In them, we make the most extensive use of bots that play in levels and reproduce a variety of game situations with great efficiency. This is used to develop and test the game balance. A designer, for example, may need to construct a probability function for passing a level from a set of input parameters (level structure, degree of development and characteristics of opponents, degree of player development). The function has dozens of variables, and it is necessary to select the essential ones from them and construct a relatively simple function of them. And if the designer does not like her, then change the rules of the game, and build a function again. Bots help us to do this. We launch bots to play a certain set of input parameters several hundred times (the number of games is determined by the number of significant parameters and the confidence interval that suits us). So we get the probability of winning at one point in the parameter space. Having done this for a sufficient number of points, we obtain data for constructing a function of a general form. And it is already used to form the complexity curve of the game and predict how the game will be felt by the player at one time or another.
It is worth mentioning here that there are two significantly different approaches to such game modeling. You can untie the drawing from the game logic, and simulate the game with great speed, without being in any way tied to the power of mobile processors and the capabilities of their graphics. On the other hand, you can simulate a game on the mobile device itself with existing game code that works when a person plays. This code, in addition to logic, draws all the beauty, plays sounds, interacts with the network, collects analytics. Due to this, it is quite slow, and it can be made to work faster only by speeding up the virtual time in which the application lives (drawing cannot work more often than 60 times per second). At the moment, we are inclined to the second option, since it is cheaper to implement, and in the process extreme testing of the game for rare errors and memory leaks is achieved. And the speed is just enough for the designer to receive new data with sufficient speed.
In some games the decisive role is played by how the player manages his resources for a long time. In them, we try to complement purely gaming bots with meta-gaming bots that manage resources according to certain reasonable rules. This allows designers to set the parameters of the economy and the complexity of the game, and then observe how bots go through the game at high speed, saving tens of hours for each iteration and allowing you to try many options. As a rule, it looks like several tablets connected to a computer, on which the game “plays itself in itself” at a very high speed. The designer watches them visually and simultaneously reads logs with game events and parameters of interest to him.
So far, our games with extensive use of bots are embarrassed to be mentioned on Habré, so I don’t name them. And if you are interested in mobile development and such tasks, then come to help us make them more known and less shy. The test task for programmers now is to write a clone of the aforementioned Flappy Bird.
This is what Om Nom looks like in Cut the Rope 2
The code of mobile games often and significantly changes in order to keep up with the thoughts of designers and artists. The variety of game situations that arise in the game makes it difficult to quickly and reliably conduct test scripts manually. It happens, you need to check what happens after the occurrence of a rare random event or the imposition of several factors. For example, in the game Cut the Rope 2, the designer can change the mass of Om Nom in order to react weaker to the effects of other objects. This will solve the problem of the designer at the level with which he works, but the increased mass may make it impossible to pass another level, where Om Nom just needed to be pushed off the pillars.
')
To check that the passage is not broken, we use a special bot, which in order quickly passes all levels exactly the same way as the designer did when they were created. He remembers all the screen touches and events occurring in the game (such as cutting a rope, pressing a button or eating candy) in a special journal. And when we run a pass check, it reads this log and emulates the same screen touches. Along the way, he ensures that all important game events take place, and in general the level is passed. If the change in the parameters of the game led to the fact that the level is now impassable by the same steps, the designers have to clarify the changes. Or re-pass the level by the new rules, showing the bot how to do it.
Obviously, the designer must re-level in Cut the Rope 2, when he changes the essential parameters of the game, this is a long and expensive exercise. Some levels are very difficult, and even their creators have to make many attempts to cut the necessary ropes at the right moment and in the right place. Therefore, the fundamental constants of the game, such as the gravitational constant and the mass of Om Nom, are actively changing only at an early stage of development. Most of the time, designers debug local things: the geometry of specific levels or the parameters of new game elements.
The designer in this process proves to the bot that the level he has created can actually be passed. And then the bot many times during testing tries to repeat it. The funny thing is that a similar principle underlies our other game, King of Thieves. It is no longer a designer, but each player creates his own level (dungeon with treasures and traps) and proves to a similar bot that this level can be completed. Then this level gets to be torn apart by other players. They are trying to pass it by spending as few attempts as possible. Bypassing all the pitfalls in a well-made level is extremely difficult. Therefore, players can ask the bot to show how its creator passed the level. So they make sure that the level is really passing. Level checks on the mobile device itself are not enough. We have such eloquent players with the appropriate software that they can convince the server that they have gone through an impassable level. Therefore, we also use to check the permeability of special server bots that recheck the levels and their passage in isolation from the devices on the servers.
The player is trying to steal the treasure from the cave with traps in the game King of Thieves
Physical puzzles, such as Cut the Rope 2, are based on the fact that the passage of their levels is not obvious to humans. To create a bot that could go through arbitrary levels is difficult. On the other hand, there are games with simpler mechanics, for which it is easy to formulate an optimal or close to it strategy. For example, in the popular Heroes Charge is quite close to the optimal strategy to use special abilities immediately, as soon as they have accumulated energy. The rest of the battle is automated, the player can only activate the ability or wait for the right moment to use them. This strategy is used by the bot, which plays for opponents or represents the interests of the player in the arena. Another example is the famous Flappy Bird, for which passage algorithms are developed and even mechanical robots that play it much more successfully than humans.
There are automated games and we have in Zeptolab. In them, we make the most extensive use of bots that play in levels and reproduce a variety of game situations with great efficiency. This is used to develop and test the game balance. A designer, for example, may need to construct a probability function for passing a level from a set of input parameters (level structure, degree of development and characteristics of opponents, degree of player development). The function has dozens of variables, and it is necessary to select the essential ones from them and construct a relatively simple function of them. And if the designer does not like her, then change the rules of the game, and build a function again. Bots help us to do this. We launch bots to play a certain set of input parameters several hundred times (the number of games is determined by the number of significant parameters and the confidence interval that suits us). So we get the probability of winning at one point in the parameter space. Having done this for a sufficient number of points, we obtain data for constructing a function of a general form. And it is already used to form the complexity curve of the game and predict how the game will be felt by the player at one time or another.
It is worth mentioning here that there are two significantly different approaches to such game modeling. You can untie the drawing from the game logic, and simulate the game with great speed, without being in any way tied to the power of mobile processors and the capabilities of their graphics. On the other hand, you can simulate a game on the mobile device itself with existing game code that works when a person plays. This code, in addition to logic, draws all the beauty, plays sounds, interacts with the network, collects analytics. Due to this, it is quite slow, and it can be made to work faster only by speeding up the virtual time in which the application lives (drawing cannot work more often than 60 times per second). At the moment, we are inclined to the second option, since it is cheaper to implement, and in the process extreme testing of the game for rare errors and memory leaks is achieved. And the speed is just enough for the designer to receive new data with sufficient speed.
In some games the decisive role is played by how the player manages his resources for a long time. In them, we try to complement purely gaming bots with meta-gaming bots that manage resources according to certain reasonable rules. This allows designers to set the parameters of the economy and the complexity of the game, and then observe how bots go through the game at high speed, saving tens of hours for each iteration and allowing you to try many options. As a rule, it looks like several tablets connected to a computer, on which the game “plays itself in itself” at a very high speed. The designer watches them visually and simultaneously reads logs with game events and parameters of interest to him.
So far, our games with extensive use of bots are embarrassed to be mentioned on Habré, so I don’t name them. And if you are interested in mobile development and such tasks, then come to help us make them more known and less shy. The test task for programmers now is to write a clone of the aforementioned Flappy Bird.
Source: https://habr.com/ru/post/267845/
All Articles