Turn-based Game using Couchbase Mobile

[Dave Holdsworth]

I am considering building a turn-based card game using Couchbase Mobile.

The playing sequence is as follows:

Deal cards to Player 1 (face-down)

Player 1 Actions         (on table)

Deal cards to Player 2 

Player 2 Actions

Deal cards to Player 1

........................

A server will deal the cards and handle the actions through the sync gateway.

It seems to me I could have 

A) a channel per player and duplicate the game state to both, plus the cards to the next player to act

B) a channel per game and only push the latest revision with cards to the next player to act.

Is this an inappropriate use of revisions?

[Jens Alfke]

On May 8, 2014, at 2:36 AM, Dave Holdsworth <dahold...@gmail.com> wrote:

A) a channel per player and duplicate the game state to both, plus the cards to the next player to act

That seems right. You wouldn’t be duplicating the game state, just tagging its docs with both channels. Or if you prefer, you could have a “game” channel that both players have access to, and put the shared game state docs into that.

B) a channel per game and only push the latest revision with cards to the next player to act.

Doesn’t work, because you can’t route a doc to a subset of the users who have access to a channel; it’s all or nothing. Channels are really lightweight so what this means is you just need to refactor with smaller-scale channels (as above).

—Jens

[Dave Holdsworth]

Thanks for the response - I think I understand channels now.

One other thing: is there any documentation on how a server side bot (say a node program) can access the sync_gateway websocket interface directly for the _changes feed? 

[Jens Alfke]

On May 8, 2014, at 12:54 PM, Dave Holdsworth <dahold...@gmail.com> wrote:

One other thing: is there any documentation on how a server side bot (say a node program) can access the sync_gateway websocket interface directly for the _changes feed? 

The best documentation is in the CouchDB API docs. The WebSocket-based mode is Gateway-specific, though; I don’t think there’s any documentation of it yet. Do you need to use WebSockets or will regular HTTP do?

—Jens

[Matt Quinn]

On Thu, May 08, 2014 at 12:54:45PM -0700, Dave Holdsworth wrote:
> One other thing: is there any documentation on how a server side bot (say a
> node program) can access the sync_gateway websocket interface directly for
> the _changes feed?

If you can use HTTP instead, follow[0] is a nice library for processing
changes using Node.js. (It was designed for CouchDB, not Sync Gateway,
but given the compatible APIs it will probably work).

[0] https://github.com/iriscouch/follow

[Dave Holdsworth]

Thanks for the advice. Unfortunately the _changes feed=continuous doesn't seem to behave very well for the sync_gateway (or I've misunderstood how to get it to work) and it looks like follow is built on that.

I should be able to roll my own using feed=longpolling.

On Thursday, 8 May 2014 10:36:19 UTC+1, Dave Holdsworth wrote:

[J. Chris Anderson]

It's not super well documented but coax has a changes handler that uses longpoll: https://github.com/jchris/coax

[Jens Alfke]

On May 9, 2014, at 12:49 AM, Dave Holdsworth <dahold...@gmail.com> wrote:

Thanks for the advice. Unfortunately the _changes feed=continuous doesn't seem to behave very well for the sync_gateway (or I've misunderstood how to get it to work)

What goes wrong? As far as I know, continuous feed works fine.

—Jens

[Dave Holdsworth]

I've just been using httpie to play around with sync_gateway using walrus.

I've set up a public channel with guest accounts.

Calling the Admin API for _changes on 4985 in one window and PUT a doc on 4984 in another.

Changes came through immediately for feed==longpoll but when I tried feed==continuous it took 5mins to get changes on one occasion and not at all on another.

Sync_gateway doc says normal or longpoll.  

Anyway, I've got it working using coax and longpoll so at least for the prototype I should be ok.

Thanks

On Thursday, 8 May 2014 10:36:19 UTC+1, Dave Holdsworth wrote:

[Jens Alfke]

On May 9, 2014, at 8:06 AM, Dave Holdsworth <dahold...@gmail.com> wrote:

I've just been using httpie to play around with sync_gateway using walrus.

I've set up a public channel with guest accounts.

Calling the Admin API for _changes on 4985 in one window and PUT a doc on 4984 in another.

Changes came through immediately for feed==longpoll but when I tried feed==continuous it took 5mins to get changes on one occasion and not at all on another.

That’s an issue with httpie, and you’re not the first to run into it :) Basically, it wants to read the entire response into memory first and then print it. But the continuous changes feed never ends, so the response is never complete.

I think there’s some flag to httpie to disable that, but I just use ‘curl’ instead whenever I want to look at continuous changes.

—Jens

[Dave Holdsworth]

Yes, the --stream option for httpie sorts it out.

I've now got it working with follow and feed=continuous

Thanks a lot.

On Thursday, 8 May 2014 10:36:19 UTC+1, Dave Holdsworth wrote: