JackieChiles/Cinch — comment on commit 6cb57ce13fad82790526fa5447b4ea39a7cf8d1f
File: core/game.py line 106
By PheonixKotori:

@JackieChiles: Your idea for the game router as a thin thing works until
you need to create games and join players to games not yet in progress --
metagame activities, if you will.

And I extended it to invoke play handling, bid handling, and so on directly
instead of passing all game traffic to the Game. Since the web server is
"signature" based, the web server needs to know the sigs of all messages
that the Game cares about. So I could either make one handler per signature
and let the web server invoke the right handler, or have a lot of
signatures call a generic game handler and the let the Game pick the right
method to call. While my solution makes the game router a bit bulkier, it
saves duplicating the functionality of a handler selector in multiple
places.

The client manager, however, solely handles the task of matching various ID
types to other ID types.

On Wed, Feb 29, 2012 at 7:41 PM, JackieChiles <
reply@reply.github.com
> wrote:

> My idea originally was that the game router is pretty "thin" and only
> basically just matches up player guids to their appropriate games and
> player numbers and passes data to the `Game`. Somewhere in this `Game`
> module the active player check should be done (see part A of the workflow),
> basically what @PheonixKotori said.
>
> Feel free to tweak that as you need to of course.
>
> Ideally the workflow wiki would be updated to match things as they change,
> but not a high priority, and I can probably just update it once I'm aware
> of any changes you need to make. I don't even think it's super accurate
> for some things at this point anyways.
>
> ---
> Reply to this email directly or view it on GitHub:
>
> https://github.com/JackieChiles/Cinch/commit/6cb57ce13fad82790526fa5447b4ea39a7cf8d1f#commitcomment-1029242
>