jdoleary / websocketpie Goto Github PK

I suggest husky and lint-staged for this.

After using Tape a bit I'm not super happy with how it reports failures. When a test times out for example. I notice that it doesn't tell me which test times out.

I'm thinking we could migrate to AVA before our tests get too advanced.

This will allow game clients more granular control over what happens at these stages.

This will give us a better handle to clients than a name. Using uuids practically ensure there are no collisions.

This special type of message would be necessary for games like "rock paper scissors" were the game is turn based, but neither client should know ahead of time what the other clients have chosen.

The config for together settings (timeout for example) can be configurable on a per-room basis when the first user makes the room.

When a together message is received, the echoserver keeps it in memory and waits for all the room's other clients to send a together message, when all are received (or the timeout is reached) it sends one bulk message to all clients simultaneously, containing the aggregated contents.

Per our conversation, the final set of callbacks that should be passed in a config object to the constructor are:

onServerAssignedData
onClientPresence / onClientPresenceChanged
onData
onRooms
onConnectInfo / onConnectInfoChanged

Originally posted by @msweda in #26

Game clients should be able to query for an array of rooms that match their game app and version.

Notice that in the screen shot, I only have two tabs open, but there are four clients in the room.... not sure where these other two connections are coming from.

https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_API/Writing_WebSocket_client_applications

https://developer.mozilla.org/en-US/docs/Web/API/WebSocket

http://docs.happyfuntimes.net/

How are rooms removed? Should they be cleaned up if all clients leave it?

makeRoom already adds user to room

Personally, I don't trust that every single dependency uses semver correctly. I'd like to make our project build deterministic and I think we should lock down the versions in package.json.

We should add .yarnrc and .npmrc files to ensure that added packages automatically use an exact version going forward.

Currently, clients can only specify a name as part of the "joinRoom" message. This should be abstracted so the user could pass in anything they like. This will give us more flexibility in the game client code.

oven-sh/bun#2988

This will allow game clients to leave a room without closing their websocket connection.

https://zeit.co/

A frontend abstraction for the Echo Server public API

Should we allow makeRoom to accept a password to allow only people who know it to enter the room?

@msweda, What do you think about just making this a small npm package? I'd be happy to take care of it.

Defeat the devil with the power of volleyball

Hey everyone ,

not sure if I just don't know the correct way to do what I wanna do, or if this could be a legitimate feature request.

I think I want a client to be able to join and be in multiple rooms and receive and send messages from and to those rooms. When sending a message, the room should be selectable.
Think of having one "global" room, one for a party of 4 or 5 players and one short-living room that represents a battle, which would be used to sync state like healthpoints etc.

Best regards

https://github.com/websockets/ws#how-to-detect-and-close-broken-connections

Joker and the bank idea

For conceptual clarity, and to prevent us from needed a package.json in the root, let's keep packages totally separate. They shouldn't be dependent on each other.

If one of the clients needs to have "final say" in an app, I'm suggesting that we can do that with a fixed order of the clients in the clients array. But I'm putting this issue here so that we can think on it. It might be something we should add to the docs when we're decided.

We have a joinRoom handler but forgot to add a makeRoom handler.

https://devcenter.heroku.com/articles/websocket-security

Joining an existing room and making a new room should be separated.

New rooms should have optional configs from the host with room specific options (max players, etc)

I know that joining a room fires a "clientPresenceChanged" but is that ideal? I have the scenario in Beelzeball where I want to make a room, and only after the room is successfully created, move to the game screen.

Related, I'm not sure we want the "host" to join a room implicitly when they make a room. It seems like it'll be easier to make a room under a certain condition but always join the same with, with a "JoinRoom" message.

Opening up for discussion.