gnushogi-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gnushogi-devel] merging gnushogi and gnuminishogi


From: H.G. Muller
Subject: [Gnushogi-devel] merging gnushogi and gnuminishogi
Date: Thu, 06 Mar 2014 12:32:22 +0100
User-agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0

In case it would ever be desirable to play regular and mini-Shogi in the same engine,
the following ideas might become useful:

* There is no real need to delete the piece types Knight and Lance. In mini-Shogi they would simply not be present.

* The overhead in testing whether a piece is a Lance or Knight, which would be done in vain in mini-Shogi, is quite negligible. It could in many places be made to disappear completely, (as well as speed up the code for regular Shogi) by testing for groups of piece types through a bitmask where each bit represents a type. Tests like "if((piece == pawn) || (piece == lance) || (piece == knight))" could be replaced by "if(mask[piece] & (T_PAWN | T_KNIGHT | T_LANCE))", with no penalty for including non-participating pieces in the set.

* Some (now complex) code for testing whether a certain piece type is (non)promotable in a certain location can be more efficiently and more generally done by having a board-size arrays that contains bit flags to indicate what each piece can do where (promote or non-promote). These could then be initialized depending on the board / promo-zone size.

* From what I understand of the code, it seems that mini-Shogi can be easily played in the same board[81] format as regular Shogi, by different initialization of the nunmap and inunmap arrays to indicate which square numbers are in use.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]