Dec 14, 2006

[Plan] Class Diagram

Java is an object oriented programming language, so let's get some objects (classes really). I've plotted down the basic outline of Mediocre Chess in the diagram to the left.

Here are the classes I will use:

Mediocre: This is basically where everything happens. At startup it will create an engine (from the engine class), and a board on which it will input the moves. It will keep track of the player's moves, and reply with the appropriate answer.

Engine: Contains the algorithm for searching every possible move and deciding which move is the best reply in the particular position. It will also contain an evaluation method that takes a position and decides who is ahead.

Board: Really the foundation of the program. Not only does it represent a position on the board, but it will also be able to generate possible moves that can be made.

Move: I've decided to make a separate class which represents a move. Basically where a piece is moving, what kind of move it is, and what piece is moving. The advantages of having every move as it's own object are:
  • Easy acces to the type of move for sorting in the future. Maybe we want to calculate all captures first (this is very important in quiescence search, more on that later on), or perhaps we need to find all moves where the king is moving.
  • We're able to extract the notation of the move (e.g. Ne5, e8Q etc.) without any hassle.
And the drawbacks (as pointed out to me in the comments):
  • Having an object for every move will be expensive in terms of memory and speed. Considering the engine will create millions of moves. As suggested in the comments a better approach would be keeping the Move-class as a static class with utility-methods, and store the actual moves as integers.

    Java has a garbage collecting feature which takes care of abandoned objects, and as stated there will be millions of them.

    But after some thinking I decided going for easy approach with an object for every move will be easier and produce clearer code, at the cost of some speed. The result will not be the fastest engine in the world, but fast enough.

Definitions: This is actually an interface which is used by all the above classes. It holds things like constants (if we put say KNIGHT_VALUE=300 in the Definitions interface, we only need to change one number if we want another value).

So this is the framework I'm gonna try working with. Perhaps more is needed later. Who knows. But it's a good start.

The UML Diagram was made using Gliffy, which I can highly recommend.


Anonymous said...

Storing move information in a own class is a clean approach. But you will have to somehow preallocate all moves needed during search. Elsewise your engine will do nothing more but collect garbage. (The engine usually will generate serveral millions of moves per second ... all of them need to be allocated and garbage collected). Making Move a static utility class and using a int as primary move storage is the faster alternative.

Jonatan Pettersson said...

I understand what you're saying. Indeed the number of Move-objects created will be vast.

But for now I'll go with the 'clean' approach, since a Move-object is easy to understand and makes the coding clearer.

Down the line I'll consider this though if I need the engine to run faster. (I guess you always want the engine to run faster... :)

Evan said...

I use this class diagram software to draw class diagrams called Creately which is awesome. Its not free but always free to try. It has many class diagram templates as well. Thanks for the free tute