December 21, 2011 at 15:26Hyperburg - a three-dimensional version of the game "Carcassonne"
Recently, at one of the forums devoted to multidimensional spaces, the question was asked: “And what games are implemented in non-trivial spaces, in particular, is there any implementation of the Carcassonne game on the Lobachevsky plane?” The question seemed interesting to me, especially since I had never heard of this game.
But in vain! The game turned out to be simple enough to try to adapt it to various spaces. This game is board. Players take turns laying out cards with fragments of a map of the area, trying to fold a connected map. During the game, players can capture some elements of the field, and receive points for completed elements.
It is clear that the scope for generalizations towards non-trivial geometry is enormous. Instead of square cards, you can design triangular or hexagonal. You can stack square cards on the surface of the cube (there will be 8 special points at which 3 rather than 4 cards converge, but this is not very important). You can draw a square grid on the Lobachevsky plane, at each vertex of which 5 (or 6, or infinitely many) squares converge. And you can replace square cells with cubic ones and build a map in space.
I have chosen the last option. It was very interesting to see how the terrain map on a four-dimensional planet would look.
To begin with, it was necessary to decide which version of the game I would adapt: there are several different basic sets of cells and rules that also have extensions with additional elements and objects. The choice fell on the option “Discovery” (aka “New World”, aka “New Lands”). There, the land is divided into three areas (seas, mountains, plains), and for completed (and even incomplete) objects you can get points.
The first estimates showed that there will be few three types of regions: on average, the cube will have two faces of each color, and you can expect an infinite growth of connected regions. Therefore, I immediately added the fourth type (desert) and set to work.
Alas ... after several dozens of laid out tiles, it became clear that it would not be possible to figure out the resulting map. The surface was too ragged, the translucent borders between areas of different colors were mixed, and I could not figure out how far this or that area extends:
Later I found a couple of ways that give a chance to make this option more or less understandable, so maybe I will return to him. But for now, it was necessary to look for something that would make an interface that was clear and suitable for the game. And the rules following the simplicity were found in the basic version of the game.
In the basic version, there are four elements of topography: cities, roads, monasteries, and fields that occupy the rest of the territory. Players during the game can occupy roads (areas bounded by ends or intersections), cities (areas bounded by walls), monasteries (individual cells) and fields. Points are awarded for completed objects (except fields) (objects are freed), and fields are evaluated only at the end of the game.
It is clear that in the three-dimensional case, the idea of a field as an element of topography does not work: roads do not divide the land into parts, and in most cases the whole map turns out to be one large field interspersed with cities. To maintain interest, I added another similar pair to cities and roads - seas and rivers. With a slightly different scoring: if a city is estimated by area, then the sea - by the number of ports (cells where rivers and sections bordering cities flow into it), and in rivers, unlike roads, intersections are not the boundaries of the section. But these are all cosmetic changes. The first question is what the playing field will look like and what kind of playing cards will be.
For the game, it is necessary that fragments of objects on new cells continue unfinished objects that are already on the field. This means that cell faces should provide convenient opportunities for their docking. The easiest way to achieve this is to make the relief on the faces symmetrical - so that any two cells with faces of the same type can join these faces in any of four possible ways. The selected game elements (plain, river, sea, road, city) give such an opportunity: it is enough that the city and the sea can occupy the faces only as a whole, and the roads and rivers pass through the centers of the faces. If such a detail of the relief as canyons (two-dimensional surfaces that divide the space into parts) were added, then this method would not work - we would have to take into account the relative orientation of the cells relative to the axis passing through their centers.
I divided the cell into 7 zones: 6 correspond to the faces and have the shape of truncated square pyramids, and the seventh in the center has the shape of a cube. External zones can be in one of 5 states (all except monasteries), internal - in one of six. The geometry and topographic properties of the cell are completely determined by the state of its zones: two sections of the sea or city belonging to neighboring faces are adjacent, if exactly two faces of the cell (and adjacent) are in the “road” state, then the road connects the centers of these faces (in other cases - connects the face to the central zone). And there are a few limitations. For example, if three or more roads enter a cell, then the central zone should be a “city” (and play the role of an intersection).
I was afraid to enumerate all possible cells, and chose random generation: first, the states of all faces are determined for the cell (with certain probabilities: plain - with 1/2 probability, river and road - 1/6, sea and city - 1/12) , then the possible states of the central cell are determined. If a monastery is possible in the center, it is placed with a probability of 1/8, and if this does not happen, the condition is chosen equally likely from all possible. After that, the cage is offered for the game. (Later I calculated that the number of different cells is approximately 750, so you can generate and include a complete list in the program, at the same time providing each with some chance of occurrence) The
starting cell looks like this:
On it there are fragments of the city, river and road. The cell is placed on the field, and in a separate window the next cell is displayed. To move, you need to rotate the cell and the field so that the face of the field to which we want to attach the cell is front, and the face of the cell that we want to attach it, looks towards it:
Use the left mouse button to rotate the cell and field, to rotate the camera - right. To zoom in / out - Ctrl + left button.
After choosing the correct orientation, just click on the center of the edge of the field on which you want to put the cell, and if the move is possible, then it is done. After that, the player is offered to put one of his chips (if there are free chips, there are only 8 of them) on some part of the cell. Possible areas are represented by blue balls:
The player can click on one of the balls or press the “Skip” button (if he does not want to place the chip). The selected ball turns into an asterisk of the color corresponding to this player, and the turn is transferred to the next.
After a few moves, it becomes difficult to navigate the situation on the field:
To facilitate the life of players, there are several additional visualization modes. In order to analyze the outer edges of cells in the field (and understand where to go), the outer edges of the field are made less transparent:
To better analyze the shape of individual objects, you can reduce their transparency and increase the transparency of the outer edges of the plain:
And finally, in order to more reliably determine the color of the chips on the field (for example, if the chip is in the sea or in the city), and just see the position of all the chips, there is a mode in which all objects become white and almost transparent:
Before starting the game, you can select the number of players (from 2 to 5) and the duration of the game (number of moves - from 20 to 10,000). After selecting them, click the New Game button.
Read more detailed rules (in English)
on this page . The executable code can be downloaded from here , and the source code from here . The program is written in C # using the Open Toolkit library. Requires Windows with .NET 2.0 to work
But in vain! The game turned out to be simple enough to try to adapt it to various spaces. This game is board. Players take turns laying out cards with fragments of a map of the area, trying to fold a connected map. During the game, players can capture some elements of the field, and receive points for completed elements.
It is clear that the scope for generalizations towards non-trivial geometry is enormous. Instead of square cards, you can design triangular or hexagonal. You can stack square cards on the surface of the cube (there will be 8 special points at which 3 rather than 4 cards converge, but this is not very important). You can draw a square grid on the Lobachevsky plane, at each vertex of which 5 (or 6, or infinitely many) squares converge. And you can replace square cells with cubic ones and build a map in space.
I have chosen the last option. It was very interesting to see how the terrain map on a four-dimensional planet would look.
To begin with, it was necessary to decide which version of the game I would adapt: there are several different basic sets of cells and rules that also have extensions with additional elements and objects. The choice fell on the option “Discovery” (aka “New World”, aka “New Lands”). There, the land is divided into three areas (seas, mountains, plains), and for completed (and even incomplete) objects you can get points.
The first estimates showed that there will be few three types of regions: on average, the cube will have two faces of each color, and you can expect an infinite growth of connected regions. Therefore, I immediately added the fourth type (desert) and set to work.
Alas ... after several dozens of laid out tiles, it became clear that it would not be possible to figure out the resulting map. The surface was too ragged, the translucent borders between areas of different colors were mixed, and I could not figure out how far this or that area extends:
Later I found a couple of ways that give a chance to make this option more or less understandable, so maybe I will return to him. But for now, it was necessary to look for something that would make an interface that was clear and suitable for the game. And the rules following the simplicity were found in the basic version of the game.
In the basic version, there are four elements of topography: cities, roads, monasteries, and fields that occupy the rest of the territory. Players during the game can occupy roads (areas bounded by ends or intersections), cities (areas bounded by walls), monasteries (individual cells) and fields. Points are awarded for completed objects (except fields) (objects are freed), and fields are evaluated only at the end of the game.
It is clear that in the three-dimensional case, the idea of a field as an element of topography does not work: roads do not divide the land into parts, and in most cases the whole map turns out to be one large field interspersed with cities. To maintain interest, I added another similar pair to cities and roads - seas and rivers. With a slightly different scoring: if a city is estimated by area, then the sea - by the number of ports (cells where rivers and sections bordering cities flow into it), and in rivers, unlike roads, intersections are not the boundaries of the section. But these are all cosmetic changes. The first question is what the playing field will look like and what kind of playing cards will be.
For the game, it is necessary that fragments of objects on new cells continue unfinished objects that are already on the field. This means that cell faces should provide convenient opportunities for their docking. The easiest way to achieve this is to make the relief on the faces symmetrical - so that any two cells with faces of the same type can join these faces in any of four possible ways. The selected game elements (plain, river, sea, road, city) give such an opportunity: it is enough that the city and the sea can occupy the faces only as a whole, and the roads and rivers pass through the centers of the faces. If such a detail of the relief as canyons (two-dimensional surfaces that divide the space into parts) were added, then this method would not work - we would have to take into account the relative orientation of the cells relative to the axis passing through their centers.
I divided the cell into 7 zones: 6 correspond to the faces and have the shape of truncated square pyramids, and the seventh in the center has the shape of a cube. External zones can be in one of 5 states (all except monasteries), internal - in one of six. The geometry and topographic properties of the cell are completely determined by the state of its zones: two sections of the sea or city belonging to neighboring faces are adjacent, if exactly two faces of the cell (and adjacent) are in the “road” state, then the road connects the centers of these faces (in other cases - connects the face to the central zone). And there are a few limitations. For example, if three or more roads enter a cell, then the central zone should be a “city” (and play the role of an intersection).
I was afraid to enumerate all possible cells, and chose random generation: first, the states of all faces are determined for the cell (with certain probabilities: plain - with 1/2 probability, river and road - 1/6, sea and city - 1/12) , then the possible states of the central cell are determined. If a monastery is possible in the center, it is placed with a probability of 1/8, and if this does not happen, the condition is chosen equally likely from all possible. After that, the cage is offered for the game. (Later I calculated that the number of different cells is approximately 750, so you can generate and include a complete list in the program, at the same time providing each with some chance of occurrence) The
starting cell looks like this:
On it there are fragments of the city, river and road. The cell is placed on the field, and in a separate window the next cell is displayed. To move, you need to rotate the cell and the field so that the face of the field to which we want to attach the cell is front, and the face of the cell that we want to attach it, looks towards it:
Use the left mouse button to rotate the cell and field, to rotate the camera - right. To zoom in / out - Ctrl + left button.
After choosing the correct orientation, just click on the center of the edge of the field on which you want to put the cell, and if the move is possible, then it is done. After that, the player is offered to put one of his chips (if there are free chips, there are only 8 of them) on some part of the cell. Possible areas are represented by blue balls:
The player can click on one of the balls or press the “Skip” button (if he does not want to place the chip). The selected ball turns into an asterisk of the color corresponding to this player, and the turn is transferred to the next.
After a few moves, it becomes difficult to navigate the situation on the field:
To facilitate the life of players, there are several additional visualization modes. In order to analyze the outer edges of cells in the field (and understand where to go), the outer edges of the field are made less transparent:
To better analyze the shape of individual objects, you can reduce their transparency and increase the transparency of the outer edges of the plain:
And finally, in order to more reliably determine the color of the chips on the field (for example, if the chip is in the sea or in the city), and just see the position of all the chips, there is a mode in which all objects become white and almost transparent:
Before starting the game, you can select the number of players (from 2 to 5) and the duration of the game (number of moves - from 20 to 10,000). After selecting them, click the New Game button.
Read more detailed rules (in English)
on this page . The executable code can be downloaded from here , and the source code from here . The program is written in C # using the Open Toolkit library. Requires Windows with .NET 2.0 to work