This is fine (if not ideal) in a game with only human players. But in preparation for supporting computer-controlled players, I'll need to update state as a result of server-initiated actions. The current approach cannot support this.
So instead of broadcasting new state synchronously in the channel in response to user-initiated actions, we'll make this asynchronous: user-initiated actions will cast to the server, and whenever the server has handled them, it will broadcast them back to the players. This opens the door for the server arbitrarily broadcasting new state for other reasons, such as server-initiated actions.
I should have done this from the start. With GenServers it's a good idea to avoid call (which blocks the sending process) and prefer cast (which doesn't). If the GameServer ever takes a while to respond, cast means it won't also make the channel process slow to respond as well.
Before, we were only ever
broadcast
ing state updates as a result of player actions:This is fine (if not ideal) in a game with only human players. But in preparation for supporting computer-controlled players, I'll need to update state as a result of server-initiated actions. The current approach cannot support this.
So instead of
broadcast
ing new state synchronously in the channel in response to user-initiated actions, we'll make this asynchronous: user-initiated actions willcast
to the server, and whenever the server has handled them, it willbroadcast
them back to the players. This opens the door for the server arbitrarilybroadcast
ing new state for other reasons, such as server-initiated actions.I should have done this from the start. With
GenServer
s it's a good idea to avoidcall
(which blocks the sending process) and prefercast
(which doesn't). If theGameServer
ever takes a while to respond,cast
means it won't also make the channel process slow to respond as well.