Finding Humor In The Horror

One of the very first things we discussed when brainstorming ideas for Interference: Dead Air is how we can combat scope creep early on by establishing a single room where the bulk of the game will take place. This was largely the genesis of the guard booth setting from which the rest of the game came to fruition. But from the start, we knew that if the game was going to be set in a single room, the onus would be on us to make it interesting. So… how do we do that?

First and foremost, we established a narrative guideline of depth of space. In lieu of having huge, sprawling maps with content spread out, we focused on densely packing lots of details in the guard booth to make a space that feels real. The story is focused on a few key characters, but there are numerous characters who we get glimpses of via memos, journals, sticky notes, and personal belongings scattered throughout the booth.

Whoever had the idea to bring this to work is my kind of coworker.

These characters don’t have speaking roles and they don’t appear physically in the game, but we wanted their presence to be felt. For every item we placed in the booth, we considered a number of questions about its in-universe origin. Who does it belong to, and how did it end up in the booth? Is it relevant to the relationships its owner has with the other booth occupants (both friendly and antagonistic)? Does it tie into any of the lore details we’ve introduced via readable items? The hope is that the result of these considerations is a game world where exploration is rewarded by learning new details of that world with every playthrough.

But with all these environmental details occupying this space (a space primarily designed as a stage to tell our game’s story), an interesting conundrum arose.

One of Jared’s notes on the design of this packaging was to make the crackers “more wet.”

How do we balance the tone of these environmental details with our central narrative? Interference: Dead Air is at its core a narrative-driven thriller game. Tension and dread are a big part of the experience. So what role do these environmental details play in that? Does the fact that many of these details utilize humor cut the tension? Possibly! Is that a problem? We don’t think so!

The truth is, dumb jokes are also at the core of Interference: Dead Air, and a major part of our creative process. Something we discovered early on is that comedy and dread are not mutually exclusive, and utilizing environmental details to inject humor into the game allows the player to engage with it as much or as little as they want to. Someone who wants to focus on the main narrative can ignore it completely, whereas someone who does explore the booth might discover unexpected juxtapositions in the tension of the gameplay and the humor of the environment. Perhaps a joke that reads one way at the start of the game hits a little differently when the intensity starts to ramp up.

Like with so much else in those early brainstorming sessions, it all came down to wanting to create a game where the player’s choices affect the experience and where multiple replays are rewarded. We hope that players will have half as much fun discovering these environmental details as we had crafting them. And if the process of discovering them all results in at least one audible groan or visible eye-roll, we’ll know we’ve done our job.

Why the 80s?

A question I often ask myself as I lie awake at night in a cold sweat thinking about Interference: Dead Air is… why is our game set in the 80s? I wasn’t alive, at least according to my birth certificate, and unless Brad has been lying to me all this time, neither was he. Seems peculiar then that we’d choose a time period that we have no frame of reference for, right? WRONG!

Well… still actually kind of right. We set the game in the late 80s to give ourselves a little bit of leeway to dip into the early 90s when it came to aesthetics, but the fact of the matter remains that neither one of us has any authority over what it was like to be pushing our 30s, like the characters in our game, during that time. And even though we both can remember an age before the internet, I at least was more preoccupied with school picture day than the existential dread that comes along with the search for belonging in an ever-changing, chaotic world.

So, back to the question: then why the 80s?

Well, believe it or not, Interference: Dead Air was originally conceived to take place in a not-so-distant future. Our setting of a remote outpost in the desert felt timeless, and imagining what we could do from a story perspective in a year that hadn’t come yet was more exciting than the prospect of sinking a ton of time researching a bygone era. It wasn’t until we started developing the mechanics of the game that our philosophy changed.

You have to remember, 2021 was the not-so-distant future when we drafted the base concept in 2018. A few other details have since changed as well. Spoilers redacted.

We knew fairly early what our three primary mechanics were going to be: talking over a radio, using a map to track locations, and utilizing a computer to reroute power… none of which require any cutting-edge technology. In fact, the complications of modern tech and communication methods were really the catalyst that forced us to reconsider when the game takes place. This is a common problem Brad and I have both encountered with our background in film: cell phones and the internet complicate everything. And if the game is set in the future, the technological abilities would be even more advanced. Writing around those possibilities was beginning to feel contrived as our story began to take shape.

On top of that, there’s a sense of nostalgia that comes with setting a story in the past, and thematically that felt more appropriate. So much of our game’s narrative is centered around the friendship between the player character and their best friend, Valerie. That relationship itself is tied to a long and storied past, rooted in “better times” and a fondness for how things once were. The future couldn’t afford that.

So, we dove in and did that research that we had been trying to avoid. And you know what? What a treat! We learned so much about the past culturally, politically, socioeconomically, and many other words ending with “-lly” that it gave us a new perspective on where the world was at when we entered into it. I’ve since become obsessed with 80s movies. And Brad? Well, let’s just say I’ve given up on talking him down from exclusively wearing parachute pants.

“Interference: Dead Air” beta and more!

Booth B awaits you. The B stands for Beta. Actually, it doesn’t. Who are we kidding?

Yikes. It’s been nearly a year since our last blog post. Insert stereotypical “we’ve been working hard on the game” excuse here. Which is the truth. Can’t subvert that cliché.

So as we wrap up the year, we wanted to take a brief moment to update y’all on what’s going on over here in the scary cornfields.

Living vicariously

We are pleased to at long last officially announce our partnership with V Publishing. We joined up with them a while ago, and they’ve been steadfastly toiling away at spreading the word about Interference: Dead Air out over the airwaves. Or… internet-waves? Honestly, we’re not really sure how the internet works, but we do know how V Publishing works: pretty darn good. Our little game will reach a much larger audience than it would without them, and when we were going around our dinner tables at Thanksgiving a few weeks ago, we all expressed gratitude that they chose to be by our side for this adventure (and that Nanna made an extra batch of stuffing this year).

Living epically

We are also thrilled to announce that we have received an Epic MegaGrant for Interference: Dead Air. The MegaGrant program from Epic Games provides funding to projects that are doing cool things with Unreal Engine, including small teams of indie game developers like us! We can’t thank Epic Games enough (nor Nanna for that extra batch of stuffing) for this additional support, which has provided a boost to development as we get closer to release and has ensured that we have everything we need to get Interference: Dead Air as close as possible to the vision we had for it when we first started working on it all those years ago.

Living beta…ly?

We’re running out of words to express our excitement, but lastly, we are ecstatic to announce that we are running a closed beta with V Publishing that you can sign up for RIGHT NOW. What more is there to say? Shoot our PR contact Liana an email to request access.

And that’s it! See you all in 2022.

Developing a Video Game With Life on Pause

2020 wasn’t all bad. Here’s to more to get excited about in 2021!

It’s strange to think back to the start of 2020 and put into perspective how the year went in terms of the goals I’d made for myself as a game developer. It was (from my perspective at the time, at least) a pre-COVID world. We were working on a demo to showcase at DreamHack Anaheim in February (see our recap post here). We didn’t realize at the time that it would end up being one of the last mass gatherings to occur in the United States before the shutdowns began.

A Brave New World

When COVID did shut everything down, everything was uncertain. Would it slow down development on Interference? Would the extra time make me more productive? More than 9 months later, I still don’t really know how my productivity output would’ve been different if everything had proceeded as normal.

But what I do know is that when it seemed like life outside of my apartment was put on pause, having a project like this to occupy my extra time at home turned out to be a great thing.

There are only so many hours in a day, and it had been a bit of a struggle at times to balance a full-time job, a social life, and a project of this scale. But with things like commuting, going to the gym, getting drinks and dinners with friends and coworkers all off the table for the time being, I found more time in my day to work on Interference without it consuming every minute of free time I had. It brought structure to my life when I really needed it, and it didn’t come at the cost of burning me out in the long run.

Keep On Keeping On

But that’s not to say this year has been easy. It can never be understated how much this pandemic has affected all of us, and will continue to affect us for the foreseeable future. People have lost loved ones and have had their lives upended. I’m so grateful to be healthy and in a position where I can look back and find a silver lining in all of this. I recognize this has not been everyone’s experience.

I’m also very grateful to continue to have a full-time job that I enjoy. It enables me to support myself and allows me the freedom to pursue game development in my spare time. But when you spend the entire workday and a good portion of your time on nights and weekends sitting in the same chair in front of the same computer screen, avoiding burnout is really hard. There have been days this year where I struggled to resist the temptation to just turn my brain off at the end of a long workday. But as a whole, I’ve managed to keep up the momentum. We’re making tangible progress on Interference every day, and we have lots of new and exciting things in store for 2021. This year was difficult, but it didn’t defeat me.

As I’m sure many others are, I’m hoping for a better 2021. Eventually life will be un-paused and we’ll all need to adjust to getting back out there. But as long as I’m going to be spending more time at home, I’m grateful to have Interference as an outlet to keep me sane through it all.

Inter-ference-view with Brad, Co-founder & Developer

I’ve been working with Jared on Interference for a long time now, but it’s not every day I really take the time to step back and think about what a journey it’s been to get to where we are today. Doing this developer interview was a great way to reflect on everything from the moment we first decided to make a video game (spoiler alert: it was on a bus to Six Flags), to how the themes of the story we’re telling still resonate with us today.

I hope that this video gives you a unique insight into what drives me to work on this game every day. If not, Jared will have forced me to get out of bed to do this interview on a Saturday morning for nothing.

Thank you, DreamHack!

Having never so much as attended a gaming conference, finding out that we’d been selected to exhibit Interference at DreamHack Anaheim was equal parts exciting and terrifying. It meant that a bunch of people would have a chance to experience the game we’d been working on for nearly 2 years for the first time, and it also meant that we’d have a little under 2 months to whip up an updated demo and handle all the logistics of setting up a booth on the other side of the country. So, okay, maybe it was slightly more terrifying than exciting.

But once we had everything wrapped up and we arrived in Anaheim with our demo and all our booth decor in tow, the excitement really took over. Neither of us are particularly outgoing, but it quickly became surprisingly easy to shed that anxiety and talk to people about the game. Seeing the interest in people’s faces when we gave the elevator pitch and getting their genuine positive feedback to playing the demo really helped to break down some of the imposter syndrome we’d been dealing with along the way. Huh, okay, so people do actually seem to enjoy playing this game, maybe a few people actually will play it when we release it!

Perhaps the most rewarding part of the whole experience was meeting other devs and learning more about their projects and processes. We’d come to learn from Twitter and Discord that indie game development is a strong and supportive community, but getting to experience that in person with a bunch of other devs all dealing with the same anxieties and successes that we’ve been experiencing the last 2 years really made that clear. And on top of that, every single game we saw or played impressed in some way. We’ll give a special plug to some of our booth neighbors — Chromatose, Adventures of Chris, and Inscryption will all be day one purchases — but we can honestly say that if any of the DreamHack Anaheim Indie Playground games catch your attention, check them out because they are all worth playing.

When it was all said and done, we were both thoroughly exhausted, physically and mentally, and we’re both still getting our sleep schedule back on track a week later. But I don’t think either of us would trade that experience for all the rest in the world, and we’re so thankful that we had the opportunity to go out there and preview Interference to the world. Here’s hoping it won’t be the last time!

The Interference demo in action!

And if you’d like to experience Interference, check out our Steam page and wishlist the game for updates! Who knows, there may be a new demo in the future…

Building a Virtual Security Booth: Intro and Modeling

Creating a 3D game asset is not all that different from creating a physical object in the real world. The skills and labor required don’t line up perfectly (you’re more likely to develop carpal tunnel than lose a finger, just as one example), but there’s more overlap there than one might think.

This series of posts will go through our workflow for creating 3D assets from the ground up. I’ll mention the tools and services we use in each step, but won’t get too bogged down in technical specifics. Instead I will focus on the thought process and theory behind each step, which can be applied to any pipeline or workflow.

To kick things off, we will look at modeling a 3D object. We use Blender for this step of the process, and the deliverable will be one or several FBX files with all the data we need for our next steps.


Before we even open our 3D software, the first and arguably most critical step is to research what exactly it is we want to make. We have a lot of flexibility and artistic license when creating things to populate our game’s world, but it’s still important to keep real world dimensions and design standards in mind, since inconsistencies across objects can be very noticeable when playing the game.

Modeling a pen based on a reference photo. We considered several different pen styles before landing on this one.

The specific things to research vary wildly from item to item, but here is a general checklist we always compare against before we start modeling:

  • Dimensions: Make sure the object is the correct size relative to the booth and, more importantly, other objects.
  • Era-appropriate: A coffee maker from 2015 looks a lot different than one from 1985. 
  • Feasibility: If we find a reference for an object with complex geometry or that relies on unnecessary physics simulation, it’s probably not ideal for our own sanity and for the ultimate performance of the game.


Once we’ve completed our research and gathered some reference photos and dimensions, it’s time to open up Blender and get to work. We’ve done a deep dive into Blender in a previous post, so definitely check that out if you are interested in the program specifics.

On a higher level, the goal here is to create an approximation of the real-world object while keeping the geometry as simple as possible. 3D modeling for games and real-word manufacturing share a key limitation: complex geometry is more expensive. In physical manufacturing, it costs time and money to get a person (or machine) capable of creating an object to match a complex spec. In computer modeling, that complexity results in more processing power required to render the virtual object.

Geometry doesn’t need to be highly complex to build a recognizable model.

So while we never want to cut corners in noticeably detrimental ways, some smart planning can optimize the model’s geometry while maintaining the standard of realism we strive for. Working on a model with lots of complex, beveled edges? Maybe save the higher resolution bevels for the most prominent edges facing the player. Have a really cool design carved into the side of an object? Don’t model it, leave the surface flat and add the design to the material with a normal map (we’ll get to this in a later post!).

By thinking in terms of optimization before and while we model, we can end up with something game-ready the first time, rather than trying to optimize an ultra-complex model after the fact.

UV Mapping

UV Mapping is cool because there isn’t really a clear parallel to real-world manufacturing. To explain it simply, 3D models are made up of 2D faces. When applying a 2D texture to a 3D model, a program needs data to know which parts of the texture image should map to which faces. This data is provided in the form of a UV map.

A UV map is essentially a 2D plane where faces of a 3D model can be laid out and arranged on a 2D image. If you’re curious to learn more, you can check out this great post that explores it in a bit more depth.

In practice, our approach to UV mapping generally involves trying to pack as many faces as possible into a single 2048×2048 texture while trying to maintain consistent texture resolution and avoiding too many obvious “seams” when a texture should flow seamlessly between faces.

The default UV projection before we’ve done any manual mapping. Notice how stretched and uneven the scaling is on the mesh compared to the 2D image.

It sort of creates a three way juggling act, because trying to accomplish one goal often comes at the expense of others. For example, shrinking the faces on the UV map allows you to pack more in, but that results in lower texture resolution for those faces, which might be an issue.

At the end of the day, it’s really more of an art than a science, and something that just begins to come a little more naturally with time. It’s maybe not the most flashy work, but I truly think that getting even high resolution UVs evenly mapped to a complex mesh is one of the most satisfying feelings in this entire process.

After we’ve manually mapped the UVs. Much better!


Once our model is complete and the UVs are mapped, it’s time to export our FBX file(s). An FBX file is readable by Unreal Engine and contains all the geometry and UV data we just spent all that time perfecting in Blender, so it’s a great universal exchange format for just about any 3D modeling workflow.

Our rule of thumb is that any piece that will be animated in-engine will be its own FBX. As these FBX files will contain all the data we need for the remainder of the process, we are done with Blender for now!

Next up we will be looking at graphic design, so stay tuned for another post next week!

The Importance of Interaction in Interference: Focusables

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, 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.

Time to tune in!

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.

Time to tune out!

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
Time to map out a strategy!

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!

The Importance of Interaction in Interference: Physics Objects

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.

Work it.

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.

Open sesame.

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:

This pencil is possessed. And too big.

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.

The Importance of Interaction in Interference: Intro and Basic Interactions

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
Lights off, lights on, lights off, lights on…

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.

Waiting for a fresh cup of joe.

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.

Ahhh, much better.

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.