Mission Impossible

Step 1: Welcome to the Real World!

The primary goal of this mission is to teach Ripley how to navigate in a new environment. To achieve this, you need to load a map representing Ripley's environment, along with surrounding, more or less living, actors when creating the game scene.

To make this possible, you first need to create a factory class that your simulation will use to configure the appropriate situation and place the actors in their initial positions as defined in the map. And since the map may contain walls, you will need to teach Ripley to recognize them and avoid passing through them.

The resulting file structure in the src/main/resources/maps directory should look like this:

src/main/resources/maps/
├── tilesets/
│  └── tileset01.png
└── mission-impossible.tmx

Write the map path as maps/mission-impossible.tmx.

The class must implement the SceneListener interface, and the scenario will later be written in the sceneInitialized() method.

This class will represent the Factory Method design pattern, and the class itself will contain only one method, create(String type, String name).

The game map for today’s mission contains objects named access card, door, ellen, energy, locker, ventilator. For now, you can provide instances for Ripley (ellen) and a medkit (energy). For other names, return null from the create() method.

Link the MissionImpossible.Factory instance with the scene instance in the main() method by passing it as the third argument to the [World constructor]<init>(java.lang.String name, java.lang.String mapResource, sk.tuke.kpi.gamelib.ActorFactory):

Scene missionImpossible = new World("mission-impossible", "maps/mission-impossible.tmx", new MissionImpossible.Factory());

Since Ripley is now created through the factory based on her placement in the scene map, do not create a new instance in the scenario. Instead, retrieve the existing instance from the scene.

If implemented correctly, you will see a scene with a map containing a medkit and Ripley. You should be able to control Ripley using the keyboard, and for now, she should be able to pass through walls.

Our tactical team considers the best approach to implement this functionality in the action class responsible for actor movement.

In the map, walls are defined within a layer named walls. This layer is not rendered graphically in the scene, but the information from this layer (filled or empty tiles) is used to create walls in the positions of filled tiles.

Step 2: Alohomora!

When implementing the MissionImpossible.Factory class, you likely noticed that not all the necessary actors defined in the map were available. In this step of the mission, you will create several missing objects. Specifically, you will create doors and an access card, which can be used to unlock locked doors.

During this step, you will also enhance the capabilities of usable items so that they can be used _interactively_—via the keyboard.

The interface will extend the Actor interface and have the following methods:

• void open() - opens the item (actor)
• void close() - closes the item (actor)
• boolean isOpen() - returns true if the item (actor) is open, otherwise returns false

Doors will be usable with any actor, so use the Actor type as the type argument for Usable. For the current mission, we will need vertically oriented doors, so use the image vdoor as the animation.

The doors will be closed by default. When used by an actor, the doors should open if they are closed and close if they are already open.

Our tactical and strategic team believes the best way to block closed doors is to create a wall in their place on the map. When the doors are opened, the wall should be removed.

Gamelib

All walls in the game map are defined in the walls layer, which you’ve already seen in the image above. When working with the Tiled editor, maps are created using tiles that, in our case, are 16x16 pixels in size. Each filled tile in the walls layer represents a wall.

In the object representation of the map, we also have tiles available. Each tile covering the map has its own x and y coordinate, representing the tile's position along the x and y axes, with the origin of the coordinate system in the bottom-left corner of the map. The tile at this location has coordinates [0, 0].

You can get a specific tile using the method getTile(int tileX, int tileY) on the map object. This tile is of type MapTile and, in addition to its position and dimensions, you can check if the given position in the map is considered a wall using the isWall() method. Finally, you can change the tile's type using the setType() method to one of two values from the MapTile.Type enumeration:

• CLEAR - the location of this tile is passable,
• WALL - the location of this tile is considered a wall.

Doors should appear in the scene, and Ripley should not be able to pass through them into the smaller room.

In the next task, you will add support for planning the Use action via the keyboard. The use case scenario is as follows:

1. Ripley approaches doors that implement the Usable interface.
2. By pressing an assigned key, the player signals their intent to open the doors.
3. The Use action is planned so that the doors are used with Ripley.

Another use case scenario, which you will implement later, is as follows:

1. Ripley, with an access card in her backpack, approaches locked doors.
2. By pressing an assigned key, the player signals their intent to use the item at the top of the backpack.
3. The Use action is planned so that the access card (item from the backpack) is used with the locked doors (item in the scene colliding with Ripley).

Due to the limitations of the JVM platform, it is not possible to work directly with types represented by type parameters during program execution (these exist only during compilation). Therefore, the getUsingActorClass() method being added will explicitly return the runtime representation of the actor class with which the usable item can interact. This class representation will be used in the next task to find a compatible actor (an actor that is an instance of the given class) with which the Use action can be planned.

The new method in the Usable interface should have the following signature:

Class<T> getUsingActorClass();  // T represents type parameter in Usable class

In every usable actor that specifies a concrete type of compatible actor for the type parameter of Usable, return a reference to the runtime representation of the compatible actor’s class from this method. For example, in the case of the hammer (class Hammer), which is usable with a reactor, the implementation of this method would look as follows:

public Class<Reactor> getUsingActorClass() {
    return Reactor.class;
}

This method is necessary in the Use action class because we need to find the first compatible actor on the scene in collision with the mediating actor (primarily Ripley) in a context where the type system of the language has access to the type argument of the Usable object. This will allow us to interactively schedule the Use action in response to a key press in the next task.

Assuming you have a functional implementation of the Use action, where the member variable usable represents the usable actor passed to the constructor of the action and T represents the type parameter of the action, this method can be implemented as follows:

public Disposable scheduleForIntersectingWith(Actor mediatingActor) {
    Scene scene = mediatingActor.getScene();
    if (scene == null) return null;
    Class<T> usingActorClass = usable.getUsingActorClass();  // `usable` is the aforementioned member variable

    for (Actor actor : scene) {
        if (mediatingActor.intersects(actor) && usingActorClass.isInstance(actor)) {
            return this.scheduleFor(usingActorClass.cast(actor));  // plan the action if we find a suitable actor
        }
    }
    return null;
}

public Disposable scheduleForIntersectingWith(Actor mediatingActor) {
    Scene scene = mediatingActor.getScene();
    if (scene == null) return null;
    Class<T> usingActorClass = usable.getUsingActorClass();  // `usable` is the aforementioned member variable
    return scene.getActors().stream()  // get stream of actors at the scene
        .filter(mediatingActor::intersects)  // filter actors which are colliding with provider
        .filter(usingActorClass::isInstance) // filter actors which are of comatible type
        .map(usingActorClass::cast)  // retype the stream of actors
        .findFirst()  // select first (if exists) actor from stream
        .map(this::scheduleFor)  // call method `scheduleFor` with found actor and receive `Disposable` object
        .orElse(null);  // if there are no suitable actors found return `null`
}

When the U key is pressed, schedule the use of the first found usable item in collision with the controlled actor. The controlled actor will then act as an intermediary to find the compatible item using the added method scheduleForIntersectingWith().

(Usable<?>) actor

If done correctly, Ripley should be able to open the doors she approaches by pressing the U key.

The security lock can only be removed by using the correct access card, which you will implement in the next task. After unlocking the door, it will be possible to open and close it just like a regular door.

In the class, implement the following methods:

• void lock() - lock (and also close) the door,
• void unlock() - unlock (and also open) the door,
• boolean isLocked() - returns the current state of the door – whether it is locked or not.

This card will implement the Collectible and Usable interfaces and will be usable with the locked doors LockedDoor. Using the card will unlock the locked door.

The animation representing the access card is stored in the file key.

When the B key is pressed, schedule the Use action on the item on top of the backpack if this item is usable. Again, use the controlled actor as an intermediary to find a compatible actor nearby on the scene.

Verify that using the U key, it is no longer possible to open locked doors, and that these doors will open when Ripley takes the access card into her backpack and uses the B key after approaching the door.

Step 3: Missing Items

For completeness, the actors defined in the map still lack the locker and the ventilator. You will create these in this step. We will also need to expand the repair capabilities of the hammer (hidden in the locker) to work with any repairable item.

class diagram: A class diagram showing the position of the Locker and Ventilator classes. [Locker{bg:cornsilk}]-^[<>;AbstractActor] [Ventilator{bg:cornsilk}]-^[<>;AbstractActor] [Ventilator]-.-^[<>;Repairable] [Locker]-.-^[<>;Usable]

Don't forget to also change the class returned by the method getUsingActorClass(). Just like you return Reactor.class, you can also return the runtime representation of the Repairable interface as Repairable.class.

The hammer will be found by having it fall out of the locker as soon as Ripley examines the locker. The locker should be usable only once, so Ripley will get only one hammer by examining a single locker.

The animation representing the locker is stored in the file locker.

The animation representing the ventilator is stored in the file ventilator. Since the ventilator starts as broken in the scene, initially stop the animation playback. In the repair() method, represent the repair of the ventilator by starting the animation playback.

Step 4: Entering Contaminated Zone

We are entering the final phase of today's mission. The goal is to repair the broken ventilator in the contaminated zone, thus eliminating the danger of contamination. In completing this step, we will demonstrate how to use messages to respond to emerging events, utilizing the Observer design pattern.

Various parts of the game (other actors, your code within the scenario, etc.) might want to react when certain doors are opened or closed. We will enable this by creating message topics with a defined message type (the type of object that will be sent in the specific topic) and publishing the message (the specific object of that type) to the message bus in the scene. For doors, the message type will naturally be Door.

You will create message topics using the factory method Topic.create(), where the first argument is the name of the topic and the second is the type of the object sent in the messages.

Since we want to access the topics without needing a reference to specific doors, implement them as static member variables in the Door class. The topic for opening doors could look like this:

public static final Topic<Door> DOOR_OPENED = Topic.create("door opened", Door.class);

Similarly, create a topic for closing doors.

In the open() and close() methods of the door, publish a message indicating which door was just opened or closed. Use the publish() method on the scene's message bus MessageBus, which you can retrieve via the getMessageBus() method.

The message bus MessageBus has the method subscribe(Topic<M> topic, Consumer<M> listener), which allows us to subscribe to receive messages published within a specific topic. The first argument is the topic object, and the second is a lambda expression (or a functional interface object of type Consumer) with a single parameter—the object sent within the specific message.

Subscribe to the message topic Door.DOOR_OPENED and react to the door opening by scheduling an action to reduce Ripley’s energy.

Note: Handle the energy reduction at a suitable interval so it does not happen too quickly, giving Ripley time to complete the mission.

After the door is opened, Ripley’s energy should start decreasing.

Use the play mode Animation.PlayMode.ONCE for the animation. Name the created message topic RIPLEY_DIED.

Modify the scenario implementation to cancel the listeners for the mentioned controllers when the death message for Ripley is received, preventing further control of Ripley.

This task should also be addressed by creating a message topic for the ventilator repair (named VENTILATOR_REPAIRED). In response to this message, stop the scheduled energy reduction for Ripley in the scenario.

Note: Keep in mind that variables defined within a lambda are not visible outside the lambda, and you cannot assign objects to local variables defined outside the lambda within the lambda itself. Local variables captured in a lambda are considered effectively final.

After the ventilator is repaired with the hammer, Ripley’s energy should stop decreasing. If she fails to repair the ventilator before her energy reaches 0, she should no longer be controllable.