Gamasutra: The Art & Business of Making Gamesspacer
Lessons from the Trenches
View All     RSS
July 31, 2014
arrowPress Releases
July 31, 2014
PR Newswire
View All





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


 
Lessons from the Trenches

September 14, 2011 Article Start Page 1 of 3 Next
 

[Henrik Markarian, a veteran developer with over 20 years in the industry, including stints at Mindscape and NovaLogic, shares production secrets he's learned over the years -- best practices aimed at improving efficiency and studio culture.]

I believe that making a game is part art and part science, so it's no wonder that managing a game project is also part art and part science. Clearly if it was all science then the industry would get a collective F for not having made any significant progress over the last decade - all one has to do is just glance at the published postmortems to see that the same patterns are repeated over and over.

A game has to be fun, engaging, grab users in the first two minutes and also keep their attention for countless more hours. These requirements place a very difficult burden onto design directors and project managers who are tasked with quantifying "fun" and then determining that at some point in the project enough fun elements have been introduced into the game so that it can actually ship.

Complicating matters are fixed budgets, tight timelines and dealing with team dynamics. All of this combined with the well-documented issues surrounding collaborative software engineering are the chief reasons why game projects are so difficult to manage.

While there are no clear-cut answers, there are obviously best practices. The goal of this article is to outline numerous lessons learned from the trenches of game development that when applied properly should help control and manage a process that by nature doesn't want to be controlled or managed.

Limit the Chefs in the Kitchen

"We have the happiest employees around because EVERYONE here contributes to the design!"

How many times have you heard this? Or perhaps you were the one saying it, when trying to hire a promising candidate? It's a common theme, and one that is often discussed during interviews.

While this sounds great in theory, in reality its execution is fraught with problems. Game projects (much like other entertainment properties) are most successful when guided by a small and focused group. This doesn't mean that the group will make a hit every time out, but it does ensure a cohesive vision for the game that in turn increases the likelihood of success.

Put together the best small team possible and empower them to make the final design decisions, while avoiding the temptation of introducing multiple points of design direction from inside or outside. If you take only one lesson away from this article -- this should be the one!

Make a Short Game

On numerous projects I've come across situations where the development team is saddled with delivering a gameplay experience that must last an inordinate number of hours. In one particular example, a publisher with a solid hold within the RPG realm tasked our team with designing a space-based action game. There was pressure in delivering a game that provided 40-plus hours rather than concentrating on a targeted experience befitting the action genre.

Put simply, this was a recipe for disaster. Most often, in order to meet these types of expectations the core gameplay experience is stretched through such a lengthy sequence that the impact is lost on the player. Similarly the story is stretched through so many unnatural twists and turns that at the end the player has little connection to the original premise or the main goal.

If we compare this with movies, rarely would a filmmaker opt for a movie that's over two hours long. Clearly there are business reasons behind the two hour movie format (number of showings in theaters, etc.) but there is a wonderful byproduct: filmmakers know that they have a limited amount of time to grasp and maintain the attention of the consumers and that anything in the movie that is not driving towards the ultimate goal is extraneous and possibly harmful to the overall experience.

Let's view this from an entertainment-value perspective: Games generally cost four to five times the cost of a movie ticket, so is it fair to expect more than 10 hours of entertainment from a $50 game? Games are different from movies, but the entertainment value aspect is not that different. There are exceptions (e.g. MMOs), but the overall lesson is solid: aim for a great short experience, rather than a lengthy mediocre experience. Walt Disney, a man who knew a thing or two about entertaining audiences, had the right idea when he said "Always leave 'em wanting more."


Article Start Page 1 of 3 Next

Related Jobs

YAGER Development GmbH
YAGER Development GmbH — Berlin, Germany
[07.31.14]

Senior Graphics Programmer (f/m)
Square Enix Co., Ltd.
Square Enix Co., Ltd. — Tokyo, Japan
[07.31.14]

Programmers
Raven Software / Activision
Raven Software / Activision — Madison, Wisconsin, United States
[07.31.14]

Senior UI Engineer
Treyarch / Activision
Treyarch / Activision — Santa Monica, California, United States
[07.31.14]

Senior Gameplay Engineer - Treyarch






Comments


Glenn Storm
profile image
This is great. Thank you, Henrik.



Regarding "suits" vs "geeks" and Team Harmony, there are good points raised here, but perhaps a little light on actionable directions to take, for individuals, teams and organizations. Status updates, understanding across disciplines and having a professional outlook/attitude are all well and good, but do not necessarily indicate what to do with that information/support alignment.



Simple approaches to graft onto these ideas might include charging each member of each team to put the professional goals of others before their own in some apparent way, on some regular basis, and to highlight and champion those "team moments" as being exemplary professional behavior. It should not distill to a portrait of 'employee of the month' on the wall, but instead, taking the time to recognize effort that branches from a teammates' comfort zone outward to help others seems like a great way to call for action.



A programmer who provided a subtle modeling feature for artists, an artist who takes the time to mock up a dozen pitch posters for a designer, a designer who takes on production management for a short sprint, a producer who writes up a list of bug reports, etc. These are powerful signs of a healthy team. Actions like this provide value to each team from outside their team (leading to satisfaction that feels like a power up). Once real value results from cooperation and proper teamwork, a snowball forms. These kinds of efforts can take on a life of their own, causing spontaneous communication and collaboration, and by example, provide strong encouragement for the rest of the team to join in and make an impact.

Matt Hackett
profile image
@Glenn Storm: agreed, and also I'd be interested in ways to smooth out weirdness between developers. Unavoidable social tension within the team can make work extremely stressful.



Also the solution to crunch time seems to be, "just don't do it" which I think is great and I agree and all, but perhaps a bit idealistic. Nobody *wants* to crunch, right? They're forced into it, so what's a good way to prevent that from happening?

Glenn Storm
profile image
Social tension in a business environment, or any organization, is a thread slowly unraveling the cohesion of that entity. The natural tendency is to leave the thread alone, particularly if (at least in short term memory/future prospects) there is no apparent benefit to change. The problem is, this metaphorical thread does get pulled through the course of the day, via inadvertent actions, inaction, mistakes, curve balls, etc. A lack of healthy communication itself is the largest contributor to this thread getting pulled. Leaving it alone ensures unraveling.



The solution involves a change in perspective on this metaphorical thread of social tension. See that thread sticking out right there? That's something to pay attention to, consider respectfully and take action on. Managers in particular, producers especially, need to be tuned in to what's happening on the team, to check in personally, and to look for these threads. But each member of a team is responsible for team-playing as well, as a matter of professionalism.



Taking the first step to smooth out a social wrinkle should be casual and expected in a healthy organization. In a troubled one, it only takes a moment's courage and a little forethought. No one will disparage someone who is offering to help in an authentic way.



So, one reliable way to approach this situation is to first consider those involved; their perspective, their fears, and their needs. (usually in that order) If one can then approach with an offer of genuine help that makes sense from their perspective, respects their fears and addresses their needs, the other is provided an easy, non-threatening way to make a meaningful connection and begin to trust more. It is very important to follow through until the other is satisfied as well as to then reflect with them in some way on that collaboration after the fact, with no expectations placed on the other. This is a powerful gift you can give someone; one that can nurture trust. With more trust, comes the ability to simply ask the other what their perspective, fears and needs are (perhaps not asked so directly); which allows for this kind of social repair to happen more frequently and with more reliability and meaning. So the steps after this initial repair include building upon that collaboration, and keeping up that momentum of communication (checking in until the other is satisfied), even if that simply involves water cooler chit chat.



The above advice is offered as a way to help bridge gaps between individuals in particular situations. In situations where teams require this kind of repair (silo dismantling, for example), or an organization's entire culture is inclined to leave the thread alone, so to speak; the attention, care and effort required is exponentially greater. This kind of change takes momentum from within, a switch or tipping point, that leads individuals to act of their own will in the same direction. To each individual asked to change, it should feel much like the above one-on-one situation. But, to make that kind of culture change happen takes more than a little forethought and courage.



Stuff happens, and if there is no way to continually gather, align and satisfy the social connections with communication, help and trust, an organization can only remain cohesive through faith and luck. Eventually those thin supports are also tested. Maintaining a healthy organization takes a longer view than that. As an individual, if you have concerns you can address, address them. If not, take the above advice to approach those who can address them; as this is another form of authentic help you can offer someone.



Hope that helps.





(Crunch may be minimized in a healthy organization through production management skill)

Thomas Engelbert
profile image
Very interesting article. Thx for sharing your thoughts and experience. I'll take it to heart.

Bart Stewart
profile image
I've run into most of these as a programmer and software project manager (in non-game settings), and I can endorse all of the prescriptive suggestions.



One in particular stood out for me though:



"[A] hard learned lesson from my perspective is to not sacrifice long-term team harmony for short-term production returns."



Most people who've done software development for any length of time will recognize this as the problem of the Superstar Jerk. This is the person (often/usually a programmer, but not always) who is unusually productive or good at solving very difficult technical problems, but whose social skills are not as well developed. They get hard technical tasks done quickly, but they treat other people with rudeness, condescension, and/or outright loud abuse.



From my experience, I agree that the Superstar Jerk almost always winds up being more trouble than he's worth. It's not just that he leaves emotional wreckage in his wake wherever he goes, creating human problems that have to be solved in addition to the already-difficult technical problems of any software project. It's also that other team members see that this person's moments of bad behavior are tolerated. Nothing good can come from this -- people either resent that the superstar is permitted to be a jerk while they are not, or they figure that abusive behavior must be OK and do it themselves. Either result is toxic to team effectiveness.



The practical problem here is that, on the one hand, technical competence is relatively easy to document and quantify financially. ("Bob's all-nighter fixed the server bug, which otherwise would have taken two people a week to find and correct, keeping us on schedule and saving approximately $50,000 in labor costs.") But on the other hand, examples of bad personal behavior can be very hard to document -- sometimes people don't want to "tattle," and having cameras/microphones everywhere is not really an option -- as well as being difficult to quantify in cost terms. How much money did you lose because Superstar Janet yelled at someone?



So it's absolutely crucial that the project manager, who is the primary point of contact for technical and human issues affecting the whole team, has the trust of the studio head and HR. If the project manager reaches the difficult conclusion that a superstar has become more trouble than he or she is worth, then whoever has the power to hire and fire has to trust that project manager's judgement.



That can be really tough when there's hard evidence of project time and money saved over the immediate term by the superstar, and only the project manager's word that the superstar's personal behavior is so bad that it will cost the whole studio more in the long run. The pressure to finish a real product versus an intangible "maybe someday" can be extraordinarily hard to ignore.



But that's what is required to be able to let go of the Superstar Jerk.



Can anyone name a single time when this has ever happened?

Glenn Storm
profile image
Interesting point, Bart. This is a case where the long view can help in focusing on the disruption, by identifying the source of toxicity. But once that source is identified (jerk), and the underlying causes are suggested (underdeveloped social skills), one could elect to help development of the problematic social habits in said jerk; losing the toxic, keeping the superstar. It might also be the case that the kinds of behavior that cause this toxicity source to be identified are reactions to other underlying problems in the jerk or in the organization. If this kind of consideration, adjustment and maintenance isn't carried out as a matter of course, the organization may end up missing opportunity, avoiding necessary repair, or just replacing the jerk with another. For the good of the organization, a toxic environment must be addressed, but in the long view, simply canning the jerk might turn out as effective as ignoring the problem.

Daniel Campbell
profile image
Very interesting read. I agree with everything but some of it's a little too "in a perfect world" for me. More specifically the section on Crunch. Sometimes it's just necessary right? Publisher breathing down your neck, two weeks left to submission, ETC. I'm not exactly an industry vet, but it seems like the time I have spent in the industry always points to crunch being a necessary evil.

Joshua Dallman
profile image
"We have the happiest employees around because EVERYONE here contributes to the design!"



Right, and game design is neither discipline nor practice, but merely coming up with smart answers, which we all know everyone wants to be a part of to score points.



True story: at one previous employer, a new executive producer came in to head the 50 person studio, promptly fired all game designers and made them associate producers (read: paid interns), and declared with gusto, "There's no more game designers in my studio because we're ALL game designers." I left that week. The studio was later dismantled, the EP fired, and the company has since been in long steep decline. Fuckers. Get what they deserve for not respecting our basic discipline and profession. It's this kind of shit that makes talented and hard working designers like myself want to quit the industry forever. Good article, hope it's not merely preaching to the converted.

Mac Senour
profile image
I strongly believe that crunch time = producer fail. No one in his or her right mind makes a schedule that involves working 7 days a week for months. Since the original plan didn't call for that, something had to have changed since project launch. That means the producer let someone in, or him or herself, and didn't account for changes or worse, didn't see the impact.



Mac



P.S. Hey Henrik, I remember you from Mindscape. If Henrik is a vet at 20 years, what am I at 30? Don't say old... :)

Piotr Zygadlo
profile image
I couldn't agree more! Great article!



I have exactly the same observations from my perspective and I love to here that I am not alone :)



Best luck in the future Henrik!



Piotr

Chris Proctor
profile image
"We have the happiest employees around because EVERYONE here contributes to the design!"



Everyone on the team should contribute to the design if you want your team invested in the project.



The key thing is that designers should curate this contribution, and each area of the game must have a single design owner/gatekeeper who decides whether a suggestion is appropriate for the game.



This is not the same as firing the designers, but an approach to design that makes a hell of a lot more sense than the "designer = idea hoses" idea that many people have.


none
 
Comment: