[Kde-games-devel] AI library in the gamelibs?

[Inge Wallin]

On Monday, January 27, 2014 11:10:59 Ian Wadham wrote:
> On 27/01/2014, at 12:16 AM, Inge Wallin wrote:
> > On Saturday, January 04, 2014 20:01:49 Inge Wallin wrote:
> > > On Saturday, January 04, 2014 00:49:56 Tom Vincent Peters wrote:
> > > > Hi Inge,
> > > > 
> > > > On 01/03/2014 10:29 PM, Inge Wallin wrote:
> > > > > [...]  the question
> > > > > is if I should just use it or if I should make some preparatory work
> > > > > to
> > > > > include it in the games library.
> > > > > 
> > > > > It supports the following features, which none of the current or
> > > > > previous board games (like kenolaba), do:
> > > > > 
> > > > > - time control of the engine, not just depth of thinking
> > > > > 
> > > > > - Iteratively deepening alpha-beta search algorithm with lots of
> > > > > optimizations
> > > > > 
> > > > > - Opening book generation and use of the opening books in the game
> > > > > 
> > > > > - Support for games with many different types of rule sets like loss
> > > > > vs
> > > > > tie if no move is available, simple win/lose vs graded win/loss
> > > > > (like
> > > > > chess and reversi, respectively), etc
> > > > > [...]
> > > > 
> > > > It would be great if you could put your code in the games library.
> > > > That
> > > > way I can use it for the very hard AI level in ksquares. I'm very
> > > > interested in the time control and iteratively deepening alpha-beta
> > > > search algorithm parts because that's just what I need to write a
> > > > ksquares AI that compares to dabble [1]. It would be nice to rely on
> > > > existing code instead of creating something from scratch, especially
> > > > because I only have very limited time.
> > > 
> > > Sounds like there is a consensus to do it, only question is exactly how,
> > > then. As Albert suggested, perhaps the best way is a separate repo.
> > 
> > Ok, a short status report.  Things are progressing nicely[1] and I will
> > soon have to start to use the library in a real application so that I can
> > finalize the API.  If there is anybody who wants to have their game get
> > an AI boost, let me know here and I will start working in a branch to
> > work the new library into the AI in question.
> > 
> > There are still lots of things to do before the first release can be done.
> >  I have identified a number of tasks and milestones in the TODO file,
> > which should be pretty understandable.
> > 
> > One suggestion of a game would be KJumpingCube which Ian talked about in
> > another part of this thread. Ian, what do you say?  Interested?
> Yes, I am, but I am head-down backside-up in Palapeli ATM and have some
> other non-KDE commitments to attend to. So maybe it would be best, for you,
> to start with KReversi or KSquares.
> 
> > If not, I will probably continue by doing this to Kreversi. Remember, I
> > will naturally work in a branch so no disruption will happen to the game
> > in question.  Any other volunteers are encouraged to speak up now.
> > 
> > [1] http://quickgit.kde.org/?p=scratch%2Fingwa%2Flibkdeai.git
> 
> This looks great.
> 
> One thing I am not clear on. Maybe you can point me in the right direction.
> 
> How do I provide the move algorithm to the AI? And would it have to
> conform to the AI's data model of the board and position (for reasons
> of speed, if nothing else)? IOW, would I use Bitboard.h?

What you should do - and right now the details are not 100% clear - is to 
inherit the Move base class that I provide in the library and create a (say) 
JCMove.  Also the same with JCPosition and JCMinimove. (The minimove is used 
in the transposition table and is a packed version of Move but without any 
extra data. See the docs for the detail (some of which may not be written yet.  
:) )).

Anyway, you don't have to do anything, I will do it for you.  You just have to 
tell me you are interested to use it in KJumpingCubes which you have now.  And 
the reason why I have to do this myself at first is because I will likely 
change the library as I get some more understanding about how this would be 
used.

> I could see, when using the lash-up you did (via private email) of
> KJumpingCube and the AI's pure C library-code, that your move
> algorithm was a lot faster than the released version of KJC, thus
> allowing more trial moves and further look-ahead in the time available.

Yes, representation of a position and how a move is done has a lot of impact 
on the overall speed of the program.  Actually I think it can be speeded up 
even more by e.g. not always looping over the cubes but instead loop over the 
set bits in the bitmaps if they are fewer than a certain threshold which you 
need to find out by experimentation.

> Also, why is Bitboard a template class? Why not just supply a size
> parameter to the constructor?

Because of speed.  If you have a template class and only use one long long int 
the compiler can optimize away any loop variables.  That is not true if you 
just have to provide it to the constructor. Also, if you have the size as a 
template then you don't have to do any allocation on the heap but can just 
allocate the memory as part of the object itself.  Remember that we are 
handling things here which are touched 10s of millions of times per second 
(literally!).

> All the best, Ian W.
> 
> 
> 
> _______________________________________________
> kde-games-devel mailing list
> kde-games-devel at kde.org
> https://mail.kde.org/mailman/listinfo/kde-games-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-games-devel/attachments/20140127/dbb96cd5/attachment.html>