[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."

Get Beyond "Suits vs. Geeks"

In my first job in the industry, our office was on two floors: the entire development staff was on the first floor and all other departments (accounting, marketing, executive, etc.) were on the second floor. The physical office layout alone led to a downstairs (geeks) vs. upstairs (suits) mentality that was difficult to overcome and counterproductive to the entire company. Geeks vs. Suits is an antiquated notion that the industry has to leave behind in order to grow.

It's understandable that the goals of the development, marketing, and sales departments are not always properly aligned, but that's a failure in the organizational structure rather than a stereotypical difference in the individuals within those departments.

While it's imperative that sales and marketing understand the challenges faced by the development team, it's equally important for the development team to understand the financial and marketing challenges in the industry. Chances of a project being successful are greatly increased when these three departments work in concert.

So how can we bring these entities closer? Involve all departments (development, sales, marketing, etc.) in weekly or bi-weekly status updates from the start of the project.

Make sure the sales and marketing representatives understand the prime essence of the game directly from the folks that are making the game, but also make sure the development team understands the difficulties in marketing and selling into an ultra competitive landscape.

It goes without saying that the amount of time spent by different departments on a singular project is never going to be equal: the development team will likely spend two or more years on the project while for marketing and sales the project is one among many.

This fact is generally the primary cause for the geek / suit balkanization, so take time to educate the team and foster good communication throughout the life of the project.

This will build trust and enable each department to get a far better grasp on the overall essence and positioning of the game and the challenges facing the project on the whole. That company-wide understanding will be an incredibly valuable asset.

Alter Project Management Approach through the Life of a Project

To Scrum or not to Scrum, that is the question. Or is it? Agile versus Waterfall has provided for numerous entertaining discussions about the virtues and merits of one approach versus the other approach.

The real answer for game development is that both methodologies are applicable and therefore should be used on the same project -- they just need to be used at different times in the project lifespan. In pre-production, where numerous ideas are tried and re-tried there is no solution to the management approach other than Agile.

However, as a project moves into full production the management dial has to slowly turn from agile to Waterfall. Whereas Agile is well-suited for the rapid prototyping phase, waterfall is equally important to the end phase of the production cycle where completing the project is of paramount importance.

Team Harmony

How exactly do we define "harmony" for a development team? For that matter, let's take a step back and ask if harmony is even a good thing to have within a game development team.

I've occasionally heard the argument from people in the industry that a little bit of discomfort is desired in order to keep everyone sharp and focused. From my perspective that's a completely flawed management position. For one thing, it's difficult to dial a certain level of discomfort, and more critically, it's impossible to fully realize the impact of that discomfort on the different personalities within the team.

So while the intent may simply be to push the team on the current project, the results are often counter to the long-term goal of establishing a cohesive team -- one that's capable of executing complex game projects on an ongoing basis.

Team harmony is an essential component of making a successful game, and should be managed with the same intensity as, for example, the milestone deliveries.

So, let's get back to the initial question of how to define harmony in a team. It's not about everyone on the team getting along, it's actually about everyone on the team being a professional -- and understanding what it entails to be a professional.

Being a professional has nothing to do with the number of years one has spent in the industry. Instead it has everything to do with understanding the structure of the team, where individuals fit within that team, what is expected of their role and putting the good of the team ahead of any personal agendas.

It's critical for project managers to continually review the makeup of their team to ensure that they are performing as expected -- this is different from determining whether the game at hand is good or bad -- it's about whether the team is structured in such a way to maximize success.

A natural extension of this discussion is contemplating adjustments to the personnel upon identifying problems. This is a thorny issue and there are no simple answers, but a hard learned lesson from my perspective is to not sacrifice long-term team harmony for short-term production returns.

Crunch Time

If you've worked for any appreciable length of time in the game industry then you're sure to have some tales of late nights, seven-day work weeks and endless death marches. Some in the industry even wear it as a badge of honor -- swapping stories reminiscent of the famous scene in Jaws when the shark hunters discuss their scars to see who has the most impressive one.

There is a popular notion that if you make games for a living, then the long hours just come with the territory. I personally find this type of assessment to be insulting to the craft. It trivializes the work by equating game development with playing games. Making games can be a fun and rewarding experience, but that doesn't mean that it's simple or easy.

Crunching can be effective, but only in short (two to three days) targeted bursts. The effect is quickly lost if the bursts are too frequent, or in the absolute worse case if the target is moving! As a project manager, the history of the industry will sway you towards imposing crunch time, but you should fight against that as it's been shown time and time again that crunching does more harm than good.

Treat your team as professionals and create a setting that provides a consistent work-life balance. The team members will appreciate it, work more efficiently, and most importantly stay onboard for the next (and the next) project.

Ultimately it's a simple question for your team: do you consider their work to be an assembly line series of tasks or a creative endeavor requiring a healthy combination of left- and right-brain utilization? I believe it's the latter which leads me to conclude that crunching does little to advance the creative push of a project.