Work in vain

Work in vain

A little about the things that will definitely be in each project - thrown out developments. This can happen for a variety of reasons: as you slowly implement it, you realize that it doesn't fit with other elements; getting rid of non-essential things due to the imminent deadline; project restructuring. An unpleasant moment, but can't go without it.

In the version for Jam, a system of bonuses for grouping cells works, if a cell is adjacent to another cell of the same type, then the player receives more coins (there are restrictions on grouping so that the player does not store cells in one place, but that's not the point) . To calculate the income, we used a depth-first search* (dfs is an algorithm for traversing the entire graph, that is, in this case, the map), which runs through the entire map after each move.

This solution fit well with the small size of the world. There were extra calculations for cells that did not change during this move, but this was insignificant. Next, we wanted to enlarge the map to introduce other mechanics. But then extra calculations could greatly slow down the program. Therefore, it was decided to optimize this system.

New idea

The recalculation of income occurred in 3 cases: setting the cell, curing the cell, and corruption. In the first two cases, we could simply run dfs from an exposed cell (consider a cured cell is also new). We simply add money per cell and if the grouping consisted of less than 7 cells, add another bonus. Problems arose when cells were infected, since this, one might say, is the removal of a cell. In this regard, difficulties could arise when one grouping was connected by one hex, the removal of which gave rise to 2 groupings (we will call such cells a bridge).

Consider a forest.

Previously, there were 9 cells in the grouping, more than necessary, so the bonus was limited to 6.

After infecting the cell, there are 2 groups, there will still be 6 bonuses.

Then it would be necessary to reduce from 0 to 2. Therefore, it is necessary to separate the cases when the bridge was infected, and when the usual cell. To do this, you can modify dfs so that it finds them. Then, when infected, we find bridges among the group of cells that the infected one belongs to, and check whether the infected cell is a bridge, if not, then we simply subtract the bonus depending on the number of cells in the group. If yes, then we need to know how many cells are in the first and second groupings. Then, knowing this, we calculate how many bonuses need to be removed.

It would seem that this is the solution to the problem, but we decided to rework our project. The grouping system is no more, it doesn't fit with the new mechanics. Therefore, this implementation is left for the future, maybe someday it will come in handy.

Footnote

* - how dfs works. We just look at all 6 neighbors of the cell, if it exists, the type is the same and we were not in it, then we move into it, increasing the counters

The brown circle - the current cell.

Purple arrow - go to an unvisited neighbor

Orange arrow - return to the previous cell when there are no more neighbors for the current cell in order to find a new unvisited neighbor of the old cell.