Lineage (New Abstract Board Game)

Hi, and welcome to the BGDF. I hope your interest in game design keeps you around beyond this one project, since you seem to have a genuine interest and talent beyond any one given project!

I love abstract strategy games, and thought Lineage seemed elegant and interesting. Here are a few thoughts about the rules, having never played the game (so take this for what it's worth).

Notation
I think that notation is important for serious analysis, and would suggest that you give each line a letter, Uppercase for one side and lowercase for the other, with intersections being denoted as a combination of the lines involved, with a number appended as needed, should there be any duplicate intersections. I'd denote the starting ovals as lines A and a, for maximum clarity, with the left-side circles listed as B and b. Those closed ellipses are distinct, and should be taken care of first, though all of the arcs on the board are topologically closed by the "opposite side of the line" rule.

Setup
The rules, as written, don't take into account the influence of one player's setup on the setup decisions of the other. Given how mobile pieces are, this is an important consideration. If one player sets up first, and then the other responds with their own setup, there will be an advantage given to the second player, who can respond to inadequacies in the initial player's choices.

To address this, you could add a setup phase, in which players alternate placing their ten pieces, but, again, one player will be responding to the other, and get the "last word". Basically, you've got a stone-placement minigame, which would have its own strategies, which could introduce annoying delays before the heart of the game gets beating. But the only other choice is fixed placement, which then raises the specter of opening books, and simply gives player advantage all the more weight.

My own suggestion, which would limit the setup phase while keeping soe sort of strategic dimension, would be to allow the player to set up as many stones as they want, as long as the number they place is equal or higher than the number their opponent placed before them. If you don't have any stones to place, you take your first turn. This allows a player to try to develop an early advantage by hanging back, matching the opposing deployment numbers, but allows a player to basically claim first move at any time by depleting their setup stores, but giving the opposition the opportunity to setup in commensurate response. With just ten stones to place, such a setup phase would be over quickly.

Game Breaking
I check my abstracts especially well for the two game-breaking flaws: Perfect Defense and Perfect Attack. Have you vetted this game for mirroring play? Since the board appears to be symmetrical, it seems possible for one player to exactly mirror the play of the other, at least to a point. This can sometimes lead to frustrating Perfect Defenses, and your game has an open-ended movement that might allow such a play style, making a strategic advantage impossible to secure, since each play could be mirrored by the other player, and captures perfectly equalled, ending in a draw each time.

A suggestion to disallow Mirroring is to give each player a single black stone, playable on any turn, that acts in all ways like a break in the lines that form its intersection: you can't slide past it, and it effectively deletes the space it occupies (which cannot be one of the central four, and, I suspect, shouldn't be one of the adjacent intersections, either), thus making capturing around it somewhat easier, as it eliminates one liberty for nearby stones. This is only quasi-elegant, but may save your game, or give you ideas for some other way to break the potentially fatal perfection of your board's topography.

I haven't seen an opportunity for Perfect Attack, but I'm sure a better player than I would be able to find a very strong opening, perhaps strong enough to tip the balance invariably in their favor. How heavily have you tested this game to such opportunities? If you're like me (and I hope, for your sake, you'r not) you'll have a hard time seeing how your game will really be played, having designed the rules to reflect imagined strategies. Real players often surprise (and annoy) by coming up with completely game-shattering tactics. If you plan on marketing this game, I'd advise a serious round of heavy playtest. Have you considered using the program Zun Tzu? If you do, say "Hi" to Jerome for me!

Anyway, it looks good, and I hope to give it a whirl sometime. Good luck, and keep us informed.

Why don't you have him make a version to play online, but keep the playing restricted to only members of bgdf! Well, maybe that's not such a good idea. The game looks very clean, I am very impressed with the web design, board design, and the concept. Congrats!

Have you approached any publisher with this idea? I am very curious to know how they've responded. Thank you for posting this!

...For a perfect information game with no element of chance, such as this one, programming a primitive one isn't too difficult, however.

What you want to do is store the as a game tree, pick a tree walking algorithm (While others exist which are better [as in faster], Minimax is extremely simple, and Alpha-Beta Pruning is an improvement on the algorithm that cuts the amount of branches. If you want a really, really stupid but fast AI, of course, you can just go with a Greedy algorithm, and simply select the immediate best move without bothering thinking about how the opponent will respond.) You then give it a limited amount of time to find a move. The trouble with applying game-tree walking to boardgames is coming up with a good way of evaluating positions. (Ideally you'd want a function that takes various factors, and assigns 1 to 'Player one wins' and -1 to 'Player two wins')

The complexity in this case will come from the variable set-up, of course, but that should be handleable.

...I may have implementations of minimax, alpha-beta pruning, and greedy lieing around somewhere. If so, they're in Java, and it was randomly generated game trees that they were walking rather than those that apply to an actual game, but they aren't too difficult to implement, and searching for them should find you plenty of places with pseudo-code for the algorithms, as I recall, so I don't expect that he'll need my implementations if he knows what he's looking for. [Data structures for storing game trees, on the other hand, is limited, as I recall, but it's just a tree data structure which values each node based on the game position... It's also possible to dynamically construct a game tree as you play the game... Which saves storage space but increases processing time] (There was also a test tree that I constructed)

As for the publisher perspective provided by Coco, this would surprise me, since based on every board game experience I've had online, playing via the internet is a poor-man's imitation of the real thing, which is only suitable for those who want to play against those in far off places. Even in games/groups/pairs who do not do table talk, the experience pales. I think it's as much the lack of physicality as the limited out-of-game social interaction.

Even there, I prefer to play in real life than on computer. [Heck, I think I prefer to play chess in a PBeM/PBP format with a physical board than purely via computer]

Though, of course, this might be just me.

I can't say I'm too familiar with the features of Action Script, but... I don't see why it wouldn't be able to, though you might need to do some poking depending on what's easy to do in it and what isn't, seeing as I'd expect it to be Turing Complete.

Algorithms should be workable in any language which is sufficiently complex. A quite good site for seeing what I'm talking about with the two gametree algorithms I mentioned would probably be http://www.cs.mcgill.ca/~cs251/OldCourses/1997/topic11/ which contains psudocode for the algorithms and as such should be useable for any language, while http://www.ocf.berkeley.edu/~yosenl/extras/alphabeta/alphabeta.html (which also has psudocode) has a far better demonstration applet, I think.

You're game looks awesome, and seems as though it could become something as widespread as chess, if implemented well. Once it gets out there I'll be sure to pick up a copy.

If you put it online, a good way I've found is to simply make a tutorial that is very limited in it's human interaction.

That way it plays out the same (basic) way every time. The player gets some options, but isn't really playing. Like the DreamBlade Demo: http://www.wizards.com/dreamblade/demo/demo.asp .

This one forces the computer to go first by pretending to randomize inititive. With the computer going first, it allows you to how how to start. The player is led through several situations, where upon the game 'jumps' forward to further n the game, to right near the end.

This way the player gets the jist of the game, has tried every thing, but is simpler to make (as it's really just a video with mild interaction). It also forces the player to buy the game to get anything more than a vague idea of what it's like.

Just my 2c CAN.

Good Luck.

Only if you stretch the words "thieves" and "steal" to mean things that they clearly don't mean.