Texas hold ' em AI Web version

Continue the previous Texas hold ' em topic, the last DOS interface really can't see, my girlfriend said this is what ghost. Haha, I guess I can only play.

This two-day refactoring of the interface, based on Web server and browser to interact.

WebSocket communication between the server and the client, this all-double foreman connection makes it easier for the server to push the entire game data to the client in a timely manner.

This essay mainly records some of the pits that were encountered while doing the front-end interface, as well as the specific logic of the Texas Hold ' em game and the logic of the AI to view my first two essays

Speaking of Web servers, the go language is very well packaged in this area and it's too cool to use. Using WebSocket, we need to use a WebSocket package that Google offers.

: Http://code.google.com/p/go.net/websocket

If you can't access it, you can download it from this address: Https://github.com/SongLiangChen/websocket (I'll do it myself and pack on GitHub)

The entire refactoring is very simple, set up a Web server, establish a websocket connection between the client and the server, and the server first packages the initialized game data into XML and pushes it to the client, and the client presents the data after parsing it with JavaScript. The server then waits for the client to enter data according to the game logic, such as betting. It then calculates the next step and pushes the data back to the client side for presentation.

The main hole encountered in the process is JavaScript parsing XML, due to the differences between the various browsers caused a lot of compatibility problems.

For example, Chrome does not allow cross-domain access, and it does not implement Loadxml () or load () functions like ie. So you can only request data from the server via HTTP requests.

functionLoadxmlstr (xmlfile) {Try{xmldoc=NewActiveXObject ("Microsoft.XMLDOM"); }Catch(e) {xmldoc=document.implementation.createdocument ("", "",NULL); }                Try{Xmldoc.async=false;                Xmldoc.loadxml (xmlfile); }Catch(e) {varXMLHTTP =Newwindow.                     XMLHttpRequest (); Xmlhttp.overridemimetype ( "Text/xml; Charset=utf-8 "); Xmlhttp.open ("GET", "xml",false);                    Xmlhttp.send (); XmlDoc=Xmlhttp.responsexml; }                                returnxmldoc; };

The red callout in the code, which is the function of labeling the requested data as an XML text resource, and can inform the server browser of the encoding used. If not, you will find that ResponseText can return the data correctly, but Responsexml will return null.

Now that we run this JS code in Chrome, the server will receive an "XML" (the name can be determined by itself) request. We just set the route, and when we get the "XML" request, we send the data to the client.

Func GetXml (w http. Responsewriter, R *http. Request) {fmt. Println ("getXml",string(desk. Getxmldata ())) W.write (desk. Getxmldata ())}func Main () {http. Handle ("/con", WebSocket. Handler (startgame)) http. Handlefunc ("/", Hello) http. Handlefunc ( "/xml", GetXml)ifERR: = http. Listenandserve (": 8080", nil); Err! =nil{FMT. Println ("LS Fail")    }}

In go language, this kind of thing is not a thing, you can see, really quite simple.

Run the server and the browser will be able to play with 8080 port access locally.

Code open source on GitHub, Welcome to Exchange: Https://github.com/SongLiangChen/AITexasHoldemForWeb

In the runtime, please put the HTML file and EXE file in the same directory

Texas hold ' em AI Web version