The difficulty of it varies greatly depending on two important parameters:
- the (maximum?) number of colors,
- the random distribution (how random is it really).
Unfortunately there are no loops in Geometry Nodes. You can use fields together with a group of things like points to do many things that loops can accomplish, but you can't manage state during a loop, except for "Accumulate Field" node, which is, however, quite limited: it just sums all elements, giving access to a sum of all elements up to the current element (excluding or including the current element). So while in a normal programming language you would just iterate over bricks and for each (4) randomize a color different than the preceding bricks (1-3), in Geonodes it's not yet possible:
So here's a much worse solution:
- Define 3 pools of colors:
- basic pool of colors used for the 1st pass,
- 2 replacement colors used for odd rows,
- 2 replacement colors used for even rows.
- Randomize brick colors out of the basic pool.
- For each brick check if it ended up with one of the colors of its 3 preceding neighbors. If so:
- pick a replacement pool depending on the row being odd or even,
- pick the 1st or the 2nd color of the replacement pool depending on the brick being odd or even on this row.
This means you need at least 4 colors (in which case you just get alternating colors), with each additional color (one added to the basic pool) improving the random distribution.
There is some room for improvement for this algorithm, like Accumulate Field nodes could be used to not glue specific replacement colors to the alternating pattern, so you would modulo the accumulated value (which would accumulate only on replacements) rather than $x$, also a random value may be generated for each row, deciding which of the two colors of the replacement pool should be first on each row.