6 Things I Learned From My First Big Failure

By Evan Fradley-Pereira [07.14.15]

 [Evan F.p. is a professor of interaction design/development and a games writer. You can find him on Twitter at @FP_Evan.]

My first major game project was a spec job for a major Canadian music label during college. The label, in search of new revenue sources, got to roll-the-dice on some free development and our postgraduate class got to work with media-industry professionals and (potentially) kick-off our careers with a prestigious credit under our belts.

Unfortunately, the project was never completed. After 8 months of development, communication between our studio and the client ceased, and we graduated with portfolios consisting of whatever respective indie projects we had been able to put together.

Despite the project's failure, the majority of my graduating class is now either gainfully employed in the games industry or happily working on personal projects. Three of us work together at Fuse Powered, where we make tools that help mobile publishers build better, more approachable free-to-play games. One of us went on to become a AAA 3D level designer. One of us is at Riot.

They were (and continue to be) a very talented bunch of guys, and though we might not have finished what we set out to do, the experience afforded us an accelerated education in the absolute fundamentals of game development that I am often surprised to find lacking even among veterans. The lessons from our collective failure that year are among the most important for anyone in the early stages of their career, and they have contributed to the success we have all since enjoyed. I thought I'd share a few.

1. Start Small

Our program afforded us free labour from other college students working towards their diplomas in game development. Working on our project earned them class credit, and our smaller postgraduate class was not only charged with putting them all to work, but also evaluating their performance and ultimately assigning each of them a letter grade. For many of us, that level of authority was unprecedented, and for a few it proved intoxicating. Having a such a huge labour pool at our disposal led us to believe we could accomplish something great, but it quickly went downhill.

The sheer volume of assets we had to deal with would have been a challenge for an experienced project manager, and we had just adopted the title of "producers" a few weeks prior. The swollen team made for impersonal communication and many hours of development time were wasted or lost in the shuffle. Many team members, rightfully frustrated with the lack of organization, stopped showing up. 

In the beginning, you don't need more resources. You need the right resources, and you need to have the skill to manage them. When building a team, whether you're working with freelancers, game jam partners, or even hiring salaried employees, invest the time in sorting through what's available/affordable and find the effective communicators who hit deadlines and ask questions. You will accomplish more with a SWAT team than a barbarian horde. If you are weak, the horde will turn on you, and they will be right to do so.

2. Learn Everything

We ran into issues in the pipeline where people on both sides of a blocker threw their hands up and said, "Not my problem. I did what I was asked." When the issue was eventually resolved, 80% of the time it turned out to be a case of one team member chucking their contribution over the fence without knowing enough about how it affected the work of other team members down the line.

No matter what role you play in the world of game development, learn enough about every other discipline that you can carry on a meaningful conversation with the other members of your team. Knowing the key terms, especially in the area where your two disciplines overlap, will make you far more valuable than just being very good at what you do.

3. Ideas Are Worthless, Execution Is Precious

It's a shame ideas can't be sold, because they're absolutely everywhere. Ask any major developer who has had a contact form up on their site for any period of time and they'll tell you how many unsolicited game ideas they receive every month. Unfortunately, your idea for a game is inherently worthless, both commercially and artistically. Ideas are only the seed of an accomplishment and have no value without time and energy invested in their realization. Sharing your ideas like they're qualifications is a good way to get ignored.

What gets attention is proof that you're able to deliver on your ideas. No one ever risked anything coming up with an idea. Risk only becomes a part of the equation once time and energy are put into execution. It's the ability to push through this risk and create something that has value. Investors and prospective employers are looking to minimize risk, and any evidence you can provide to suggest that you're capable of doing what they need done is to your benefit. 

4. Who's Having Fun?

Early on, we settled on doing some version of an endless runner. During prototyping, one of our classmates was able to analyze the volume of a song to create a particle trail that the player's avatar had to follow to earn points. The client was impressed, which made us feel very clever, so we ran with it. We invested time and effort into polishing the mechanic, never once looking for a second opinion. If we had, we would have learned that the mechanic was absolutely no fun.

Music is best enjoyed through participation, as evidenced by games like Guitar Hero and Rock Band. Short of being an actual on-stage musician, most music listeners participate through rhythm by bobbing their heads, tapping their toes, singing along, and dancing. Our mechanic did not require the player to participate in rhythm, only trace a line and avoid obstacles that were derivatives of the song they were listening to. It was novel, but boring. By the time we realized it, it was too late. 

To paraphrase freemium game design consultant Mark Sorrell, "(Successful games) are a subset of games that are fun." Not all fun games are successful, but very few successful games aren't fun. We allowed ourselves to invest resources in a faulty design because the client was impressed with its novelty, which made us feel good. Understandable, given that we were new and desperate to impress, but making games is not about having fun, though it's hopefully a pleasant consequence. You're making games so your players can have fun. Every step of the journey, repeat this mantra: "Who's having fun?"

5. Respect Yourself And Your Team

Our personal failings aside, there were issues maintaining communication with the client. Our design required audio assets that we agreed would be delivered to us early in production. Deadlines for delivery came and went, and even after 8 months of development we never received the assets we had been initially promised, and we had to make due with placeholders. Members of our team grew rightfully frustrated while I advocated for patience and flexibility, afraid that we might lose the credit. In our efforts to retain developers, I argued for how valuable the opportunity was, and how it would strengthen our resumes upon graduating. 

I'm ashamed we didn't deliver on the promises I made to our team members. There was enough blame to be shared between ourselves and the client, as is often the case with this sort of breakdown. Them for not thinking enough of the project to deliver on their original commitment, and us for promising our devs a credit that they wouldn't ultimately receive. My advice is to respect your team enough to hold clients (and yourselves) accountable for commitments. Work it into contract wording wherever possible and don't be afraid to walk away from a partnership that is not proving to be mutually respectful. Execution is precious, even in novices.

6. We Learn More From Failure Than Success

We don't naturally ask ourselves "What did I do right there?" Our failures frustrate us and so we dissect them, and with the right attitude, learn from them. When failed projects come up either in job interviews or pitch meetings, don't divert the conversation. Address them head-on and don't waste breathe assigning blame. Demonstrate a clear understanding of where the breakdowns occurred, even if it involves you, and explain ways you've learned to prevent them. It's likely these explanations will be among some of the most valuable things you have to say.

- Evan F.P.

You can find Evan on Twitter at @FP_Evan.

Return to the web version of this article
Copyright © UBM TechWeb