This thing starts to be (barely) playable:


Really glad that I managed to do something, despite my health deteriorating sharply because of it. (Cough, cough, …)
However the whole project is far more complex than I have thought. Only after starting coding for a while that I found existing protocol definition between chess engines and boards, namely “cxboard” and “UCCI” protocol, akin to xboard/WinBoard and UCI protocols. What it means to me is, one single project becomes two!
There are only very few existing open source implementations of Chinese Chess (XiangQi):
| Name |
Type |
Comment |
| MRSD+ (夢入神蛋) |
engine + board |
Strong AI, dead project (since 2003), UI and engine not separable (i.e. no communication protocol) |
| ElephantEye (象眼) |
engine |
Strong AI, actively developed, supposed to be UCCI reference implementation |
| CXBoard |
board |
Feature rich, uses GTK+ 1.2 (old), doesn’t support newer cxboard protocol in spite of its name |
| JunFa |
engine |
Supposed to be the reference implementation of cxboard protocol. Guess what — one can capture all of the opponent’s 16 pieces in the first 16 moves with one single pawn. Only supports a few commands in cxboard protocol. |
| QiPan |
board |
Uses Qt 2.x (not available on most Linux now), better support of cxboard protocol, can’t test because I can’t compile it |
| tsito |
engine |
Only supports old cxboard protocol, very weak AI |
| VSCCP |
engine |
Only intended as a coding sample, very weak AI |
Until today, the route chosen is: (1) separate the engine part of MRSD+ into a command line interface, which is not so hard, thanks to Wei Tzer Jen implementing the AI as a C++ class; (2) write a GTK+2 frontend, as I have (psychological?) problem learning any OO language.
However when I found Elephany Eye to be compilable on Linux without problem, seems it’s time to switch strategy: using existing, working engine is far better than modifying one not working well. So most likely I’ll make sure it is playable with Elephant Eye first, only work on MRSD+ if there is any spare time.
Anyway, this stuff is still far from release quality — lots of variables and memory leaked globally, even more variables hard-coded, etc. Much more time is needed to clean up all of these, not to mention all of the TODOs below:
- Make preferences work
- Allows taking back moves
- Allows engine playing either side (right now hard-coded to black/blue side)
- More complete cxboard implementation
- Implement UCCI protocol support
- Compile with autotools (though I know this toolchain sucks)
- Some artwork (EEEK, I never mean doing it myself)
And the long term plans:
- Two engine mode
- Implement chess clock
- Implement proper game history navigation
- Turn the board into a full featured widget
- Implement import and export of PGN or XGF or whatever format invented in universe
- …
- ……
- …………
In the process I found Quarry to be very helpful as a reference, IMHO it is one of the best implementation of game boards, fully widgetized and controllable in great detail, not to mention its capability in handling various kinds of game board (Go, Amazons and Reversi) in a single program.
About releasing, my best guess is that it can at least compile and run properly on, say, 2-3 weeks later, since I need to go to Beijing for a job interview recently, thus unable to work on it for a few days. Please forgive me if anybody thinks my code is as ugly as food dipped in shit — I’m just an absolute beginner in programming, especially on working at larger scale program. Yes, that’s not a joke, perhaps I can read a bit of code, but have almost never been a coder myself before.
Currently there are a few areas where help is needed:
- Public source code repository. Is sourceforge a good idea? Or should I set up my own subversion/cvs?
- Somebody care to teach me on stuff about widget and signals? :-D
- Artwork (right now most of the things are shamelessly ripped off from Quarry and MRSD+)