• Some users have recently had their accounts hijacked. It seems that the now defunct EVGA forums might have compromised your password there and seems many are using the same PW here. We would suggest you UPDATE YOUR PASSWORD and TURN ON 2FA for your account here to further secure it. None of the compromised accounts had 2FA turned on.
    Once you have enabled 2FA, your account will be updated soon to show a badge, letting other members know that you use 2FA to protect your account. This should be beneficial for everyone that uses FSFT.

[H] Connect Four Programming Competition.

K

KingKaeru

Supreme [H]ardness
Joined
Jul 16, 2000
Messages
6,465
In [MS]'s Vs2003 Whatsisname mentioned writing Connect Four AI.

This gave me the idea of maybe a friendly Connect Four Tournament within the [H] W&P Community. Anyone interested? If so, we could decide on the protocol and get this thing running :)

--KK
 
the fact that there is a publicly available algorithms written by profs for connect 4 kind of makes me leery of such a competition...
 
That's what real programming consists of anyway, so I'm told... stealing code.
 
In a "match" type setting it might give people more incentive than to just dig through google for algorithms since "players" will be matched against each other. Besides, what's the fun in using someone else's code when you can write your own?

Anyways, if there's enough interest then I'll try to set something up. Tournament would be client server based so you can use any language you want for the most part.

--KK
 
Whatsisname said:
the game can always be changed.
Click to expand...

It sure can :)

Anyways, if connect four of n size isnt [H] enough, please provide suggestions. Either way, I think this could be a fun.

--KK
 
I am in for this. I think we should all use PASCAL with ASCII output. :p :)
 
It's "Pascal" - not every computer term needs to be CAPITALIZED.

But, yes, ASCII communication from stdin/stdout is probably the best way to do it - have the software running the tourney start up the two programs & handle communication between the two (as well as some sanity checking/cheat prevention).
 
maybe poker or something, yeah cards have been analyzed to death too....but with betting and such, you could program the ability to bluff, to raise,call bluffs, fold, etc. that would require some AI and some thought....
 
Steel Chicken said:
maybe poker or something, yeah cards have been analyzed to death too....but with betting and such, you could program the ability to bluff, to raise,call bluffs, fold, etc. that would require some AI and some thought....
Click to expand...
But that's a TON more effort than just writing a simple connect four AI. Only suggestions I have, are #1 don't release the source code for the server(cuts down on the easy cheats anyway), and #2 release binary(s) of the server for people to test against.
 
ameoba said:
It's "Pascal" - not every computer term needs to be CAPITALIZED.

But, yes, ASCII communication from stdin/stdout is probably the best way to do it - have the software running the tourney start up the two programs & handle communication between the two (as well as some sanity checking/cheat prevention).
Click to expand...
Wow. Picky, picky. I'll just take my happy fun ball and go home now.
 
Cool!

Here are the set rules so far. Feel free to comment.

Communications will be via HTTP port 80 (so PHP/JSP/ASP guys can join easily) and/or another port for non HTTP
Server source will be published for all to see and debug.
Server keeps track of game time and game state.
Player sources will be kept private until the end of the tournament.

Here are some other guidelines that we should decide on.

Max time per turn.
Max game time?
Number of games per match
Number of resubmissions?
Tournament timetable?
Prizes? (I'll try to get ahold of something)

--KK
 
I don't like that http port issue. What i would prefer is everyone sends their source to the tournament oeprater who builds the source and runs it. Each person would essentially write a function that would be passed either the board, or the last move, then it would return it's move. Then the operator will run the server, and return the results. Using a network scheme, someone could go as far as to simply read the results from the operator/server and choose himself.
 
KingKaeru said:
Cool!

Here are the set rules so far. Feel free to comment.

Communications will be via HTTP port 80 (so PHP/JSP/ASP guys can join easily) and/or another port for non HTTP
Server source will be published for all to see and debug.
Server keeps track of game time and game state.
Player sources will be kept private until the end of the tournament.
--KK
Click to expand...

Similar to what I'd envisioned

I’d been thinking of making a site where you could upload code, it’d be built, and you could choose to run it against other entries submitted by others. If you thought you had a good version, you could hit a publish button, and then yours would be added to the pool that others could run against.

I know how it could be done securely, but just never had the time to implement it. 
Alternatively, exposing a web service would also work, but that’s inherently limiting since it requires multiple players to poll a single source as their only method of interaction. And there’d likely be issues with clients dropping out of games.
 
This sounds like a cool idea. I'd be willing to compete, but I think trying to do an internet client/server scheme, would add too much complexity. The idea about uploading code, and running it from a central server, by a non-biased judge is very cool. That means less people would spend their time trying to cheat the client/server system. Maybe make a framework with a publically documented API, so we could write just our AI algorythms(sp?), and then have the server program load each module, and run them againsrt each other. You could have the upload up for a couple months, and then at the end run all the submitted modules against each other and post the results. Quick and easy. Of course that requires more work on the server end, but we could all pitch in on that. Have code reviews of the server code each week, even open a sourceforge project for it. Who knows, we could put CodeWars on the map and get syndicated!

Anyways, I always like practial excerises better than just reading something out of a book. Stumbling and fumbling in the dark and finally hitting that brilliant light at the end of the tunnel is cool. Lets keep this thread going, and start something.
 
Ok, it's late, so I might be slow here, but is this contest to have a tournament of competing Connect Four AI bots?

That's a really cool idea. Too bad I'm an ass-awful programmer or I might get in on that.
 
if you ask me, this should be an HTTP communication project, using straight up XML or SOAP
 
Tnadrev said:
if you ask me, this should be an HTTP communication project, using straight up XML or SOAP
Click to expand...

The transport layer really should be the insignificant portion of this project. Keep it simple, and everyone benifits. The real purpose of this is to get the best AI, not the best netcode.
 
Sgarissta said:
The transport layer really should be the insignificant portion of this project. Keep it simple, and everyone benifits. The real purpose of this is to get the best AI, not the best netcode.
Click to expand...


exactly why it should be XML/SOAP, about the easiest way i can think of
 
If we really wanted to do the whole net thing, I guess we could just put up a webserver, apache hopefully, and do session handling to match up two players' code, then just have their code talk to the server through http GETs and POSTs. That's pretty simple, but I still say handling the actual running of the code should be done on the same server, that way do need to worry about disconnects, or slow links and so on. Also, there's less of a chance that people can complain about cheating and whatnot. Just a few more cents...
 
Yes, all code submissions will be run against each other on the same server. So what should we do about the Client-Server communications? I'd like to at least have capabilities for http post/requests so that the Web guys can join in easily. For everyone else, we could let them connect via another port.

since the networking part of it would be consistent between "competitors", interfaces and classes for these can be made public to get everyone started.

--KK
 
Still think an ASCII test harness would be the way to go. Forcing HTTP request or any such network BS into the deal is silly. Anyone who considers themselves a programmer and can't write a basic console app would have a hard time justifying themselves as such in my book. It doesn't take that much to learn a language that's truly general purpose and doesn't require a webserver to run.
 
Ok, if we're going to go with the network idea, then let's stick with a GET/POST model, using sessions to match up competitors. You'll log into the browser and get a session id that's tied to a user in a DB, the server will check to see if there are any waiting users to pair you up with. Then you can begin sending your first move, based off a response from the server. The hard part, IMO, is going to be able to create the libraries so that web-driven scripting or PHP can use methods to send moves and retrive the current layout of the board. We could write it in C#, if we all plan on using Windows, but for Mac and *NIX people we would need to look at C, which I'm no where near as proficent as I would need to be to write it. If we could agree that we'd all use a windows platform to run our code, then writing a library would be easy, I could have the basics done in a few hours for connecting, sending, and recieving. Of course I'd be using an Apache webserver to test on, but the server we use shouldn't matter much, as long as it supports sessions and GET/POST requests. If of course we want to go that route. Otherwise, I'll just sit here and wait till we come up with a plan.
 
arken420 said:
Ok, if we're going to go with the network idea, then let's stick with a GET/POST model, using sessions to match up competitors. You'll log into the browser and get a session id that's tied to a user in a DB, the server will check to see if there are any waiting users to pair you up with. Then you can begin sending your first move, based off a response from the server. The hard part, IMO, is going to be able to create the libraries so that web-driven scripting or PHP can use methods to send moves and retrive the current layout of the board. We could write it in C#, if we all plan on using Windows, but for Mac and *NIX people we would need to look at C, which I'm no where near as proficent as I would need to be to write it. If we could agree that we'd all use a windows platform to run our code, then writing a library would be easy, I could have the basics done in a few hours for connecting, sending, and recieving. Of course I'd be using an Apache webserver to test on, but the server we use shouldn't matter much, as long as it supports sessions and GET/POST requests. If of course we want to go that route. Otherwise, I'll just sit here and wait till we come up with a plan.
Click to expand...

Not quite. the communication would need to be a lot more abstract than what you just described in order for us to be language/platform independant.

(note that both clients and servers would be run on the same machine):

1. Players Authenticate with server
2. Clients wait for Server command.
3. Server sends info and request
Info:
a. Opponent's move(s)
b. Game State (init/pause/resume/end)

Requests:
a. Request Move
b. Request player info
4. Client processes info and request; sends Response.

The server would have one or more sockets open listening for connections so you can either write a simple console app or webapp; it's up to you.

flowchart.gif


I'll try to put something together this weekend. If you want to "join in" on the server development buzz me on AIM: KingKaeru or PM.

--KK
 
i don't like using client server. If you want true cross platform compatibility, have each bot output its move and the tourney operator can manually feed it to the other program. That way noones at a disadvantage having to dick around with networking API's and crap. The point behind the game AI is that it's entirely conceptual and doesnt require any application API's whatsoever. That way its a test of reducing the game to a computer understandable model, not a game of who has the most time to get their networking thing working and then work on the actual AI.

KingKaeru said:
Yes, all code submissions will be run against each other on the same server. So what should we do about the Client-Server communications? I'd like to at least have capabilities for http post/requests so that the Web guys can join in easily. For everyone else, we could let them connect via another port.

since the networking part of it would be consistent between "competitors", interfaces and classes for these can be made public to get everyone started.

--KK
Click to expand...
 
Whatsisname said:
have each bot output its move and the tourney operator can manually feed it to the other program.
Click to expand...

Can you give me an example of this in a non-client-server scenario?

--KK
 
if it was restricted to say c++, each user would provide a class or a function that the "server" would execute back and forth until the game is won or there is a tie. a .dll would also work. To try and match a c++ program with a php program for instance though, the output would be viewed from either entry and fed to the 'server' or to the other entry manually, using some kind of input scheme in the server. Or each could write to a file with a standard format what its move is, and the server reads that, because reading and writing files is simple enough in almost every popular language.

KingKaeru said:
Can you give me an example of this in a non-client-server scenario?

--KK
Click to expand...
 
additionally, upon googling it seems theres lots of well made connect 4 ai's out there, so maybe it would be good to pick a different, uncommon game, like 9 mens morris or something.
 
Whatsisname said:
if it was restricted to say c++, each user would provide a class or a function that the "server" would execute back and forth until the game is won or there is a tie. a .dll would also work. To try and match a c++ program with a php program for instance though, the output would be viewed from either entry and fed to the 'server' or to the other entry manually, using some kind of input scheme in the server. Or each could write to a file with a standard format what its move is, and the server reads that, because reading and writing files is simple enough in almost every popular language.
Click to expand...

Heh. How isn't this client-server though ;)

the "using some kind of input scheme in the server" would be your interfaces. Regardless,

the communications between the client and server would have to be abstracted. I don't see the networking code to be an issue as it could be reused and shared between all players.

--KK
 
KingKaeru said:
the communications between the client and server would have to be abstracted. I don't see the networking code to be an issue as it could be reused and shared between all players.

--KK
Click to expand...

As much as I hate to say it. If this is the case, just make it a SOAP or XML/RPC service and be done with it. Every major platform has one, even the web guys. Pass a token back and forth to preserve state. Opponents moves get registered in a simple notation like +col3 or whatever so it's easy to parse.

On another point I do agree that there are probably too many good connect four algorithms out there. I'm just not sure of a game as simple as connect four that we could use.
 
This is getting entirely too complicated, seriously. If the entries were simple executables that used stdio, a simple python script could use a popen() variant and then read/write to each program's stdin/out until a winner is determined. No need for complex protocols and APIs, authentication or any of that - 2-3 commands going each way would do the job.
 
ameoba said:
This is getting entirely too complicated, seriously. If the entries were simple executables that used stdio, a simple python script could use a popen() variant and then read/write to each program's stdin/out until a winner is determined. No need for complex protocols and APIs, authentication or any of that - 2-3 commands going each way would do the job.
Click to expand...

Except that KK wants to support the web-users, hence command line goes out the window. I agree that simple command line is by far the easiest way to go, but not for the web people.
 
then just read the board state in from a file, and spit out your move in a file, both with explicitly defined formats.

Sgarissta said:
Except that KK wants to support the web-users, hence command line goes out the window. I agree that simple command line is by far the easiest way to go, but not for the web people.
Click to expand...
 
KingKaeru said:
Not quite. the communication would need to be a lot more abstract than what you just described in order for us to be language/platform independant.

--KK
Click to expand...


Ok, I think we've got scope creep going on here. We could sit here and decide about how to support the thousands of variables, or we could get something working, and start testing...
 
So, in order to support the PHP-kiddies, you're going to force everyone else into the web's braindead stateless GET/POST application paradigm and write CGIs or use some bloated XML RPC stuff?
 
I would love to be involved, if the game doesn't take a high amount of resources (I don't see why it would) I'll provide a server for this and I would also love to be involved in designing the interface and GUI.

-randyc
 
You must log in or register to reply here.
Back
Top