• Register
Post feature Report RSS Developing Development Guidelines w/ Fear of Corn

Independent developer Fear of Corn walks through their process in crafting guidelines to aid in the development of their first game, Interference.

Posted by on

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. However, 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. Let's break 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.

Don't Reinvent the Wheel

by Brad Leyden

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.

Leave Perfectionism Out of It

by Jared Bohlken

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?

Maintain Accountability

by Brad Leyden

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.

This Should Be Fun

by Jared Bohlken

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.

Post a comment

Your comment will be anonymous unless you join the community. Or sign in with your social account: