Wee, I can redo a move! Shiny new features entered the world of Kigo (formerly known as KGo) in the last two weeks. Let’s have a start with the full undo/redo implementation. This does not sound very noteworthy off course, but (at least the redo part) turned out to be more of an issue than I originally expected. The scapegoat is once again the wonderful GTP protocol, it features a nice undo command which makes undoing moves a breeze. Unfortunatly the original implementors forgot to add a redo command, in fact the GTP-compatible Go engines don’t know this concept. Ergo one has to track all the different moves (moves, passes, resigns, generated actions, …) externally and re-apply them if the user decides to jump through the command/action/move history. But Qt came to the rescue, the Qt undo framework is a breeze to use and saved the day here. Long story short, here is a little screenie showing the obvious:
Doesn’t that look a bit like dock widgets? Yeah, I decided to replace my first design of using different screens to show game state with a more modular approach. Screen-based meant something like having a SetupScreen responsible for setting a new/loaded game up and a GameScreen for handling board display/interaction/… (and ErrorScreen, you get it). Altough this worked quite well it raised some issues here and there. It first of all results into a static user interface which is non-customizable. Second thing is a lack of seperation of concerns in the codebase (in contrast to what was originally intended by using that screen concept). Namely which class/screen is the owner of the Go engine backend class and the running Go engine? Also some doubled code for house-keeping … Moving away from this approach to using QDockWidgets took around 3 hours (a nice example how Qt enables rapid application development). Actually I had to throw away only little portions of code because all visual stuff was created with Designer, so bits and pieces of those UI files just had to be copied into smaller distinct pieces. So the new approach is laid out like this:
- Kigo::MainWindow class which is _the_ GUI class with it children
- Kigo::GameView class (QGraphicsView subclass) as a widget to interact with the user
- Kigo::GameScene class (QGraphicsScene) only depends on a GoEngine and is responsible for giving it a (themed) visual representation
- Kigo::GoEngine class, the GTP abstraction and responsible for game interaction, etc.
All those little dock widgets are then shown or hidden based on game state and allow for great extensibility in the future (The game editor feature for example). Enough bla bla, here is another screenie:
Seems like I forgot to mention the most important fact, playing against a Go engine is possible now. Strange as it sounds but I finally got this right and enabled it in the GUI part. So you finally can play Go with a Go game, how awesome is this?
Having this sorted out there are still some things marked as TODO. Being able to let multiple go engines fight each other is still in the pipeline, I already had a solution here but I want to have it implemented in a clear way, so you won’t see this feature in current trunk. Multiplay via GGZ or the more traditional go servers will definitly happen after a first release. And yes, there will definitly be a release in time for KDE-4.2, probably in extragear.
Therefore I plan to get in touch with the kdegames guys a bit more to get things sorted out (sorry guys, internet connection in my current location remains mostly a wish, but I promise to do better).
Next thing to concentrate on is to get this backend configuration right, as well as fixing some usability glitches. And a better icon would be cool, the one I stole from KReversi (and which seem to be not used any more) is nice but a bit too green, I would be glad if someone could turn this into a more wooden (resembling a go board) appearance.
Expect these changes to be pushed into SVN in the following days…