Learning the production secrets of Return to Monkey Island

In her GDC talk, Terrible Toybox lead producer Jenn Sandercock revealed a treasure trove of secrets (and generally great production advice) for the creation of last year's Return to Monkey Island.

Keeping secrets secret

The team was keen to keep the project largely a secret until its (excellent) April Fool's Day announcement. This went off without a hitch thanks to the use of "code" names and clear rules about what was under wraps and what was not!

"We kept some of our team members secret," said Sandercock. "So people were able to say 'I'm working with Ron Gilbert on his next adventure game.' But they couldn't say they were also working with Dave Grossman. If people had known that Ron and Dave were working together, they'd probably put two and two together to jump to some conclusions."

She made sure that extended to things like meeting names and calendar invitations too.

"We made sure invitations didn't have any sort of secrets in them. So we wouldn't have a meeting about 'Guybrush' animation. We have a meeting about the main characters," she said. "We had a policy of 'no searching any niche fan websites when you are logged in.' You needed to have a workspace that has a door [in real life] and [we] shared a document that would show what was and wasn't secret so that people knew what they could promote to their friends."

The long view on scheduling

Sandercock organized the production calendar in a modular way: with two week sprints, two of which would equal a "stage," and every three stages would equal a milestone. Each of those basically represented an entire pass of the game: with rough early assets, more polished "beta" art and animation, and then the near-final and final versions. Because the team was not prototyping a ton of new gameplay systems, they could focus on this particular flow, such that the entire game was playable very quickly.

"We started with a gray box or thumbnail version of the entire game that was fully playable just three months after we started pre-production. We then worked to improve all of our art and animation. And we repeated this as many times as we could: we were able to do this about three times."

She used a slide with early, beta, and final art to prove the point.

Onboarding and ongoing work practices

Sandercock set up a "buddy" system for new employees, and had a whole system of day one, week one, and month one tasks ready for them, to cut down on the chaos and confusion of starting a new job. This was crucial for welcoming a new person into a very creative atmosphere, able do their best work.

"We gave people installation instructions on how they could start playing the game so we could get some fresh eyes on the game, which was very unique for us. We had links to information in notion about like, the overall vision of the project. And we're also going down to the details of what somebody needed to know for this specific discipline."

"Such as: where's the archive [of instructions and resources] and how do you make animation, and of course we make sure to update it when new people started, so they're always getting the most up to date information."

"We gave people a 'working buddy:' so that was a volunteer who had worked with the company for at least two months already. That person was a friendly face to the newbie, to answer questions. They'd also organize a one on one with the new person for the first week."

Sandercock noted that the "buddies" didn't need to be in the same discipline, it was just useful to have a peer resource for new folks.

Sandercock also encouraged producers to respect people's working hours, and implement a "check out" system, for folks to list their finished tasks at the end of the day. She stressed the importance of not encouraging people to work after hours to avoid burnout, and to practice what you preach as a team lead: to commit to reasonable working hours.

Meeting notes

Sandercock's advice on running efficient, useful meetings could be a talk in itself (or an entire course!), but she broke down her meeting wisdom into a few broad points: keep them focused, take notes (ideally, the person running the meeting isn't the note-taker, but you do your best), and keep them limited to who needs to be there: you can stagger teams in such a way that one group can leave early after their section, etc.

Sprint meetings, in particular, took on a particular importance to structure properly:

"We made sure in our sprint meetings [that] we had six or less people in a meeting, [and made] sure it was just people within the same discipline," she said. "If we had more than that, the meeting would go for a lot longer and a bunch of people would be listening to work which wasn't very relevant to them. We made sure we would ask retrospective questions ahead of time so that people have time to stop and think about what was going on for them. Or big questions. [We asked] 'what went well?' 'what could have gone better?"

One bit of advice I personally loved (and might steal for our own tasks here at Game Developer) was the system of estimating task person-hours. The team used t-shirt sizes, from extra small all the way to multiple XL (and with cute animal emoji). Team members could give a very clear estimate based on this colorful criteria, and, naturally, adjustments could be made from there as needed.