Developers in the Mist

Video game producer and junior anthropologist Matt Powers takes us with him on his travels through the jungles of video game production in search of the elusive game developer.  Inspired by the efforts of great producers before him, Mr. Powers brings us along on a journey of discovery and adventure, and along the way quenches our thirst for knowledge.  Producers learn what to look for on the search for a developer and the developer learns how the producers hunt.

Introduction

Picking the right developer for a project is critical.  And certainly from the developer side, getting the project you want/need from the publisher is important.

An important early step in the development process is the developer visit.  This is when representatives from the publisher go to the developers' offices to check everything out and have a face-to-face.  This should be a requirement for any medium to large size project.  At minimum, the producer from the publisher would be visiting the developer, usually accompanied by a technical director (and maybe more).

To make the most of this first meeting it is important for both developer and publisher to be prepared.  Hopefully I can help you prepare.

Developer Visits

I have had some good first developer visits and some not so good.  Here are just a couple examples of some developer visits that were, let's say, memorable.

NOTE:  these stories are completely true but some details (notably names) have been omitted.

The Missing Development Team

I arrived at the developer's office and I was met in the lobby.   it was immediately obvious they had very nice offices. One would expect this from a developer that recently released one of the best selling games.  And that is why I was there - I wanted to see what the team that made that game was currently working on.  Perhaps there was other talent we could work with.  Maybe we could get them to make a game for us.

I was given a great tour and the developer was very keen to sign a project with us.  But they were a bit vague on what they were currently working on.   There were people, and they all looked busy.  But there were a couple odd bits I noticed: 

Turns out, the team I was looking for had left the company recently and were starting their own shop.  I actually knew this going in but was interested in seeing what remained of the developer that shipped a hit game.  And, curious if the developer would give me the honest pitch of their current situation.

The Strip Club

I was looking for a developer for a project.  The developer visit I was currently on looked promising - they had a good size and great track record.

I got off the plane after a long flight and received a call from the developers.  They thought it would be nice for us to meet up for dinner that night.  That wasn't firm prior to the flight - I usually like to get my rest before the studio visit and avoid too much socializing until we get a little business done.  Since I was hungry,  I agreed to dinner.  The developer gave me an address; I got my rental car and took off.

Turns out, the dinner was at a strip club.  Nothing like the first visit with a developer being steaks and stripers.

The next day I visited the studio.  They ushered me into a conference room.  The meeting was not terribly long.  I couldn't meet the team, the leads, or see what the company was working on.  But, they assured me they could do the project.  They were confident that they had the right people and could easily hire more talent as needed.

I did not choose to work with either of these developers.

Developer Visit Checklist

Here is a checklist I put together for a developer visit.  I recommend those of you working at a publisher integrate this into your processes.  Those of you on the developer side - be aware - this is what the publisher should be asking and looking for.

DUE DILIGENCE CHECKLIST

The Team

Project Particulars

The Company

Development Processes

Finances

Technology

END CHECKLIST

Getting the Answers

One item I do not cover in detail in this article is methods of gathering the above information.  While the checklist is straightforward, getting the answers can be tricky.  One can often expect a developer to provide answers that suits them - if they want the project they may say anything to get it.  The publisher can't always be straightforward.

EXAMPLES:

Situation:  As a publisher you like the developer but don't want them taking on too many projects and overreach themselves.  Let's say you feel this developer is probably best as a two project company.  Having a second project can be good - then you (as publisher) could potentially get some team members from the other project onto your team when needed.  But if the developer tried to go for three teams that might be risky.  How do you find out if the developer would go to three teams?

Resolution:  The developer currently has one project in development.  I tell the developer I really like them and I would like to sign two projects with them.  Maybe not all at once but maybe one now and another in a couple months.  Then they could grow the company and have three teams.  I dangle the carrot, see if they bite.

Situation:  Important for me to know who is going to be on my team and what their skill set is.  The developer may be just telling me they are putting the best people on the project.  And they may be just telling me they have people available now.  How do I know for sure?

Resolution:  Doing a studio walk around is very important to me as a publisher producer.  During this walk around I will stop and talk to the people at their desks. 

"What are you working on there?"

"That looks really good.  I've not an artist/designer/engineer myself - how does that actually work?"

"Looks like you specialize in animation - did you do all the animation on [insert project name]?"

"Must keep you really busy with all the animations you have now."

"How many animators do you have here?"  "Are you the lead?"

It is very likely the team on the floor has not been trained in guile or what to say to the visiting publisher.  They will probably answer honestly and you can learn a lot.

There are many methods such as the above;  if you would like more, that will have to be another article. In the end, I recommend both publisher and developer try to be as honest as possible.  Not all projects are a good match and finding that out sooner rather than later is always a good thing.

In Conclusion

By no means is the checklist I provide complete.  Nor does it necessarily work for all situations.  But hopefully it gives you a good outline.  I recommend publishers have something similar to this.  I recommend developers be prepared for publishers to examine and ask all the above.

And most important,  know what answers to these questions will work best for your particular situation.  You need to know the questions, get the honest answers, determine what areas can be flexible, and what fits into your current project needs.  The developer<>publisher relationship is critical; finding the right partner is difficult, but the more homework you do initially can save you a lot of headache later.

Do you have some additions to the checklist?  Any interesting developer/publisher visits you would like to share?

ABOUT THE AUTHOR

Matt Powers has been making video games for over 20 years.  Matt has worked with a lot of developers, and looks forward to working with many more.