Nick Bentley
United States Madison Wisconsin

I realized to my horror yesterday that somehow, I'd ordered the species on the Circle of Life incorrectly when I was composing Carnivores!
The order isn't arbitrary  it's based on a polyhex construction diagram and the species are *supposed* to be ordered by how difficult they are to build (the harder to build, the higher up on the food chain). However, I noticed the order wasn't right. This should only make any real difference at highlevel play, but I'm a perfectionist so I can't let it go. Here's the *correct* board:
I still need to fix this in the rules, but won't have time for that until next week.
tl;dr I'm an idiot.



It's funny because just yesterday I took a second (or third) look at
while musing on which types of tied groups would be more common in Carteso and noticed that you included no twospace jumps in that diagram. Is that the mistake that you fixed now?
I was also puzzled by this:
Quote: lines segments coming from the lefthand side should be weighted more than than those coming from the right, because objects on the left of the diagram will appear more commonly on the board (and so their construction paths will be available more frequently) than objects appearing on the right I'm sure this is right, but I'm curious as to why. Could you elaborate a little?

Stephen Tavener
United Kingdom London England
The overtext below is true.
The overtext above is false.

Let me kno what changes you need to Ai Ai. This might be a good time to add some heuristics as well.

Nick Bentley
United States Madison Wisconsin

luigi87 wrote: It's funny because just yesterday I took a second (or third) look at while musing on which types of tied groups would be more common in Carteso and noticed that you included no twospace jumps in that diagram. Is that the mistake that you fixed now?
Nope. The diagram is right. Any "twospace" jumps would require making a onespace jump first, so that's included in the diagram.
The problem was, for some reason I didn't weight the lines to a couple of the 4hexes correctly (the red lines going to them should count for about 2 and I seem not to have weighted those lines at all, so they were effectively 1), *and* there was another one out of place for reasons beyond me.
I was also puzzled by this:
Quote: lines segments coming from the lefthand side should be weighted more than than those coming from the right, because objects on the left of the diagram will appear more commonly on the board (and so their construction paths will be available more frequently) than objects appearing on the right
I'm sure this is right, but I'm curious as to why. Could you elaborate a little?
The simple version is that the more commonly some pattern shows up on the board, the easier it is to build polyhexes that can be constructed from that pattern, simply because there's more opportunity to do so. This frequency effect needs to be taken into account.
It's even a little more complicated than that though: the "bent 3" will show up even more than expected based on this diagram, due to its utility: it can capture the 2hex, which is the most important shape in the game, and you can construct 6 the 7 4hexes from it (as opposed to only 2 of 7 for the other two 3hexes). So players end up building the bent3 A LOT, and the frequency means the red lines in the 2nd layer actually end up with the highest weights, despite being only second from farthest left.
The net effect is to devalue that 4hexes that can be built most easily from the "bent3"

Nick Bentley
United States Madison Wisconsin

mrraow wrote: Let me kno what changes you need to Ai Ai. This might be a good time to add some heuristics as well.
Will do. I'll get to this next week
[edit] I'm also going to run an online tournament in the new year. That should help with heuristics

Nick Bentley
United States Madison Wisconsin

luigi87 wrote: It's funny because just yesterday I took a second (or third) look at while musing on which types of tied groups would be more common in Carteso and noticed that you included no twospace jumps in that diagram. Is that the mistake that you fixed now?
It occurs to me you might be talking about the 2way stretch? That *is* in the diagram, in the upper left. I need to remake this diagram so it's more clear. At some I'm going to write about how this game was designed (probably my most involved design), and I've been sort of waiting until then to make a nice version.



milomilo122 wrote: Any "twospace" jumps would require making a onespace jump first, so that's included in the diagram. But, by the same token, couldn't you also say that any onespace jumps require making a zerospace jump first and that therefore onespace jumps needn't be included either?
milomilo122 wrote: the more commonly some pattern shows up on the board, the easier it is to build polyhexes that can be constructed from that pattern, simply because there's more opportunity to do so. This frequency effect needs to be taken into account. I was actually wondering how is it that some nstone patterns occur more frequently than others in ways other than those reflected by the line segments, but I guess you just meant that you placed the polyhexes in descending order of number of lines segments pointing at them in the diagram itself, right?



milomilo122 wrote: It occurs to me you might be talking about the 2way stretch? No, I was just talking about any two stones that are three singlecell steps away from eath other.

Nick Bentley
United States Madison Wisconsin

luigi87 wrote: milomilo122 wrote: Any "twospace" jumps would require making a onespace jump first, so that's included in the diagram. But, by the same token, couldn't you also say that any onespace jumps require making a zerospace jump first and that therefore onespace jumps needn't be included either?
I don't follow your logic, but here's how I think of it: each layer shows all the patterns that can be made from the previous layer by the addition of a single stone. That's all I need to know to make my calculations. (noting I've left out the single space hops in the layer of 4hexes  no need to have them because they would only be useful for calculation if 5hexes were allowed, which they aren't)
Quote: milomilo122 wrote: the more commonly some pattern shows up on the board, the easier it is to build polyhexes that can be constructed from that pattern, simply because there's more opportunity to do so. This frequency effect needs to be taken into account. I was actually wondering how is it that some nstone patterns occur more frequently than others, but I guess you just meant that you placed the polyhexes in descending order of number of lines segments pointing at them in the diagram itself, right?
Yes, a better description than frequency is "degrees of freedom in construction" or "how many enemy stones are required to block the construction of a particular polyhex", but those are mouthfuls.



milomilo122 wrote: I don't follow your logic, but here's how I think of it: each layer shows all the patterns that can be made from the previous layer by the addition of a single stone. That's all I need to know to make my calculations. I was specifically referring to your leaving out the patterns
. . . . . . x . . x . . . . . .
and
. . . . . x . . . . . . x . . . . .
in the second row. I still think those need to be included to get the frequencies right, but maybe I'm missing something.

Nick Bentley
United States Madison Wisconsin

luigi87 wrote: milomilo122 wrote: I don't follow your logic, but here's how I think of it: each layer shows all the patterns that can be made from the previous layer by the addition of a single stone. That's all I need to know to make my calculations. I was specifically referring to your leaving out the patterns . . . . . . x . . x . . . . . .and . . . . . x . . . . . . x . . . . .in the second row. I still think those need to be included to get the frequencies right, but maybe I'm missing something.
hmmmm, let me think about it. So your notion here is: when you add a stone to one of these, you are jumping from the 2stone layer to the 3stone layer, and that this is important for calculating degrees of freedom?

Nick Bentley
United States Madison Wisconsin

by jove I think you may be right! I'm going to dwell on this for a bit more, but def leaning your way at the moment.
[edit] ok you're definitely right. equal parts fascinated and embarrassed over here
[another edit] looks like I need to do the circle again. I'll have luis check my work this time



milomilo122 wrote: by jove I think you may be right! I'm going to dwell on this for a bit more, but def leaning your way at the moment. [edit] ok you're definitely right. equal parts fascinated and embarrassed over here [another edit] looks like I need to do the circle again. I'll have luis check my work this time Well, I think I'm not considering all angles of the problem. I never thought of including
milomilo122 wrote: "how many enemy stones are required to block the construction of a particular polyhex" in the equation, for instance, and I wouldn't know how to.
The only thing I'm reasonably sure of is that if 1space jumps are included, leaving out 2space jumps should be wrong.
And this is where I start brooding over how much better games I could make if I had a better understanding of mathematics.
Not to mention how much better games we could have if mathematicians were more interested in designing games.

Nick Bentley
United States Madison Wisconsin

luigi87 wrote: Well, I think I'm not considering all angles of the problem. I never thought of including milomilo122 wrote: "how many enemy stones are required to block the construction of a particular polyhex"
This is equivalent to the number of lines going between one pattern and a pattern in the next layer down.
For example, I can place a stone in 6 different spots next to a singleton to create a 2hex. Therefore, I'd need 6 enemy stones to make it impossible for that singleton to become a 2hex.

Nick Bentley
United States Madison Wisconsin

luigi87 wrote: Not to mention how much better games we could have if mathematicians were more interested in designing games.
Plenty of mathematicians design games. They have their own problems though: they often fail to be sensitive to human psychology, e.g. Multiple modes of thought are needed.



milomilo122 wrote: luigi87 wrote: Well, I think I'm not considering all angles of the problem. I never thought of including milomilo122 wrote: "how many enemy stones are required to block the construction of a particular polyhex" This is equivalent to the number of lines going between one pattern and a pattern in the next layer down. For example, I can place a stone in 6 different spots next to a singleton to create a 2hex. Therefore, I'd need 6 enemy stones to make it impossible for that singleton to become a 2hex. Oh, right. Trying to accommodate enemy stones in the system threw me off the track there.

Nick Bentley
United States Madison Wisconsin

luigi87 wrote: milomilo122 wrote: luigi87 wrote: Well, I think I'm not considering all angles of the problem. I never thought of including milomilo122 wrote: "how many enemy stones are required to block the construction of a particular polyhex" This is equivalent to the number of lines going between one pattern and a pattern in the next layer down. For example, I can place a stone in 6 different spots next to a singleton to create a 2hex. Therefore, I'd need 6 enemy stones to make it impossible for that singleton to become a 2hex. Oh, right. Trying to accommodate enemy stones in the system threw me off the track there.
Cool. Of course, this analysis doesn't include edge effects (degrees of freedom in construction differ at the edges), which are a bit beyond me at the moment.



I've pondered on this a bit more and feel that I understand it better now. In fact, I think
milomilo122 wrote: edge effects (degrees of freedom in construction differ at the edges) should be easy to incorporate.
There are six ways to make a 2stone group starting from a single stone on any cell of an infinite board. Therefore, in your diagram, you currently assign this a 6.
Instead of that, you could assign it a
37*6 + 18*4 + 6*3 = 312
based on the fact that, on the Carnivores board, there are 37 cells where a singleton can be turned into a 2stone group in 6 ways, 18 cells where a singleton can be turned into a 2stone group in 4 ways and 6 cells where a singleton can be turned into a 2stone group in 3 ways.
And so on and so forth.

Nick Bentley
United States Madison Wisconsin

luigi87 wrote: I've pondered on this a bit more and feel that I understand it better now. In fact, I think milomilo122 wrote: edge effects (degrees of freedom in construction differ at the edges) should be easy to incorporate. There are six ways to make a 2stone group starting from a single stone on any cell of an infinite board. Therefore, in your diagram, you currently assign this a 6. Instead of that, you could assign it a 37*6 + 18*4 + 6*3 = 312 based on the fact that, on the Carnivores board, there are 37 cells where a singleton can be turned into a 2stone group in 6 ways, 18 cells where a singleton can be turned into a 2stone group in 4 ways and 6 cells where a singleton can be turned into a 2stone group in 3 ways. And so on and so forth.
It gets more complicated for larger groups though, because the orientation and distance of the group with respect to the edge influences the calculation. You'd have to do the same calculation a bunch of times for multiple edgegroup configurations for a single group. Not against it but it's a big job and easy to get wrong.
Also, I want one circle of life that applies to every board size. So to *really* go deep, you'd have to average over the board sizes people would realistically play on. (hexhex5 is prob smallest, but I don't know about how big it might go)



milomilo122 wrote: It gets more complicated for larger groups though, because the orientation of the group with respect to the edge influences the calculation. Since the board is symmetrical, I think the calculation is exactly the same for each of the six rotations of a stone pattern. Rotating the stone pattern is equivalent to rotating the board, and rotating the board results in the same board.

Nick Bentley
United States Madison Wisconsin

luigi87 wrote: milomilo122 wrote: It gets more complicated for larger groups though, because the orientation of the group with respect to the edge influences the calculation. Since the board is symmetrical, I think the calculation is exactly the same for each of the six rotations of a stone pattern. Rotating the stone pattern is equivalent to rotating the board, and rotating the board results in the same board.
Here's why I'm not sure that's right: consider the threeinarow pattern. How many ways are there to make, eg, 4inarow, when the 3inarow is touching an edge?
Well, if the 3inarow is flush against the edge, the answer is 2. But if not, the answer is 1.
I think there are several cases like this.
Maybe another way to say this is that a multistone group can span multiple spacetypes, and how it spans them matters.

Russ Williams
Poland Wrocław Dolny Śląsk

milomilo122 wrote: Also, I want one circle of life that applies to every board size. So to *really* go deep, you'd have to average over the board sizes people would realistically play on. (hexhex5 is prob smallest, but I don't know about how big it might go) But if the order is different for different board sizes, then you wouldn't really be able to have one "correct" order for different board sizes.
And if the order is the same for different board sizes, then there's no need to worry about computing it for different board sizes and then averaging those (and making the subjective judgment about the distribution of sizes which would be played on in practice).
So it seems (at first glance to me, anyway) like it would make sense to simply ignore edge effects and (in effect) assume an arbitrarily large / infinite board (with the philosophy that larger board sizes are the "real" game anyway, analogous to 19x19 Go instead of 13x13 and 9x9 being "real" Go)
(and with the philosophy that any simple computed "objective" measure is not necessarily "correct" in any case, but is a simplifying abstraction, if it's not also taking into account a complete (hugely intractible) game tree because of higher level effects impacting difficulty of forming shapes based on wholeboard stuff). (E.g. similarly I've seen games which use various pokerstyle hands but don't rank them merely on some simple obvious objective measure like how many ways there are to form them but involve some subjective judgment based on playtesting)
(and with the philosophy that the asymptotic limit as the board grows large is itself a handwavingly natural / objective and frequently used notion in math)
But I don't know.



milomilo122 wrote: consider the threeinarow pattern. How many ways are there to make, eg, 4inarow, when the 3inarow is touching an edge?
Well, if the 3inarow is flush against the edge, the answer is 2. But if not, the answer is 1. My point is that, in your example, you'll cover all possibilities by simply "scanning" the board with one of the six rotationally symmetrical versions of the 3inarow pattern. You needn't even multiply by six afterwards because that's already accounted for in previous steps of the diagram.

Nick Bentley
United States Madison Wisconsin

luigi87 wrote: milomilo122 wrote: consider the threeinarow pattern. How many ways are there to make, eg, 4inarow, when the 3inarow is touching an edge?
Well, if the 3inarow is flush against the edge, the answer is 2. But if not, the answer is 1. My point is that, in your example, you'll cover all possibilities by simply "scanning" the board with one of the six rotationally symmetrical versions of the 3inarow pattern. You needn't even multiply by six afterwards because that's already accounted for in previous steps of the diagram.
Ah, yes, ok, I see what you're saying. Agreed.

Nick Bentley
United States Madison Wisconsin

russ wrote: And if the order is the same for different board sizes, then there's no need to worry about computing it for different board sizes and then averaging those (and making the subjective judgment about the distribution of sizes which would be played on in practice).
So it seems (at first glance to me, anyway) like it would make sense to simply ignore edge effects and (in effect) assume an arbitrarily large / infinite board (with the philosophy that larger board sizes are the "real" game anyway, analogous to 19x19 Go instead of 13x13 and 9x9 being "real" Go)
This is why I haven't put much effort into including edge effects. In fact, if I were a betting man, I'd bet edge effects don't change the order.
Quote: (and with the philosophy that any simple computed "objective" measure is not necessarily "correct" in any case, but is a simplifying abstraction, if it's not also taking into account a complete (hugely intractible) game tree because of higher level effects impacting difficulty of forming shapes based on wholeboard stuff).
Yep. I would love to revisit the question with a group of experienced players, if any ever exist, to see if experience suggests the theory I've concocted doesn't match practice.
One great difficulty is the problem is recursive: if higher order effects change the difficulties enough to change the order on the circle, that's not the end of it, because rearranging the circle alters the higher order effects. Which means you have to start the evaluation process again.
I'd love to convince Little Golem to do the game so I could get some players.
Do you think LG might be interested in being part of a dev process, rather than a home for completely finished games?
If it turns out they would, would anybody here be willing to write a note lobbying for its inclusion?
I also wonder whether Cameron's software might be repurposed usefully to study the question. Instead of evaluating different games, it evaluates different Circle of Life arrangements. As a fairly constrained problem, it seems like something that an algorithmic approach might do well.


