Progress update:
chess_engine.hyb is an initial draft of a Hybrix chess interface that allows different algorithms (e.g. micro-Max) to be used interchangeably by a chess front end such as my graphical game, a simple text console, or (later) a simple harness for community tournaments. Although it's a bit bureaucratic, I think this formalism is worthwhile because it enables tutorials to separately focus on the front end (sprites, mouse actions, etc) versus the algorithm. Also, if someone does the work to implement an alternative algorithm, their work can potentially be leveraged by multiple front ends.
As a software person I tend to sketch a full integrated design, then disable/delete the parts that aren't needed today. So, I've split the contract into four orthogonal features that are each optional:
-
load_position(): ability to support loading/saving of board states
-
undo_move(): ability to undo one or more moves
-
collect_moves(): ability for a GUI to highlight possible next moves
-
find_move(): ability to search for a move for computer play
I'm now working on two subclasses of the
chess_engine base class:
-
rules_chess_engine: a human-vs-human reference implementation that supports everything except find_move()
-
micromax_chess_engine: the micro-Max port. We only need find_move() to reproduce micro-Max's text UI; however, for other front ends it seems relatively cheap to add collect_moves() and/or undo_move(). load_position() may not be worthwhile.
Let me know what you think of this approach. Is anything unconventional? Can you think of any popular algorithms that wouldn't fit this contract? (Keeping in mind the constraints of a 32-bit retro computer with 256KB, no OS, and a focus on teaching coding rather than professional app development.)