[Pokersource-users] Confirmations for Animation Packets

[Loic D. <lo...@gn...>]

        Hi,

        For some reason I never received the mail you posted on the list. I ran into
it when reading the archives.

        The answer to your question is not simple. It very much depends on how you
manage your animations. From the game engine point of view (poker-engine), every 
action is instantaneous. The game engine itself does not support the idea that an
action such as receiving cards or finishing a hand can take "some time". 

        However, and my guess is that this is the problem you are trying to solve,
when displaying animations related to chip stacks movements or cards being dealt,
you want to pause the game engine. Since the game engine knows nothing about delaying,
it all relies on the application.

        Now that we are clear about the fact that poker-engine won't save you, there
are a few options:

        - brutal : you can block the client completly until the animation is 
          over (that would be done by forcing the protocol.py module to be synchronous)
          The problem is that you don't really want to pause everything (including chat
          and dealing other cards for instance) just for the sake of spending 2 seconds
          to play a "deal card" animation. Or maybe it's acceptable to you. 

        - delay the renderer: you can ask the pokerrenderer.py to pause for a while
          without stoping the handling of incoming packets. Better yet : you can 
          ask the module to pause the packets for a given player. That would allow
          the client to act on other players while playing the animation.
          This pause just helps you ensure you won't run a deal card animation on top
          of another.

        - chain the actions in the animation module: meaning you schedule the animations
          yourself without asking for support from the renderer or the protocol. It is
          an attractive approach but tricky in some cases because you introduce an
          asynchronous layer on top of another asynchronous layer. It's most likely to
          work well 95% of the time and be a complete mess when a special case occur (such
          as canceling a hand and returning the big blind to a player). You can get it
          right if and only if you have all the special cases in mind when you design your
          code.

        I'd be interested to look into your problem if you have some code to show.

        Cheers,

-- 
Loic Dachary, 12 bd Magenta, 75010 Paris. Tel: 33 8 71 18 43 38
http://www.fsffrance.org/   http://www.dachary.org/loic/gpg.txt