Dagaz: From simple to complex

た つ ぶ り そ ろ そ ろ 登 れ れ 富士 の 山

Silently crawl, snail, on the slope of Fuji,
up to the heights

小林 一 茶 (Kobayashi Issa)

I wrote a lot about what I want to get in the end. He told how it can be used, but left one simple question unanswered. Why am I convinced that all this (well, okay, almost all of this) works? I have a secret weapon! And today I want to talk about it.

The project that I am writing is complicated. I am developing a universal model, potentially suitable for describing any board games. There is nothing to think about developing such a project from scratch, launching it and checking whether it works. Moreover, there is nothing to launch yet. There is neither a controller, nor any sort of a stray view, under which this model could be launched. But I have to check and debug the written code right now! Then, when the controller and the presentation appear, it will be simply impossible to debug it all, in its entirety!
')
I am not the first to face such a problem, and the method of its solution has long been invented . To test my code, I use QUnit , but of course, this is not the only such solution in the JavaScript world. I do not adhere to the TDD methodology, in the sense that I do not try to preface writing code with tests, but I try to cover the entire model code with tests as much as possible. This helps me to solve the following tasks:

• Finding and fixing stupid bugs and typos in the code
• Check compatibility of solutions used with various platforms (browsers)
• Regression testing (changing something, I have to be sure that I didn't break anything)
• Minimum documentation (tests fix ways to use model interfaces)

As I develop tests, I move from simple code to more complex code. Before checking the complex logic of the course generation (this is the main thing from what the model does), I must make sure that all the parts used by it are working correctly. All classes used in my model can be ranked by increasing “complexity”:

• ZrfPiece - description of the figure (object on the board)
• ZrfDesign - description of the board topology and game rules
• ZrfMove - description of the course that changes the state of the game
• ZrfMoveGenerator - a generator of possible moves "by pattern"
• ZrfBoard - game state storage and generator of all allowable moves

The ZrfPiece class is so simple that testing it does not even require a full-fledged game design . However, it has some not obvious features that need to be verified. For example, the logic of creating a new object when changing the type, the owner or some of the attributes of the shape.


We manually create the most minimal “design” (two players, two types of figures and no hint of a board) and manually perform all the checks we are interested in. After that, calmly use the ZrfPiece , not expecting any tricks from him. Even if it later turns out that you forgot to check something, just add a few more checks. Next we test more complex code:


ZrfDesign is 99% navigation on the game board. Her and check. We create the design again manually (now with a small board), after which we run the most typical test cases. And do not forget, at the end, clear the created design! So he did not break the other tests.


Further, the tests are becoming more and more high-level. Generation of a separate move according to a pattern by the ZrfMoveGenerator class, applying a turn to the game state and, finally, generating a set of moves by a certain position:


With all the brevity of the test, it is almost a full game! In any case, one move from it. Here both the composite moves and the move by the “sliding” figure and the capture priority and even the majority rule , implemented as a game extension and prescribing the capture of the maximum possible number of enemy pieces, are tested! This small test covers almost all the functionality of the model. And when something breaks, we see it, and immediately correct it .

One more thing unit-tests help is refactoring! At some point, we decided that Underscore would be used in the project. This wonderful library helps to write code in a functional style , making it more concise and maintainable. To make it clearer, I will give one example of the “life” of the project.

Functional programming is the more useful the more complex the task. If the code is very simple, rewriting it in a functional style will do little. But if the task is a bit more complicated, the advantages of the functional approach become more obvious.


Remember this game ? She has two fun rules:

• If moving a stone creates a new row, the player gets the right to capture any of the opponent’s stones.
• When a player is left with just three stones, his stones turn into “flying”. These stones can move (“fly”) not only to one of the neighboring ones, but generally to any free cell on the board.

I marked the key word. What does "a player can capture any opponent's stone"? If the enemy has N pieces on the board, then exactly the same number of times we are obliged to duplicate each turn, leading to the construction of a “row”. These moves will differ only in the figure taken! In Zillions of Games, this is exactly what is being done. And this incredibly complicates the implementation of the game! But there is still the rule of "flying" stones ...

There is another solution. We can form only one move, listing in it all the positions of the potential take. Of course, this does not mean that we will take all the stones, not at all! Only one of these will be taken. The move will become non-deterministic. The same with the movements. If a “flying” stone can build a “row”, it turns out the Cartesian product of all effective moves to the many positions occupied by enemy figures.

I came up with a good way by which the user interface can work with such moves, but for AI bots it is not applicable! AI should receive strictly determined moves on an input! This means that there must be a mechanism that turns non-deterministic moves into deterministic moves.


60 lines of completely incomprehensible and absolutely unsupported code! Most likely, it does not even work! I never tested it.


The code is longer and, at first glance, does not look more understandable. But let's take a closer look at it. For a start, let's try to understand the problem. The course description ( ZrfMove ) consists of a set of actions ( actions ), each of which is a tuple of four elements:

1. Starting Position ( from )
2. End position ( to )
3. Figure
4. Partial stroke number ( num )

Since the transformation of the figures in the "Mill" is absent and the composite moves are not used, only the first two of these values ​​are important for us. They are enough to describe any action performed:

• Adding a piece to the board (reset) - from == null && to! = Null
• Deleting a shape (capture) - from! = Null && to == null
• Moving the shape - from! = Null && to! = Null && from! = To

But this is only half the battle! In fact, both from and to (and even piece , but it's not about it) are also arrays! If the move is deterministic, each of these arrays contains exactly one element. The presence of more values ​​in any of them means the possibility of choice (which we must deal with).


There is a movement of the figure from position 0 to any of the two positions ( 1 or 2 ) and the capture of one opponent's figure from positions 3 , 4 or 5 . To begin with, you can choose the size of all “non-deterministic” positions (containing more than one element):


This array is “smoothed out”, after which we turn each numeric value into a range:


Now we need an operation, which is not provided in the basic configuration of Underscore.js . Something like a Cartesian product . Nothing wrong.


I admit that my decision is not quite "kosher." If anyone knows how to do better, write in the comments. Apply it:


The rest of the task is a little more complicated. It is necessary to choose “non-determined” positions from the initial variant of the move, in accordance with the existing cheat sheet. I will not bother with this reader, the problem is purely technical. The most important thing is that the use of the functional approach allowed us to divide the rather complex task into parts that can be solved and debugged separately.

Of course, the use of the functional approach is not always associated with solving such puzzles. Usually, everything is somewhat simpler. As a typical example, I can cite the maximal-captures module, which implements an option inherited from Zillions of Games, which takes the maximum number of pieces in games of the checkers family.


Both options work well (at the time of refactoring, the code was already covered with tests), but the functional version is shorter, easier to understand and assembled from unified blocks. To support him, of course, much easier.

In conclusion of the article, I want to voice a few principles by which I try to be guided in my work. I, in any case, do not want to make a dogma of them, but they help me.


Of course, I still have room to grow. I do not see this problem. My understanding of the language is changing (I hope for the better), and with it the code is also changing. And unit tests just help me with that.