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!

We interrupt this broadcast…

Making video games is hard.

And while a visit from Captain Obvious is well-deserved for making that statement, truth be told, Brad and I had no idea the depth of the valley we were descending into when we began working on Harvest: The Unseen back in 2015.

Long story short: that game doesn’t exist.

Now, here we are in 2019, still toiling away. But at what? Harvest was the only game we publicly scrapped. Fun fact: there were two more (and while I love those games dearly, they shall remain undisclosed). One might have given up by the fourth go-around; that’s not us. So it is with great honor and even-greater dread that I announce Interference, a game that exists and will be finished, so help me.


Interference is a short interactive experience in which you play as a security guard monitoring the mysterious happenings of a top-secret laboratory from the safety of your isolated desert outpost. Just as the sun starts to set on another quiet night on the job, the facility is attacked by a fanatical cult hell-bent on releasing the lab’s most secretive and dangerous asset.

Through careful monitoring of multiple radio channels and effective use of the resources around your guard booth, it is up to you to guide your friend safely out of the facility and to thwart the escape of the infiltrators. But be careful – there are strange forces at play in the desert tonight, and not everything you see or hear is necessarily as it seems.


Interference is being developed for PC and Mac using the Unreal Engine 4. No release date or pricing has been set.

For the most up-to-date information, follow us on Facebook, Twitter, and/or Tumblr, and keep an eye on this blog for development updates.