-
Notifications
You must be signed in to change notification settings - Fork 14
Live replays
Jerome Leclanche edited this page Nov 27, 2015
·
5 revisions
Server:
- Centrifugo (docs)
HDT:
- Own centrifugal implementation
Web client:
- centrifuge.js
- sha256.js
- sockjs (for compat?)
- joust
- HDT connects to Centrifugo and asks to create a new channel. Centrifugo replies with the created channel. (How to do this?)
- Channel can be made public (as in, browsable from the user's page), or accessible only with the URL (shared secret?)
- HDT user shares URL.
- Web user goes to URL, enters the channel
- Gets the beginning of the match up until now from somewhere...
- Is the
history
method enough to do this? Maybe there's too many messages. - It would appear so.history_lifetime
needs to be configured. - Listens for further messages
- Forwards everything to Joust
The simplest way to packetize hsreplay is to flush every time a top-level action is closed. This is problematic for Discover... maybe tracking too. Because the choices are blocking and not top-level. But nothing else.
A more complex way is to follow more closely the game's protocol, sending in ACTION_BEGIN
and ACTION_END
. Maybe flush every second. This would let us send fewer packets while still respecting choice "waits".
We can also, instead of all that, simply implement a minimum wait time on choices in joust, eg. an animation like Hearthstone does. This solves the problem very neatly.
- Make sure the data can't be harmful to the clients as it will essentially not be changed from HDT to web client
- (Later)
presence
can be used to tell how many concurrent live viewers are there. Once we have enough...