Two Excel programs playing (passing moves back in forth) against each other

[Ed_Collins]

Greetings,

If I were two write a chess or checkers program (for example) in Excel, using VBA, (these are known as "engines") and if a friend of mine were to do the same, would it be possible for our two programs to play against each other, i.e. pass moves back and forth to one another? If so, where could I read up on the commands to implement that?

Somehow each program would have to open up a pipe or something, and "talk" to each other and I know this is possible in other languages, but I've never seen this done in Excel before.

[Kyle123]

I suspect the easiest architecture would be to send the moves to an intermediary (like a web server) and then the workbooks poll the server on a regular basis

[Ed_Collins]

Thanks for responding. I appreciate it.

Yea, and it wouldn't even have to be on a web server... it could be a text file on the hard drive, for example, since both programs would be on the same computer.

However, that solution isn't acceptable to me, although maybe with Excel it is the only one available.

There are hundreds and hundreds (if not thousands) of different chess programs (engines) that are available

http://www.computerchess.org.uk/ccrl/4040/

to download, many for free, that can play a game against each other via a user interface, known as chess GUIs.

The GUI acts as an intermediary, and passes the moves back and forth between the two different engines. The user watches all of this on the screen, since the GUI graphically displays the chessboard and pieces, displays each engine's output and best line, etc.

I would have though Excel had the capabilities of doing the same thing... opening a pipe and communicating with another program that way... but maybe I'm wrong.

[Kyle123]

Then create two instances of the same engine in the same workbook, that removes the complexity altogether I would have thought

Or am I misunderstanding something here?

[Ed_Collins]

Are you missing something? No, not really. Well, maybe.

I was just wondering if Excel could communicate with another (chess) engine and/or a chess interface, like all of the other chess engines do.

Polling a server or regular checking the contents of a text file or having two Excel programs in one workbook is not the same thing at all.

To clarify, as it is now I can fire up my favorite chess graphical user interface... my chess GUI (which, if you're curious, is often a program called WinBoard or a program called Scid vs PC. Many others use a program called Arena or Tarrasch) and load a couple of my favorite chess engines (again, there are HUNDREDS available. Chess programming is a big hobby, all over the world) and have the two engines play a game or two against each other.

Using the GUI I can watch the game on my screen as they are playing it.

Both engines are each separately communicating with the GUI. It's the GUI that displays the chess clocks, the amount of time each engine has left, the chessboard and chess pieces, a list of the moves already made, often an analysis window, etc., etc.

Note that the engine programs themselves can't do anything BUT play chess. None of these program have any graphics or menus or mouse support or anything at all. All they are capable of doing is accepting a chess position fed into them and look for the best move and when found, spit it back out, in chess notation. (And of these engines all follow the same protocol, that the GUI knows and understands.)

I was wondering if an Excel code could be written that would also play chess and then communicate (via STDIN and STDOUT pipes, I think it's referred to) with these GUIs.

The Excel program would be given a specific chess position and compute what it thinks is the best move from that position and then "send it" to the GUI it is talking to, and then sit there and wait for a response back from the GUI.

The GUI accepted the move from Excel, displayed the move on the chess board for the user to see, and then passed this move on to the other chess engine, the one Excel is playing against. When this other engine received the move, which it was waiting for, it then began calculating its best response, in the time allotted. Once done, it then would send it back to the GUI, who would receive it, display it on the graphical board for the user, and then pass it back to Excel. And so on. And so on.

[Ed_Collins]

Ah, I just found this page, which I must have missed earlier.

http://support.microsoft.com/kb/173085

I need to study this a bit more. This seems to be what I might be after.

[Kyle123]

Yes, I was going to point you to that actually

Out of interest why Excel? I suspect that this would be easier in other languages - it certainly is in .Net and I suspect you'd find more examples in lower level languages, like c or c++

[Ed_Collins]

Why Excel?

Two reasons... one, I was just curious if it could be done in Excel. A co-worker and I were discussing Excel and VBA the other day and he doesn't think Excel and Visual Basic are a "real language" - he has nothing good to say about it and he doesn't think it is worth much at all. (And yet I can code programs and utilities and tiny scripts in VB that get the job done three or four times faster than if he were to attempt to do the same thing in C or C++.)

And two, which is somewhat related to the first reason, is that I myself am not NEARLY as proficient or productive with C or C++ as I am with VB. The darn syntax of C just slows me down, for whatever reason.

[Kyle123]

I must admit I'm more inclined to side with him on the whole - as far as performance is concerned anyway, there's just no competition between vba and c/c++, even c# is around 3 times as fast as vba. Interacting with the excel object model is also very slow - dealing with worksheet calls anyway.

If you don't like c syntax, why not take a look at vb.net, it compiles to the same language as c# and you get all the benefits of a modern programming language and environment rather than making life difficult for yourself in a dumbed down version of vb6.

Whilst the above may seem unduly negative, it isn't the intention, I like the vba world (evidently since I spend so much time on here ), but I wouldn't ever choose for any serious programming I just find it a bit limiting - it is afterall based in a language thats kind of been dead for years