Skip to main content

Boss Room Actions Walkthrough

Example banner
Playing an anticipatory animation on the owner client to appear reactive and hide Network Latency
Example banner
Boss Room's mage's bolt doesn't use NetworkVariables and NetworkObjects to track the bolt's state. Since its movement is very fast, we only send an RPC to trigger VFX on clients. No need to waste CPU and bandwidth on a NetworkObject over time for this. Even if the FX passes through a wall on some clients (due to network discrepancies in target positions), the FX is so quick it wouldn't be visible to players.
Example banner
Boss Room's archer's arrows use fully replicated NetworkObjects + NetworkTransform. Since they are slow moving, we want them to be seen by late joining players. We also want to make sure their behaviour is the same for all clients (so they don't go through walls for example). This will use more bandwidth, but will be more accurate.
Example banner
The archer's volley takes multiple steps. First on click, the client will show a circle VFX tracking the mouse. That FX is not networked and client side only. Then on click, the client will send a ServerRPC to the server. The server will then apply it's gameplay logic, update the imp's health (tracked by NetworkVariables) and trigger a Client RPC to play the volley animation on all clients.
Example banner
Emotes only use RPCs. We don't care if a late joining player doesn't see other player's emotes.
Example banner
Most of the rogue sneak's logic happens server side. Since Boss Room is a coop game, we're not using Network invisibility here, only client side effects. Clients will still receive that invisible player's information and imp AIs will ignore invisible players.