Gamasutra: The Art & Business of Making Gamesspacer
View All     RSS
September 20, 2014
arrowPress Releases
September 20, 2014
PR Newswire
View All





If you enjoy reading this site, you might also want to check out these UBM Tech sites:


 
5 Deadly Words: "We Should Make A Game"
by Christopher Totten on 12/12/11 09:35:00 am   Expert Blogs   Featured Blogs

The following blog post, unless otherwise noted, was written by a member of Gamasutra’s community.
The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.

 

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.

Ted and Barney bartending
"Check out our physical prototype guys!" 

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.

tighten up the graphics
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.
realistic expectations  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.

Statler and Waldorf
 "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.

wonder woman 
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.

epic fail
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. 


Related Jobs

Infinity Ward / Activision
Infinity Ward / Activision — Woodland Hills, California, United States
[09.20.14]

Producer - Infinity Ward
Infinity Ward / Activision
Infinity Ward / Activision — Woodland Hills, California, United States
[09.20.14]

Senior Tools Engineer - Infinity Ward
Blizzard Entertainment
Blizzard Entertainment — Irvine, California, United States
[09.19.14]

Senior Vice President, Cross Media
Blizzard Entertainment
Blizzard Entertainment — Irvine, California, United States
[09.19.14]

Lead 3D Character Artist - New Unannounced Title






Comments


Tiago Raposo
profile image
Great article. Really, thanks a lot.

Christopher Totten
profile image
Glad you liked it :)

Matt Spaulding
profile image
I am making an indie game by myself. I could imagine some problems arising when working with a group of hobbyists. Good post.

Lucas Daltro
profile image
Thanks for this article,I want to do my first commercial game now and it's good to see what problems I'll have in the future:D

Daneel Filimonov
profile image
Very informative!



I remember when I was naive about game design. A good couple years can change that! Oh, and reading this article too, I suppose :P

Tora Teig
profile image
I think I need to print this and hand it out when someone say the five words. :D

I wish everyone could read this, thank you!

Giacomo Vaccari
profile image
Great article! Specially relevant since I am starting an indie project, managing a young group of game design students. I can relate to most of your points, particularly in scope, as my previous failed attempt at creating a AAA styled game demonstrates.



The book references are also great, read most of them and I can safely say they have improved my understanding of the game development pipeline by leaps and bounds.



I'm sure I will be revisiting this post with my team soon!

Michael Gribbin
profile image
In my indie-er days, I ran into several issues that were excluded from this list.



For Oh Buoy (http://www.kongregate.com/games/damijin/oh-buoy), I had no team issues -- but my inexperience and lack of desire to seek criticism led to a product that was virtually unplayable by anyone other then myself. Production went good though -- it was our first "Let's make a game!" where I partnered with two friends from highschool. I did the art and design, a friend did code, and another friend did sound and music.



Following the market failure of "Oh, Buoy!" we were unable to maintain momentum. We put a lot of energy into it, and I'm happy with it having been my first game, but we expected much more. As a result, we lost that traction and never got it back.



Later, when I was working with the programmer friend on new ideas, we had issues of creative control. Since my previous game design hadnt worked out, he was less likely to accept my ideas as "good enough."



This became a problem when my ideas required additional coding, or if I was asking him to do portions of design that should have been my responsibility. As a result, our other game, The Pinball Adventure (http://www.kongregate.com/games/damijin/the-pinball-adventure) failed to become the RPG style pinball game I had hoped it would be. We disagreed on ideas of upgradable equipment, monster health bars, and player statistics. The end result was a pinball game with an RPG theme, but no RPG mechanics because the effort to implement them was too high for his time restraints.



Ultimately, it is totally possible to make games with your friends -- but the lack of a salary makes things hard. When a real disagreement comes up, a compromise is always needed, and that can happen to the detriment of the product.



Excellent article, btw.


none
 
Comment: