The least noticeable is that which lies on the surface. For the usual routine, we do not see the miraculous. The developers of board games come up with more and more new game mechanics, but they often confuse the “interestingness” of the game with its “complexity”. To make it clear what is at stake, I will give an example:
')
Pressure game
TAMSK or the “Pressure Game” was the second game developed as part of the “ GIPF Project ” initiative. This is perhaps the strangest of all the games I know. As gaming chips, it uses a set of hourglasses:
Each player has three 3-minute "flasks". In addition, the game uses a neutral 15-second clock to limit the time it takes. At the beginning of the game, "shapes" are placed in the corners of a hexagonal board, with alternating colors. When making a move, each player moves one of the flasks to a neighboring field (in any direction), turning it over. Immediately after that, a ring is put on the field with the figure. It is prohibited by the rules to perform a move by a figure in which the sand has completely spilled out (the first three moves each player must “wind” all of his watches) and walk on those fields whose tube reaches the ring (the fields have different heights). The game ends when the moves become impossible. The player who has the most rings wins.
Of course, this game is very complex (it’s absolutely impossible to describe it on ZRF , and on Axiom , with its support for timers, it’s unlikely that a friendly interface can be developed), but this complexity looks somewhat artificial, “far-fetched”. As a board game developer, I am interested in games that “challenge” existing development tools, but I don’t welcome “complexity for the sake of complexity”. I would like to tell about…
1. Simple things
I started this entire cycle of articles, mainly to determine the limits of the capabilities of the existing "universal" toolkit (" Zillions of Games " and " Axiom Development Kit ") intended for the development of board games. A new project should be started only if there are tasks that it can solve better than the existing ones (or simply can solve). What causes functionality limitations? The developers themselves come up with them!
In developing any product (ZoG is no exception), its creators take a number of assumptions that make their lives easier. There is no need to go far for examples. In chess, the figures that perform the takeover replace those taken. This mechanism is so common for all games of the chess family that it is called "chess taking". The ZoG developers considered it a good idea not to delete the taken figures explicitly (if their place, at the end of the turn, is taken by another figure). As a result, a restriction was born - one field cannot contain more than one figure (for checkers, the chess taking mechanism was not relevant, but the new restriction did not affect them). Games in which this restriction is not fulfilled (various mankaly , Tavreli , Pillars ) 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 from bronze, sounds like this: "A player can only walk with his own figures." Stavropol drafts have an opinion on this matter. Yes, they can also be made, but how! In order for both players to move all the pieces, they had to be made neutral (that is, to have one more player not participating in the game, but owning all the pieces). Not only does a completely artificial restriction lead to a serious implementation complexity, some of the possible functionality becomes simply inaccessible.
In this game there are figures belonging to the players and a neutral “ball” figure. 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 make a move with your own figure or neutral. Both in turn, but not one or the other together! Sometimes , it interferes (and again leads to excessive code complication). Everything gets worse with the combination of several "anti-patterns".
To determine the mandatory take, in games of the family of checkers, ZRF uses a priority mechanism. This decision, in itself, is not very successful, since priorities could be easily implemented on the basis of a more universal mechanism, but, more importantly, makes an entire layer of functionality inaccessible in games such as Stavropol Drafts. In checkers, the player is obliged to take a take, if he has such an opportunity (this is very important, in tactical terms), but, in Stavropol checkers, the player can walk with figures from both sides. Although the original rules do not stipulate this point, it would be interesting to make the taking of your own pieces a higher priority (and taking the opponent's pieces, for example, is not necessary at all), but you cannot achieve this in ZRF! No
Playing this game for the first time, I lost control (the discarded piece is switched by the mouse wheel) and I dropped the pieces onto the board strictly according to seniority (the first of all the pawns, then the horses, the bishops, and only the last one - the queen). Even with this in mind, I won easily and the game, in this mode, in my opinion, was even more interesting. I did a clone of the original mission, but with the addition of pieces on the board “according to seniority”, problems arose related to 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 completion of the reset of all pieces, not a single piece can be moved, including the king, even if he is under check). In ZRF this is completely impossible! Priorities ZRF is clearly not enough flexibility.
The topic of interaction of heterogeneous options, in general, is inexhaustible. For example, in the games of the Halma family (in our country, one of its variants is known as “ Corners ”), it becomes necessary to “tag” previously visited fields, in order to avoid possible looping of moves. At first glance, “positional flags” are ideal for this purpose, allowing you to associate a boolean value with a specific position for the duration of the turn. Unfortunately, as with global flags, setpoints are automatically reset to zero at the beginning of each turn. Since the composite move in ZoG consists of completely independent “partial” moves, positional flags do not meet the expectations associated with them. Solving the problem has to “mark” not the fields, but the figures with the help of their attributes (such as those used when testing the possibility of castling), but this is a topic for another conversation.
In games of the family of checkers, 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 taken pieces are removed from the board only at the end of the turn, all together. For us, this means two things: firstly, from the set of “partial” ones, it is necessary to select the very last move in order to remove all taken pieces (when using the “rule of majority” or turning the checkers during the execution of the turn, as in “Russian drafts”). "Is, in itself, a daunting task). In addition, it is necessary to mark the taken figures using the attributes or the transformation of the figures. This is where a surprise awaits us. ZSG-notation is built in such a way that a marked or transformed figure, in the same move, cannot be deleted! This means that you do not need to mark the last taken figure and should be deleted individually. Add to this not very convenient semantics of moving figures (until the generation of a move is completed, the figures performing the move, as it were, remain in their places) and the development of seemingly trivial checkers will turn into a complex and fascinating quest filled with adventures and fighting "bosses" .
A little more about the compound course
The concept of a composite move in ZoG, in general, is very far from universal. Even if one does not recall the hard-code implementation of the “rule of majority”, its main limitation remains - the composite move must be continued by the figure moved by the previous partial move! This requirement, as well as the specificity of generating random numbers in ZoG, immediately puts an end to all attempts to use a composite move for the implementation of repeated shots, in games like Nard , Ur , etc. As a result, it is necessary to indulge in “all serious”, for the implementation, in general, a simple and natural requirement.
When, to all this, problems are added with the definition of priorities, the life of the developer becomes even more interesting . In the variant of drafts, common in the territory of Ossetia ( Kena ), in general, very similar to the Turkish and Armenian drafts, an interesting rule was introduced. Not transformed checker (ken) can jump over friendly kens, just as it is done in the games of the Hulma family. Unfortunately, I did not manage to find out whether it is allowed to alternate such jumps with taking enemy figures, but this option would undoubtedly be the most interesting. And it is precisely to embody it in the ZRF, apparently, will never succeed. Since taking must remain a priority, and “jumps” can be alternated with taking in a random order - they must also be prioritized. But if you do this, ordinary (low-priority) moves can be performed only in extremely rare cases.
Often, the rules that are difficult to implement are the result of the game's improvements by its creators. Thus, in the classic " Ordo " of Dieter Stein, the game's invariant is the "connectedness" of figures, at the end of the turn. If a group of figures is divided (neighbors are taken into account both along orthogonals and along diagonals), the move restoring connectivity is a priority. If you cannot find such a move, the player is considered a defeat. In this form, though not without difficulty, the game was described on Axiom. In the improved version of OrdoX , in addition to the introduction of new (diagonal) moves, the rule of preserving connectivity was changed. Now, only the largest group of divided ones should remain on the board, but if there are several (maybe more than two) equal groups, the player has the right to choose which of them to leave on the board. If the solution is possible in ZoG, it will be extremely time consuming.
A more ancient example of improving game rules can be found in one of the varieties of " Combat Racing ", common in Western Sahara, Morocco and Central Algeria. In Sigh , as in most of these games, use the "bones", made in the form of four flat sticks. Dropped points are counted by the number of sticks that have fallen bright side up. In general, in this game, everything is as usual - there are throws that bring a new chip into play (1- khadzh ), additional throws (for example, 4 - barga ), but there is one throw that makes the game really unique. Two-point ( khmar ) - annuls the result of the previous throw and gives the right to re-throw. If he 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 will have to keep a log of moves, with the possibility of their rollback!
Some games revise the very concept of the move. In the Ambiguous Chess , shown above, the player performing the turn indicates the field to which he is about to descend, and already his opponent performs the move of one of the pieces capable of performing it. To make such a game in ZoG is difficult, but possible. " Refusal Chess " goes even further! In it, the opponent can prohibit the execution of the move declared by the player (if this move is not the only possible one) and then the player will have to make another move. Perhaps this can also be implemented on the ZRF, but I do not really know how.