Support for Infinite Piece Positions - 1.X Feature

[Naviary2]

Add support for playing games with infinitely many pieces. This would be a major 1.X update.

A chunk system would be used (256x256 maybe?) that only loads/generates a finite area of the board at a time immediately around the camera, when zoomed in.

Requirements:

• Support for defining positions of infinitely many pieces/void. With highly customizable repeating patterns.
• Placing pieces, or air, act as exceptions/overrides for infinite regions.
• Support for defining the algorithm code itself for more mathematically complex positions.
• Support for infinitely many promotion lines, specified by an algorithm.
• Checkmate & Stalemate is disabled. Win by king capture (win condition royalcapture).
• Board editor has the ability to specify generation via using the UI to place infinitely repeating pieces/void of various patterns and spacing, or manually providing the algorithm if desired. Each generation rule may override previous rules, depending on their ordering.
• When zoomed out, some sort of generalized algorithm that can render a preview of generation regions, without actually generating any chunks. Their brightness depends on their piece density.
• To allow move generation across arbitrarily many chunks of empty space, each generation rule must have clear boundaries defined, so if a piece's movement path does not intersect with any boundaries, their moves can instantly be calculated out to infinity, or atleast until they intersect the next boundary. Inside generation boundaries, pieces have to be generated first before calculating moves.
• Quality of life: Button & hotkey for teleporting to the last moved piece.

Variants that should be supported:

Obstocean with truly infinite obstacles

Infinite Armada Chess (queens repeat infinitely downward & upward)

General infinitely repeating position

All showcasings with infinitely repeating pieces

[Idonotus]

What about a system with two levels of detail. In this case I'll call them Discrete and Continuous.

• Discrete: actually holds the patterns of each piece
• Continuous: Approximates the span of a pattern for a quicker method of checking

The system would first compare continuous detail and if they overlap can start looking at discrete detail

[Naviary2]

Example? Are you referring to the various types of patterns pieces can be generated in? Are you referring to the preview renderer of generation regions?

[Idonotus]

Take this rectangle. It would be stored as several layers:

1. A rectangle of pieces (Continuous)
2. Rook pattern (Continuous)
3. Deletion overrides (Discrete)

[Naviary2]

Firstly I would argue a rectangle shouldn't be considered a pattern at all but each piece inside it added manually, or as an "override" for existing patterns.

But even if this rook pattern did extend infinitely on one axis...

I'm not thinking so much like overrides will be tied to one specific piece pattern/generation. Overrides affect ALL patterns. i.e. a piece will not be generated on a square if an override exists for it.

[Naviary2]

But piece patterns that are defined after previous patterns can override those patterns. For example in this image there would be a pattern for repeating air spaces declared after the pattern for these infinitely repeating rooks. I don't think we should think of this as an "override", just a higher priority pattern.

[Naviary2]

And for structures that aren't repeating infinitely, like this king and pawns. These are what we call overrides, and are not patterns at all they are just a list of finite pieces in the game, like how positions are described now.

[Idonotus]

Firstly I would argue a rectangle shouldn't be considered a pattern at all but each piece inside it added manually, or as an "override" for existing patterns.

I'm not saying this rectangle should be a rectangle hitbox but there would be a limit to how large of a rectangle could be created before the upper bound for complexity favors the rectangle pattern

[Naviary2]

Should we really support patterns that result in a finite number of pieces? Seems counterintuitive to why their design is needed.

[Idonotus]

I don't see why we can't and I don't see why we shouldn't

[Naviary2]

Alright, I guess massive finite structures could be cool.

Do you understand how the overrides would work?

[Idonotus]

I am cool with how overrides are but should we have multipiece patterns like:
... <- RNBKQBNR -> ...