News:

MASM32 SDK Description, downloads and other helpful links
MASM32.com New Forum Link
masmforum WebSite

chess game

Started by simona66, January 30, 2007, 11:07:52 AM

Previous topic - Next topic

simona66

hello
Is there anyone to help me inorder to write chess game in assembly?
I drew the pieces and the board but I can't move the pieces. I donn't want to designe the professional one just i want to move the pieces.
I f you have any odea or the code fo it please share it.
thanks

Mark_Larson

  I once wrote an Othello program that could out play me.  You want to do searches on what are called Min-Max algorithms.  There are several.  They are recursive.  The basic one is pretty easy to implement.  The basic one is called Alpha-Beta.  The variant I wrote was called NegaScout.  It's faster than a standard one.  The recursion stops after a fixed depth.  Depending on how fast your algorithm is you can use a greater and greater depth.  At the lowest point, it calls an Evaulate() function which gives a numeric value based on the current state of the board.  It returns that values to it's calling function.  It's recursive so it calls itself.  Having a properly written Evalaute() function is extremelly important.  You can initially set the max recursion level to something like 8, and then tweak the program, and then after you have it running correctly you can try setting it for a higher number.

  I'd recommend downloading a Evaulate() function from the net, so you can see how one works.  They can be quite complex.  There are two theories on how to properly use them.  One is a big long Evaulate function with a short recursion depth.  Second is a short/fast Evaulate function with a high recursion depth.  Try both and see which works best for your algorithm.


  The recursion lets you see several moves ahead, so you can check 2 or 3 moves ahead to see if you get captured, and if so return a low value for the evaulate function. 

  I wrote mine in C, so I'd recommend trying stuff out in C, or some other language, until you get the hang of how all this stuff works.

Optimizations:

  Also most people use bitmaps for comparisons of possible moves, which is faster since you use logical compares.  So just making stuff up, you could have a bitmap of all the possible moves of a Knight.  The bitmap is one bit for each board position, so 64-bits = 8 bytes.  You can AND that with a bitmap of all the positions of the other team that can capture it.  If you get a zero, then there are no moves you can make that result in your piece not getting captured.  Make sense? 

  Hashing is important as well.  You can hash already checked moves of a certain depth.  Recursion is extremelly expensive time wise.  So not having to recurse a certain position helps a lot.  I used zobrist hashing.  It doesn't use a MOD a prime like most hashes, and so is faster in figuring out a key.  Also it has a low collision rating.  the hash size is a power of 2.  I generally make it big enough so I get 0 collisions.  The way I test that is I run it, and exit with an error message if I get a collision.  No collisions means it runs really fast, because collisions are what slow a hash down.  Once I have it tested with no collisions occuring, I remove the code that checks for a collision and exits.  In general I look at the size of the hash table I need, and go to the next higher power of 2 from there.  If I get a lot of collisions from that, then I bump it up one more power of 2.  I've never had to bump it up twice, since it generates so few collisions.  And usually the next higher power of 2 works 9 times out of 10.

URL for a bunch of hash functions being compared, also includes the code.
http://www.burtleburtle.net/bob/hash/doobs.html



  You can do the MinMax to a depth of 4, call the evaulate function, and then sort all these moves from highest to lowest, assuming that the higher a number the better board it is for the computer.  That way you check the best possible moves first.  The algorithm will exit early if it finds a best move early.

  Their is also a depth algorithm you can try.  You repeatedly call the MinMax function with increasing depths until you find a "good" move.  That saves time, because with shorter depth you search less of the tree.  This is called "iterative deepening". 

BIOS programmers do it fastest, hehe.  ;)

My Optimization webpage
htttp://www.website.masmforum.com/mark/index.htm

TomRiddle

I always wondered what the calculations for all possible boards(where the pieces were located) were.  Multiply that by two and you could have a board for each possible scenario.  Granted it would probably take 10 years for you to write what move the program should do, but I could see that being the fastest/smartest chess game in the world, even if it did take 10gb!  :snooty:

Mark_Larson


  I left something off of the optimizations.  A lot of people use Books.  What they do is set their search depth to much higher than normal, and then run through some moves, and saves the results to their Book.  As the game is going along, you do a simple compare ( remember the board is 64-bits), with the entries in the book.  Several ways to handle looking them up.  Hash table ( the fastest), or you can list your 64-bit values alphabetically and do a binary search.
BIOS programmers do it fastest, hehe.  ;)

My Optimization webpage
htttp://www.website.masmforum.com/mark/index.htm

Rockoon

Quote from: TomRiddle on January 31, 2007, 01:06:32 AM
I always wondered what the calculations for all possible boards(where the pieces were located) were.  Multiply that by two and you could have a board for each possible scenario.  Granted it would probably take 10 years for you to write what move the program should do, but I could see that being the fastest/smartest chess game in the world, even if it did take 10gb!  :snooty:

There are more legal chess positions than there are particles in the universe.

The estimate is 64!/(32!*8!^2*2!^6) ~= 10^43 legal positions.

To index a table of them, the index alone would require 143 bits.

A maxed out 64-bit processor could (idealy) address 18 million billion bytes of information, which is for all intents and purposes nothing in relation to the size of full "game solved" table.

If you could generate 1 *trillion* (a million billion) chess positions per second, it would still take you
~10,000,000,000,000,000,000,000,000,000,000 seconds to generate them all. The universe is currently only
~500,000,000,000,000,000 seconds old.

Nobody is going to solve chess any time soon.
When C++ compilers can be coerced to emit rcl and rcr, I *might* consider using one.

TomRiddle

Give it time, and one big Linux Cluster :P

ecube

Ultrano wrote one, I don't know if he wants to upload the source or not, I have it somewhere allows you to play with people remotely too is I recall correctly.

u

I'm not sure if it's compilable, since it depends on "dreamer.inc" and "wind.inc" from my commercial app Dreamer1.5 (this chess program was an easter-egg in Dreamer).
Also, it uses classes (OOP), so might be hard to read some parts without knowing ATC.
The sub-files, that get concatenated during compilation to form "chess.asm" are (in order) : "startup", "classes", "network", "gui stuff" . (there's no file-extention).

I used Bulgarian words for the figures' classes:
peshka = pawn
top = rook
kon = knight
oficer = bishop
car = king
carica = queen


Still, you can find the code you need in procs, named *_canMoveTo

[attachment deleted by admin]
Please use a smaller graphic in your signature.