In an episode of How I Met Your Mother, an aged version of the series’ main character, Ted Mosby, tells his children that there are five disastrous words a man will say sometime in his life: “We should buy a bar.” The episode about Ted’s personal relationship with these words has he and friend Barney volunteering to “hold down the fort” at their favorite bar and almost destroying it. Likewise, there are five equally disastrous words that many gamers will say to one another at some point in their lives: “We should make a game.” Today, game development is in a state where it is very possible for the indie developer to find their way into the industry if they know how to approach it. However, the newbie developer should understand the realities of game development and the steps to avoid amateur developer pitfalls.

We should buy a bar

The disparity between the audience for games and the reality of game development is a rather huge one. Many assume that game designers are magicians who breathe epic ideas and sprawling worlds. Likewise, many gamers believe that games require little work, or that working on a game is an experience filled with puppies, rainbows, and inter-office Nerf wars. While the Nerf wars may be true, game development is also a lot of hard work, late nights, and stress.

In projects where the developers to be are all amateurs, the road to a complete game is a difficult one that may not end well. Gamers with visions of building a new Tamriel often stay in the idea phase for an indefinite period of time. When the reality of production comes crashing down, it often does so on the team’s work ethic and excitement. For team members with more serious intentions for the project, these implosions can be a frustrating experience.

For amateur developers or indie devs looking to build games with their gamer friends, there are steps that can be taken to avoid product implosion, or at least stave it off admirably.

Have a game developer in your midst

This can take many forms. The obvious application of this tactic is to have a friend on your team that has worked on a game in some fashion. In some parts of the country that may be difficult, however, so some legwork may need to happen. If you are even semi-serious when you utter those five deadly words, you will want to do your research and learn what a game development cycle looks like.

In The Art of Game Design: A Book of Lenses, author Jesse Schell welcomes readers to the book by declaring them game designers. In many ways this is a good thing: we should be welcoming new designers into the industry and fostering their development. Schell’s comments are true because there are a great many avenues and resources available to the amateur game dev. I often highlight resources such as 3D modeling environment Blender and the Unity game engine as great products to get one’s feet wet.


The graphics on level 3 - you must tighten them...

Likewise, books such as The Art of Game Design, Tracy Fullerton’s Game Design Workshop, and Salen and Zimmerman’s Rules of Play: Game Design Fundamentals are excellent educational resources. These books teach everything from how to make games to how to analyze and understand them as pieces of interactive media.

Anyone spouting “we should make a game” to their friends should take the time to explore the resources available and the realities of game development. This knowledge can be invaluable for advising the team in a projects direction, development cycle, or scope.

Scale your game appropriately 

The scope of a game is a huge consideration when planning a project. For my talk at GDC China 2011, for example, I developed a five-minute 3D level demonstration. The artwork consisted of custom characters, level models, and game objects – textured, lit, and baked. The whole thing was put together in Blender and Unity with scripts cobbled together from the remains of old projects. Prior to the event, I didn’t even have time to actually animate any of the characters, so they run around in their modeled T-poses. All of this took about a month, working day and night around my work schedule, to complete. Five minutes of 3D gameplay without character animations developed in a month while functioning at a 9-to-5: do the math for a fifty-hour quest developed under similar conditions.
 Learn to set realistic expectations for your game project. 

A common mistake I see students commit is coming to a game design class with very large visions for their projects. My two favorite student pitches are:

“So you know (insert AAA retail game title here)? Well I want to make something like that, only set in a (insert alternate narrative setting here) style universe but BIGGER AND…like…BETTER.”

 Or…

“Gawd…why do games have to be about one type of gameplay? I want to make aWorld of Warcraft-like game where your choice of character dictates how the game plays: if you’re the fighter it’s a fighting game or if you’re the marksman the game is an FPS. There could be 20 characters.”

Time should be taken when conceiving a game project to figure out what your team’s development goals are and how reachable they are. It can be helpful to make a wishlist or a document with large and small-scale goals for the project.  The small-scale goals should be reachable with the team you have and the large-scale goals should be pursued by reaching out to new team members.

Establish good recruiting criteria

New team members are a tricky thing to manage. It is easy to find someone with talent in their particular field but there are no guarantees that they will fit in with the rest of your team or even do their work. In projects where developers are working for fun or for future shares of the released game’s profit, it is difficult to keep people on task. Also, negative teammates can be detrimental to the social mechanics of the group so they must be watched out for.

I once worked on a project with a person who was only interested in his own ideas. If he suggested an answer to a problem, he refused to see the legitimacy of anyone else’s proposal. As the director of the project, he would approach me to say that our game was “incomplete” unless we implemented his ideas. He ignored the written production schedule and disappeared once production began. When he finally showed up to a meeting, his progress report was, “if it didn’t involve my motorcycle or Warhammer 40K in the last three weeks, then I haven’t done it.” He was let go of the project soon after.


 "Can I get a copy of your design document? I need scrap paper to line my bird's cage! Dohhhhh ho ho ho ho ho ho!"

What the experience taught our team about recruiting was that talent was not enough to warrant a position on a game development team. In the end, we had to weigh the risks of having a negative presence in meetings vs. the value of their talent. While in this story, the person made the decision for us by unabashedly refusing to make progress, other situations are not so simple. Avoiding such personalities should be a priority when recruiting rather than a reason for letting people go. This is not to say that a designer should avoid having to fire people; it happens; but having team members that fit in with your group can help create more productive meetings.

The opposite of the Nay-sayer is the Socialite. This is the person that is friendly and charismatic to the point of spending all of your team’s time joking around with the group. A powerful Socialite can be like an atom bomb dropped into your workspace. You know when you’ve got one of these workers in your midst when your team’s environment becomes a raucous party when they would otherwise be more productive. Obviously it’s good to joke and have fun during long working hours, but it becomes a problem when it prevents people from working. In some ways this character is more dangerous than the negative person and makes milestones harder to reach. 

Setting concrete milestones

Milestones are another difficult thing to manage in an amateur or indie project. In a full studio environment, milestones are where you get money from the publisher – if you don’t make your milestones you don’t get money, simple as that. In a project where you are making a game while having a day job, milestones need to be something both tangible and bearing consequences.

In his talk at GDC China, Bastion dev Amir Rao discussed how they utilized event-based milestones for their project. Each new game conference required them to reach a development milestone so progress could be demonstrated. Not every studio needs to have the cash to fly to GDC, PAX, and E3 every year, however, as there are other avenues that can be explored locally.

 
Failing to finish her demo before GDC, Linda resorted to dressing as Wonder Woman to garner attention from publishers. 

One group I have presented projects to is our local IGDA (International Game Developers’ Association) chapter. They and their sister group in DC, Games Gateway, host events solely for getting feedback on and recruiting for new game ideas. One such meeting was a milestone for a team I was managing, and even less motivated team members crunched to be able to show something.

Even in areas lacking IGDA chapters have gaming groups or clubs that can be utilized for a playtest. There are also smaller fan conferences where player feedback can be gathered. Being creative with opportunities for showing off your game can help you create a development schedule based around milestones.

Fail epically 

Many job postings for big studios ask applicants to have successfully shipped “x” number of retail games. I would argue that having a project fail is as educational, if not more.

I wrote this post based on experiences where game projects imploded upon themselves; where teams disbanded through strife, distance, or distraction. My own portfolio is filled with concept art from projects that never became full games. Some would wonder why I would want to show examples of failed projects. For one, they are still good concept art, and secondly, because failures are so educational.


What did we learn today kids? 

In a sidebar of the book, Game Design Workshop, game designer Chaim Gingold expresses similar thoughts about programming prototypes that never panned out. He says that for a while he regretted some of the applications on his hard drive that never came to fruition, but eventually came to appreciate them as educational exercises.
           
As someone who has fallen victim to the dangers of “we should make a game”, I can attest to their value as a learning experience. Team managers gain valuable experience by having to manage crises, rebuild projects, and fire people.

Should I be lucky enough to have a leadership position at a studio in twenty years, I would ask applicants for leadership positions to not only demonstrate the fruits of their successes, but also their failures and how they learned from them. Game development is an iterative process: we create a prototype, test it, and make changes if things do not pan out as we envisioned. The road of a motivated indie developer getting from amateur to professional is similarly iterative.

 Conclusion

There are many pitfalls to consider when someone approaches you with, “we should make a game” – the knowledge of the group, the scale of the idea, the team itself, and the schedule. Having these things in order and being serious about the realities of game development will increase the likelihood that your idea becomes a design and eventually a product. Even if you fail miserably, you will learn from the experience and, if you are serious about making games, enthusiastically prepare for the next project.