- Created Saturday, December 17th 2016 @ 18:54:07
Any new progress for you guys? What's everyone up to? I've been lazy lately; haven't been working on my bot haha.
- Created Sunday, December 18th 2016 @ 05:16:25
I've been busy with other things. I'd like to get time to put some real work into my Go bot, but the truth is that Go programming is difficult and daunting.
Congrats to everyone who has written some real AI for this game though!
- Created Sunday, December 18th 2016 @ 23:55:33
I slowly make the first real version of my program. My initial goal is to defeat GnuGo on level 1 with the given time constraints. So far I wrote a lot of code but it sill loses miserably to GnuGo.
- Updated Wednesday, December 28th 2016 @ 18:00:19
@smiley - Yeah agreed, Go is a really hard game! I don't even know how to play it that well after studying it for a while. I hope we see you back around making updates to your bot :)
@Yngvi - Nice, that would be an impressive feat to beat GnuGo. Beating any Go AI out there would be a feat. It's cool you've got it set up where you can play against GnuGo. Was it difficult to set up the infrastructure to run AIs against each other?
I started coding again for the holidays haha. I realized I gotta refactor my code because it's a mess so spending a lot of time doing that. My eventual hope is to add some deeper search for my bot like monte carlo tree search or some other search strategy; curious how the time limit will affect the strategy.
- Created Thursday, December 29th 2016 @ 21:35:55
Usually people in Go papers consider GnuGo a weaker program compared to the new generation of MCTS algorithms. However, I found that in these ultra-blitz settings GnuGo becomes quite competitive. When there is little time for the search, heuristics become more important, and GnuGo is packed with them.
It's rather easy to set up the infrastructure. The standard interface for Go engines is the Go Text Protocol, GTP, which is similar to the interface here on theaigames.com. You only need to implement a few basic commands, and then you can use the excellent gogui software ( gogui.sourceforge.net ) to match programs against each other, play against your bot using the GUI, set up positions to see how your bot treats various situations, etc.
- Created Saturday, January 7th 2017 @ 21:22:00
I'm doing something a little like GnuGo: A pattern based move generator backed by a strong tactical engine.
What I am lacking right now is a life&death calculator and an influence module. I'm pretty happy that I can be in the top 4 despite that. The next step (after the Ultimate TTT competition is in the semifinals) is to implement an influence field so that I can check how much a move changes the territory and moyos.
- Created Monday, February 6th 2017 @ 21:48:30
So... Since I'm waiting for more matches to be played and more examples to further eradicate bugs from my bot, I'll take some time to explain, how my bot works.
I am go player myself, and after watching several games even of highly rated bots it looked like bots lack most basic "instincts" known to human go players. So I decided to build bot, which has those main instincts. First implementation of my bot had four parts: 1) saving/capturing stones in atari or ladder, 2) basic instincts as 3x3 patterns (yea, so small), 3) random move generation without filling own eyes and 4) simple opening moves. I had/have three types of 3x3 patterns: centered on empty space, centered on player stone and centered on opponent stone with valuest not only for empty, player and opponent, but also border, empty or opponent, empty or player and similar. Each pattern has value, so when several are matched, pattern with biggest value is chosen.
Second version of bot added border patterns to play, those are 5x5 and one line means always a border line of board. Another addition was capturing of stones in net (two liberties, which can't be captured by ladder or three liberties). Oh boy, I was naive, when I coded simple net capture and was thinking, that I'm done! There are so many different cases of capturing strings of stones with three liberties, that I'm still fixing bugs in that module even after several mounths work. Third main future was placement of stones, when there is nothing to capture and no patterns are matched (random isn't very good you know). I created a somewhat bizzare function, which would be updated, when new stone is placed and had local maximas, where there would be certain shapes of stones (player or opponent). Funny thing is that I can't remember, why I chosen it or how should it work.:) This version of bot got to 4-6 position, lost badly agains top 3 bots and sometimes agains "snakes bots".
Current version (at time of writing) is third. Lets summarize, what it is and what it is not. So first what it does: 1) Opening moves, 2) Most simple invasions, 3) Capturing of groups with one, two or three liberties, 4) Builds simple influence function and tries to play on border of influences, 5) Makes bases and takes bases/extenions (partially turned of at time of writing for maintinance:)), 6) Matches 3x3 patterns with various additional triggers (isCut, protectsCut, minLibs, overrideTigerMouth, ignoreBad shape, etc.), 7) Defends most obviuos cuts, 8) Has some special programmed patterns, which are to hard to implement in 3x3 format, 9) Makes very rudimentry killing moves (when there is nothing else to play, it can take opponents eye, or create own, where eye could be falsified). 10) It values cutting stones more than others and calculates values of captures (or ignoring capture) based on this. 11) Plays random moves and capturing stones strings even, when those can't run at the end(cleaning up the game). What it does not; 1) Joseki (standard sequences). Several critical moves are programmed as special patterns, everything else is handled by 3x3 patterns or 5x5 border patterns. 2) Unstable groups with 4 liberties are threatened as alive. 3) It doesn't actively try to kill group or live with own group (sadly). 4) It doesn't know what territory or moyo is and how to count a game.(!) 5) It doesn't evaluate position, just follows rules. 6) No double threat moves apart from direct double atari. If series of ataris can be made leading to capture of one or other string, it will not "see" this situation.
My plan is to spend several weeks to fix some bugs, which eventually will show themselves, then start to work on version 4. Hope, I can implement at least approximate evaluation function for non-terminal positions to have some equivalent of reading in game of go.
Hope, this wall of text will be interesting to someone and maybe will inspire some new ideas. See you in competition!
Here are some links, which served as a base for my bot: http://senseis.xmp.net/?RankingTheBigOpeningMoves http://senseis.xmp.net/?BasicInstinct http://senseis.xmp.net/?GoProverbs (mostly tactics proverbs) http://senseis.xmp.net/?CuttingStone
- Created Monday, February 13th 2017 @ 02:29:31
@tsukrus Cool to hear what you've been working on! I think your approach is interesting; it's interesting how you are implementing high-level strategies in Go. Good luck with the bug-finding; that's often a painful part. For this competition I wrote a lot of tests for my bot haha. I have around 80 or so unit tests. It has helped me a lot in situations where I've rewritten code or changed things.
At the moment I'm working on rewriting my board data structure for Go. It is just way too slow. I really want to try to make MCTS work. I've been finding that 250ms per turn is really short! For my bot, a single pass over the board to find the best move takes 50ms. And when I do playouts it takes quite some time.