Actually, a pretty big change that was skipped was the Player object now owning its id as a readonly value. Big for functions like getMyPlayer, as well as instances where you are accessing Player objects outside of events (ie without context.playerId).
Something else I stumbled across: game.connected is no longer a property of the Game type. This makes error handling (especially for long-running scripts that have to deal with 1006 style errors) a little trickier. Is game.engine._connected the recommended way to check this now?
oh hm game.engine._connected will work but the recommended way is to game.subscribeToConnection where you can get callbacks when it changes
(engine._connected is very slightly different, and won’t become true until you’ve authenticated with the server, which is a bit after the literal ws connection is established. but should be functionally the same for most things you’d care about)
Currently, I have a number of scripts that handle multiple game connections, usually to passively collect data. One issue I have had in the past is when I attempt to connect to a space and its mid 1006, or something else causes the connection to fail (user role issue, guestlist, etc.). game.connected was a quick and easy attribute to check as a guard clause before launching into a db connection, etc.
I have also used it to detect timeout issues, where I put the space on watch if game.connected was false for an extended number of loops.
I am not opposed to swapping around to a new pattern. More just evaluating the goals of the different fields.