Socket / frontend controller architecture.

[jdmcpeek]

I'm still trying to wrap my head around the way realtime updates will be architected. We can use our websockets to send/update game data and tags like #{game.players} to print what we need. We could continue down this path for now... the next step is to define emitters and receivers on client and server.

We could also pass control to the Angular controllers by wrapping them around the sockets. Check this article out for integrating socketio with angular: http://briantford.com/blog/angular-socket-io. I think the major benefit to Angular is that it provides us with a lot of tools to organize our information on the page and make interaction much nicer. For instance, filtering by card type to reveal only Cocoa beans would be a breeze: https://docs.angularjs.org/tutorial/step_03. I think the idea is that we would have socket.io res.send game data to Angular controllers, which would in turn update the view templates. More thoughts coming along as I explore this framework further.

[jdmcpeek]

Lesson learned: res.render will only display the data you tag in the view. For example:

p Channel: #{game.channel} p(id="players") Players: #{game.players}

Will give you 'Bohnanza_example' for the channel and 'Steven' for the player, but the client does not receive a JSON object to work with in-browser. We'll have to figure out some roundabout way to get the rest of the game data and I'm not in favor of doing a bunch of JQuery magic tricks. We could open up a socket event and transmit the data through that. This might be another vote in favor of Angular, we'll just have to figure out a way to send game data to ng-controller.

[Steven-Wright]

Alright, so I took a look. Angular might be nice no complaints here. You can actually pass locals in the render call through the view and into javascript on the page.

in app.js res.render('play', {channel: req.params.channel});

in views/play.jade

script.
  var channel = '#{channel}'

I don't see why you couldn't pass a JSON object through this way.

[Steven-Wright]

Ok. So you can in fact send the game object through this way, but it is probably a bad idea for a few reasons.

• it is wasteful as we only need a subset of the game on the client
• it allows easy cheating as the deck and other players hands are exposed.

So we can send part of the game through as a different but similar object, without deck, discard, or hands. Use this information as the boilerplate for every /play req.

Then we can use sockets to give each player their appropriate hands and interact with the game. Smarter players will still have enough information to ask for other players hands by injecting their own JS that asks for and then receives other players hands.

[Steven-Wright]

Can't really spend anymore time on this for a while, ending with this last note inspired by reading the following doc.

We can have each game have a namespace, this way we can have more than one game going on at once. In addition, each socket has a unique ID which can be used for direct app -> client communication. When a player connects we could store this ID in the player schema and use it to ferry updates to the players hand to and fro. Handling dc/rc might be an adventure.

Lastly we can have chat just be a room separating them from other broadcasts.

@HarryTerrell ^

[Steven-Wright]

@jdmcpeek Here's an article about using mocha to test angular controllers... ignore karma... @jdmcpeek This one seems comprehensive.