Sunday, February 28, 2010

Back

So...that previous Klabiash rewrite fell through. As usual.

In fact, I think I've started and stopped writing an updated Klabiash client at least 10 times since I first put out the Visual Basic version in 1995.

In any case, I've rewritten the Visual Basic version in Javascript, so it can be played online. There are probably still some refinements that can be made, but if you want to, you can view it now at http://www.kobireiter.net/klabjs/main.html. Drop a comment here if you encounter a problem or have comments.

Monday, May 26, 2008

Run announcements and seven swapping complete

Making an offer on a house takes some time, so I wasn't able to get as much done as I had hoped.

The action items that have been completed recently:
  • Play progresses up to (but not including) the playing of the first card. After the bidding process is over, players are offered to swap the seven (if they can), and are presented with their runs which they can choose to announce. The server calculates whose runs win, and only that player announces his/her highest run. (Possible improvement here for the future: simulate a real situation, based on the order of announcements described in Card Games Around the World By Sid Sackson).
  • When a player has logged out when they were in a middle of a game, their status is updated to 'available' so they can be invited to other games.
Next order of business is to allow resumption of a game which had been left. This will be available if all parties involved in the game are available.

Saturday, May 24, 2008

Klabiash online development under way

For the past few weeks I have been working (again) on the online version of Klabiash. The past effort failed because of a couple of technical reasons, but those reasons have been rectified.

If you're not interested in the technical detail, skip down to the next paragraph. Because of the way HTTP works, the server cannot proactively push data to the client - rather, the client has to request it. So in the previous version, I had a client which polled the server every so often. For this to be a usable experience, the polling was done every half a second. This caused the server to start rejecting (and dropping) requests, which led to a whole lot of havoc. The newer implementation uses a pattern known as long-lived requests. Basically, the client sends data to the server whenever it has new data to send. When the server receives data from the client, it processes it, and if it has any data to send back, it does. However, if there is no new data, the server holds the connection open until there is data, at which point it writes back to the client. In order to prevent weird unnoticed timeouts, the client cancels each request after 10 seconds, and sends a new one. This gets rid of the problem of too many hits to the server. In addition, whenever the client or the server receive a message from the other, they need to let the sender know that that message has been handled, otherwise the sender keeps resending the message (this is to avoid accidentally dropped requests). Likewise, once a 'handled' has been received, an acknowledgment is sent, so that the handler knows it can stop sending a handled response. Both these improvements together make the network communication more robust.

The new version development is coming along. Currently implemented we have:
  • Users can log in and log out
  • Users can chat in the lobby
  • Users can invite one another to games, withdraw invitations, reject invitations or accept them.
  • If all the invitees (currently just one, but everything is being written with support for two), accept, a game starts, dealing the cards.
  • The game lets players pass, and will deal out a new hand if one is passed out.
  • The game lets users call, and will deal out the rest of the cards.
Today I am working on:
  • Players can switch the seven if they have it, and can announce runs (In a more complete solution than the windows version - you get to choose exactly which runs you want to announce rather than having to announce your strongest possible runs).
The immediate next order of business is:
  • Allow games to be resumed if a player leaves (logs out) in the middle. This should help debugging the future parts of the game, since games won't have to be restarted losing the existing situation which may have caused the bug.
Near future development which will take place:
  • Players will be able to play their cards
  • Players will be able to announce bella
  • Players will show their runs and receive points for them
  • When a hand ends, Be'te will be calculated and attributed (if applicable)
  • If the game is not over a new hand will start.
  • If the game is over, the game will end, and the users will be back in the lobby.
Future development:
  • Support three players. All the code is currently being written to support three players, but is only being tested for two at this point. Also, the UI doesn't allow people to invite more than one person, so a three-player situation cannot be entered into.
  • Support for playing against the computer. First as a two player game, then with the computer as one or two players in a three-player game.
Far future development:
  • Support for being in more than a single game at once.
  • User names and passwords.
Feel free to discuss and add comments if you'd like. As soon as the game is playable, I'll post the address for beta testing.