Fear of Corn

The last few posts have walked through Basic Interactables and Physics Objects, two-thirds of the available interaction types in Interference. However, there is a third distinguishable type of interactive object known as Focusables. Let’s check them out!

Focusables

Focusables, perhaps, involve the most complex set of interactions available to the player. Not to be confused with Basic Interactables, these objects require the player to engage with them before interaction can occur, and the interactions are specifically tailored to each object.

At the outset, Focusables seem relatively simple: “focus” on the object to use it and “de-focus” from the object to return to the game. However, it’s within that focus where interaction becomes complicated, as each object has its own set of usage requirements, many of which are intrinsic to the core gameplay of Interference.

All the critical elements of Interference are Focusable objects: the radio, the map, and the computer. Each one of these objects necessitates different sets of actions to, well, play the game, as well as dispenses the information needed by the player to engage with the narrative; the radio provides the interface for communicating with your trapped friend, the map gives you the necessary spatial information of the facility she is trapped in, and the computer clues you into the dangers lurking around every corner.

The other Focusables, while not as critical to the immediate narrative, give a greater sense of the world of Interference. CCTV monitors give you external views from your desert outpost, a TV and VCR tune you into 80s-era programming, memos and other scraps of paper provide insight to the lives and personalities of your coworkers. And the linchpin to the entire experience? The book of wordsearch puzzles lying open on the desk.

It’s difficult not to talk about the wordsearch (after all, it’s a featured object in our teaser trailer). While the object itself doesn’t necessarily differentiate itself from the myriad of other distractions scattered around the guard booth, its presence as a Focusable object is representative of the kind of game we set out to make. It was one of the first interactions Brad and I conceptualized when we started talking about player autonomy: give the player something else to focus on (ha), and maybe they’ll forget (or want to forget) about the life-threatening situation playing out through the crackling speakers of the radio.

Even though the functionality of each object may vastly differ, all Focusables share the same set of properties:

1. “Using” the object requires that the player is focused on said object
2. The player cannot move freely while using a Focusable object
3. The player must “exit” the Focusable to return to the play-space

Let’s focus on the facility map, for example (ha, again) to see these properties in action.

The Map

The facility map available to the player in Interference is one of the most important objects in the game. Walking through the above steps, let’s see how interacting with the map plays out:

1. The player clicks on the map, and the camera zooms into the map for a closer look
2. The player cannot move freely while using the map but can do the following:
   • Move the camera around the surface area of the map by moving the mouse
   • Pick up, move, and place pushpins on the map by clicking and moving the mouse
   • Zoom into the map even closer by pressing the spacebar
3. The player right-clicks to exit the map and return to the play-space

While Basic Interactables and Physics Objects are important to the overall experience of Interference, Focusables do much of the heavy lifting through their contribution to gameplay and story.

Next time, we’ll put everything together and wrap things up with some final thoughts. Until then!

Interference is chock-full of interactive objects. Last time we talked about Basic Interactables (objects that accept an input to perform a specific task) and our methodology behind ascribing functionality to interactive objects. Today, our topic is much simpler: we’re gonna talk about Physics Objects!

Physics Objects

Physics Objects provide a straightforward interaction to the player: pick up and drop. In a sense, Physics Objects are just another implementation of Basic Interactables, the key difference being that these objects aren’t specifically used to perform a task—they simply exist, waiting for a task to be performed on them.

But the binary choice of picking up and dropping an object does not encompass what it’s like to manipulate objects in the real world. Objects can be moved. They can be inspected at all angles. And most importantly, they can be thrown. And in Interference, the same is true.

There isn’t much to talk about regarding the implementation of these actions. Unreal Engine’s physics engine does much of the heavy lifting in terms of simulation. We merely provide the input schemes and applied forces behind tossing your favorite mug at the wall. However, when accounting for player variability in the way these objects are manipulated, we must keep a few things in mind:

1. How do Physics Objects interact with other objects?

There are two ways of interpreting this question. A Physics Object colliding with another object will do just that: collide. This collision might result simply in the Physics Object bouncing back. If the Physics Object is breakable, it might break. If the collided object is also a Physics Object, both objects will exert their forces on each other. These collisions are all handled by the engine.

But what about objects that are for other objects, like a key? A key can’t be a Basic Interactable since it needs to be manipulated by the player and moved to its corresponding lock to trigger an interaction. These Physics Objects are given additional functionality and are designated as an Object-for-Object (or OFO), a subset of Physics Objects that make up a small number of items in the guard booth.

OFOs are told what object they are for, and from there a collection of generic functions determine whether the OFO is in position to trigger an action on the receiving object. As per our method of anticipating intention and breaking down tasks into their fundamentals, we don’t belabor the player with nuances such as twisting the key. Once the key overlaps with a lock’s collision box, it automatically snaps into place and opens the lock.

2. How do Physics Objects stay within reach of the player?

I’m glad you asked! All our Physics Objects share a parent class that defines common characteristics of all Physics Objects. One of these variables drives the size of the object’s sphere of influence. If the player character is inside one of these spheres, then the interaction system knows that object is available for interaction.

To keep objects within the reach of the player at all times is as simple as making sure that the sphere radius is large enough for all situations in which another object (like the desk) may impede the player’s reach. But that’s not enough; since objects in front of another object take precedence in our interaction system, if an object is fully blocked by another object—even if the player is within its sphere—the player won’t be able to interact with that object.

We try to place objects in such a way that these blockages cannot occur. However, there are a few places objects can still go that need a bit more attention. To be honest, we haven’t spent much time addressing these interaction-voids since we’ve yet to lock down the final placement of objects, but the intent is that angled collision planes with low friction will be placed in these locations to gently encourage objects that find themselves there to slide into view of the player.

It is important to note that due to the inherent unpredictability of physics engines, we determined that no Physics Objects will be needed to engage with the narrative components of Interference, so any solutions to the blocked object issue are primarily to decrease player frustration rather than preventing situations that break the experience completely.

3. What happens if a Physics Object “breaks”?

If a Physics Object decides to rebel against our carefully crafted safeguards, your computer will crash and all your files will be erased.

Just kidding! (At least that’s not supposed to happen. We are not liable if it does.)

There are situations where the physics engine will perform erratically. Objects may clip through other objects, get stuck inside geometry, or warp through walls. We’ve done what we can in both the physical and conceptual design of Interference to mitigate any issues, but in a game that takes a sandbox approach to the play-space, the unexpected is, quite frankly, expected.

As mentioned above, no Physics Objects are required to engage with the narrative experience of Interference. However, as an experiment in player autonomy, it’s important that these non-critical elements are functional so that any approach in playstyle is treated fairly. If you don’t want to help your friend Valerie escape, that’s fine. And it shouldn’t feel as if we cut corners on the non-narrative components of Interference to allow for such a thing, because doing so would be antithetical to the entire purpose of the game. Even if it’s supremely hilarious when something like this happens:

Physics Objects comprise most object types found around the guard booth in Interference. Books, writing utensils, BERF balls, you name it! All can be moved around the space completely at the player’s discretion, and as we continue to develop Interference, great care is being taken to make sure these interactions behave properly.

On the next post in this series, we will talk about the third and final type of interaction: Focusables.

Video games exist on a bedrock of player interaction. But have you ever been absorbed in a game only for that engagement to be compromised by questions like, “why can I open this door but not that door” or “why can’t I look at this object closer”?

Interference is a game that experiments with player autonomy, and we knew early in the design process that constraining the playable area to a single room would necessitate heaps of interactive elements to successfully conduct said experiment. And it became clear fairly quickly that we would need to address those types of questions above or risk pulling the player out of the experience altogether.

Long story short: yes, you can interact with virtually everything in Interference.

We spent months prototyping interaction systems before settling on the one we are currently using. The first implementation completely broke our game and sent us straight back to the drawing board, and even now, we are continuously modifying and refining the current system to feel cohesive, yet expansive enough to cover the many “types” of interactions we’ve scattered throughout the guard booth.

Objects are broken into various categories to provide a framework for how we assign interactivity. This classification affords us the ability to create generalizations for how the player interacts with that object; through the use of parent classes, we are able to make an adjustment to one interaction type and have those changes reflected in every object of that type. For the player, categorizing these objects provides a shorthand understanding for how an object will work and what control scheme to expect.

Over the next few weeks, we will talk in-depth about the various “types” of interactions Interference has to offer: Basic Interactables, Physics Objects, and Focusables. Let’s start with Basic Interactables.

Basic Interactables

Interactive objects in their simplest form accept an input to perform a specific task. Some simple examples:

• Light switches: turns lights on and off
• Doors and drawers: can be opened and closed
• Cactus: can be touched

Basic interactivity can be expanded on to create seemingly more complex interactions based on object states and external factors. For instance, objects that use electrical power in Interference cannot be turned on and off during power fluctuations or outages.

In any interaction, we break down what the fundamentals are for that interaction in reality to create a shorthand version for use in-game. Intention becomes important in crafting these simplified representations. Take our coffee system for example.

How does one use a coffeemaker in real life? Well…

1. Water, filter, and coffee grounds go into the coffeemaker
2. A button is pressed to brew the coffee
3. Coffee is poured from the carafe into a mug
4. The coffee is consumed

This process is one that’s ingrained into our daily lives; we don’t often have to think about the steps in the coffee-making process. However, while pouring a liquid from a carafe to a mug is generally a task that requires very little thought in real life, transferring that interaction to a video game is not so simple. All of a sudden you’re dealing with liquid simulation, multiple objects, and the need to replicate the motor skills necessary to delicately pour scalding hot liquid into a mug. Not to mention, what if the mug overflows? Does it burn the player? Do we let the player pour coffee on everything in the booth?

And the questions cascade. Believe us, we’d love to allow for such complicated interactions as soaking books with coffee, but we’ll leave that for real life. With the added layer of screen and controller, performing these steps becomes a clunky, complicated ordeal (VR perhaps eliminates this issue, but that’s a whole other story). Generally, we keep interactions self-contained, which is beneficial to both us (we want to, ya know, finish the game) and the player (through setting simple expectations for how objects work).

So, how do we approach the coffee-making process in-game? First, we distill the above steps down into its fundamentals of intent:

1. Brew coffee
2. Drink coffee

Then, we break down how best to represent each fundamental step:

Brew Coffee

If the carafe is empty and power is stable, interacting with the coffeemaker will simply brew coffee. While the coffee is being brewed, the player cannot interact with the coffeemaker.

Drink Coffee

Once the coffee is brewed and the carafe is full, interacting with the coffeemaker will allow the player to drink coffee (assuming there is at least one unbroken mug left in the booth). While the player is drinking coffee, player input is disabled. The level of available coffee lowers until the carafe is once again empty.

The rest of the process is simply represented by objects that can be found in the booth: a coffee tin, coffee filters, and mugs.

By breaking down complex processes into simple, straightforward interactions, we are able to quickly add all sorts of interactivity throughout the booth. However, Basic Interactables are merely one classification of interactivity; we are only scratching the surface on the depth of interactivity Interference has to offer.

Next time, we will talk about our next type of interaction: Physics Objects.