Image Image Image




Post new topic Reply to topic  [ 6 posts ] 
Author Message
 Post subject: Partial versus full game state
PostPosted: Mon Nov 05, 2007 11:29 am 
Offline
PokerAI fellow
User avatar

Posts: 7731
Favourite Bot: V12
There is one block in the whole architecture that might need discussion. Once we decide on binary or XML representation, we can also discuss specifically how this will affect the protocol.

The topic is how to represent the game state.
It is very important design decision (that I would like we stick to) to keep every message of the protocol self contained and complete with regard to all information about the hand for which decision is requested.

Having that, the open is how to handle info from a scraper, that can only see what's now the situation on the table (but has no info from the beginning of the hand).

So there are two type of scrapers, or front ends:
1) That can provide the complete hand information: initial stack sizes, actions on previous betting rounds, etc.
2) That can provide only what they see currently: bets made by players on this round, current stack sizes of the players, current pot size.

The questions are:
1) How to handle that with the same protocol?
2) Will there be bots that handle both cases? Or it make sense to simply have binary switch as first "tag" for what is the case, and bot authors to provide info what they support?

_________________
indiana


Top
 Profile E-mail  
 
 Post subject: Re: Partial versus full game state
PostPosted: Mon Nov 05, 2007 11:55 am 
Offline
Senior member
User avatar

Posts: 477
Favourite Bot: Donbot
Quote:
The questions are:
1) How to handle that with the same protocol?
2) Will there be bots that handle both cases? Or it make sense to simply have binary switch as first "tag" for what is the case, and bot authors to provide info what they support?


1) Perhaps many of the XML tags (and attributes) can be marked optional. For example a player has both starting stack and current stack, and some AIs need one of them, some need both and some need none. It is up to the AI holder to communicate which ones are needed.
2) I dont think there will be. So I guess there could be 2 different versions of the protocol, though I prefer my above suggestion.

_________________
I'm doing my part


Top
 Profile E-mail  
 
 Post subject: Re: Partial versus full game state
PostPosted: Mon Nov 05, 2007 12:04 pm 
Offline
PokerAI fellow
User avatar

Posts: 7731
Favourite Bot: V12
Now we can say that the bots that are able to work with partial state will be able to work with the full state. This is good to have (at least).

Therefore I like the idea with optional info. Can we minimize this? For example say
- we always provide current stack sizes
- we provide bets (money in front of) the players on this round
- we proivde pot size
- and the betting sequence (since the beginning of the game) is the ONLY optional thing?

_________________
indiana


Top
 Profile E-mail  
 
 Post subject: Re: Partial versus full game state
PostPosted: Mon Nov 05, 2007 4:35 pm 
Offline
Senior member
User avatar

Posts: 477
Favourite Bot: Donbot
Yes, though players names should be optional aswell.

0

_________________
I'm doing my part


Top
 Profile E-mail  
 
 Post subject: Re: Partial versus full game state
PostPosted: Mon Nov 05, 2007 4:43 pm 
Offline
PokerAI fellow
User avatar

Posts: 7731
Favourite Bot: V12
0svald wrote:
Yes, though players names should be optional aswell.

0


I would propose to make player names mandatory, but the scraper is free to provide just "player1", "player2" etc. as player names, if he cannot read the actual names. This will make it easier as you don't need to maintain mapping to the actions (ok, if we go for more compressed messages, which make sense), and only player number is given in the action sequence, then this is not valid argue).

Still we have the options to make the names optional, or to allow the frontend to provide whatever it wants as player names (eventually propose default scheme for fake players, to exlcude them from profiling).

EDIT: Along these lines, the same idea may actually help to define the "optionallity" of the player's actions. If the length of the action sequence is zero, consider it non-available.

_________________
indiana


Top
 Profile E-mail  
 
 Post subject: Re: Partial versus full game state
PostPosted: Thu May 15, 2008 6:45 am 
Offline
Junior member
User avatar

Posts: 13
Favourite Bot: None for now
Communicating full state, like previous 10 or 100 or 500 hands could be very heavy on the network and parsing side but why not.

Anyway optional data is easy with XML (the parser simply ignores the tags/attributes it doesn't know or doesn't want to read) and if we have XML, partial or full states becomes a no-problem. We only have to tell the receiving end the message type:

<message type="deep-history">
...the message, 500 hand history and other states...
</message>

or

<message type="current-hand">
..current hand state data...
</message>

this would allow us to send hand histories for live game, analysis, easy storage in a database, or any other application we could think of. We only need to change the message type as long as the embedded data objects have a clear and agreed-upon specification.

I mean we can abstract a bet, we can abstract a table, we can abstract a player, and combine it in 2 or 3 slightly different ways depending on the application if really needed.

Again, unneeded data is implicitly ignored by an xml parser. the parser would only "stop" on data it recognizes and needs. This leaves the protocol open for evolution.

But maybe i miss the point.


Top
 Profile E-mail  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 6 posts ] 


Who is online

Users browsing this forum: No registered users and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to: