Gromit

Home * Engines * GromitChess

Gromit, Wallace, and creator Nick Park ¹

Creator Nick Park with his characters in 2005 promoting Wallace & Gromit: The Curse of the Were-Rabbit, Photo by Sam Felder, September 19, 2005, originally posted on Flickr, Wikimedia Commons, CC BY-SA 2.0 ↩︎

GromitChess, (Gromit, Gromit Chess)
a chess engine by Frank Schneider and Kai Skibbe. Gromit, later renamed to GromitChess, was initially written by Frank. In 1999 former tester Kai Skibbe joined the development ¹. Gromit and GromitChess played several IPCCCs, the WMCCC 1995, WCCC 1999 in Paderborn and the WMCCC 2001 in Maastricht, where it won the title of the Amateur World Microcomputer Chess Champion. Early versions (1.2) were standalone engines with an own GUI, later versions (> 2.0) were WinBoard/XBoard compatible, a dedicated version (3.1) was sold along with other Young Talents by ChessBase, running under their Database or Fritz GUI ². GromitChess (3.10.3) emphasized its ambitions going commercial while incorporated into the PocketGrandmaster for Pocket PC ³ ⁴, and became predecessor of Anaconda.

Contents

Description

given in 1999 from the ICGA tournament site ⁵:

GromitChess is a C++-program, developed in a Linux-environment (Emacs, gcc). It searches about 25000 to 50000 nodes per second on a K6/200 and tries to be intelligent rather than fast. Attacktables are the primary datastructure (16 bit for every square and player; bit n is set if piece n attacks the square). The search uses iterative deepening, PVS, transposition tables, killer- and history heuristic, nullmove (R=2), about 10 chess-specific extensions and some pruning heuristics. The quiescence uses a static exchange evaluator and includes some checks and other threatening moves. Parts of the evaluation are initialized at the root but most of the work is done at the leafnodes. You can find more information and executables in the WWW.

Copy Make

Frank Schneider on Gromit's Copy-Make approach ⁶:

I think it depends on your program and the board representation. Gromit uses copy+update and >1KB is copied every move (which is maybe too much). When I decided to do it that way (on an Amiga) I only considered clock cycles, but on a PC the low memory-bandwidth is the real problem. Since Gromit's evaluation and search heuristics use most of the processor time I never tried update+take back, because I guess it would give me less than 10% speedup, probably being slower than copy+update.

There are some advantages of copy+update:
- it is easy to program
- it is easier to do some 'clever' things that would be difficult to take back
- you can compare the current position with previous positions in the search tree
An alternative would use a mix of copied and static data structures.