That connection between playing Go well and being able to describe positions that arise is the precise section I am going to be working on.

I have this concept of Shapes. One thing I noticed when playing Chess, Othello, and learning Go, is that there's this concept of pressure in space and time. I'll use Chess as an example, as it's the game I know how to describe best.

If you're executing an attack on the King's Side, then what you are doing is attempting to have more officers able to reach the opponent's KS than your opponent can muster in defence. This is pressure in space - you have cut off places your opponent can safely move to. This is also pressure in time, in that your opponent needs more moves to successfully defend than you need to successfully attack.

All pressures can be graphed. The trick to graphing is to find meaningful axes and to assign meaningful values to the observed phenomena. Anything that can be graphed has a shape (and, potentially, an equation).

So, what I want to do is to start observing how these shapes interact with one another. What properties do these shapes have? Go is actually easier to do this with than Chess because the game naturally lends itself to this concept, due to its grouping nature. The shapes (initially) will be the actual groups of pieces. In Chess, these shapes are based on what the pieces will do, not on the pieces themselves.

I think that this is much closer to the way humans think about strategy games than static board analysis. I know that when I think about a move in Chess (or Go), I'm not thinking about the board position that will arise so much as about the pressures I will be placing on my opponent. I'm thinkin about keeping to the fundamentals and making solid moves. Why are they solid moves? Because they apply more pressure to the opponent. Your army is a weapon - as sharp or blunt as you want to make it. If you have sufficiently more men, a blunt attack is fine, otherwise a sharp attack is demanded.

------
We are the carpenters and bricklayers of the Information Age.

Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.