Multiple games

[matthewphilyaw]

I believe it would be trivial to add the ability to select a game to play, and us support multiple games. If we go ahead and tackle this now I think it will set this up nicely to be a platform and keep us from doing too many global things.

• user logins
• client joins game:user_id topic (for not I'm not sure we need everyone in the same topic, unless for a chat)
• user types "list games"
• client sends a "lobby" event with a message of "list games"
• server broadcasts the list of games back
• user types "select [number|name]" to choose the game
• the client sends a "lobby" event with a message of "join game [number|name]"
• server sends back topic two topics to join "player:game_id" and "player:game_id#user_id" with the first one allowing game level events to be broadcast to all users (but nothing gets sent here) and the last one being player specific like we already have.
• The client would then disconnect from the game channel and connect to the respective channels, this event would rewire the client ui so that all user input now gets sent to player:game_id#user_id.

This can all be supported by one ui screen where the user issues commands, no need for multiple pages or anything.

[matthewphilyaw]

I think we could easily do by making the following modifications to the GameChannel module

• modify GameChannel.join to accept "game:user_id" instead of "game:lobby", and not send back player topic. Instead it just simply connects.
• the game channel would then need a handle_in that handles "lobby" events
• parse a "list game" command for the lobby event and we make a module like Game that has a list_games function to start with or something to list games. I'd imagine they would be stored in the DB and it replies on the same "lobby" event.
• parse a "join game" command for the lobby event which the user specified which game to join and the server would broadcast a "join_game" event to the client with the details, I think using a different event here is useful because in the client you can have a hook for "join_game" that changes over and connects to the player.

For the PlayerChannel I think we can do this

• implement two joins, one for player:game_id and one for player:game_id#user_id mentioned above the second one listed here would be pretty much what we have. The first one can be optional for now. So perhaps just expanding the current one to include game_id.
• For now PlayerRegistry I think would be fine as it is. It just takes the string "game_id#user_id" as the key and doesn't care and passes that into player process.
• Player process on init can pull out the game_id out of the "game_id#"user_id" string and we could have a game ets, that resolves game_id to game_pid, and the player process can send register it self with the game assuming a central module for a game, if not it has the game_id to use as a key to look up game specific info in the db. Implementation detail, it's easy to reason about a central game but in reality this may not be at all.

The client changes would be minimal I think and the transition between channels would be transparent to the user.

This will pipe the game_id around and if we only have one game it's ok but it's there and we don't have global modules that assume there is only one game etc - then we have a platform/engine that the build tools can be layered on to.

[matthewphilyaw]

https://github.com/voluspa/yggdrasil/commit/99252b584ea3e82b04d27d83623d99175a4646ca

Quick example of what I mean, the client here doesn't join the player channel, but does log the join_event from the game channel which contains the channel to connect to. Didn't have time to finish it out completely. Just an example of what I had in mind.

client does work though, so if you type list games it will, and join 1, for example will log the response. Games are also just hard coded for now.

[copenhas]

Ok, a lot to digest here. I think I got the gist of what you are talking about. I would prefer that that web app side shows the game list and gives info on them. Everything doesn't have to go through the client and be command based. I think most users would rather browse a list and click or hover on links/buttons to get info and descriptions. The user could click a join button for the game to jump to the client which will receive the game_id for which one was chosen. Everything else sounds reasonable. We pass the game_id for all the topics.

[matthewphilyaw]

Yeah, that is good point. Kind of a console addict :) the api could return a list of games by all means and the user clicks into the one they want to play.

I mocked up the game stuff, but can be ignored was just trying to express it in code it was how I was thinking at the moment.

[copenhas]

Ha, yeah no problem. I'm thinking that using ember directly outside of the client would make rendering some content easier and richer.

[matthewphilyaw]

So with that in mind I think it would really be more like:

• the user logs in
• navigates to some page that makes an api call to list the available games
• the user selects one
• the client then can connect up
  • it connects to game:[game_id] for game level events which returns player channel
  • it connects to given player channel that the game channel returned

I'm not sure we need "game:lobby" anymore if we went that route, I think game:[game_id] would suffice and scope events to each game.

[copenhas]

Yeah I agree. "game:lobby" was partly from following the chat tutorial. The topic is more for broadcasted messages. Hell it could be dropped all together. Maybe we only need "player#game_id#user_id" or something.

• Sean Copenhaver

On Jan 17, 2016, at 10:34 AM, Matthew Philyaw notifications@github.com wrote:

So with that in mind I think it would really be more like:

the user logs in navigates to some page that makes an api call to list the available games the user selects one the client then can connect up it connects to game:[game_id] for game level events which returns player channel it connects to given player channel that the game channel returned I'm not sure we need "game:lobby" anymore if we went that route, I think game:[game_id] would suffice and scope events to each game.

— Reply to this email directly or view it on GitHub.

[matthewphilyaw]

The client is fully capable in this model to connect directly to player:game_id#player_id, so maybe we start there and add back in game:game_id when we need it. I think this channel would only be used if we had a in game chat, but honestly probably be cleaner if it was chat:chat_id.

if we needed to support game level chat then chat_id is the game_id, if we wanted to have private chats then we could issue uuid's that gets distributed to the parties wanting to chat and they connect there.

I'm starting to see where we could have multiple channels with one task and we can scope it either by user, groups games or what ever.