Intricate Devices of Life and Death

Step 1: They mostly come at night... Mostly.

The operations center has obtained fresh satellite images of the colony on the planet Acheron (LV_426). Strange creatures of so far unknown and evidently alien (i.e. extraterrestrial, abbreviated E.T.) origin have been sighted in the area. These are most certainly not the cute Spielberg creatures that just want to go home. Contact with these ones will likely not be pleasant...

class diagram: Class Alien and its relationships to existing classes and interfaces. [Alien{bg:cornsilk}]-.-^[<>;Movable] [Alien]-^[<>;AbstractActor] [<>;Movable]-^[<>;Actor] [<>;AbstractActor]-.-^[<>;Actor]

Properly modify the main() method so that you have in the game a scene with the new map, a configured instance of EscapeRoom.Factory as the actor factory, and EscapeRoom as the scene listener.

For now, the class should have a parameterless constructor. The intruder should be represented by the sprite alien.

Note: Open the map file and check the names and types of actors that you will need for this mission.

Use the message topic World.ACTOR_ADDED_TOPIC to "catch" the addition of intruders into the scene and schedule their random movement using already existing actions.

Note: Since the scene method sceneInitialized() is called only after the scene map has already been initialized and the actors defined in it have already been inserted into the scene, you need to subscribe to messages from the topic World.ACTOR_ADDED_TOPIC earlier. Therefore, within the scene class, override the method sceneCreated(), which will be called immediately after the scene is created.

After starting the game, you should see the map of today’s mission, on which Ripley should already be placed, along with several items and running around intruders.

Step 2: Signs of (Half-)Life

The tactical and strategic team managed to break into the secret records of the classified autopsies of the intruders and, surprisingly, discovered that their existence depends on vital functions similar to those of humans. The tactical and strategic team therefore proposes that you create a class Health to represent these life functions, which will replace the current energy variables and ensure greater flexibility of the solution. Our team further suggests that you distinguish actors that show signs of life from the others through the interface Alive.

Objects of the Health class will serve to store the health value of living actors as well as to manipulate this value.

Store the values of both constructor parameters in the state of the class. Since you will need to retrieve the current health value, make it accessible via a getter method named getValue().

A common situation will be setting both constructor parameters to the same value, which will mean that the actor starts with maximum health. To simplify the use of the class in such a case, also create another parameterized constructor in the Health class with a single integer parameter, which sets both the initial and maximum health values to the same value.

The method signatures and their meaning should be as follows:

• void refill(int amount) – the method increases the health value by the amount specified by the parameter. Of course, the resulting value must not exceed the maximum value specified when the object was created.
• void restore() – the method sets the health value to the maximum possible value.
• void drain(int amount) – the method decreases the health value by the amount specified by its parameter. The resulting value must not drop below 0, which already represents a state indicating that the actor owning this health object has been completely exhausted and has died.
• void exhaust() – the method causes immediate complete exhaustion of health and thus sets the health value to 0.

The interface will mark living actors and will contain the declaration of the method Health getHealth(), which returns a reference to the Health class object associated with the given actor.

Adjust the Ripley class so that it implements the Alive interface.

Next, ensure the creation of a Health class object in the constructor of the Ripley class. Set both the initial and maximum health values to 100.

Note: Do not forget that you no longer need the methods getEnergy() and setEnergy(), nor the related member variable, in the Ripley class. Also properly update all places where you have used these methods so far to use the new methods of the Health class object.

From the previous exercise, you should have in the setEnergy() method, in addition to setting the energy, also a test for reaching the value 0, upon which a message about Ripley’s death is sent. However, since the Health class object does not have a reference to the owning actor, you cannot move this functionality into its drain() method. Therefore, we will add a method onFatigued() to the Health class, which will allow you to register an action at the call site in the form of a block of code (a function) that will be executed at the moment when health reaches the value 0.

Note: Realize that by using a so-called callback you do not automatically implement the Observer design pattern. However, a callback can be used with this pattern in situations similar to the example described here: the block of code passed as a callback is used only at the moment when the event that is to be processed by the observer occurs.

In our case, the callback will be represented by a function without parameters and without a return value. In Java, we need to use a so-called functional interface for this purpose: an interface that has exactly one abstract method. You will create such an interface, named FatigueEffect, containing the method apply(). And since this interface will ultimately be used only in the Health class, create this interface as a nested one directly in the Health class as follows:

public class Health {
    // ...

    @FunctionalInterface
    public interface FatigueEffect {
        void apply();
    }
}

Note: Notice the @FunctionalInterface annotation in the code example above. It is not necessary for functional interfaces to work, but it ensures that an error is raised if the annotated interface does not have exactly one abstract method.

So, after preparing the type for our callback, back to the new onFatigued() method that needs to be added to the Health class. This method will have the following signature:

public void onFatigued(FatigueEffect effect);

In the body of the onFatigued() method, add the object provided in the effect parameter to the list of all effects, which you will create in the Health class. Use a list so that multiple calls to the onFatigued() method can register several fatigue effects on the same Health object.

Then modify the implementation of the drain() method so that after the health value reaches 0, the apply() method is called in sequence on all registered effects.

Note: Do not forget that even in the case of calling the exhaust() method, the actor dies and the callback functions must be called in this case as well. Implement the exhaust() method appropriately so that you avoid code duplication.

Note: In your implementation, ensure that the callbacks are triggered only the first time the health value reaches 0.

Write the argument of the onFatigued() method using a lambda expression:

health.onFatigued(() -> {
    // reaction to drained health
});

Note: The lambda notation is equivalent to the following form using an anonymous class, where directly at the call site of the onFatigued() method we implement the FatigueEffect class with a concrete implementation of the apply() method and at the same time create an instance of it. Such code would look as follows:

health.onFatigued(new Health.FatigueEffect() {
    @Override
    public void apply() {
        // method implementation
    }
});

Note: When implementing Ripley’s reaction to a zero health value, the method cancelActions(Actor actor), available on the scene, may be useful to you. With it, you can cancel all scheduled and running actions associated with the actor that you pass as the method’s argument.

Step 3: Know Your Enemy

In the previous step, you trained Ripley on how to take care of her health, but now the time has come for her to face her enemies. She will recognize them thanks to the Enemy interface.

Also perform all the necessary changes resulting from the implementation of the Alive interface.

This class will be an extension of the regular alien class. The alien queen will have a higher maximum and initial health value than the other aliens, for example a value of 200.

Use the mother image as the animation.

The alien queen has the name alien mother.

Step 4: Lieutenant, what do those pulse rifles fire?

Ripley can now effectively identify enemies, but that will not help her as long as she lacks an effective weapon. Although she would not complain even if we put an ordinary crowbar in her hands, long-range combat is much safer, and for that a good quality firearm is required. Before you equip Ripley with a weapon via the Armed interface, she must undergo express training in handling weapons and ammunition, which will be enabled by the abstract class Firearm and the Fireable interface.

The constructor of the class will have (similarly to the Health class) 2 integer parameters: the initial number of bullets in the weapon and the maximum possible number of bullets in the weapon. For the situation where the initial and maximum number of bullets are the same, also add an overloaded constructor with a single parameter.

The method signatures and their meaning should be as follows:

• int getAmmo() – the method returns the currently available number of bullets.
• void reload(int newAmmo) – the method increases the number of bullets in the weapon by the value defined by the newAmmo parameter. However, the value may increase only so much that it does not exceed the maximum number of bullets in the weapon defined when it was created.

The Fireable interface will be the contract for all actors that can serve as ammunition for a weapon.

In the startedMoving() method from the Movable interface, do not forget to set the correct rotation of the fired bullet’s animation. Set the bullet’s speed, for example, to 4.

Use the bullet file as the animation representing the bullet.

After being placed into the scene, the fired bullet should start moving in the defined direction (the movement itself will be handled in one of the subsequent tasks), and if it hits any object of type Alive, it should reduce its current health value by 15. The bullet then disappears from the scene. Upon collision with walls (solid obstacles), the bullet also disappears.

While a collision with Alive actors can be detected easily using their intersects() method, detecting a collision with a wall presents a problem. Such a collision is "hidden" inside the Move action (which the Bullet class should use for movement), and it cannot be tracked outside its execute() method. Implementing the removal of Bullet objects directly in this method is not a suitable solution, because it violates the single responsibility principle and unnecessarily introduces undesirable dependencies between classes. We will solve the task of detecting wall collisions as follows, and at the same time generalize the solution for all Movable actors.

Add the method collidedWithWall() with a standard (default) empty implementation to the Movable interface:

public interface Movable extends Actor {
    // ...

    default void collidedWithWall() {}
}

This method will represent the event of hitting a wall for Movable actors. Therefore, you need to call it in the Move action when detecting a collision with a wall. By overriding this method in the Bullet class, you can then achieve the desired removal of the projectile from the scene.

Both methods will be parameterless and their return type will be Fireable.

The createBullet() method is reserved for creating an instance of the ammunition intended for the given weapon. It will be abstract and protected because its implementation – creating a specific type of ammunition – will be provided by the concrete weapon.

The fire() method has 2 possible behaviors:

• If the weapon still contains bullets, their number is decremented and the method returns a new ammunition instance created by calling createBullet().
• If there are no bullets left in the weapon, the method returns null.

The constructor should have two parameters corresponding to the constructor of the superclass.

The weapon will fire bullets of type Bullet.

The Armed interface will identify actors who have a weapon (they hold a reference to an instance of a class extending Firearm) and will contain methods for getting and changing the actor’s weapon:

• Firearm getFirearm()
• void setFirearm(Firearm weapon)

Implement this interface in the Ripley class and ensure that Ripley has a weapon (Gun) available immediately after her instance is created.

The Fire action should be usable by actors implementing Armed and should ensure placing a new instance of the ammunition of the used weapon into the scene and scheduling its “infinite” movement in the direction of the Armed actor’s rotation using the Move action. The constructor of the action will be parameterless, since for the implementation we only need the actor on which the action is scheduled.

Note: In the implementation you will need to determine the direction of movement (Direction) based on the actor’s rotation angle. For this purpose, create a static method Direction fromAngle(float angle) in the Direction enumeration, which returns the direction corresponding to the given angle.

ShooterController will have a parameterized constructor with a parameter of type Armed, representing the controlled actor. Schedule the Fire action in the keyPressed() method when the **SPACE** key is pressed.

Step 5: Watch your behaviour!

The main hazard for Ripley in this mission will, of course, be the aliens lurking behind closed doors. However, the event of opening a door will awaken them, which may result in chaos. To prevent the situation from getting completely out of control, your task, cadet, will be to teach groups of aliens to behave appropriately. Preserving one of the main themes of today’s mission, namely composition over inheritance, our tactical and strategic team will guide you through this part using the Decorator design pattern.

Add an enumeration type Orientation with the values HORIZONTAL and VERTICAL to the Door class, which will be used to distinguish the door orientation. Add the door orientation as a constructor parameter and, based on its value, set the correct animation (vdoor or hdoor) for the door.

Note: Do not forget to check whether the way you create a wall at the position of the closed door works correctly for both door orientations. Adjust it if necessary.

Pass the door name as an argument to the superclass AbstractActor constructor.

The interface will have:

• a type parameter (e.g. A), which restricts for which type of actors the given behaviour is applicable,
• a void method setUp(A actor), which receives the actor as a parameter and whose task is to define the behaviour of the given actor.

Use the implementation of random alien movement, which you should already have within the scenario. Generalize the scheduled actions for an arbitrary Movable actor.

Since we want to be able to use behaviours intended for the type Alien and all its supertypes (types from which Alien inherits, e.g. Movable, Alive, etc.), write the signature of the behaviour parameter as follows:

Behaviour<? super Alien> behaviour

Use the obtained reference to the behaviour object in the addedToScene() method, where you will call its setUp() method to configure the given alien’s behaviour.

For the other alien types, for now set the behaviour to null.

Note: Do not forget to cancel the scheduling of random movement for aliens directly in the scenario.

An alien with the type "running" should move randomly. The other aliens should remain stationary.

This behaviour class will serve as a decorator for another behaviour.

Note: The intended usage is as follows: if an actor receives, in this behaviour, a wrapped random movement behaviour, it will first wait for the publication of a matching message and only then will the behaviour that was wrapped be applied.

Since the Observing class will be wrapping, i.e., decorating another behaviour, it will have a type parameter (e.g. A) for the type of actors for which the decorated behaviour will be created. Moreover, since it will also work with some type of message topics, it will have an additional type parameter (e.g. T) for the objects sent in messages:

public class Observing<A extends Actor, T> implements Behaviour<A> {
    // ...
}

The class will have a constructor with the following three parameters:

• Topic<T> topic – the message topic that the actor will observe
• Predicate<T> predicate – a predicate (condition) for checking the received message
• Behaviour<A> delegate – the wrapped behaviour

In the setUp() method, subscribe to the message topic topic, and upon receiving a message, check the condition defined by the predicate. If the condition is satisfied, call the setUp() method of the wrapped behaviour delegate.

Note: The Predicate<T> interface is a standard functional interface intended for testing conditions. It defines a single abstract method test(), whose parameter is of type T and whose return type is boolean.

Note: The intended use of the Observing behaviour can be demonstrated with the following example. If we wanted to define behaviour for an alien such that after an ammo magazine is used (it is removed from the scene), it starts chasing Ripley (assuming we had a behaviour such as ChasingRipley defined for that), we would write it as follows:

new Alien(
    new Observing<>(
        World.ACTOR_REMOVED_TOPIC,  // waiting for message in this topic
        actor -> actor instanceof Ammo,  // verification if magazine was removed
        new ChasingRipley()  // passing behaviour, which was supposed to happen when prerequisite is fulfilled
   )
);

By awakening the aliens, we mean that they start moving randomly.

Use the created behaviour classes to define the behaviour of aliens that have the types "waiting1" and "waiting2" defined in the map. They should react to the opening of the doors named "front door" and "back door", respectively. You, of course, need to define this behaviour already when creating them in the factory class.

The aliens in the individual rooms should start moving after Ripley opens the corresponding doors.

You can represent the end of the game, for example, by displaying some text (e.g. Well done!) in the game’s Overlay layer.