When I mentioned I was going to spend some time working on UI first to my wife she was sceptical. As she pointed out, on my previous attempt back when 512K was a lot of memory (no, really), I'd gotten bogged down in UI work and lost sight of the the bigger picture, forever polishing the surface. Well, she was right of course, and a compromise was needed.
A little bit of rationalisation and reflection supported the case for some UI beyond the very most basic I could get away with. Since I professionally program mostly at a systems level, with very little UI surface, this was an ideal opportunity to broaden my skills and learn how to do UIs (yeh, right - I did mention some rationalisation was involved didn't I?). Also it was clear that some visualisation capabilities would aid in later debugging, and that eventually I'd want something that looked pretty!
Based on this I decided the best approach was to design some fairly robust abstract interfaces for display and interaction with Go-board-like objects, but for now to instantiate them relatively crudely. That way the game engine could develop assuming a fairly capable front end, but the actually implemenation wouldn't cost too much effort up front.
In the end it took me a few hours to knock up a functional-enough UI that just represented the board 2-dimensionally in a reasonably tidy grid, with circular stones, and which fed clicks back to the engine to interpret. For debugging and editing purposes I embelished it slightly to also support highlighting of points and area selection. Here's an example display (ignore the toolbar - that was actually a later addition which I'll no doubt be posting about later):
The same UI could readily be re-used to both display games (and process user interaction with them), and to form the basis of a shape editor. Of course, I secretly planned a more prettified implementation later based on a photo of my physical Go-ban (I have pretty decent 2" thick, 4 pedestral-suppoprted, wooden Go-ban that is reasonably authentic to the Japaneese roots), presented in 3-d, with sampled stone click sounds etc., but I guess that'll be the subject of a future blog. For now here's a picture for reference:
I'm a young and, I'll admit it, amateur computer programmer. I'm also a very amateur Go player, but I'm interested in studying your process in developing a Go playing program.
ReplyDeleteYou seem to be starting from scratch here, which may not be a bad thing at all, but are you planning on using one of the standard Go protocols for interacting with other computers? I would suggest using Go Text Protocol, the Kiseido Go Server uses this protocol.
I'm on a hiatus on this project currently, but when I get back to it, yes, that would certainly make sense
ReplyDelete