I kind of go on tangents when I do personal projects. First my goal was to make a poker game for bots to play… then somehow it diverged to making an ajax client…. somehow it diverged after that to use comet/cometd to do it… and then finally I decided to rewrite the cometd-twisted for my own evil.

Basically, for games and such, the bayeux protocol is a good place to start, but all the publish/subscribe stuff is superfluous. I basically just wanted to use the heart of the protocol and the ability to use the existing JavaScript libraries.

I think what I did is pretty cool. Basically, I made it so when a client connects it spawns a new client class. Then when they subscribe to a channel it makes a ChannelSubscription class. The messages are routed through this. Each ChannelSubscription behaves as a logical connection to the client such as a Protocol class with Twisted would. In fact, there’s about 3 lines of difference between my TCP layer for my poker client and my comet layer now. It’s pretty cool.

I set it up so that authentication and such would happen one level on top of the Bayeux protocol to allow for more customizations. It doesn’t matter whether or not they connect.

I have half of an ajax poker client written for my server with this, but it’s basically just a proof of concept that this works. I think I’m going to write a blackjack server too to allow for easier testing, and a better demo for when there aren’t people to play against. It’s simpler, and I already have most of the code done in Ruby from a long time ago… I just need to port it over Python.

Anywho… I’m calling my cometd server ucommet. Why? I couldn’t think of anything better.

The source is here for all the stuff (you want ucommet.py and possibly tabled.tac to see how it’s used)

you can do a “svn co http://svn.lolrus.org/dpoker/trunk dpoker” to get my poker tree.

You’ll need twisted.web2. If you have twisted 2.5, actually might have to get the SVN version. The apt-get seemed to get a working version for me in Ubuntu, but on my Gentoo server it was a whole different story :(.

I’m going to be in Prague with some friends for the next three days (my last days in Europe before I come home). Then once I get back to the states, I’m going out to Cali for a day or two for an interview. It’s been too long since I’ve had a burrito or a double-double. So what this means is I probably won’t have time to work on this for the next week or two.

I started a new project a few days ago. It’s one I’ve been pondering over for a long time, and it’s about time I did something about it. I’m bad at naming projects, so I chose dPoker, the d is for donkey.  Donkeys are cool either in poker, on waffles, or on waffles on VT200s in Sysprog class. Basically, the core of the project is just a poker server. It’s purpose is for bots to play, compete, and learn, not really humans. Of course, humans will be able to play too, once somebody writes a client. I have a few friends interested in working on this too, but I need to get a proof of concept together first.

I set up a trac for it here.

Here’s a few technologies I’ll be using and design decisions (for the proof of concept at least) and why:

• The server will be written in Python.
  • it’s relatively fast and small in memory (compared to Ruby)
  • good libraries
  • readable
  • native thread support
  • I find it fun to write
• Probably using Twisted framework.
  • It seems nice and supports a variety of protocols.
  • Eventually want to make a javascript client
  • Don’t want to reinvent the wheel
• SQLAlchemy for data logging and account
  • I really like it
  • Sadly, there’s no recent updates to Asynchronous wrappers for for like a year, so I will probably have to roll my own :(.

I’ll be using a very simple protocol so people can easily write their own clients/bots in any language.  I’m trying to design it to scale well over multiple processes and servers.  It will also be modular so it can extend to different card games or non-card games.  The primary reason i want it to be scalable is because if computer learning is to be done, it has to either go really fast, or support hundreds of games at once.  There’s latency over the internet, so that would be the bottleneck for how fast a game finishes.  So my solution for networked games would be to have say maybe 10-100 instances of a bot running in that many different game rooms.  Although, there would still be latency, it would still increase the game’s played/time period.

Me or a friend will write a JS or even a flash client  so people can easily play over the internet against bots or each other.  I’d still have to work out a way to get people to try instead of going all-in all the time, but I think this would be important to add a bit of supervised learning to the mix and see how these bots evolve.