This line also makes sure that SinkingBehaviour is only enabled if the Health component exists on the ship.

2. Play a sinking animation

In this section, you’ll write the function that’s called whenever the ship’s Health changes.
It needs to check what the updated current_health is, and play the SinkingAnimation if the current_health
is below 0.

Add the following line in your class body to declare an alreadySunk member variable:

private bool alreadySunk = false;

alreadySunk is used to check whether a ship has already sunk to avoid playing a sinking animation twice.

This uses OnCurrentHealthUpdated as a synchronous callback: a function that runs every time the CurrentHealth
property of Health is updated. If alreadySunk is false and currentHealth is below zero, it calls a function
that plays the sinking animation and disables the particle effect for the ship’s trail in the water.

At the beginning of OnEnable(), add the following line:
csharp
alreadySunk = false;
This is because this project uses prefab pooling. Prefab pooling allows Unity to reuse GameObjects to represent
different entities. Including this line ensures that, when this script is enabled, a ship entity with health > 0 doesn’t
appear as a sunk ship just because the ship entity that was previous associated with this GameObject
was sunk.

3. Register a callback for OnCurrentHealthUpdated

Register a callback to run OnCurrentHealthUpdated whenever the entity’s CurrentHealth changes.

In lesson 4, you
registered callbacks for whenever an event was triggered. Callbacks for property changes are similar: instead of
using ComponentReader.<event name>Triggered.Add(), use ComponentReader.<property name>Updated.Add().

There are a couple of alternative methods we could have used to register this callback, if we’d wanted different behaviour:
* HealthReader.ComponentUpdated.Add() would invoke the method every time any property of Health changed,
or any event on Health was triggered.
* HealthReader.CurrentHealthUpdated.AddAndInvoke() would invoke the callback immediately with the current
component values upon registration.

Deregister the callback in OnDisable() to prevent unexpected behaviour:

Copy this InitializeSinkingAnimation function into SinkingBehaviour.cs:

private void InitializeSinkingAnimation()
{
/*
* SinkingAnimation is triggered when the ship is first killed. But a worker which checks out
* the entity after this time (for example, a client connecting to the game later)
* must not visualize the ship as still alive.
*
* Therefore, on checkout, any sunk ships jump to the end of the sinking animation.
*/
if (HealthReader.Data.currentHealth <= 0)
{
foreach (AnimationState state in SinkingAnimation)
{
// Jump to end of the animation
state.normalizedTime = 1;
}
VisualiseSinking();
alreadySunk = true;
}
}

Finished version of SinkingBehaviour.cs

The finished script should look like something this:

```

using Improbable.Ship;
using Improbable.Unity;
using Improbable.Unity.Visualizer;
using UnityEngine;

4. Build the changes

You don’t need to build any changes this time. This is because all the changes have been made to Unity code,
and you haven’t added components to or removed components from a prefab. So when you run a client from Unity, Unity refreshes
code changes automatically.

If you wanted to run a client from the command line instead (using
spatial local worker launch UnityClient default), you’d need to build worker code, using
the SpatialOS window: Build > Workers > Build.

5. Check it worked

To test these changes, run the game locally:

Run the game locally from the SpatialOS window, then run a client from Unity.

Find another ship, and press E or Q to fire a cannon at it.

After four hits, the ship should sink.

It’s done when: the ship you hit sinks:

To stop spatial local launch running, use Ctrl + C.

Deploying to the cloud

So far in the Pirates tutorial, you’ve always run your game locally. But there’s an alternative: running
in the cloud. This has some advantages, including making it much easier to test multiplayer
functionality.