Thank you for sharing this, I am very pleased to learn it is on your radar!
In case the developers team is interested, you can forward them this post explaining the core of this algorithm, but also this CodePen page with the demo and all the code freely available (the main logic is written in the wall_end_points() function in the JS section).
I did not exactly understand your example. Could you maybe post a screenshot of this? You can for instance use the ‘Salamander thing’ tool with the Clear Map and draw options to draw something describing it.
This choice is already available in the ‘Salamander algorithm’
I just made the diagonal at the beginning as default, but this is just an arbitrary choice.
For the solution (a) ‘straight line only’, I assume you refer to something similar to what is implemented in AoE3.
I don’t know the code of AoE2DE, but I think this solution would be very difficult to implement.
Even if still using the buildings grid system to define the wall end points, this would mean that there are a very (very!) huge number of angles possible for the walls (given that walls can take all the map size).
AoE2DE is still using a 2D rendering system (see here for explanations about AoE1DE). It means that you would need to store (and load in-game) as many renderings as there are possible angles (increasing a lot the size of the game and affecting the performances on lower-end systems).
If you limit the number of angles, it means you still need a ‘salamander-like’ algorithm to join end points without a correct angle.
The implementation issues do not stop there as this would also impact other stuff like the collision boxes…
On top of that, this is not just a QoL feature, because it would add stuff which cannot be achieved in the game currently.
So, it could be nice, but it seems nearly impossible to apply this to AoE2DE
To give more information about ( c ) ‘Salamander thing’:
For two wall end points, we can only draw a straight line if these two points are on the same row/column/diagonal (which is properly done in the current game implementation).
For all the other cases, we need to use straight lines connected by an intermediate point (to compute). The game always computes a L-shape in the current implementation.
The purpose of the ‘Salamander algorithm’ is to allow to choose between 4 solutions:
- diagonal attached to the first point (then horizontal or vertical) → optimal in terms of tiles & cost
- diagonal attached to the second point (then horizontal or vertical) → also optimal in terms of tiles & cost
- vertical attached to the first point (then horizontal) → L-shape
- horizontal attached to the first point (then vertical) → L-shape
The game currently only uses solution 3 or 4 (depending on the largest delta in X or Y coordinates).
If I understand properly (b) what you mentioned above, the SHIFT solution is similar to (a) straight line only (see comments above), while the CTRL solution is the game current implementation (always L-shape). In fact, I do not understand what is the difference between the CTRL solution and the ‘not using SHIFT or CTRL’ solution (except if you want to be able of building L-shapes when a single straight line is possible).
Maybe I am missing something. Could you tell me ?