And... Action!

Step 1: Similarity (not) entirely coincidental

Cadet! Do not doubt that the origin of hammer Mjolnir is definitely extraterrestrial, and although it abounds with superhuman power, it has some common features, whether one likes it or not, with fire extinguisher. It can be used and breaks after some time. This similarity can be transformed into usage of inheritance in your implementation, which can reduce repeating code.

Generalized implementation of a tool that can wear away includes tracking the number of remaining uses (this is the state) and updating this number on each actual usage (this is the behaviour). To achieve this, add the following to the class BreakableTool:

• Instance variable remainingUses for amount of remaining uses. It should be available outside the class only for reading and it should be inintialized in parametrized constructor.
• Method use() for decreasing number of tool's remainig uses and its removal from the scene once the number reaches 0 (the tool wore away and broke).

Edit constructors of these classes. Now that the parent class contains only parametrized constructor, you need to call it with the help of the super keyword.

Do not forget the purpose of the generalized implementation of BreakableTool class and update implementations of Hammer and FireExtinguisher classes to maximize usage of the inherited functionality.

The number of classes in the project is increasing. To maintain order among them and group related classes together, create new package tools in package sk.tuke.kpi.oop.game and move class BreakableTool, Hammer, Mjolnir and also FireExtinguisher in there.

Step 2: Self-exploding reactor

Until now you could work with reactor only manually - you could turn it on and off, and increase and decrease its temperature by calling appropriate methods through Inspector. In this step you will make some changes to make reactor work independently. We will use a system of actions for that which will represent activity or behaviour of actor in a game scene.

As you can see in the class diagram above, new class of action PerpetualReactorHeating should inherit from class AbstractAction. AbstractAction is available in the library package sk.tuke.kpi.gamelib.framework.actions.

The class AbstractAction uses type parameter A which defines the type of actor, with which the action should be possible to execute. Since the action should increase temperature of a reactor, set Reactor as its type argument:

public class PerpetualReactorHeating extends AbstractAction<Reactor> {

}

public abstract class AbstractAction<A extends Actor> implements Action<A> {
    private A actor;

    @Override
    public A getActor() { return actor; }

    @Override
    public void setActor(A actor) { this.actor = actor; }

    /* ... the rest of the class ... */
}

When implementing method execute(), obtain reference to actor with which the action is executing (it will be some reactor) and increase its temperature by value specified as parameter of action's constructor.

Since actor needs to know which scene it belongs to when scheduling an action, the right place for scheduling the action can be method addedToScene() inherited from class AbstractActor which obtains reference to scene in parameter (type Scene) and is called right after the actor was added into the scene. Therefore, it is necessary to override method addedToScene(). Do not forget, however, that we still need to execute the original implementation of method addedToScene() from class AbstractActor, and so use keyword super to call the inherited implementation!

Scene defines method scheduleAction() which receives action and actor with which the action should be later executed. Scheduling execution of action in reactor's method can look as follows:

// in method addedToScene of class Reactor
scene.scheduleAction(new PerpetualReactorHeating(1), this);

Our tactical and strategic team, however, designed also a complementary method scheduleFor() available directly on object of action, which receives object of actor and provides the same functionality as method scheduleAction() on scene, but with somewhat clearer notation:

// in method addedToScene of class Reactor
new PerpetualReactorHeating(1).scheduleFor(this);

Disposable scheduleFor(A actor) {
    return actor.getScene().scheduleAction(this, actor);
}

If you proceeded correctly, a reactor that is turned on should gradually increase its temperature, what you can also verify by using inspector.

Step 3: How cool is cool enough?

Now when the first step towards autonomous reactor is behind us, it surely has not escaped your attention that basically only for calling one method of reactor a whole new class was created. We will try to solve this shortcoming of initial implementation one step after the other.

The adjustment made to reactor in previous step has a little catch though - by letting reactor work independently it will systematically overheat. And overheating, as we know since year 1986, will inevitably lead to its permanent damage. To avoid such situation, instead of hammers you will create a cooler which will cool reactor down systematically.

Behaviour of cooler and its relationship with reactor is described by the following class diagram:

Use file fan as animation for cooler. When cooler is turned off, pause its animation. Otherwise when cooler is turned on, play its animation. You will find appropriate methods on object of animation to control it.

You can name this method e.g. coolReactor(). Every time it is called (when cooler is turned on) temperature of connected reactor should decrease by one degree.

For calling a method within action it is not necessary to create whole new class of action which will then serve only one very specific purpose. Instead of implementing a new action class we will use action Invoke (available from GameLib library), with which we can define activity of an action (method execute()) also by reference to the method that implements the required behaviour.

We can implement the action and its scheduling as follows:

// in method addedToScene of class Cooler
new Invoke<>(this::coolReactor).scheduleFor(this);

This action, however, will not meet our expectations: method coolReactor() will be called only once and after that it is considered finished (isDone() will return true). We can achieve repeated execution of action by composing Invoke with action Loop (available in GameLib), which simply calls another action given as an argument to its constructor and is always considered not completed (isDone() of action Loop always returns false):

// in method addedToScene of class Cooler
new Loop<>(new Invoke<>(this::coolReactor)).scheduleFor(this);

The more coolers you connect with reactor, the sooner will reactor be cooled down. Beware, however, that reactor cannot be cooled to negative temperature.

Step 4: Defective Light

Our analytic team defined defective light as light which is defective. Since we can assume that defective light was all right at first, we can derive its behaviour from the well-functioning light. In this case, the defectiveness will be manifested by blinking of light at irregular intervals.

To achieve the effect of defective light you can use any approach you like. One of them could be e.g. generating random number in range from 0 to 20 and if the generated number is 1 the state of light will change from off to on and vice-versa.

Remember that type of parameter in method addLight() in class Reactor needs no change. The principle of polymorphism is used right here: DefectiveLight as descendant of class Light can be used wherever type Light is accepted.

Step 5: Repository

Upload your implementation even if it's not yet complete. We recommend to comment out parts of the code that could cause compilation errors.