tgoossens / htttp-peno Goto Github PK

• Clients can broadcast a found message on demand.
  • Message data: playerID
• Clients can receive other found messages for logging purposes.

Team members should be aware of their partner's position so they can meet up.

• PlayerClient.PublicConsumer should also handle update.
• If the player is in a team and receives an update from his partner, call PlayerHandler.teamPosition(x, y, angle).

1. Player 1 successfully joins the game with the name foo.
2. Player 2 joins the game with the same name foo.
3. Player 2 is rejected by player 1 because of the duplicate name.
4. Player 2 reports that he's leaving.

Expected result:

• Player 1 does not trigger playerLeft as no valid player left the game.

Actual result:

• Player 1 triggers playerLeft for foo, effectively unregistering himself.

Update JavaDoc to clarify that angles should be interpreted in degrees.

StackTrace: https://gist.github.com/stevenroose/174572f692b7605ab2d7

I get this error when one of my players finds his object and tries to broadcast that.

The position topic still needs a handler. Simply parsing and calling the handler method should suffice.

Clients should listen to ready broadcasts and update their PlayerInfos accordingly.

The robots controlled by the players have all different dimension. To allow for proper collision detection, this needs to be communicated to all parties.

• Set the width and height when creating the client.
• When joining, publish the size for other players to register.
• Publish the size with each position update to listening simulators.

• Clients can pause (and stop) game on demand.
  • All players switch to paused (or waiting) state and notify handlers.

• Clients can start the game on the following conditions:
  • Game must be in waiting or paused state.
  • All four players must be ready.
• Client broadcasts start message to notify other players.

• Clients broadcast heartbeat periodically while connected.
  • Message data: playerID
• Clients keep track of time of last received heartbeat of each player.
  • Extend PlayerInfo to include lastHeartbeat
• When last received heartbeat is too long ago, assume player left.
  • Periodically check all heartbeats, possibly at same time when sending own heartbeat.
  • Interpret or broadcast a leave message.

Currently, the ready state is redundant. As soon as you joined the game, you're in fact ready to roll for player numbers. It is much more useful to report a ready state after getting a player number, since this is the stage where robots need to be moved to their correct starting positions and may need some time to do so.

The following updated scenario is proposed:

1. Players join the game.
2. When all 4 players have joined, the player numbers are rolled.
3. Players receive their player number and position their robot on the board. When they're done, they report that they're ready to start.
4. When all 4 players are ready to start, the game is started.

This replaces the redundant "wait until ready to roll" with the more important "wait until ready to start" check. This should be fairly simple to implement, but all implementations will need to adjust their handling.

give a short overview in the readme and link to the complete specification documents

Completely separate from the currently implemented game communication, players have to broadcast their positions. This information should not be communicated by the current Handler interface, because Players should not know this information.

Proposal:

• a separate WorldHandler class to receive this information. Currently this will only include each player's relative coordinates.
• an extra method in the client class to allow players to broadcast this information

This would imply that the current playerPosition method should be moved.

-- fixed

1. Four players join and start a game.
2. Two players leave the game.
3. The first player reconnects and is accepted.
4. The second player reconnects and is rejected.

This occurs because the first reconnected player no longer knows that the second player used to be in the game. He assumes that the second player is trying to join a game in progress in which he didn't start. The other connected players correctly accept the second player's request, but the rejection from the first player causes the second player to bail out.

Do we really need all players to accept a join request? All players in the game keep their game state synchronized, so theoretically one acceptation should suffice.

Is it possible to let the handler also have a method that is called when a player in the game changes its ready status?

• Position updates are only sent when moving to a new tile.
• Coordinate components only need to be long instead of double.
• Angles can still be doubles.

• Player can propose a merge between the two mazes.
• Partner needs to respond with accept or reject.

Question: When can/should a merge be accepted or rejected?

Hoe moeten we de positie van onze robot doorsturen? (Voor een spectator die dus alle 4 de robots ziet bewegen) Ik had een thread gemaakt die PlayerClient.updatePosition(...) gebruikt om elke seconde de positie door te sturen. Dit lukt ook maar dan krijg ik geen andere berichten meer binnen. Bijvoorbeeld bij een disconnect van een andere client wordt de handler niet opgeroepen.

Enig idee waar dit aan ligt/hoe ik het anders moet aanpakken?

How else can we scan for physical robots only in the physical world and for virtual robots only in the virtual world.
Differently put:
If no distinction can be made between these two types of robots, why would we scan in the real world? We can just scan the virtual world and get all the information we need there.

• When both players reach the meeting point, publish win.

Because initially players were assumed to broadcast their position periodically.

Currently, players only do so when entering a new tile. This means that players can stay on a tile for a long time without communicating, having themselves kicked out.

Proposed fix: When a player stays idle for a long time, ping it and wait for a heartbeat before kicking him out.

I don't know if it is meant to be like this, but the GameHandler.gameStarted() method is called 4 times when I run the game. Probably every player sends a gameStarted signal to the others.

• If this is implemented to be this way, I think it should be documented so as well.
• If it isn't this is probably caused by the fact that a gameStarted signal from one player takes about a second to reach the others and in the meantime other players feel responsible to start the game themselves. In this case there should be something to prevent the client from calling the Handler method multiple times.

https://gist.github.com/stevenroose/bad701fda65f2adeb6e1

All our method GameCommunicationManager.joinTeam only calls the PlayerClient.joinTeam method.

• Player can propose a position where to meet.
• Partner needs to respond with accept or reject.

Question: When can/should a meeting point be accepted or rejected?