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.
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.
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:
- Walking around, about half the desks were empty.
- The desks that had people didn't look like they were actually working - more like displaying "stuff" on their screens.
- There weren't any team leads with whom I could meet.
- The key people from the successful project (producer, technical lead, etc...) were not in the office at the moment. NOTE: I got the names of the people that were on the team from the credits of the shipped game.
- Other clues seemed to point to the fact that the talent had left the building.
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.
- Count heads - do they have the people they report? Are there desks enough for the people needed on the project?
- Meet the team members - especially leads. Find out who would be assigned to the project.
- What games has this team done before? What does this team have experience doing? What are they good at?
- What would the developer consider their teams specialty?
- Is the project you are considering with them something they have done before? Something similar?
- Availability to attend shows/conventions? Always nice to have members of the development team at E3.
- Walk around, talk to people, get a general feel of the atmosphere.
- Could the company add additional resources to the project easily/quickly if necessary?
- How many new people would the developer need to hire for this project?
- Are all the leads/director's in place?
- Does the company have some art they can show that matches the style for the project?
- Have they worked with the licensor before?
- Discuss design methodology. What is their design process? Level maps? Layout tools? etc...
- Defining GDD, ADD, and TDD. How does the developer define these? Any examples from previous projects you might be able to look at?
- Who has the company done business with in the past?
- What does the company leadership think of their previous games? Where did they succeed and where did they fail?
- What were some of the areas in previous development projects that went really well? Went poorly?
- What does the development company look for in a good publishing partner?
- Did they learn any valuable lessons from their last project? Did they change any processes after this project?
- Any internal QA?
- Do they have more than one team? How many teams do they have? How many teams would they like to have?
- What is the developers goal for number of projects they would like at one time?
- What is the management structure? Who reports to whom?
- What intellectual property does the developer own?
- Any lawsuits pending against the company?
- Does the developer have the office space to support this project (and whatever other project they may have or be considering)?
- Company holidays - (basically, do they have any holidays that are different than yours).
- If currently working on another project - roughly when is the Alpha date?
- How would they manage hitting Alpha on two projects in the same month?
- What is the company policy/theory regarding crunch?
- File control system?
- Computer/data backup system?
- How do they manage tasks? (Jira? for example)
- What is their production methodology?
- How will they track the publisher change requests?
- Milestone release form(s)?
- Team meetings? Weekly meetings with publisher?
- Overall, internal and external communication methods and preferences.
- How do they propose to do all the CG / cut-scenes?
- Any experience with outsourcing art?
- What is their definition of Alpha and Beta?
- Review goals of pre-production and production. Make sure everyone is on the same page with the big deliverables and production methodology.
- Ask what they would do if something occurs and they get behind schedule? What would be some of the methods they would take to get back/keep on schedule?
- Are they hand to mouth?
- What is their burn rate and overhead?
- Do they have other projects (with other publishers) in development?
- Any debts to be aware of?
- Does the city/county/state provide any tax breaks to companies such as this?
- If the other project, with the other publisher, was cancelled how would that affect the company?
- Can the developer get a loan if needed to cover any lean times?
- What is their build system and build process?
- Do they have the development systems/kits required or do they need more?
- Do they have all the equipment necessary currently for this project?
- Mastering system?
- Render farm?
- Motion capture experience?
- Tech - licensed tech or internal tech. What engines have they used in the past?
- What is their preferred 3D modeling software? Animation package?
- Physics engine?
- What tools/tech do they own? What do they license?
- What is their network connection and speed?
- How would builds be transferred to the publisher/licensor?
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.
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.
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.