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.

Why we’re on Patreon

Oh, shit, we sold out!

We put it off for as long as we could, but the fact of the matter is developing a video game costs money. In our case, we’ve been incredibly frugal, but since every cent has come out of our own pockets, we’ve turned to Patreon to help offset some of our necessary expenses.

First and foremost, Interference will be made whether we only have one Patreon supporter or 1000. Development may take a bit longer with fewer supporters, but it’s a pace we’ve been accustomed to for the last year and a half since we started.

Second, any money we do receive through Patreon will not be pocketed. 100% of donations (after Patreon’s share, of course) will be put towards covering the following:

  • Server fees
  • Software licenses
  • Asset costs
  • Web hosting
  • Talent acquisition
  • Marketing

And lastly, there’s something in it for you! Our Patreon supporters will receive exclusive access to development builds, behind-the-scenes images and videos, opportunities to provide feedback that may affect the game itself, their name in the credits, and more! We won’t be locking any of these goodies behind arbitrary “tiers” either, not now nor in the future since we believe anyone should be able to be part of our community.

And that’s that! Hit us up on Twitter if you have any questions, comments, or concerns. And if you would like to become a Patreon supporter, we’d be honored to have ya:

“Interference” teaser trailer now hitting the airwaves! (And more exciting updates!)

After nearly 15 months of development, we are very excited to formally announce to the world our first game slated for public release: Interference.

Well, technically we “announced” Interference back in January. And we’ve been posting periodically about it on various channels since then. We’re not exactly releasing state secrets here, is what we’re saying. But we do have some cool new stuff to share with you all, and we think that’s more than enough reason to get excited!

A New Name

First things first, our team has a new name. We’ve transitioned from our longtime moniker of The Scary Farm to adopt Fear of Corn because we wanted a name that was unique and memorable. We loved “The Scary Farm” for its simplicity, but we feel like Fear of Corn speaks more to our approach to making games: it’s multilayered, has a sense of humor, and it’ll stick with you.

It’s got a nice look to it, right?

But the new name is just the tip of the iceberg.

A New Purpose

Our primary motivation for an official unveiling of Interference now, as opposed to back in January, is a renewed sense of purpose for why we are pouring countless hours into this game. What is driving us to get it over the finish line? Because investing this much time into a game with no concrete purpose would be crazy, right?

We are serious about seeing Interference through because we know that it’s going to be a narrative experience that’s not exactly like anything else that’s been made before it. We’ve been working with two brilliant storytellers to craft true-to-life dialogue and build it into a compelling interactive narrative framework. All the while we’ve continued to explore the idea that the player can participate in a game’s story without being the driving force behind it.

In Interference, the player is not the most important figure in the game’s world. They’re not even the most important figure in the particular story we’re telling. They’re only connected to the action via a two-way radio connection, which can be totally ignored if the player so desires. But the story is still gonna happen with or without them.

We feel that this approach to storytelling is refreshing because it’s more true to the consequences of real life decision-making, which in turn make the narrative stakes feel more real. Indecisiveness in real life doesn’t mean lingering on the dialogue options while you run to look up which narrative path will yield the best quest rewards. Indecisiveness in real life can end friendships and cost lives, and we want a game that captures that in some way.

We all love being the center of the universe in games from time to time, but what effect does this have on storytelling? Can true player freedom and a realistic sense of narrative consequence coexist in a game? We’re out to prove that they can.

A New Trailer

Finally, we’re very, VERY excited to announce our first official trailer for Interference! If you haven’t seen it yet, check it out right here:

That’s all for now, but we will have much more in the coming weeks, so we encourage you to follow us on Twitter, check out our TIGSource thread, and join our mailing list! We’d love to hear from you so please don’t hesitate to reach out on any of those platforms with your thoughts.

Until next time!

Brad and Jared

Developing Development Guidelines: This Should Be Fun

Read the IntroductionGuideline #1: Don’t Reinvent the Wheel, Guideline #2: Leave Perfection Out of It, and Guideline #3: Maintain Accountability.

Making a video game is not fun. There. I said it.

Okay, that’s not totally true, but when it’s 3:00 AM and you’ve been pulling your hair out for hours over what should have been an easy-to-fix bug, it’s easy to question why you’ve chosen this life for yourself in the first place.

Making a video game is an exercise in patience. Finding simple ways to combat the trying nature of game development is one thing—you can simplify your game concepts to limit scope, you can learn to let the little things go, you can come up with ways to stay on the ball—but having fun while doing it is another. And while it seems obvious that any work extracurricular to your day job should be fun, it still needs to be acknowledged, and that’s why it is our fourth and final guideline: This Should Be Fun.

There’s not much elaboration that needs to be made on this topic, but I must warn anyone who is reading this the dangers of this guideline: it won’t be fun all the time. There will always be those late nights, those inane, frustrating tasks. I just spent the last few weeks reformatting a flowchart for the intro dialogue sequence for Interference. Was it fun? Hell no. Does it allow us to turn our focus back to the parts of development that are fun? You betcha.

It’s all about balance; the “fun” parts should counteract the “not-so-fun” parts. And the “fun” can come from any number of places. It can be found in the feeling of accomplishment in implementing a new game feature, the hilarity of designing fake brands to populate the game environment, the relief of finally squashing that bug at 3:37 AM. If at any point Brad and I take a holistic view of our work and realize we aren’t enjoying it, we’re in big trouble, because having fun is the driving force behind our motivation.

The other guidelines are the fortifications, the safeguards we’ve put into place to protect our sanity. And by periodically checking our progress against the guidelines we set for ourselves over a year ago, we’ve stayed strong, we’ve persevered… we’ve had fun.

Developing Development Guidelines: Maintain Accountability

Read the Introduction, Guideline #1: Don’t Reinvent the Wheel, and Guideline #2: Leave Perfection Out of It.

One thing that Jared and I have always come back to over the course of our nearly 4 years of experience building games with Unreal Engine is the fundamental fact that we both enjoy it. So why is it that we’ve given up in the past?

We’ve discussed in previous posts a few of the pitfalls that have contributed to our inability to follow through on past attempts at releasing a finished game project, but the truth is that it wasn’t over ambition or perfectionism that made us not finish our previous games. We didn’t finish those games for a very simple reason: we eventually stopped working on them.

And that is exactly what we tried to address with our third guideline: Maintain Accountability.

It’s easy to say at the onset of a long creative project that you simply won’t stop working on it until it’s done. But that project will eventually start to feel daunting, and if you don’t take measures to hold yourself accountable, letting it fizzle out will become a natural outcome, despite your best intentions.

Working on Interference is not a full-time commitment for us. Jared and I both have jobs and lives and only so many hours in the day in which we can fully commit to working on the game. We also live in different timezones. We knew going in that if we wanted to make this work, we’d need to be better about communication and task management than we had been on past projects.

For the last year, we’ve been committed to tracking our work with Trello cards and checking in at least once per week via video call, with tons of communication over Slack in between. Life can be unpredictable and there are certainly days where we don’t really accomplish much. But by setting a cadence of weekly check-ins, we’ve been really effective with never letting those periods of unproductivity stretch beyond a few days. We knew from experience that a week of not working on a game very easily becomes two weeks, which becomes two months and eventually three years.

Weekly check-ins disrupt this natural depression in productivity over time by making sure we can always reassess our goals and objectives if we ever find ourselves losing steam. We avoid hard deadlines, but always set reasonable weekly goals so we can keep a pulse on how we’re doing and stay flexible in our approach to avoid burnout. Working on the game for 14 months straight sounds exhausting. Working on it for just a few more days until the next check-in though? How can I give up when I’m just three days away from hitting the goal I set for myself just last week!?

Of course, even with all the accountability in the world, other factors can still sap the fun out of a project start to make it feel like a drag. But the beauty of staying accountable is that we’re always in control over the fate of the project.

Had we decided 3 months in that we just weren’t feeling it and wanted to put the game on hiatus, it would have been a bummer, but it at least would have been a conscious decision and not something we look back on years later and just think “man what ever happened with Interference…?”.

Thankfully, our other guidelines have kept us motivated well beyond that 3 month mark, and their importance cannot be overstated. But it’s been the commitment to accountability that has given us a framework to channel that motivation into an actual game, and seeing our progress unfold week by week has been the biggest motivator of all.

Developing Development Guidelines: Leave Perfectionism Out of It

Read the Introduction and Guideline #1: Don’t Reinvent the Wheel.

If over-ambition is a threat to the completion of a creative project, then perfectionism is the weapon used to make the final kill. I’ve gone my whole life as a perfectionist in varying degrees, and while I enjoy meddling in the meticulous details, I’ve found that this trait has done more harm than good. This duality is especially true when embarking on a project with as many components as a video game.

Details are everywhere in game development, and getting bogged down in making sure each and every 3D model, texture, sound effect, line of dialogue, post-process effect, gameplay system, etc. is “perfect” is a fool’s errand. As a lifelong perfectionist, this lesson was the hardest to learn when Harvest collapsed. And while we don’t like to assign any of our four pillars any importance over the others, I personally believe that our second guideline, Leave Perfectionism Out of It, might just be the saving grace of Fear of Corn.

I so desperately wanted things to be “right” for Harvest. After all, it was our first game, and I wanted to make a bold first impression as a game developer. I remember asking Brad, much to his annoyance I’m sure, so many questions about whether we were UV-mapping models correctly, whether the scale of an object was realistic, whether a certain color matched… My focus was entirely centered on the wrong things, and instead of spending weeks on tinkering with our character’s head-bob, I could have been working on the systems we needed to make our game actually work. By the time we released a teaser trailer for Harvest, we were both so exhausted that development never resumed.

For Interference to be successful, we had to toss aside the notion of “perfect” – in fact, there is no such a thing. It’s an unrealistic standard to hold anything to because it’s not even measurable. It’s totally subjective, and thus, undefined. Instead, we needed to formulate some other way to determine whether or not something could be deemed as “complete,” a question we could ask ourselves given any situation and be able to walk away satisfied: does this meet our goal?

Goal-setting is vital for managing expectations. Sure, it’s not sexy, but knowing when to stop working on that texture or model or sound effect makes a night-and-day difference not only in progress, but in morale. Goals can be simple (i.e. “does this material look like paper?”) or complex (i.e. “is this gameplay fun?”), and many times it’s not something Brad and I talk explicitly about. But in any situation, we know how we define “done,” and a peer-review process helps support that determination. Goals are the reason we are still going strong after one full year of development on Interference.

At the end of the day, the satisfaction that comes with completing a creative project far outweighs the disappointment in things we wish we could do differently. There’s always a next time, and while it’s important to make note of those improvements to learn and grow, spending time wallowing in self-doubt is the fastest way to lose creative momentum. So what if our radio is too shiny? It’s still a radio, right?

Developing Development Guidelines: Don’t Reinvent the Wheel

Read the Introduction.

I think there’s an inherent desire when beginning work on a creative project to do something different, to bring something totally new to the table. After all, that is the value of creative work – to create something, rather than just repurpose other things that already exist. But this desire can be somewhat antithetical to a fundamental truth of creative work: imitation can be the most effective way to learn something new.

And we are still relatively new to game development.

When we started trying to develop our first game, Harvest, beyond the basic premise (sci-fi survival horror set on a farm), we wanted to do things differently. We didn’t want our game to feel like other survival horror games. We ditched any semblance of linear level design and typical puzzle-solving, opting instead to drop players in a small, but extremely open ended space, where they could explore however they wanted. An item needed to open a door in the farmhouse might be hidden in the barn, and we wouldn’t push players to it, leaving them to discover things at their own pace.

Needless to say, designing a game like this is hard. And for first-time game designers, it was simply not realistic. We started building out the environment without a real plan in place for how to execute on our ambitious gameplay ideas. Would it even be fun for players to have to backtrack throughout several locations on the map with no guidance or sense of linear progression? We had no idea, because we’d never played a game quite like that. Our ambition to do something totally new was a major reason we never got close to finishing the game.

And it was for that reason that we decided on our first development guideline for Interference: Don’t Reinvent the Wheel.

We acknowledged our previous missteps and made an effort to embrace that we are new game developers. We need to learn why certain video game tropes exist, and learn how to execute them before we can subvert them. We had to learn the rules before we could effectively break them.

So with Interference, we decided to stay a little more traditional, with a scripted experience that plays out in an even smaller physical space. We didn’t shy away from using a familiar branching dialogue system that works in so many other games. By leaning on familiar building-blocks, we had a better sense of how the game would feel to play going in, which gave us direction and motivation to stick with it.

All of this is not to say that Interference is just like other games. In fact, we feel that it’s even harder to neatly categorize than Harvest was. We are still able to experiment with narrative and player freedom in ways we feel make our game unique. But this experimentation is grounded in elements we’ve seen work in games before, and has been the difference between staying motivated and flailing in our own over-ambition.

Developing Development Guidelines: Introduction

There are a ton of cheesy quotes about “failure” out there, about learning from failure, about taking failure in stride. But failure, no matter how flowery the sentiment surrounding it, straight up sucks. As mentioned in a previous post, failures led us to the development of Interference. It was important that this time we get things right though, that we spare us a future of having to hang up the towel and call it quits for good.

So, before the cacti, radios, and mysterious happenings of Interference could be summoned into existence, we needed some help. Specifically, some guidelines. Some…

Things to Keep in Mind

These are the four pillars upon which Interference was conceived and the foundation for all of the decisions we make for our game. In the next few weeks, we’ll be breaking down each of these guidelines, talking about where they came from as well as specific moments of development in which these guidelines informed our choices.

Stay tuned.

Will It Blend: Using Blender To Build A Game

When we started working on Harvest back in 2015, I had just graduated college and still had access to the student license for Autodesk Maya that I’d used for class. Fast forward three years to the start of our work on Interference, and that student license was no more. So we had to decide on a 3D modeling solution.

While Maya is fantastic software that I had grown quite fond of using as a student, Blender was my first foray into the world of 3D modeling. As a freshman in high school, I installed Blender with no idea how to use it and picked up a copy of Blender For Dummies (for real). I never made anything particularly impressive back in those days (I’d probably be equal parts impressed and embarrassed if I dug up my first Blender animation, an exciting clip of a rhino charging at the camera), but Blender’s depth of features and relative ease of use left an impression on me, and I was excited to spin it up again.

Getting Started!

I’ll admit I was frustrated when I first started tinkering with Blender again after all those years. I started out using the Maya key bindings to ease the transition, but this made reading documentation and following tutorials significantly less helpful. So I ripped off the Band-Aid and switched back to Blender’s native settings, essentially starting back at square one. Only no Blender For Dummies to help this time.

Relearning things you already know how to do is a humbling experience. There are still times I need to do simple things in Blender that require a Google search that feels a little silly, but figuring out how to do it for next time is consistently rewarding. Before long I was inserting edge loops, extruding faces, and unwrapping UVs like old times. But the learning process is never really “finished”.

UV Mapping Cones Is Hard

Very recently I had a brain fart where I confused radius for diameter and spent a good half hour banging my head on the wall because simple cylinders and cubes were importing to Unreal twice as big as I expected them to be. I didn’t have my Blender UI set up at the time to show the object dimensions panel, which would have been a 10 second sanity check if I’d just thought to look. But out of sight out of mind, and I completely ignored Occam’s Razor to try to find a more complex solution. It was frustrating at the time, but I’ll never neglect to check my object’s dimensions next time I’m dealing with object scale, even if they’re not immediately right in front of me.

Looking Fresh!

It’s been nearly a year since we started work on Interference and made the choice to use Blender as our 3D modeling tool, and we haven’t regretted it once. It’s an amazing piece of software that can really hold its own against pricier competition. Knowing it’s open source just makes it all the more impressive and rewarding to learn, and not just because of its price tag.

I owe my interest in 3D modeling and animation to Blender, and it feels great to finally have an awesome project to really do it justice (with all apologies Rhino Charging At The Camera, 2008).


All Done!