Producerland (part 2 of 3)

Welcome to Producerland - a three part series sharing tips on being a producer and stories from the field.  Producerland defines "10 Rules" for producers and shares stories that cover "easpouse", Unreal, Medal of Honor, Infinity Ward, and many more.  This is the second part of three.

PRODUCERLAND - PART 2 of 3

TO FIND PREVIOUS CHAPTERS:  http://gamasutra.com/blogs/author/MattPowers/951858/

Tallahassee: Have you ever read that book "She's Just Not That Into You"?

RULE:        
Producers should avoid motivating by milestone or checkbook

I often find producers use the power of milestone approval to "motivate" their developer.  But by doing this, the producer just motivates the developer to get the milestone done - per whatever requirements the producer lists.  This does not promote quality of work.  Over time, this creates a relationship where the developer will just do whatever it takes to get approval.  The developer was hired because of their talent.  If we motivate them poorly we waste the talent, get an inferior product, and create an antagonistic relationship between publisher and developer.

As producers we should find ways to motivate our development team that does not always use the milestone or checkbook.  Usually the best way to do this is to appeal to their passion, talent, and ego.

Unreal

When Infogrames purchased GT, one of the opportunities that came with that was working with Epic Games on the Unreal franchise.  I was asked if I wanted to manage the Unreal brand for product development - I was excited about the opportunity.  This meant working with Epic on everything related to Unreal and most importantly, getting Unreal 2 finished. 

Legend Entertainment was the developer of Unreal 2 and was wholly owned by GT (now Infogrames).  They had been working on Unreal 2 for quite a while and had a lot of assets completed but not a lot of game.  The deal with Epic for the Unreal franchise included the fact that Epic owned the IP and everything related to the IP had to be approved by Epic.  This meant that we had to get Epic approval on Unreal 2 before we could ship it.  It's an interesting situation where every day costs the publisher money but the publisher does not have complete control over the final date.

Working with Epic, we were able to bring Unreal Tournament to the PlayStation2 as a launch title and then to Dreamcast when they launched their online system.  At the time there were a lot of questions regarding if a first-person-shooter could work on a console; similar to what people still say/question about RTS games on the console.  Up until this point, all fps games were on the PC - games such as:  Doom, Duke-Nukem, Eradicator, Quake, Unreal, Unreal Tournament.  Because of the mouse and keyboard, the PC was the platform that could support the genre.

NOTE:  mouse support for fps didn't really come along strong until Quake.  I still remember having to add "+mlook" as a console command in Quake to get mouse support.

The Dreamcast supported a mouse and keyboard which both us with Unreal Tournament and Quake supported with our Dreamcast ports.  But the PS2 was a different matter - how would we make sure people could play UT with a gamepad?  We did things like trying to slow the game down and even added a 180 degree turn to the hat press.

At the same time we also had Digital Extremes start work on Unreal Championship.  This would be our Unreal game for the Xbox.  The idea at the time was that fps games could be successful if we tapped into an existing console mindset - sports.  UT already had some of this with the announcer, exclaiming "Awesome!"  And we added more.  We also added powerups such as "shards" for players to run about and pick up.  Trying to find console established gameplays items and "port" them to the fps.

I think what eventually sold console gamers on fps's was Halo.  Mainly because this was a console original and introduced a new audience to first-person shooters.  Prior to that, we were a hardcore PC club; Halo changed all that.

But I digress a bit from the original point - working with Epic I learned that as a producer one must find ways to motivate developers to meet our schedule and budget without having to using the "traditional" methods most producers use.  We could not motivate Epic by money alone - they were primarily interested in the quality of the product.  Epic is very talented and wants to make great games, and wants to make money.  Same goal we all have.  As a team (publisher and developer) we should be able to come to the best decisions for the product without having to always use the money or milestone approval.  Use the stick, use the carrot, work together - as a team we should be able to come to solutions.

Wichita: Let's play the quiet game.

Columbus: I've actually been meaning to ask you, have you been to Columbus, because I've been trying to...

Wichita: Have you never played the quiet game?

SIDENOTE: Scheduling tip

One particular project I was responsible for had a serious amount of talent and dedication on the team.  

Artists, also designers, often are never "done" with their work.  They can be "done enough," but there is always more tweaking and adjusting that can be done.  When putting together the schedule for the team it is important, when possible, to keep this in mind.

It is good to have "cleanup" time in the schedule -  time after the tasks are done where the team members can touchup and adjust whatever assets need it.  This is not necessary so much  to actually fix up assets but to put your team members minds at ease.  When you are working through the middle of the schedule and need to stay on track (or catch up some days), you can point to these "catch-up/cleanup" days later in the schedule.  This can help get your artist to "let go" of his current work now, knowing he/she will have time later to get back to it and "finish it".

I would also try, when possible, to schedule tasks to be complete on a Friday.  I would review the task on the Thursday or Friday and often it would usually be done, or at least "good enough" for me.  And often the team members would want to spend more time on it.  I would tell them, 

"This is good.  We have to move on to the next task.  Monday you start something new.  Now, whatever you want to do between now and Monday is up to you."

I would often see these team members working the weekend to polish up their work.

Columbus: The first rule of Zombieland: Cardio. When the zombie outbreak first hit, the first to go, for obvious reasons... were the fatties.

RULE:        
Get used to not being able to specifically measure your successes or accomplishments

Before I was a producer, I was a programmer as well as a producer.  Then I became a full-time producer.  The first project I was producer on - but not programmer - was a difficult transition.  The code base we were using on this project was one that I helped develop on my previous projects.  I knew how the code worked very well and initially I probably knew better than the lead engineer on the project.  Early in the project I would check out parts of the code myself to make changes or fix issues.  This not only undercut the engineers role but didn't convey any confidence from me to the engineer.  I had to learn to let the people on the team do their job - their way. 

But where this desire to keep coding came from was a initial difficulty in determining what my specific contribution to the team was as a producer.  As an artist, designer, or engineer you can check tasks off each day.  You check art or code into the database.  You have a clear list of accomplishments.  A producer's contribution is not so clear.  And for the producer this can often be unsettling.

This unclear contribution issue I believe can lead to some insecurity in the producer.  And this is often "fixed" by the producer becoming more involved, often - too involved.  The producer will feel they need to make changes. and make sure his/her influence on the project is known and felt.  This is usually not good and can lead to bad management.

The producer must learn that his/her contribution to the project is never going to be easily measured.  The producer is not the engineer, the artist, nor the designer.  In fact, there is hopefully people better at all those roles than the producer on the project.  The producer's job is to ensure everyone else related to the project is able to do their job.

Little Rock: No Twinkies.

Tallahassee: Shit! fuck!

Wichita: See, I told you we should have gone to Russell Crowe's!  No one listens to me!

RULE:        
The Publisher and the Developer need to be a team

Activision and Infinity Ward

One day I received a call from the President at Infinity Ward, who was a friend of mine at the time, who told me that they were looking for a producer on the Activision side and that I should interview.  During the interview process I spoke with both the Infinity Ward group as well as Activision.

Infinity Ward told me that they needed a producer to make sure information flowed between Activision and themselves.  Primarily in regards to sales, marketing, PR, information.  Basically, the publisher-side responsibilities - they wanted in the loop on these and to have some assurance they were being handled.

Activision on the other hand wanted a producer who could keep track of Infinity Ward.  A producer that could make sure Activision know what IW was doing and keep IW on track.

It is important to realize that at this time Activision had just shipped World at War.  And unknown to the public at this time, IW was not planning another World War II game.  The IW group came from 2015 where they created Medal of Honor: Allied Assault.  World War II was a huge and successful business - but IW was tired of it.  IW wanted to make a modern war game.

Today a modern war game seems obvious, but at the time there was a lot of debate if this was a good idea.  Certainly after the successes with Call of Duty in the WWII era one could see Activision's hesitation with switching to the untested modern combat.

I took the job feeling this was a traditional example of publisher and developer just not communicating well.  I knew Infinity Ward and I knew there were an excellent developer.  Activision shouldn't have to worry too much about quality as IW really cared about quality.  And, unique for many developers, IW understood the importance of hitting a ship date and coordinating sales, marketing, and PR for a successful launch.

As many are probably familiar with the history between IW and Activision they will know that unfortunately things did not work out well.  I quickly found out that IW really just wanted to do whatever they wanted and wanted Activision off their back.  Activision on the other hand really wanted to know everything of what IW was doing and wanted to have input and some control.  Basically, we had two groups at almost polar opposites.  

I'm definitely simplifying the situation, but the basic fact was that what Activision wanted, IW wouldn't provide and vice-versa.  And there was no middle ground.  On one hand I looked at it and thought, "IW is a proven, successful developer, just leave them alone and let them make money for Activision."  But on the other hand, "Activision is investing a lot of money and trust into IW.  Activision should have more insight and say in what goes on at the developer."  I was the producer stuck in the middle of two immovable forces.  It was not a rewarding experience for me and I left before the project was completed.

RULE:        
Producer can sometimes also mean babysitter.

The team had a lot of talent on it.  One situation in particular I remember.  A designer and an artist had to work together as the artist would be creating the backgrounds and details of the level the designer was laying out.  But these two people did not get along.  The artist would tell me that the designer usually didn't think things out well enough and that he(the artist) could probably design the levels better himself.  On the other side, the designer would tell me that the artist didn't listen, often argued, and would sometimes change his design.  This clearly was dysfunctional; something needed to be done.

I sat down with the artist and told him:  "You are the experienced one here.  You probably could do the design yourself, but I need your time and skills focused on the great art you do.  The designer is young and needs to learn."  I told the artist that I needed him to help teach the designer.  Sure, he'll make mistakes, but that is part of the learning process.  I asked him to be a mentor, listen to the designer, and try and be understanding of the learning curve he is going through.  I told the artist, "You are the Yoda in this relationship."

Then I sat down with the designer:  "You are the experienced designer in this situation.  Yes, the artist does feel he has design skills, but that will be everyone you meet and talk to on a development team.  Everyone wants to be the designer - but you are the designer.  And you need the buy-in and commitment from people on this team to ensure your design becomes reality.  In this situation, listen to the artist, let him make suggestions.  Let him take some credit.  If he doesn't believe in the design then you won't get his best work.  In the end, it is your design, but if you allow the artist and the rest of the team to feel they have contributed. then you will get better work from them."  I told the designer, "You are the Yoda in this relationship."

NEXT:  PRODUCERLAND PART 3 of 3