Attack of the Nerd Squad

The following programs exist for creating optimised beacon maps:

Currently **Rebrane's** program gives the most optimal maps, which are found on User:Rebrane/Optimal beacon configuration .

**Hyphz v2** can tie with Rebrane but has not yet exceeded it; it can however generate (relatively) higher scoring maps more reliably.

**MisterCodo** can tie on some maps and exceed on a few others. It can also generate graphical maps from textual ones and can optimize for speed+production combined.

**Rabbit**'s program provides a visual view of the effect of all beacons and the solving process. It is so far the only program that can optimize for efficiency or combinations including efficiency.

#### Algorithm Notes

Tutorial Island, the smallest map, has 132 available squares. If only Square beacons are available, then each of these squares can either have a beacon or not, meaning that the number of potential combinations is a 132-bit number - 5,444,517,870,735,015,415,413,993,718,908,291,383,296. A computer that could score 1,000,000,000 (1 billion) states a second would still take millions of years to check them all, so it is clearly not possible to evaluate every combination.

As a result, most programs have used **local search** techniques instead. These are based on searching only positions that are close to the current position, then repeating this process to gradually move towards better solutions. There are several approaches that have been implemented so far.

**Hill Climbing** is based on taking the "current" map, trying every possible single move (adding, removing, or replacing a beacon) and seeing which one yields the highest score, then repeating the process. This will quickly produce an efficient map, but it will often not produce the **most** efficient map, because it focuses entirely on improvements that can be achieved in one move. It will eventually reach a state which cannot be improved in one move, but is not necessarily the optimal state available, nor even the best that could be reached with a larger number of changes; this is called a **local maximum** (plural maxima).

This is especially the case in NGU industries because of the way wider beacons can stack. In production when Knights and Arrows are available, the total score added by a single Knight is greater than that added by a single Arrow. However, in most positions it is easier to apply multiple Arrows without them blocking each other, which yields a greater benefit than using Knights. However, straight Hill Climbing will not detect this because adding a knight always gives a greater benefit in one move.

As a result two variant algorithms have been used.

**Randomised Hill Climbing** makes a small number of *random* moves and takes the best of those, rather than trying every move. This will thus have a *chance* of trying every move, but will still favour those that provide immediate benefit.

**Beam Search** tries all moves, but rather than keeping only the one best result, keeps a larger number (called the **beam width**). For example, if the beam width is 50, it will keep the top 50 results. At the next step, it will try all moves on *all 50 previous results*, and keep the top 50 results amongst all of those. Beam Search is less likely to hit a local maximum than straightforward Hill Climbing, but may still do so; and without a random element, it will always reach the same local minimum every time it is used.

The most successful approach so far has been to **alternate** these two approaches, by starting from a random position, using a Beam Search to refine it until it reaches a local maximum, then trying a different random position in the hope that it will refine to a better local maximum.

## Simplifying laws

There are a number of observable rules that simplify the problem.

Rule 1: **The total bonus granted by a beacon can only be lowered by other beacons, never raised.**

Beacons do not give bonuses to other beacons. The only interaction between beacons is that a beacon B placed on a square affected by another beacon A causes that square not to be productive and thus reduces beacon A's total benefit.

This means that there is a fixed upper bound on the maximum benefit a given beacon can have on a given square, which can be calculated as the benefit that beacon has on a map with no other beacons. In the case where that upper bound is less than 100 (the number of points lost by placing a beacon on a square), there is never any point placing that type of beacon on that square. This can be used to reduce the search space and generally eliminates obviously bad moves such as placing an arrow pointing off the edge of the map.

Rule 2: **Beacons are affected only by the position of other beacons, not by their type.**

Since beacons only affect other beacons by blocking squares they affect, it does not matter what type they are. This is very important! It means that it is possible to calculate the benefit of a beacon in a given position while knowing only the **positions** of other beacons on the map, not their **type.**

These rules them have two valuable corrolaries:

**C1: In any optimal map each individual beacon will be of the type that offers the maximum benefit on that square.**

If this were not the case, then replacing the beacon with one that offered more benefit on that square would increase the score, which would mean the map is not optimal. It is not necessary to consider that the beacon might be benefitting from or providing benefit to other beacons, because this cannot happen (rule 1)

**C2: That "best" type can be calculated knowing only beacon positions, not beacon types.**

Because of rule 2, to calculate the best beacon type for a square you only need to know where other beacons are, not what type they are (because that doesn't change how they effect other beacons - once you know that the square is blocked, that's enough).

Which gives the following, intriguing, result:

**For any given range of available beacon types, and map showing which squares contain beacons, there is exactly one optimal mapping of beacon types to those locations, and that can be calculated in place.**

This means that the search space can be dramatically reduced by not considering beacon types during search, but identifying each square as only "unavailable", "free" or "beacon". This can then be turned in-place into a map with optimal beacon types by examining each "beacon" square and considering which of the available beacon types increases the map's score by the most, when considering other "beacon" squares to score 0. It will be impossible for any map with the same arrangement of beacons but different beacon types to exceed that of the generated map.