EGBB-PROBE

• Rename the dll to egbbdll.dll without the suffixes.
  
  
• After downloading the new egbb files from Dann's site, replace the egbb dlls with the ones available here.The v3.2 had issues with SMP.
  
  
• Mixing old and new egbb dlls. Use v3.3 for the new ones and v3.0 for the old ones.
  
  
• Some engines work only for a certain way of egbb path scripting. For example for Toga c:/egbb/ and c:\egbb\ would work but not c:/egbb and c:/egbb. Make sure that the engine displays "EgbbProbe v3.x" message.

This project is an attempt to equip Nebiyu with a java interface that can be used on any device (originally intended for mobiles). A unique feature of JavaBoard is that it is a multi-player GUI. Two or more players can play one game turn by turn. It uses winboard protocol for communication. UCI engines can also be used using an adapter. It has also a console interface that can be used for fast game playing. The jar javaboard.jar contains GuiTester and ConsoleTester application classes.

Engines
There are basically four types of players:

1. An engine - Set command line and working directory.
   
   • Command line : command to be executed when starting process.
     This can be tweaked to use  adapters like polyglot, remote engines, java engines etc
   • Working directory for the engine to find its initialization & log files etc.
2. A human player - Yes humans could be installed too:)
   
   • Command line : name of human being
   • Working directory should be set to human 
3. An ICS player - To play on internet chess servers fics, ics etc with style 12 support.
   JavaBoard acts like a client and will not try to handle tournaments by itself.
   
   • Command line : address port [username] [password]
   • Working director is ics
4. A TCP server/client - JavaBoard can act a server and a client. To begin service "Engines->Accept connections @ port"
   Connections can be made from another computer using JavaBoard or any telnet client if you wish. To use JavaBoard client install
   a TCP engine with:
   
   • Command line : address port [username] [password]
   • Working directory : tcps
   The TCP server supports chats between connected observers. Many ICS style commands are added to the server now. For more
   information type "help commands". You can observe multiple games from game servers and later switch by the game ID.

You can play in chess servers either by loading an engine , or as a human OR as a combination of engines and humans. Isn't that cool ? This is possible even with old Winboard engines since it places the engine in force mode. Hence more than two colors (other than white/black) is possible.

You can install engines and play games on this website without downloading! Another cool feature!

Referee engine
The referee engine is used to check legality of moves and display the board. You can say it is part of the GUI as it is used for that purpose only.
For any engine to be a referee engine , it should send the "setup" command after each move. It should do so even when getting an Illegal move.
So the engine should do either one of the following when receiving any move:
    a) setup newFEN
    b) Illegal move : move
        setup oldFEN
JavaBoard waits for response from the referee to know if a move is Illegal and update the board accordingly . You can create any board game and create a simple engine (basically a move generator) and take advantage of all features of JavaBoard. Client application need not load a referee engine since the server will send them the board positions. Also since any telnet client like putty can be used, it is unwise to put a restriction of loading a referee engine on the client side.

The referee engine is written only once for a new variant!! Nebiyu can be used as a referee for many variants so there is almost no need for other referee engines. All existing winboard and uci engines can be played against Nebiyu and also against each other. At first I thought Nebiyu has to be one of the participants since it is the board updater. But with this concept of referee engine any existing engines can be played against each other ! Nebiyu sits as the referee and updates the board on their behalf, checks legality of moves, so it pretty much acts as the GUI. So in short writing a referee engine is only required for a completely new game that Nebiyu don't support (which is very hard to find :) ). Also Nebiyu has highlighting capablities but JavaBoard do not support that yet. I will try to rewrite Nebiyu in Java to avoid loading a refree engine most of the time but that is really not necessary and also not ellegant. Because the point of JavaBoard is that the game rules are to be taken care of by an external referee engine so loading is the true solution..

• Number of games in match - Total number of games in a match
• Permutation - If there are three players , 3! = 6 games are played by the same participants
• Time control - Winboard "level 40 5 0" type
• Pondering - Untested

Cons
Winboard engines which do not send moves in plain coordinate notation (e2e4) do not work. I will not add SAN support because the GUI do not try to interpret moves. You can send "87$@#$" as long as the engines understand what it means. So if both engines understand SAN it works!! One can write a referee engine which converts one move format to the other but it is simpler to assume that two engines can play each other when they use the same move format.

Changes :

• FICS seek table added. I don't see much use for the popular "seek graph".  The table seems to work as good. You can sort based on any
  property, say rating of seeker, and then double click on your opponent to play... Simple!

• A lot of verbose output in ICS mode is off now so only chats and other important staff is displayed. The debug window can be used as a chat
  box too. I am reluctant to add chat boxes for different users, tells, shouts etc...

• Variants with holdings such as crazy house can be viewed now. Holdings are displayed at the bottom row. Just click on the piece and drop it to make a move.
  

• Multiple games can be viewed at the same time with separate windows. If you have enough space you can watch a thousand games since boards are created dynamically. The layout is 2 columns by N rows. You can select any of the boards for further investigation such as move history and plotting  graphs.
  

• You can play at most one game , while observing many at the same time. To play a bug-house open one window for your game and watch your partner's game on a separate board placed by the side.
  

• The size of the applet is significantly reduced. I was jarring Thumbs.db of Windows XP thumbnail database which was accounting for most of the size. Silly me! Now it is only 180kb compared to previous 530kb. I knew I didn't write that much stuff for all that size!

• Drag and drop of pieces is added now. Many people prefer that over click-click mode in blitz games, although personally I don't find it as a significant improvement. Anyway you can use both modes at the same time.

• Flicker free drawing. Tabbed pane browsing of  games in observation list. Separate chat (whisper/kibitz) boxes for each game.

• Applet size reduced further by 40 kb. Also loading time of applet reduced from 1 minute to 2-3 seconds !! That was achieved by merging
  the image files into one file.
  

• Automatic highlighting of moves. This is done by comparing consecutive FENs since JavaBoard has no idea of moves.

• It is now possible to accept take back offers. It doesn't actually process take back offers directly. When a position with a lesser move number than the previous position is received, it assumes a take back was done. Less headache and more robust.

• Ics shortcut command buttons similar to Thief's. Less typing!

• Now every tell from users and channels have a separate chat panel.
  

Additional Notes:

I was informed about this contest about a week after it was officially announced. Then I decided to give it a try and picked up the java starter package. It turned out to be a lot of fun and challenging at the same time. There were a total of ~7300 participants! I got 165th place in the finals. I was more or less satisfied with the result but it could have been better given my performance in the beta stages and tcp servers. You can find my code here. It was quite  a different experience from the kind of problem solving I was used to. I could not use min-max or any of the multi-player algorithms I learned recently mainly due to  large state-space complexity (5^N where N is number of ants) and imperfect information (fog of war, simultaneous moves etc..). The game involves two major goals: a) Exploration - exploring the map and maximizing visibility for foraging. Due to the fog of war each ant can only see within a certain radius.  b) Combat - Killing enemy ants without taking losses.  Breadth first search, A* search and collaborative diffusion were the algorithms mostly used for exploration. Collaborative diffusion is a new approach that allows agents (ants) to collaborate in achieving a goal . Combat can be done using different heuristics: influence maps, a sort of monte-carlo simulation within the allotted time (500 ms), a minmax approach  or a plain & dumb approach that I used in my bot. You can find discussions about the different methods people used here.

If you want to study a new language this contest is for you. Starter packages are available in many languages and if there is none you can write one yourself. Speed is not a big issue for the contest so people write bots in php , javascript or any other awkward scripting language you can imagine. It has certainly invigorated my interest in programming languages. I will be participating in future ai challenges as much as I can.