Dagaz: Kicks to Common Sense (part 10)

... Ten will come ...
And you will tremble,
Like an aspen leaf tremble! 

         Yurine " Karas " The 
 

least noticeable is what lies on the surface. Beyond the usual routine, we do not see the miraculous. Board game developers come up with more and more game mechanics, but often confuse the “interestingness” of a game with its “complexity”. To make it clear what is at stake, I will give an example:


Of course, this game is very complex (it certainly cannot be described on ZRF , and on Axiom , with its support for timers, it is unlikely to be able to develop any friendly interface), but this complexity seems to be artificial, far-fetched. As a board game developer, I am interested in games that "challenge" existing development tools, but I do not welcome "complexity for the sake of complexity." I would like to tell about…

1. Simple things

I started this entire series of articles, mainly, in order to determine the boundaries of the possibilities of the existing “universal” toolkit (“ Zillions of Games ” and “ Axiom Development Kit ”) intended for the development of board games. A new project is worth undertaking only if there are tasks that it can solve better than existing ones (or simply can solve it). What results in functionality limitations? The developers themselves come up with them!

When developing any product (ZoG is no exception), its creators make a number of assumptions that make their life easier. You don’t have to go far for examples. In chess, the pieces performing the capture replace the taken. This mechanism is so general for all games of a chess family that it is called "chess capture". ZoG developers considered it a good idea not to delete the taken pieces explicitly (if their place, at the end of the move, is occupied by another figure). As a result, a restriction was born - one field cannot contain more than one piece (for checkers, the chess mechanism of capture was not relevant, but the new restriction did not affect them either). Games in which this limitation is not performed (various mankaly , tavreli , Pole-checkers) immediately turned out to be “overboard”. Do not misunderstand me. You can make such games , but their development turns into a real nightmare!

Another "good intention", cast in bronze, is: "a player can only walk with his own figures." Stavropol checkers have their own opinion on this matter. Yes, they can also be made, but how! In order for both players to be able to move all the pieces, they had to be made neutral (that is, to have another player who was not participating in the game, but owning all the pieces). Not only does the completely artificial restriction lead to a serious complication of the implementation, part of the possible functionality becomes simply inaccessible.



In this game, there are figures belonging to the players and a neutral figure “ball”. Having made a move with his piece, the player moves the neutral piece. In this form, everything works, but using ZRF means it is impossible to complete the move with your own piece or neutral. That and more at a time, but not , or both together! Sometimes , it gets in the way (and again leads to over-complicating the code). Things get worse with a combination of several “antipatterns”.

To determine a mandatory take, in games of the family of drafts, ZRF uses a priority mechanism. This solution, in itself, is not very successful, since priorities could be easily implemented on the basis of a more universalmechanism, but, more importantly, makes a whole layer of functionality inaccessible in games like Stavropol Checkers. In checkers, the player is obliged to take, if he has such an opportunity (this is very important, in tactical terms), but, in the "Stavropol Checkers", the player can walk with pieces on both sides. Although the original rules do not stipulate this point, it would be interesting to make taking with your own pieces more priority (and taking with your opponent's pieces, for example, is not mandatory at all), but this cannot be achieved in ZRF! No way!



The magnificent second mission of the Chaos campaign in Battle vs Chess (starting at 6:40, setting start on Habr, unfortunately, does not work ). Blacks can add their pieces from the reserve to any place on the board if they do not check white. Even taking this restriction into account, Black has a serious advantage, since, as we know from Shogi , "the piece in the hand is stronger than the piece on the board."

When playing this game for the first time, I lost control (the discarded piece is switched with the mouse wheel) and dropped the pieces onto the board strictly according to seniority (the first of all pawns, then horses, bishops, and only last, the queen). Even with this in mind, I easily won and the game, in this mode, in my opinion, turned out to be even more interesting. I made a clone of the original mission , but with the addition of the pieces to the “seniority” board, there were problems associated with all the same priorities. It is possible to prioritize the moves of resetting the pieces, but the priority of moving the pieces must coincide with each of these priorities (otherwise, until the reset of all the pieces, it will not be possible to move a single piece, including the king, even under the check). In ZRF, this is completely impossible! ZRF priorities clearly lack flexibility.

The topic of the interaction of heterogeneous options is, in general, inexhaustible. So, for example, in games of the Halma family (in our country, one of its variants is known under the name Corners ), it becomes necessary to “mark” previously visited fields in order to avoid possible looping of moves. At first glance, “position flags” are ideal for this purpose, allowing you to associate a Boolean value with a specific position for the duration of the move. Unfortunately, as with the use of global flags, the set values ​​are automatically reset at the beginning of eachmove. Since the composite move in ZoG consists of completely independent “partial” moves, position flags do not justify the expectations associated with them. It is necessary to solve the problem by “marking” not the fields, but the figures with the help of their attributes (such as those used when performing the castling check), but this is a topic for another discussion.



In checker family games, the attributes of the pieces are used to prevent the Turkish strike. According to the rules adopted in most modern versions of the game, the pieces taken are removed from the board only at the end of the move, all together. For us, this means two things: firstly, from the set of “partial” it is necessary to single out the very last move, in order to remove all the pieces taken during its execution (when using the “majority rule” or turning the drafts during the execution of the move, as in “Russian Drafts” "- this, in itself, is not an easy task). In addition, you need to mark the taken shapes using attributes or turning shapes. Here we are in for a surprise. The ZSG notation is constructed in such a way that a marked or transformed figure cannot be deleted in the same move! It means, that the last figure taken should not be marked and should be deleted individually. Add to this the not very convenient semantics of moving the pieces (until the completion of the generation of the move, the figures performing the move, as it were, remain in their places) and the development of seemingly banalcheckers will turn into a complex and fascinating quest , filled with adventure and the fight against the "bosses".


When, to all this, problems with prioritization are added, the life of the developer becomes even more interesting . In the version of drafts, common in Ossetia ( Kena), in general, very similar to Turkish and Armenian drafts, an interesting rule was introduced. An unreformed checker (ken) can jump over friendly ken, similar to how it is done in games of the Halma family. Unfortunately, I was not able to find out whether such jumps are allowed to alternate with taking enemy pieces, but this option would undoubtedly be the most interesting. And it is precisely his implementation in ZRF, apparently, will never succeed. Since the captures must remain priority, and the “jumps” can be alternated with captures in any order - they must be prioritized too. But if you do so, the usual (low-priority) moves can only be completed in extremely rare cases.


Often, difficult to implement rules are the result of improvements to the game by its creators. So, in the classic " Ordo " by Dieter Stein, the invariant of the game is the "connectedness" of the pieces, at the end of the move. If the group of figures is divided (neighbors are taken into account both along the orthogonal and diagonal lines), the move restoring connectivity is a priority. If such a move fails, the player is credited with a loss. In this form, although not without difficulty, the game was described on Axiom. In an improved version of OrdoXIn addition to introducing new (diagonal) moves, the rule of preserving connectivity has been changed. Now, only the largest group of divided ones should remain on the board, but if there are several (possibly more than two) equal groups, the player has the right to choose which one to leave on the board. If the solution is possible in ZoG, it will be extremely time-consuming.

A more ancient example of improved game rules can be found in one of the varieties of " Battle Racing ", common in Western Sahara, Morocco and Central Algeria. In Sigh , as in most of these games, "bones" are used, made in the form of four flat sticks. Drop points are counted by the number of sticks that have fallen light side up. In general, in this game, everything is as usual - there are throws introducing a new chip into the game (1-khaj ), additional throws (for example, 4 - barga ), but there is one throw that makes the game really unique. Two-pointer ( khmar ) - cancels the result of the previous throw and gives the right to re-throw. If it falls again, an even earlier move is canceled (the corresponding chip returns to its original position) and so on. For the correct implementation of this game, you have to keep a log of moves, with the possibility of their rollback!



Some games are redefining the concept of the move. In the " Ambiguous Chess " shown above, the player performing the move indicates the field that he is about to go to, and his opponent is already making the move of one of the pieces that can execute it. Making such a game in ZoG is difficult, but possible. " Refusal Chess " goes even further! In it, the opponent can prohibit the player’s declared move (if this move is not the only possible one) and then the player will have to make another move. Probably, this can also be implemented on ZRF, but I don’t really imagine how.

But this is not the limit! In the first part of the cycle, I already mentioned the Ethiopian Senterej , in which players start the game, performing moves simultaneously, until the first battle of the figure. In the Sulus-idi mankal , in the same mode, “zero sowing” is performed, which determines the right of the first move and, at the same time, violates the determinism of the initial layout of stones. I emphasize that the players at the same time take and lay out stones from the same holes! I think the audience on Habré understands well what this means . If this is not enough for you, think about what difficulties you will encounter in the process of implementing the familiar “ Throwing Fool ” in ZoG . I hope I brought you my thought:

For every sage, there is quite simplicity.