Geek approach to a simple browser game

A few years ago, I was happy to play a small amateur browser-based game created after the classic “Majesty: The Fantasy Kingdom Sim”. Very soon, it revealed several vulnerabilities and bugs, including very suitable for "exploitation". The story of how I wrote the exploit scripts, reported the bugs and later participated in the development of the game a bit - below. I think it will illustrate well the somewhat non-standard, geek user approach to the game, which may be useful for developers to know.

First about the game itself. I do not provide a link, but if you wish, you can find it inside the source below. The idea of ​​the game is quite simple: the player creates one or several heroes from a choice of 16 classes (Warrior, Barbarian, Monk and others, just like in Majesty) and then explores the world around them, defeating monsters, gradually gaining levels and selecting good equipment. The interface is hypertext, graphics at least. All graphics are taken from Majesty, and, as I recall, with the permission of the copyright holders. There is no interaction between the players, except for a completely competitive arena independent of the main gameplay and one very indirect path, which I will discuss below.

The main feature of the game is that the hero begins with a reserve of 200 "moves", which are quickly spent on researching starting locations and first journeys. New moves accumulate at a rate of 1 per real hour, regardless of the player’s actions. 24 moves are collected per day, which is very little, enough for 5-10 minutes of play. The game is free, there is no donate in it, you can not buy for “real” either moves or anything else. The only way to play more is to create a lot of heroes, and each play 5-10 minutes a day or about an hour a week. However, creating more than 16 heroes - one for each class - is not of particular interest due to the lack of in-game interaction. That's how I played - one hero of each type. This amount is enough for about an hour of quiet play per day.
')

Hero Generation

When creating a hero, the first opportunity opens for geek optimization: generation of a hero with the best characteristics. There are five stats in the game: Strength, Vitality, Intelligence, Willpower, Artifice. After a little testing, I assumed that the value of each is chosen randomly from a range of 20–25, that is, 6 possible values ​​per characteristic. The total possible combinations are 6 ^ 5 = 7776, of which only one is ideal. Obviously, you manually re-create the hero, you need to write a script!

However, first you still need to accurately determine the ranges of stats for each character. This can be done manually (on average, 5-6 generations for each class of the hero), but this is long and uninteresting. It was more interesting and quicker for me to take the Autohotkey scripting language already a little mastered in other games, and write code to control the Opera browser. There was no captcha when creating a hero then - it was added later with my submission - therefore the scheme of work is quite simple:
- choose a class, take the starting hypothesis about the ranges of parameters (min 50, max 1);
- Login, send a form to create a new hero;
- see which stats turned out, correct the hypothesis (reduce the min, increase the max);
- if all five ranges are 6 units long, then write the ranges to a file and proceed to the next class.


As a result, we obtain the desired ranges for all classes and (weakly) confirmation of the hypothesis - all characteristics have exactly 6 possible values. Further, for each class, only some of the characteristics are important, and the very top of the range is not always needed, but an intermediate threshold value is sufficient. For example, the Strength parameter gives an increase of +1 to damage for every 6 units, so from a range of 21-26 we will fit 24, 25 and 26. This allows us to raise the probability of getting a suitable combination from [1 of 7776] to a reasonable value in [1 of several tens or hundreds]. This is important, because the re-creation of the hero takes 10-15 seconds, and ideal stats would be generated on average for more than a day, and we need something else besides them.

Namely, starting money is the second opportunity for geek optimization. They are few, only 200 coins, which is not enough to buy even weak equipment. It is enough only for the simplest baton and weak armor that does not save the weakest monsters in the first combat location from being bitten. Therefore, usually newly created heroes have to spend a lot of moves to heal wounds or even resurrection after death (in a game, death is the loss of a portion of money and several priceless moves). However, there is a casino in the starting city! The sizes of the bets are 50, 100, 500 and 1000 coins, the types of bets are:
- “to black”: a half chance to double the bet;
- “to red”: 1/5 chance to check the bet;
- “on gold”: 1/20 chance to “udvadtsadterit” rate.

Obviously, unlike real casinos, the expected payoff is zero. However, each bet spends one move, which makes playing in a casino ultimately unprofitable for everyone except Gnome class heroes (they have increased luck and expectation is positive). For the generation of casino heroes it is very useful: you can put the starting money for gold, and in case of failure just create a hero again. There are no bets for 200 coins, so you have to make two bets of 100 and count on winning 2000 coins (total probability is about 1/10). So many coins are still not enough for a good start, so you need to bet again: two bets of 1000 each with the hope of getting 20,000 coins (the probability is again ~ 1/10).



The corresponding script is simple:
- recreate the hero until the stats are suitable;
- go to the casino, make 2 bets of 100, if won, then another 2 of 1000;
- if you won, then go to the next class of the hero;
- in case of failure at any stage, return to re-creation.


In total, the hero needs to pick up the characteristics (probability ~ 1/200 - 1/50) and win twice in a row at the casino (probability ~ 1/100). The overall probability is very small (~ 1 / 10,000), so on average the script worked for me for 20-30 hours for each character. I found it unnecessary to do several threads, and I didn’t want to load the game server and spoil the life of amateur developers. With these nice people, besides, I managed to meet, fixing up to this a few bugs. The most enchanting bugs, and how I became the Royal Catcher of Bugs, are the last part of the article.

So, in the end, I got 16 heroes, each with good stats and 20k gold. With this money for starting 200 moves, you can already buy good starting equipment, run from another city for super-useful amulets and conveniently collect a dozen levels. However, this advantage of the "improved start" ends, and then the hero is played like any other. The level to the 20-25th difference is leveled, and the main thing is already the knowledge of the game - which location to go at the current level and with the available equipment in order to effectively spend moves on the development of the hero. How to help your heroes at this stage? It turns out that there is an opportunity to make their lives a little easier.

Money laundering through the clan system

Here comes the very only indirect way of interaction between the characters. Each hero from level 5 can join a clan created by another hero, and from 10 he can create his own. In the general treasury of the clan, you can donate money and with this money you can then build buildings such as a gym, a garden for meditation, etc. These buildings allow you to spend your moves a little more efficiently - to heal faster, get temporary bonuses, even improve stats a little. All of these bonuses are small with one exception - spells from clan temples. After the construction of temples dedicated to local deities, they can donate money to temporary useful spells that extend to all the heroes of the clan. The bonuses from some of the spells are already very noticeable - the full treatment after each battle (saving moves and money), increasing armor, increasing the number of attacks. It costs a lot of money, so in a normal game even very large clans of highly developed heroes cannot afford to often activate these spells. By the way, there can be no more than 15 or 20 heroes in a clan, and the cost of spells in the temple is proportional to the number of clan members.

You can get around this problem with the help of temporary clan members, each of whom joins a clan, donates a large amount of money to the treasury, and leaves the clan - so the cost of temple spells does not increase, but the treasury grows. It is not effective to do this manually - in order to constantly maintain all useful bonuses for each beneficiary hero you need about a dozen donor heroes, and for each donor you need to remember to play in order to farm money. According to my calculations, in order to continuously provide all 16 heroes with bonuses, it was necessary to launch 200 dwarf donors into operation. It is gnomes, and not heroes of another class, because due to heightened luck, they win the starting 20k (sometimes even 40k) of gold much easier, and after that they can very quickly get the right level, throw money into the clan and start productively farming.

Here the script will help us again, a little more complicated:
- generate 200 gnomes with unique names and sufficient stats and 20-40k gold from a casino;
- each of them to run away from another city, buy good equipment and amulets;
- almost all of the remaining moves to spend on pumping and pharming of gold in a suitable location;
- The remaining few moves to spend on a trip to the clan city and donation of all the money to the desired clan.

The code was created only for the first item:



The remaining items were never implemented, because several events occurred simultaneously:
- I'm already tired of playing and writing exploits;
- developers have received an offer to help with the development of the game;
- crowds of suspicious gnomes were spotted by players. The fact is that writing a generator of realistic unique names for dwarves was too lazy for me, and the dwarves had names like Lucky XY, Lucky PQ, etc. It turned out that during a consecutive game with several heroes in the last 10 minutes they were all displayed in the list of online players, and my too-alike gnomes stably hung there for 5-6 pieces. A topic appeared on the forum, in which the puzzled players wondered what kind of dwarves were and who needed them. Then I realized that it was time to open up, told about the exploits and curtailed my dark activities.

A little about the moral side of the issue. Due to the lack of any opportunity to ruin the lives of other players, as well as the weak competitive component of the game at that time, my obtaining of dishonest advantages had no effect on the game society. And generally passed unnoticed. My heroes were young, because of the “1 move per hour” system they could not bear with the old-timers and were completely lost in the bottom of all ratings. In the process of my digging in the game, I found and reprimanded a lot of bugs and vulnerabilities, including those that initially exploited.

Bug catching

The first major bugs I discovered were related to things that gave + Vitality. According to the data in gaming Wikipedia, an increase in HPmax with increasing levels is subject to the formula HPmax + = floor (Vitality / 4) + rand (1, floor (Vitality / 4)). Thus, every 4 points Vitality was given an average of + 1.5HP per level. If the hero at the time of raising the level were wearing things with + Vitality, then the additional HP should have been higher. However, because of the bug, these things were not taken into account (as the developer told me, for some reason, before raising the level, all things were removed from the hero, and then put on again).

After my report, the bug was fixed, which led to completely unexpected results. Heroes with a very low Vitality ratio, who had barely survived the battles before, now began to receive much more HP per level. In particular, the gnomes, whose base Vitality lies in the range of 4–9, easily doubled their equipment and even tripled their health, and, taking into account their other abilities, turned from the most choked people into potentially strongest heroes. The same is true in the original extremely fragile Healers. It became extremely important for such heroes to find the appropriate things as low as possible in order to start receiving bonuses to HP early.

A minor flaw was in the casino: it was possible to enter into it with things that increase luck and win more often. After my report to the casino, they added a bouncer who sniffed out such things and simply did not let them inside. In a casino in another city, one could always win in one of the games by simple frauds with GET request parameters. Now there are also bouncers: "Cheaters are not welcomed here!"

The game as a whole was made on the knee, and therefore was extremely leaky. In particular, to exit from the first city, it was necessary to buy a card for 600 or 800 coins, and only then in the dialogue at the gate an option “leave the city” appeared. However, all the options in the dialogs had links of the form “... & State = n”, and selecting the desired value of the GET parameter allowed using the hidden dialog option.

The most enchanting vulnerability is associated with numerical input fields like “how many moves to rest” or “how many moves to pray to the deity”. In most cases, input negativity checking was done by Javascript on the client side. As a result, one day my hero rested -1000 moves for an experiment and ... died! “You have rested for -1000 turns-restored –6000 health points. You are killed! ” But death is only a loss of money and a few moves. Which I now have almost 1000 more ... With the same -1000 moves to the deity, instead of a heap of blessings, the hero receives no less a lot of curses.

Impressed by my reports, the developers gave me for a more effective search for the bugs of a special hero with impenetrable armor and a bunch of moves:



Later, the developers gave me access to the test branch, where I could barely mix it (it turned out that the whole game was written in a completely unknown VBScript for me) wrote a new feature - fast switching of equipment sets. The feature was “in production”, but my contribution ended there, because I still could not overcome my dislike of VBScript and continue development.

In conclusion, we can say that the geek player has a non-standard view of the game. It is more interesting for him (at least in my case) to study the game, look for unbalanced strong strategies, vulnerabilities and exploits, than just playing “as it should be”. If the results of his research, he is not too lazy to convey to the developers, the game will only benefit from this.Of course, the new in this reasoning is not enough - the classification of players, including such a “researcher”, I think I saw a couple of years ago on Habré. However, for me personally, as well as probably for everyone in my place, it is nice to remember this time and my modest contribution to that wonderful cozy game.