com.unity.services.samples.game-lobby

文件历史

Bart Janczuk 0aa1fee6 Remove usage of connectionInfo		3 年前
..
AsyncRequestRelay.cs	Merging the error code exception branch.	3 年前
AsyncRequestRelay.cs.meta	Changing the error pop-up to handle the LobbyServiceException with more player-facing error output. The same work for Relay will follow if the package is in a usable state.	3 年前
RelayAPIInterface.cs	Bugs: Adding clarifying comments for Relay + UTP and for some of the design patterns. Adding a rate limit on the lobby host button. Adding a blocker on the spinner so that the lobby list UI can't be interacted with while the spinner is visible (to prevent someone from starting to join a room that's about to be removed from the list).	3 年前
RelayAPIInterface.cs.meta	Latest Dev and Readme without Vivox	3 年前
RelayPendingApproval.cs	Primary rejection behavior - A host will reject an incoming client if the lobby is already in the in-game state. Clients will now no longer send data until they are approved, but once approved, connection completes as usual.	3 年前
RelayPendingApproval.cs.meta	Primary rejection behavior - A host will reject an incoming client if the lobby is already in the in-game state. Clients will now no longer send data until they are approved, but once approved, connection completes as usual.	3 年前
RelayUtpClient.cs	Adding in a call to CheckIfAllUsersReady in the RelayUtpHost within the lobby rate limits, so that if a player disconnects and all remaining players are readied, the countdown will begin. (If and when Wire is integrated, that might obsolesce this.)	3 年前
RelayUtpClient.cs.meta	Still partial progress. I have a little handoff going where the client identifies itself to the server and the server responds with an ID to use in further communication. However, I don't think that will actually work since all clients would also need those IDs? I can just send the user ID, which takes up more bandwidth but not dramatically so. Also, this pinpoints the heartbeat for keeping the Relay allocation up. I'm trying to pull out all the job system things, since that both seems like an extra layer of complexity that devs would have to learn and it also isn't, like, actually used correctly in the sample?	3 年前
RelayUtpHost.cs	Merge from staging. This breaks behavior for this fix, will investigate.	3 年前
RelayUtpHost.cs.meta	Still partial progress. I have a little handoff going where the client identifies itself to the server and the server responds with an ID to use in further communication. However, I don't think that will actually work since all clients would also need those IDs? I can just send the user ID, which takes up more bandwidth but not dramatically so. Also, this pinpoints the heartbeat for keeping the Relay allocation up. I'm trying to pull out all the job system things, since that both seems like an extra layer of complexity that devs would have to learn and it also isn't, like, actually used correctly in the sample?	3 年前
RelayUtpSetup.cs	Remove usage of connectionInfo	3 年前
RelayUtpSetup.cs.meta	Partial progress: Following a trio of Relay+UTP samples, I seem to have something that will bind a transport to Relay and keep the connection open (as evident from the fact that a client can join after what would be the 10s timeout on Relay and successfully get the JoinAllocation, when they wouldn't without keeping the connection open even when binding was correct). However, this current code is very slapdash and sloppy; I'm just committing now as a very rough draft.	3 年前